JNDI BeanFactory lookup

[edalquist]

I have a web application in context A needs access to some APIs provided by a web application in context B. I'm going to create a set of interfaces to define the APIs that application A can access.

This library of interfaces will also include factories. My current idea is the factories have a utlity that will do a lookup via JNDI for a BeanFactory and then the factories will use the BeanFactory to create instances of the interfaces. The BeanFactory would be configured and implementations of the interfaces provided by the application in context B.

This will keep any spring code out of the application in context A that depend only on the factories and interfaces API and allow for the actual application in context B to be swapped out more easily.

I looked at using the JndiBeanFactoryLocator for the factories to find the bean factory but I don't know how to setup a bean factory to be accesable via jndi. Any pointers will be much appreciated.

-Eric Dalquist

[Alef Arendsen]

Binding a beanfactory in the JNDI tree is not recommended. You're basically violating the spec by doing so; each and every object in the JNDI tree should be serializable.

We've done this in the past and have our internal class to do this, extending the ApplicationContext to add Serializalbe to it.

I think the better option would be to make your beans in context B remotely accessible by using HttpInvokers, Hessian, Burlab or RMI. Spring provides excellent support for all four of those and it'll be completely transparant to your application (have a look at the reference manual for more info on remoting).

[irbouho]

Alef,

What if Contexts A and B use the same JVM. Is Spring Remoting sweetable for such case?

[edalquist]

They will both be in the same JVM. The main issue with the contexts is classloaders. Since, in tomcat at least, the each context has it's own classloader. The point of the interfaces is to put them in a shared lib folder to work around the classloader problem. The interfaces factories would use JNDI to find the implementation of the interfaces provided by some application in the JVM. The idea then is that the common interfaces won't have any knowledge of the actual implementation.

[sethladd]

While I agree with Alef that it's not a great idea to bind a beanfactory into JNDI, we have one reason why we need to do this.

We need to access some shared services from all webapps. Usually, the HttpInvoker would be perfect for this. But, we also need to maintain the thread context (and its authentication information) throughout the entire call. Accessing remote services, even if they are in the same application server, would lose this caller identity.

There are a few services that a full blown J2EE server might provide, like authentication information propogation that we just don't have in Tomcat. By binding the BeanFactory into JNDI (which wasn't easy on Tomcat, let me tell you) we can access a shared singleton of the service from all webapps and within the same thread.

Now, if maybe Acegi Security Plugin would include a Tomcat authentication identity Valve and then propogate this information across HttpInvoker calls, we might be on to something.