Deployment options of shared code

[kgilpin]

We have a set of common libraries (utilities classes, Hibernate beans) that are used by multiple different J2EE applications. With Weblogic, each application is an EAR file that contains all of its JARs, plus a manifest in the EJB JAR. This works quite nicely. Each application is independent from the rest, which means that we can apply patches to individual applications on our production server, we can hot deploy the entire application, etc.

In JBoss, the default classloader architecture seems to encourage putting all the shared stuff in the [server]/lib folder. However, if I understand correctly, this code will not be hot-deployable, which really defeats the purpose of using a container in my mind (the whole reason I am learning JBoss is because I am fed up with Weblogic's unreliability while hot-deploying).

So, I tried building my EARs with a jboss-app.xml which creates a separate classloading context for each application. I was happy and thought this was working nicely, until I tried an application which looks up Home interfaces from the global JNDI namespace. What happened then is that the objects in JNDI were implementing separately loaded instances of the RemoteHome and RemoteSession interfaces, so PortableRemoteObject.narrow threw ClassCastException. I attempted to work around this problem by trying to figure out how to make JBoss use a non-JNP connection to JNDI, but I don't see a way to do this other than the HTTP invoker. Using the HTTP invoker inside the container is a big hack, but I decided to try it anyway; unfortunately this approach also failed (stack trace below).

So now I am 100% stuck. I can't deploy everything in [server]/lib, because then it won't hot deploy (right?). I also can't deploy everything in their own classloaders, because then I can't use remote Session beans through JNDI.

Surely people do stuff like this all the time. What is the right answer? I have learned a lot about JBoss, and that is good. But I am ready for it all to start working now.

All this code is currently in production on a Weblogic server, so whatever my problems are they are JBoss-specific.

- kevin

Attempt to use HTTP JNDI provider:

12:41:44,986 WARN [HttpNamingContextFactory] Invalid reply content seen: class
org.jboss.invocation.InvocationException
java.io.EOFException
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream
.java:2165)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputS
tream.java:2634)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734
)
at java.io.ObjectInputStream.(ObjectInputStream.java:253)
at org.jboss.invocation.http.servlet.InvokerServlet.processRequest(Invok
erServlet.java:117)

[jonlee]

What happens if you don't pack your own copies of the interfaces in each application? That is; you only have one set of interfaces loaded - those packaged with the actual EJBs. This should work in JBoss 3.2.x. As I remember, it won't work in 2.4.x and probably won't in 3.0.x. I guess you should be able to also pack shared libraries (rather than interfaces) in a SAR although I haven't tried this except in concert with some MBeans.

We tend to develop with free floating EJBs in 3.2.x - not packaged in an EAR and we can use the interfaces without issue because the only copies are with the EJB's JAR. Of course, you need to redeploy the other components that use the resouece when you redeploy, usually due to JNDI issues. YMMV.

Hope that helps.