app classloader isolation in AS5

[ips]

How is it configured in AS5? - the same as in AS4 or some new way?

The following EmbJopr post suggests that the 4.x way of doing it (http://www.jboss.org/community/wiki/classloadingconfiguration ) may not be working in 5.1.0:

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240442

Thanks,
Ian

[jaikiran]

AFAIK, that should have worked. But yes, i have seen users complaining about similar issue. Some of the users have got the jboss-classloading.xml (JBoss AS5 approach of classloading) working http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154592#4233045

I guess if the jboss-web.xml approach isn't working then its probably a bug (or atleast we should have some documented reason why it doesn't work).

[alesj]

Looking at the code, this should still be there:
- http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/tomcat/src/main/org/jboss/web/tomcat/service/deployers/WarClassLoaderDeployer.java

[jaikiran]

"ips" wrote:

The following EmbJopr post suggests that the 4.x way of doing it (http://www.jboss.org/community/wiki/classloadingconfiguration ) may not be working in 5.1.0:

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240442

Thanks,
Ian

Ah wait, the configuration shipped in admin-console.war looks wrong:

<jboss-web>

 <class-loading>
 <loader-repository>
 org.jboss.on:loader=embedded
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
 </class-loading>
...

The wiki http://www.jboss.org/community/wiki/classloadingconfiguration states this:

*Note: As of at least JBoss 4.2.1, the <class-loading> tag appears to no longer be supported as isolation is ignored. Instead, the following configuration appears to accomplish the same goal:

<jboss-web>
 <loader-repository>
 com.example:archive=unique-archive-name
 </loader-repository>
</jboss-web>

Try removing the class-loading in admin-console and instead use loader-repository as the top level element and see if that works (i guess it will).

[jaikiran]

"jaikiran" wrote:

Try removing the class-loading in admin-console and instead use loader-repository as the top level element and see if that works (i guess it will).

Nope, that won't work. The DTD does not allow this.

Looks like the classloading isolation through jboss-web.xml is broken. I don't see any JMX MBean created for the loader repository (org.jboss.on:loader=embedded)

[alesj]

"jaikiran" wrote:

Looks like the classloading isolation through jboss-web.xml is broken.

Broken in what way?

[jaikiran]

"alesj" wrote:

Broken in what way?

1) The MBean which is expected to be created out of the domain name set in the loader-repository :

<loader-repository>
 org.jboss.on:loader=embedded

is not created

The more important thing is whether the isolation is really working with this configuration. I could not complete the debugging this issue during the weekend. I'll try and get more info about this later today.

[jaikiran]

Gave it a try with a simple war application. The isolation works. 2 war files containing 2 different version of the same class were deployed:

app1.war
|
|--- WEB-INF
| |--- web.xml
| |--- jboss-web.xml
| |--- lib
| | |
| | |--- myapp.jar
| | | |--- org.myapp.core.Version (version1 of the class)

app2.war
|
|--- WEB-INF
| |--- web.xml
| |--- jboss-web.xml
| |--- lib
| | |
| | |--- myapp.jar
| | | |--- org.myapp.core.Version (version2 of the class)

The applications contained these jboss-web.xml:

<?xml version="1.0"?>

<!DOCTYPE jboss-web PUBLIC
 "-//JBoss//DTD Web Application 5.0//EN"
 "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">

<jboss-web>

 <class-loading>
 <loader-repository>
 org.jboss.test:classloader=app2
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
</class-loading>
 <context-root>app2</context-root>

</jboss-web>

<?xml version="1.0"?>

<!DOCTYPE jboss-web PUBLIC
 "-//JBoss//DTD Web Application 5.0//EN"
 "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">

<jboss-web>

 <class-loading>
 <loader-repository>
 org.jboss.test:classloader=app1
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
</class-loading>
 <context-root>app1</context-root>

</jboss-web>

Then the class was accessed from a JSP, to print out the versions:

14:06:09,874 INFO [STDOUT] From app2 Version is 2.0

14:06:18,868 INFO [STDOUT] From app1 Version is 1.0

So the classloading scoping is working.

The only thing that does *not* work is the MBean creation for the loader repositories. The org.jboss.test:classloader=app1 and org.jboss.test:classloader=app2 are not created. Looks like an issue.

[alesj]

"jaikiran" wrote:

The only thing that does *not* work is the MBean creation for the loader repositories. The org.jboss.test:classloader=app1 and org.jboss.test:classloader=app2 are not created. Looks like an issue.

Why should these mbeans be created in the first place?
For back compatibility reasons?
Or do you need them somewhere else?

btw: what exactly are those mbeans?

[ips]

What version of AS did you test against? The user who reported the issue in the linked post was using the jdk6 version of 5.1.0.GA.

[jaikiran]

"alesj" wrote:

Why should these mbeans be created in the first place?
For back compatibility reasons?
Or do you need them somewhere else?

btw: what exactly are those mbeans?

Yes, backward compatibility is the reason. As per the wiki, those MBeans are for:

The loader-repository ObjectName will appear in the JMX-Console (http://localhost:8080/jmx-console/).

This MBean is great for debugging any class-loading issues which might arise.

"ips" wrote:
What version of AS did you test against? The user who reported the issue in the linked post was using the jdk6 version of 5.1.0.GA.

Tested against AS 5.1.0 GA the JDK5 variant. Although i don't think the JDK version will make a difference.

Note that, that thread does not provide the exact classloader issue the user is running into. If there's some reproducible example, i can give it a try. My guess is, even though the classloader isolation is working, the application probably is not bundling *all* the relevant/dependent jars (just a guess).

[alesj]

"jaikiran" wrote:

"alesj" wrote:

Why should these mbeans be created in the first place?
For back compatibility reasons?
Or do you need them somewhere else?

btw: what exactly are those mbeans?

Yes, backward compatibility is the reason. As per the wiki, those MBeans are for:

The loader-repository ObjectName will appear in the JMX-Console (http://localhost:8080/jmx-console/).

This MBean is great for debugging any class-loading issues which might arise.

I think this is just old wiki, new CL layer exposes this info differently.
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloader/src/main/java/org/jboss/classloader/spi/ClassLoaderDomainMBean.java

[shelly.mcgowan]

https://jira.jboss.org/jira/browse/JBAS-7032
has been identified to be related to:
https://jira.jboss.org/jira/browse/WBINT-15
With web beans, classloader isolation is supposed to be done automatically as noted here:
http://lists.jboss.org/pipermail/webbeans-dev/2009-January/000477.html

Specifically,

no jboss-* to enable classloader isolation

In JBAS-7032 referenced forum post , another user had an issue with RF and Seam jars that were also not isolated in the application .ear which conflicted with admin-console.war deployment. But to Ian's earlier comment, shouldn't the isolated CL on the admin-console.war be enough to prevent non-isolated deployments to conflict. The admin-console.war has the following entry in its' WEB-INF/jboss-web.xml:

 <class-loading>
 <loader-repository>
 org.jboss.on:loader=embedded
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
 </class-loading>

There is still question whether this is working correctly. I'm going to write some tests with diff version of SEAM/RF jars. Is there any "rules" about classloader isolation for SEAM deployments similar to what is defined for web beans?

[alesj]

I'm going to write some tests with diff version of SEAM/RF jars.

While you're there :-), could you also write some test that checks webbeans .ear isolation aka WBINT-15 issue?
Thanks.

Is there any "rules" about classloader isolation for SEAM deployments similar to what is defined for web beans?

No, Seam apps should still provide their own jboss-(app|web).xml with proper cl isolation rules.

I'll try to see what might be the issue with WBINT-15,
just let me know when you have the tests ready.
And I'll also check the other isolation issues, based on your tests.