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. |
|
I was thinking about it, but I did not have time yet to take a look how it is done in old tests.I think it should be possible to use also some custom annotation, lookup name can be specified on the stateless bean too if I remember well - we used that years ago on one project to run tests on embedded glassfish 3 for application developed for SGES2 (JEE5 = global jndi names were not standardized, so we had to force SGES to use standards defined by JEE6). public @interface EJB {
...
/**
* The product specific name of the enterprise bean component to which this enterprise bean reference should be mapped.
* This mapped name is often a global JNDI name, but may be a name of any form.
* <p>
* Application servers are not required to support any particular form or type of mapped name, nor the ability to use
* mapped names. The mapped name is product-dependent and often installation-dependent. No use of a mapped name is
* portable.
*
* @return a {@link java.lang.String} object.
*/
String mappedName() default "";
/**
* A portable lookup string containing the JNDI name for the target enterprise bean component.
*
* @since EJB 3.1
* @return a {@link java.lang.String} object.
*/
String lookup() default "";Maybe server and client used same packages? I don't know, I'm trying to guess how it could match ... |
|
Hi, I'll try to investigate this next week. |
|
So I don't see that Glassfish and I assume other servers honor the lookup value as where to bind the EJB on the server side. It is used on the client. However, I did find that just injecting the remote being useing @ejb in the client container rather than looking it up does work. In the standalone client example I had created at This change allows the test to run without any ejb-jar.xml or sun-ejb-jar.xml descriptors: |
|
Trying ^ via scottmarlow/jakartaee-tck@e73b28b |
I'm trying the appclient @ejb approach via scottmarlow/jakartaee-tck@e73b28b but getting: |
|
That is not working as I'm trying it in my issue1667 branch. The problem is that the call path is different in these tests as the Stateless3VehicleRunner is not the appclient main, and injection of the ejb is not happening because this the instance is created dynamically rather than being injected. This happens in the com.sun.ts.tests.common.vehicle.VehicleRunnerFactory. The instance created there would have to be injected using the CDI Unmanaged or InjectionTargetFactory as described in https://www.next-presso.com/2017/06/non-contextual-instances-in-cdi. I think the latter will be required because the runners are not valid beans. |
|
I'm not even seeing it try to inject. I'm using the ee.jakarta.tck.persistence.core.EntityGraph.ClientStateless3Test. Which test are you trying? |
|
|
|
That is using the same structure as ClientStateless3Test. Where do you see that 'could not inject the' msg? |
Just in the test output as per a null check I added in a static block that checks if the vehicle bean is null: Perhaps the static block check should the |
|
Ah, ok. So I have added the code to inject the runner for the Stateless3VehicleRunner, but CDI is not available: The should be part of the appclient environment, so figuring that out is the first step. |
|
I pushed updated code that doesn't mention |
|
I added a call to TSNamingContext.dumpJndi("", new InitialContext()) if the
|
|
So the appclient does not run a full CDI container. It is just doing custom injection of the I'm not clear on how this differs from the simple case that works, so I'll see if I can determine what differs. |
OndroMih
added
the
8.0
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: