We are trying to deploy two, different, applications (let's say APP1 and APP2) recently but we have a problem as one of them use reverse ordered class loader. What we find - after deployment - is that classes are mixed up within applications. We have shared components (shared libs) which provide access to APP1 (reverse ordered class loader) from APP2 (standard class loader). But when we try to access APP1 from APP2 through the API from the shared libs, Java gets confused.
We would like to assure, somehow, that APP1 is encapsulated and has no access to shared libraries at all. Additionally we would like to make APP1 be available for APP2 - as we need it's features.
Is it possible to do this within JBoss? We base on Tomcat at the moment.
Are you saying that you wrote your own class loaders? In which case I would know know how to help you.
(Warning: this is a simplification) In JBossAS, each app is assigned its own classloader, but they all use a common classloader repository. Except for WAR files, where each WAR also has its own classloader repository. Thus all apps (except web apps), by default, can share classes. You can change this by declaring a classloader repository for an EAR file, in which case the classes in the EAR file are isolated - noone from outside can use them, and the classes in the EAR file are preferred to classes outside the EAR file (handy is, for example, your app needs a different version of Hibernate than what is provided by JBossAS).
Now, in JBossAS, the classloaders where completely rewritten to make use of the Virtual File System (VFS), and are therefore known as the VFS classlaoders (prior to 5.0 there were the unified classloaders). But even though the underlying implementation is different, the end result is the same. In other words, the prior paragraph applies to 4.0.x, 4.2.x and 5.0 (and probably also to 3.2.x but it has been a long time since I used that).
An issue is that we are using third party library - which is a must for us.
What we have done so far is that we provided web services that are used as an interface to the library. Additionally we have two tomcat instances - each instance is used for each application. Tomcat1 for app1 and Tomcat2 for app2.
As far as I understand you, if we encapsulate app1 and app2 into EAR and then we deploy them inside JBoss we will be able to have only one instance of JBoss while both applications are running. Am I right?
I'm not quite following your question or exactly what you're trying to accomplish, but no, how you deploy your applications should be mutually exclusive from how many instances of JBoss you can run. Are you trying to cluster you applications?
As you can see, what we want to achieve is to have only one server installed while both applications are entirely separated so we don't have class loader issues while it comes to shared libraries loading.
It sounds like you should at least look into classloader repositories to see if they will do what you need. If not, then you would need to come back with specific questions on problems you encounter using classloader repositories.
Joined: May 14, 2008
You should be able to completely isolate your applications. I think you can deploy each WAR in its own EAR and then isolate the classloaders. You may encounter performance problems with isolated classloaders though. Why can't you keep them in separate JBoss instances? Is hardware a concern?
I guess the real question is: what problem are you trying to solve? What is wrong with the current model that you have?
Why do nt you deploy app1 and app2 as different ear with isolated class loader policy on differenet server but on same hardware. Create two instances of server and deploy each app on it.
I am not sure on Tomcat whether you can have multiple instaces of server. You can do it on Webspshere and many other servers.
SCEA, SCJP and IBM Certified XML Developer
Joined: Aug 17, 2007
We have fully automated installation process. One of our requirements is to have Tomcat already installed. What we want to get is to reduce installation procedure to minimum. At the moment we force people to install additional Tomcat instance - which is not quite good solution.
Joined: Mar 15, 2008
Deploy all classes at war level and make class loading strategy in such way that always war classes loaded first in each war.