This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am using Jboss 4.2.2, and currently have 3 ears. EarA and EarB both make remote EJB calls to EarC. The problem is I had to turn on isolated classloading for each ear, so this setup is now throwing ClassCastException on the narrow() method during runtime.
So what I had tried was, placing the jar and war files of EarC in EarA, and modifying the application.xml for EarA to include the EarC modules. This worked.. until I did the same thing for EarB. Since the ejb in EarC is bound to JNDI already, it doesnt work.
Now I guess I could rename EarC to EarCa and EarCb, and that should solve the problem, but it doesnt seem right to me...
Is there something else I could do?
Thanks very much!
Edit: forgot to mention, it's ejb 2 [ July 07, 2008: Message edited by: Jessica ]
You could change the order of the classloader from parent-first (default) to child-first so that the isolated classloader setting is not necessary. In this way the class loader will go up the tree from the most local version of the class available to each ear and only share class loaders as required. I know there's a setting for this in WebSphere admin console, but off hand don't remember where this is in JBoss.
Originally posted by Jessica: Unfortunately, the isolated class loading is not set up by me, so I cant modify the jboss settings.
It should be manageable on the EAR level, not the JBoss level. I just meant the command to do it is JBoss-specific, such as in a jboss.xml file in the EAR.
Joined: Oct 17, 2003
Thanks for your help Scott, but I did something else instead.
One of my coworkers suggested to place the stubs in the share folder, but it initially didnt work because I kept deploying the ejb in the ear file! Once I tried it outside of the ear packaging, it worked like a charm.
But if I understand your solution correctly, you've broken the easily-portable nature of an EAR. In other words, other EAR's can now access the same JAR (might be a security issue or even a usability issue if other users create EARs with similar class names/paths) and you now have to install the JAR/stubs separately as part of the installation process (as well as update/maintain them separately). I don't disagree that putting the Stubs on a higher server level will work, I'm just saying its not really a great idea in the long term. Once you get into environments with multiple EARs and/or high number of updates/rollouts, it becomes more cumbersome. [ July 09, 2008: Message edited by: Scott Selikoff ]