JNDI Context lookup issues between EJB and Servlet and others

[Former Member]

Hi,

I am noticing the following behavior with respect to JNDI Lookups:

The contexts are not shared between EJBs and Servelts.

If I add a object into JNDI in a servlet, it is not looked up in EJB and vice versa.

On particular threads, like the Omni Socket threads - both the JNDI context is emtpy, and does not have access to either objects set via EJB or Servlet.

I am not sure, if this is a standard J2EE application server behavior, and I did not see such behavior in JBOSS atleast.

Could you let me know :

1. If this is expected behavior or a bug?

2. If bug : What would be the workaround, if expected : What is the expected way to look up objects in each others context?

P.S:

I am getting the initial context, by just doing a "new InitialContext()"

Demo Project (Attached jndi.txt : rename to jndi.rar)

http://server/jndi/JNDITest

This will print the jndi tree

Notice that I add an object "guru" into the initial context in a servlet and this is not visible in the EJB.

I am not able to notice the thread differences here, but in certain cases that happens too.

Thanks

Guru

jndi.txt.zip

[Vlado · Accepted solution]

This issue is now fixed with neo-javaee6-wp-sdk-2.25.7.zip and the corresponding runtime.

Cheers,

--Vlado

[Former Member]

Hi,

I am able to look up container injected object through JNDI look up in EJB context. (Using neo sdk 2.29.13.1) I looked for com.sap.ecm.api.EcmService configured through resource-ref in web.xml.

But not able to look up application injected object through JNDI look up in EJB context.

I am injecting (binding) object through context.rebind(String, Object) method (context is object of InitialContext created through new InitialContext()).

Getting same behavior on Cloud as well as on local environment.

Attached is source code (jndi.zip.txt please rename to jndi.zip).

Is it expected behavior?

Thanks,

Sachin

jndi.zip.txt.zip

[Vlado]

Yes, see the first reply in this thread.

[Former Member]

Hello,

I can see that in the servlet you are trying to bind something in the naming context.

This is not allowed as per specification:

"

Java™ Platform, Enterprise Edition (Java EE) Specification, v6

EE.5.3.4Java EE Product Provider’s Responsibilities

The container must ensure that the application component instances have only read access to their naming context. The container must throw the javax.naming.OperationNotSupportedException from all the methods of the javax.naming.Context interface that modify the environment naming context and its subcontexts.

"

You should use env-entry elements in the deployment descriptor as per  "EE.5.4.1.3Declaration of Simple Environment Entries" for example.

Regards

Violeta

[Former Member]

Actually I just did that to give you an example. This is the case even with predefined objects in the JNDI also. Like : EcmService too.

[Former Member]

Hi,

Can you explain in details what exactly you did?

Some example will help.

Regards

Violeta

[Former Member]

Hello Violeta,

thanks for following up. I will try to clarify further with an example.

in web.xml I add this:

	<resource-ref>
		<res-ref-name>EcmService</res-ref-name>
		<res-type>com.sap.ecm.api.EcmService</res-type>
	</resource-ref>

now to look this up, I need to :

new InitialContext().lookup("java:comp/env/EcmService").

Now:

If this is called from a servlet context, the lookup works fine.

If I call the same lookup code with in an EJB, the lookup fails.

Is this an expected behavior?

[Former Member]

Did you find a solution for this? I'm facing the same problem...

[Former Member]

No, not yet.

The workaround I have is to copy all required JNDI objects to a known location in different contexts at startup of the application.

[Former Member]

Hi,

We are working on the issue and we will provide a solution.

Regards

Violeta