Improve information presented for jndi lookup failures #25190
Comments
|
Note this line below:
App client container side output inclues: |
|
server.log contents are below: |
|
Paste of conversation from Jakarta EE TCK Slack channel https://eclipsefoundationhq.slack.com/archives/C0131MLD538/p1729612177243759:
|
|
Would be good to understand more about the The glassfish8/glassfish/modules/glassfish-corba-orb.jar contains the org/glassfish/jndi/cosnaming/CNCtxFactory.class so either that is not on the classpath or another class that is needed isn't. |
|
We are using a ts.jte from EE 10. If there are any dependency changes in GlassFish 8 we may be setting the classpath incorrectly in the ts.jte file. |
|
Note that the In attached server.log, I see:
|
|
A subset of output from GlassFish server.log for the test deployment:
A subset of console output (from maven/app client container):
Note that the jndi dump is via custom code that we could merge: |
|
The current main must be missing some updates as I had to make a few changes just to get to the point of seeing the naming exception. I has pushed the changes to an appclient-jndi branch of https://github.com/jakartaee/platform-tck.git. This is the current exception output: It looks like the appclient env is being linked to the Stateless3VehicleBean, but the resolution of the bound object factory for the ejb-ref somehow ends up trying to lookup "#com.sun.ts.tests.common.vehicle.stateless3.Stateless3VehicleIF", which is not a correct server side binding. The application-client.xml in the test artifact is: and the sun-ejb-jar.xml file (which the glassfish docs says it supports) is: If I can the ejb-name in this file, the deployment fails with an exception of: so the current test artifact deployment that succeeds is finding a match for the appclient ejb-link. The bound object factory is just failing to resolve the remote lookup at runtime for some reason. I'll double check the EE 10 deployment artifact to see if there is some other descriptor missing. |
|
So the ee10 dist has essentially the same application-client.xml: and a sun-ejb-jar.xml file of: So the jndi-name is different, but still not one that matches the server.log jndi entries. The server side jndi name really should not matter since this is being matched via the ejb-link from the client, but there is something wrong with the resulting binding. I'll see if I can find where the client side jndi environment is created on the server when resolving the ejb-link. |
|
I have created a simple reproducer that shows the problem. The appclient has an entry in the java:comp/env/ejb/StatelessVehicleBean location, but the EjbReferenceProxy value bound there ends up attempting to lookup an invalid jndi name. To run the reproducer: Clone the https://github.com/jakartaee/platform-tck.git This produces a verbose appclient container log at glassfish-runner/jpa-platform-tck/target/appclient-0.log |
I don't see such branch, but I can see your branch Expectation: having built glassfish 8.0.0-SNAPSHOT and having the clone of the jakartaee-tck repo. ... and the same result with the default glassfish version 8.0.0-JDK17-M7 |
|
The appclient-jndi branch is in the main platform-tck repo. I just tried a clean checkout and test run: |
|
Oh, I forgot there are two repositories, thanks! Now I reproduced it. |
|
Hello @dmatej , thanks so much for giving your time to this. We all greatly appreciate it. |
|
@scottmarlow I have enabled full glassfish logging (remove all logger in GlassFish's logging.properties and set just I added the lookup-name: Then the test passed: I pushed it to the branch. Is it what you needed, or you need something more? |
|
The problem with that is that this is a common vehicle ejb and the test artifact changes across tests. If the lookup-name is required, every test needs to have a local copy of the application-client.xml descriptor or reset the lookup-name value. This was not required in EE10, so why isn't the ejb-link sufficient to establish the jndi binding in the client env? We can certainly use this as a workaround for now. |
Is there a likely deployment descriptor problem or class not found exception that is responsible for the following? Could we include the cause exception or at least log it?
Exception call stack from EE 11 Persistence TCK testing:
The text was updated successfully, but these errors were encountered: