Mutliple ears with similar files

[integ]

I am trying to deploy 2 ears with the same files. These ears contain some utility class files in addition to the bean classes. These utility classes are slightly different across the 2 ears. My observation is that the utility class files belonging the ear which gets deployed first are the ones which take effect. Similarly named files from the second ear are probably ignored. So what happens is the 2nd ear makes use of the utility classes from 1st ear. How can i make each ear use its own utility class files.

[adrian.brock]

http://sourceforge.net/tracker/index.php?func=detail&aid=558189&group_id=22866&atid=381174

Regards,
Adrian

[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.

[adrian.brock]

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

[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.

[davidjencks]

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.

[narve2]

> 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)

[adrian.brock]

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