Tim Holloway

Well, if your login page pulls in a CSS URL named something like "/css/prettyPage.css" and it's not in the web ignoring requestmatchers, then you'll be sent to login in order for your login page to be able to display, which will try to pull in "/css/prettyPage.css" which will need a login, which will try to pull in "/css/prettyPage.css", ...

I believe you're using the built in login pages, so that sort of thing shouldn't happen, but user-designed login pages can easily fall into that trap.

Here my security config, although I don't know how much help it will be. The login pages are custom JavaServer Faces pages.
@Bean SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http.csrf(AbstractHttpConfigurer::disable) .cors(AbstractHttpConfigurer::disable) .formLogin(login -> login.loginPage("/login.jsf") .permitAll() .failureUrl("/login.jsf?error=true")) .logout(logout -> logout .logoutSuccessUrl("/login.jsf")) .httpBasic(Customizer.withDefaults()) .authorizeHttpRequests((authorize) -> authorize .anyRequest().authenticated()); return http.build(); }

And to avoid the circularity problem I just mentioned, my CSS and JSF URLs are unrestricted:
   /**     * Replaces old antMatchers for determining secured URLs.     * @return customizer     */    @Bean    public WebSecurityCustomizer webSecurityCustomizer() {        return (web) -> web.ignoring().requestMatchers(         "/jakarta.faces.resource/**", "/", "/index.html", // "/login", // "/login.jsf", // Leave them for the authenticator! // "/login.xhtml", "/main.jsf", "/main.xhtml", "/img/**", "/error/**", "/RES_NOT_FOUND", "/recipeDetails.jsf", "/recipeDetails.xhtml", "/shoppingList.jsf", "/recipePrint.jsf");    } }

Most likely, you've set up a chicken-and-egg situation where you can't login until you're already logged in.

This can happen if you haven't designated your login page as "no security" AND your login page isn't pulling in any secured JavaScript, images, CSS or whatever. In other words, both the login form page and any URLs it references much be designated as not being secured.

I think you might find that difficult. C and Python managed to become OOP, but only modifying the core language (C++ and Python's hacked "class" support).

You could kind of fake it by storing related data in a data structure, but that doesn't allow for member functions, so the best you could do would be to set up a standard function naming convention that includes the "object" "class" as part of the procedure name. The original C++ was a pre-processor that converted C++ to C and it did something similar, although the C++ front-end managed the actual OOP functionality.

If your primary concern for going OOP would be to aid in expandability and maintainability, though, sticking with a dead language and pretending OOP is a lot of work for a dead end. Keep the VBA as long as you can, use something that's actually OOP for new stuff.

Very good. But that's a solution that's useless unless the developer is using Eclipse. The process will be different for IntelliJ, NetBeans and so forth.

On the other hand, Maven doesn't care which IDE you're using, and Eclipse can run Maven to build its projects. Or you can do Maven builds without any IDE at all.

The getproperties method looks in the current Thread's classpath. Thus, to load a properties file named "jdbc.properties", you simply need to have it in your application classpath, as defined via the "classpath" option on the execution command line and have it in the root of that classpath (since you didn't qualify it with a package name).

If you build an executable JAR, then it would then be in the root "directory" of that JAR. Maven would automatically copy it there if your project contained a /src/main/resources/jdbc.properties file,

Does VBA even work anymore? VB itself has been dead for half an æon.

VB.Net may actually have some OOP support, since it's based on the same language environment as C#.net. But I haven't programmed for Windows since, well VB days.

Welcome to the Ranch!

It's dagngerous to assume what the current directory or even the current logged Windows drive is in Java. Other parts of the system might alter it without warning. Always use an
absolute path.

Mike, I believe "J8" is an IBM JVM. I've worked with J9, so the main puzzlement is whether that's a really old JVM or they just numbered arbitrarily.

I'm not familiar with specifics here, but there are a couple of things I'd look at.

First, if you are trying to resolve a resource via JNDI from another (remote) WildFly instance, a general rule is that the default JNDI server that your webapp would see is usually only listening on the localhost connection. That is, unless you have specifically configured WildFly, you can't get at its JNDI server from outside that particular instance of WildFly.

Now if you have managed to get to what you think looks like a JNDI lookup for what I think you hope is an IMS connection object, you're probably not getting what you think. First, because class instance objects cannot simply transfer from one machine to another without having a serialization/deserialization mechanism that JNDI alone cannot provide. Secondly, because even if you did, it would probably come across damaged.

For an application in one JVM to use resources inside another JVM, you need Remote Method Invocation (RMI). RMI does not transfer function objects, it simply provides a standard interfacing system so that a client can invoke methods on a server using a skeleton/stub framework. RMI doesn't go through most Open Internet firewalls, and it can fail if client and server are running different JVM versions, as the serial data format is neither published nor standard.

Even if you did manage to transfer a serialized clone of your IMS connection, it wouldn't work. Consider JDBC Connections. They are not concrete classes, they are interfaces. The actual object implementing that Interface includes a network socket pair that allows the Connection to talk to the JDBC database server. Network sockets are OS objects, not Java objects (though Java may wrap them). OS objects are not serializable at all. You cannot even store a JDBC Connection in an HTTPSession for that reason.

So what I think you really want is some central reference such that each IMS client app can construct their own without you having to manually define them for each app instance, While JNDI could technically keep such data, as I said, JNDI isn't usually sharable. However, you may be able to do what you want by storing the construction parameters in an LDAP/Active Directory instance, a JDBC database or even a web service from a common configuration server.

Possibly the android.media.MediaRecorder class. Supposedly it dates back to Android 1.

Also, Java RMI is not commonly used anymore. You are probably better served by a Web Services server, such as a Spring Boot app.

Note that Hibernate "Sessions" are artefacts of legacy Hibernate. I strongly discourage legacy Hibernate, especially with Spring. Use Spring JPA with a Hibernate backend.

Again, JPA (including Hibernate JPA) does not use "sessions". They use EntityManagers.

I haven't worked much with Axis2. It's a lot different from Axis. Buth I'm fairly sure that neither framework provides any security services. I think they leave it up to the container and/or appliation logic.

Piet Souris wrote:I read 6 F's! But my brain is male, since I read the text twice, to eliminate any chance of error.

I scanned left-to-right, line-by line 4 times and blew it all 4 times!

Welcome to the Ranch, Robin!

þe problem wið þe English Language is that our attempts to achieve a properly phonetic spelling keep getting ruined by influx of words from other languages and chronological mutations. I mean, who pronounces the "u" in "colour" in the last few centuries? And just as we we figuring out how to use "i" and "j", and "u" and "v", þey stole 2 of our most important letters just because the English couldn't be arsed to create their own movable type!

But how many people actually pronounce "standarised" as "standardized", despite the way þey spell it?

Anyway, I fell for it, too. I þought I was scanning letter-by-letter, but obviously þat was a mere conceit on my part.

(þis message was brought to you by Þe Committee to Bring Back þe "Þorn").

OK, we're playing Forum Ping-Pong here!

I was thinking that we had an actual SOAP forum, but I can't find it in the list and anyway, as I said, OAUTH is for securing the entire webapp and not just SOAP services.

I've added this thread to "Web Services", although I think that SOAP isn't considered as a proper "web service" as it would have been back in its heyday.

Interestingly, we also seem to lack a forum for general webapp questions. Instead we have a smattering of forums relating to particular components of webapps such as JSPs, servlets, and so forth.

Note that if you use a container-managed security system then part of your job would include configuring the container itself, so if I knew whether you're working with Tomcat, Wildfly, WebLogic, or whatever, I could also link this thread there.