Blavo
commented
1 year ago G'day,
Issue #24541 was that a context lookup() from an embedded glassfish app failed on a reference to method removed at Java 9. The fix to #24541 was a new glassfish-embedded-all.jar. I expected that with the fix in place that issue would revert to this one ie that issue was masking this one (whose reproducer has a bypass for the issue in the class path). That didn't happen - the lookup() actually worked with the fix in place. That led me to wonder if the fix fixed this issue as well.
So I applied the fix to #24541 to my copy of the reproducer for this issue by substituting the supplied glassfish-embedded-all.jar for glassfish-embedded-all-7.0.6.jar and removing pfl-basic-4.1.2 from the class path. The change had no effect.
There is one obvious difference between #24541 and this issue. In the former we use a short cut - we do the lookup() from a normal Java application with an embedded-all JAR in the class path. In the past that has been reliable in reproducing errors that occur in embedded glassfish apps and simplifies the reproducer. In the reproducer for this issue we don't use the short cut - we actually deploy a very simple app to an embedded glassfish.
github-actions[bot]
avpinchuk
If I deploy a very simple web app to an embedded glassfish based on glassfish-embedded-all-7.0.6.jar, and that app does a context lookup() to lookup, say, a remote EJB, the lookup will fail with a javax.naming.NamingException saying that the name is not found; this assumes that the bypass in #24541 has been applied to the calling app (otherwise the error in #24541 will occur)
Environment Details
Glassfish 7.0.6 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) Mac OS 12.4 Monterey Database not applicable
Problem Description
So, I have a stand alone (non-enterprise client) app. I run the app with the bypass for #24541 in place. The app does a context lookup() against some running glassfish server. This works. The app then starts glassfish embedded and deploys a very simple web app to the embedded glassfish. (Currently that app can't have any EJBs, or it won't deploy - see #24521). The app does exactly the same context lookup(). The lookup() fails saying the name isn't found. Since the lookup() already worked outside embedded glassfish it should work from within embedded glassfish.
The problem is reliably reproducible.
Steps to reproduce
1 Start a convenient glassfish that has a remote EJB for which the class definition is available in a JAR 2 Obtain the JNDI name for the remote reference to the chosen EJB from the glassfish log 3 Put that JNDI name as the value of 'lookupString' in the attached LookerUpper source 4 Compile LookerUpper as a class library 5 Compile the attached WebApp as a web application with the EJB JAR and the LookerUpper JAR in the compile class path 6 Obtain the path to the .war file produced in the above step 7 Change the value of 'warPath' in the attached TestRepeatedEmbeddedLookups source to the path from above 8 Copy the domain.xml file from the above glassfish somewhere convenient 9 Change the following ports in the copied domain XML file to avoid clashes with the running glassfish:
For extra credit
This issue probably masks another (as it was masked by #24541) - see Payara/payara #6299. Rather than wait for the solution for this one to be delivered before testing the potentially masked issue I mention it here so the two can be resolved at the same time.
To provided a test of the masked issue the reproducer for this one does 50 lookup()s , not just the one that would be enough to demonstrate the issue raised here,
The masked issue is that after 'sufficient' lookup() calls being received from the one client a server will switch to a faster, but less debuggable, implementation of the lookup. In the payara issue this 2nd implementation reliably fails with a ClassCastException. So, if after resolving the issue raised here, you find that some, but not all, of the lookup()s done by the web app succeed with the remainder failing with a ClassCastException, then you have demonstrated the masked issue (and you have a reproducer).
Impact of Issue
I intend to offer two alternate configurations of my project to my intended customers - one that runs as a remote client of a non-embedded server and (the preferred one) that runs as a client of an embedded server. I can continue development using the former but at some stage I will need a fix to this before I can resume QA of, and ship, the latter.
LookerUpper.txt StackTrace.txt WebApp.txt TestRepeatedEmbeddedLookups.txt