Naming context lookup gives different results depending on physical location of gf-client.jar #6338
Comments
Blavo
added
Status: Open
|
Greetings @Blavo, I'm afraid that the encountered issue is the expected behaviour of the server runtime: The If you wish more flexibility to create a client applications that is not tied to the standard location of the file in the server's installation you can either:
Since this issue is not caused by a bug/defect in the platform, we'll proceed to close it. |
fturizo
removed
the
Status: Open
|
G’day,
Fair enough.
But if correct operation of gf-client.jar depends on it being in its default location, should it not issue an error if it is not in that location, rather than give unexpected results ?
Of your (appreciated) suggestions the only one that is applicable to my circumstances is to use payara-embedded-all (which is what I was doing). I switched to gf-client.jar because there are cases where it works and payara-embedded-all does not work. See #6214.
… On 10 Aug 2023, at 07:11, Fabio Turizo ***@***.***> wrote:
Greetings @Blavo <https://github.com/Blavo>,
I'm afraid that the encountered issue is the expected behaviour of the server runtime: The gf-client.jar artifact is meant to be used by applications as a sort of "proxy" to all of the artifacts and modules included in the server's installation and it is imperative that the file remains in its default location so that client applications work properly when depending on it.
If you wish more flexibility to create a client applications that is not tied to the standard location of the file in the server's installation you can either:
Use a symlink to point the application's to the location of the gf-client and update it accordingly in case of changes (like using a different installation for a new version).
Use the payara-embedded-all artifact dependency to create your client application and make it a self-contained application.
Use the appclient script utility instead and run the application in the Appclient container.
Since this issue is not caused by a bug/defect in the platform, we'll proceed to close it.
—
Reply to this email directly, view it on GitHub <#6338 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOKL4EMAI5OH6QZ3OONSYN3XUP4JPANCNFSM6AAAAAA2LEJ7XE>.
You are receiving this because you were mentioned.
|
|
I would say stay with gf-client (or app client container) which are pretty much equivalent. |
Brief Summary
If I do a naming context lookup() using the gf-client.jar in the payara 6 install (ie the one at /glassfish/lib/gf-client.jar) in my class path the lookup works.
If I copy that jar to a some other location (such as my desktop, or some other location) and change the class path to use the jar copy the same lookup fails.
If I revert the class path to use the instance of the jar in the payara 6 install, the lookup works.
Yeah, I know - this sounds pretty unlikely. But I've tried it sufficient times to be satisfied that this really is true. Bizarra. But true.
Expected Outcome
The lookup should work regardless of the location of the jar.
Current Outcome
The lookup succeeds or fails depending on the location of the gf-client jar.
Using the instance of the jar in the payara 6 install gives a successful lookup.
Using a copy of that jar on my desktop gives:
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or in an application resource file: java.naming.factory.initial
at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:704)
at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
at java.naming/javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:342)
at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
at testrepeatedlookups.TestRepeatedLookups.main(Unknown Source)
This is quite reproducible. I can toggle between the two instances of the jar and reliably get successes with the jar in the glassfish install and failures with the jar on my desktop (or somewhere else, the actual location doesn't seem to matter).
Reproducer
Change the lookup string in the attached reproducer to match the portable JNDI name of a resource (bean) in a convenient running payara 6 instance on the same machine. (Or not - you will get different results depending on the location of gf-client.jar, but its more satisfying if one works and the other doesn't; but to get one run to work you have to lookup() a real resource.)
Change the class path of the reproducer to point to gf-client.jar in the payara 6 install on your machine. The only JARs required are an instance of gf-client.jar and maybe a JAR that contains the classes used by the lookup item.
Compile and run the reproducer. Should work.
Copy that exact same gf-client.jar somewhere else (such as the desktop).
Change the class path of the reproducer to use the copy.
Clean compile and run the reproducer. Should now fail as described.
Optional:
Change the class path back to the instance of gf-client in the payara 6 install.
Compile and run the reproducer. Should resume working.
Reproducer.txt
The bypass is easy (at least if you are running the lookup on the same machine as the payara install) - just use the instance of the gf-client.jar in the install in the class path.
Might be a bit more challenging if you aren't on that machine since you will presumably need to use a copy. I haven't tried that.
Operating System
Mac OS 12.4 (Monterey)
JDK Version
java version "17.0.7" 2023-04-18 LTS Java(TM) SE Runtime Environment (build 17.0.7+8-LTS-224) Java HotSpot(TM) 64-Bit Server VM (build 17.0.7+8-LTS-224, mixed mode, sharing)
Payara Distribution
Payara Server Full Profile
The text was updated successfully, but these errors were encountered: