-
-
2. Re: Mutliple ears with similar files
integ Aug 8, 2002 6:38 PM (in response to integ)Adrian, I tried that, but doesnt work for me.
This is the jboss-app.xml file that goes into the META-INF section of ear 1.
<jboss-app>
<loader-repository>localhost:8080:loader=xyz1.ear</loader-repository>
</jboss-app>
This is the jboss-app.xml file that goes into the META-INF section of ear 2.
<jboss-app>
<loader-repository>localhost:8080:loader=xyz2.ear</loader-repository>
</jboss-app>
But xyz2.ear continues to load utility files from xyz1.ear.
Plz tell me where i am wrong. -
3. Re: Mutliple ears with similar files
adrian.brock Aug 9, 2002 5:53 AM (in response to integ)You don't have a valid jmx ObjectName
try something like
<loader-repository>repository:loader=xyz1.ear</loader-repository>
There was some talk about reversing this behaviour,
making ears a classloader scope by default with a flag
to not isolate it. I don't think it has been done yet.
Regards,
Adrian -
4. Re: Mutliple ears with similar files
integ Aug 9, 2002 4:36 PM (in response to integ)Adrian,
that too didnt work for me. I think i missed telling u an important point. I am on JBoss3.0.0 and not JBoss3.0.1. Do u think this might work on JBoss3.0.1, or is there anything else that i can do abt this. -
5. Re: Mutliple ears with similar files
davidjencks Aug 10, 2002 1:53 PM (in response to integ)Most likely you will need a cvs version of Branch_3_0, Branch_3_2, or head. There was a bug when mbeans were involved, just fixed today by Scott in I think all 3 versions.
-
6. Re: Mutliple ears with similar files
narve2 Oct 15, 2002 4:31 PM (in response to integ)> Most likely you will need a cvs version of
> Branch_3_0, Branch_3_2, or head. There was a bug
> when mbeans were involved, just fixed today by Scott
> in I think all 3 versions.
Does this mean that "loader-repository" does not work at all? That there are no ways to have two different versions of a library? And are there any dates for a 3.0.4 (or 3.2.0)?
Some further "loader-repository" questions:
I've had the same problem as several other users in the forums, and tried specifying loader-repository. Unfortunately, the classes were still loaded from the wrong ear (the first to be deployed). I have not tried using a loader-repository in all ear's, as there are many of them.
What exactly happens when you specify a loader? After reading the (slightly vague) comments, things are a bit unclear. My understanding was that specifying a loader gives you a special loader that first looks in its own local repository (usually, in the ear/war file) and thereafter in the general repository. However this is not the behaviour I observed. Is the other way, that by specifying a repository the classes are excluded from other class loaders, but Class.forName will still look in other repositories first?
Furthermore, the symptoms in my case were actually a ClassNotFound-exception: In one library (in app1.ear) I have a library class C that uses Class.forName(...) to load another class. This works fine. I then deploy app2.ear, containing another version of library C, and calls Class.forName on a class that is found in app2.ear. This causes a ClassNotFound-exception. Should it? Can anybody explain this? There seem to be no information about this in the documentation, except the small paragraph that was posted in the forum.
(Just in case: jboss-3.0.3, jdk1.4, win2k) -
7. Re: Mutliple ears with similar files
adrian.brock Oct 15, 2002 10:49 PM (in response to integ)A loader repository is a separate classloader space.
In default jboss, there is only one loader repository,
all classes can see each other (or very nearly see later).
This allows optimal processing between the different
components installed.
By specifying <loader-repository> in jboss-app.xml
you create a new classloader space, allowing you to
vary class definitions for different apps. It can see
the classes in the main loader repository and its own
classes.
It cannot see classes in other ears with a
<loader-repository> unless....
If you specify the same name in <loader-repository> for
two ears, they share the same classloader space.
Use a naming convention like
<loader-repository>loader-repository:ear={your-ear-package-name-here}</loader-repository>
to avoid sharing.
There are other complications, like the bootstrap
classloader and wars get their own classloader
that branches from the relevent <loader-repository>.
wars can see ejb classes but not the other way around.
Don't use Class.forName() use
Thread.currentThread().getContextClassLoader().loadClass()
But that would take another long explanation.
The bug Scott fixed was for MBeans inside an
ear with a loader-repository.
Regards,
Adrian