Classloading configurations for applications in JBoss-5

[jaikiran]

From one of the other posts here, i understand that for classloading configurations the recommended approach is using jboss-classloading.xml (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130122)

<classloading xmlns="urn:jboss:classloading:1.0">

<!-- capabilities are classloading exports -->
 <capabilities>
<!-- This deployment can be referenced by either of these two module names -->
 <module name="export2" version="2.0.0"/>
 <module name="export1" version="1.0.0"/>
<!-- It exports these packages with the given versions -->
 <package name="export2" version="2.0.0"/>
 <package name="export1" version="1.0.0"/>
 </capabilities>
<!-- requirements are classloading imports -->
 <requirements>
<!-- It needs to import the following modules -->
 <module name="import2" from="2.0.0"/>
 <module name="import1" from="1.0.0"/>
<!-- and packages -->
 <package name="import2" from="2.0.0"/>
 <package name="import1" from="1.0.0"/>
 </requirements>
</classloading>

I went through that dev forum discussion and had some initial questions about how the classloader configurations need to be done.


1) What exactly is a module? Is it the same as the one in the application.xml (probably not, because i don't see a way to name the module in application.xml)

2) The version (and from) attribute that is used in the configuration above, how is it resolved? For example, if my application needs a 1.2.9 version of log4j, is the version information searched in the MANIFEST.MF?

3) Is this jboss-classloading.xml supported in CR1? I was thinking of changing my sample application which uses jboss-app.xml for classloader configuration, to try out this xml file.

Is there any documentation i can refer to for configuring this?

[alesj]

"jaikiran" wrote:

1) What exactly is a module? Is it the same as the one in the application.xml (probably not, because i don't see a way to name the module in application.xml)

Almost.
This is OSGi notion.
Module ~ bundle name ~ deployment unit name.
More relaxed/abstract notion about what a module is.

"jaikiran" wrote:

2) The version (and from) attribute that is used in the configuration above, how is it resolved? For example, if my application needs a 1.2.9 version of log4j, is the version information searched in the MANIFEST.MF?

Could be.
It's a matter of providing classloading metadata.
It can come from another jboss-classloading.xml or MANIFEST.MF ... or where ever.
e.g.
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/osgi-int/src/main/org/jboss/osgi/plugins/deployers/OSGiMetaDataDeployer.java
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/osgi-int/src/main/org/jboss/osgi/plugins/deployers/OSGiMetaData2ClassLoadingMetaDataDeployer.java

"jaikiran" wrote:

3) Is this jboss-classloading.xml supported in CR1? I was thinking of changing my sample application which uses jboss-app.xml for classloader configuration, to try out this xml file.

Yes.
See deployers.xml in conf directory about which deployer transforms xml into ClassLoadingMetaData instance.
And which one picks it up.

"jaikiran" wrote:

Is there any documentation i can refer to for configuring this?

Unfortunately not yet:
- http://jira.jboss.com/jira/browse/JBCL-10

[jaikiran]

Thanks. I'll take a look at these.

[jaikiran]

I started trying out the classloader changes, but unfortunately haven't yet been able to get a sample application to even deploy. Here's what i am trying:

- JBoss-5.0 CR1 ships with log4j 1.2.14 version.
- I packaged log4j 1.2.8 version in the lib folder of my ear file.
- I have a jboss-classloading.xml file in the META-INF folder of the ear:

<classloading xmlns="urn:jboss:classloading:1.0" export-all="NON_EMPTY" import-all="true"
parent-first="false">



 <requirements>
 <package name="org.apache.log4j" from="1.2.8" />

 </requirements>

</classloading>

The MANIFEST.MF of the log4j.jar in my ear contains this:

Manifest-Version: 1.0

Name: org/apache/log4j/
Implementation-Title: log4j
Implementation-Version: 1.2.8
Implementation-Vendor: "Apache Software Foundation"

The EAR packaged is as follows:

ClassloadingTest.ear\lib
ClassloadingTest.ear\META-INF
ClassloadingTest.ear\myapp.war
ClassloadingTest.ear\lib\log4j.jar
ClassloadingTest.ear\META-INF\application.xml
ClassloadingTest.ear\META-INF\jboss-classloading.xml
ClassloadingTest.ear\META-INF\MANIFEST.MF
ClassloadingTest.ear\myapp.war\META-INF
ClassloadingTest.ear\myapp.war\test.jsp
ClassloadingTest.ear\myapp.war\WEB-INF
ClassloadingTest.ear\myapp.war\META-INF\MANIFEST.MF
ClassloadingTest.ear\myapp.war\WEB-INF\web.xml

Finally when i deploy my application, i just see this error on the console as well as the server.log:

20:07:01,135 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}

vfsfile:/D:/jboss-5.0.0.CR1/server/jaikiran/deploy/ClassloadingTest.ear/
 -> <UNKNOWN vfsfile:/D:/jboss-5.0.0.CR1/server/jaikiran/deploy/ClassloadingTest.ear/>{ClassLoader:** UNRESOLVED PackageRequirement{org.apache.log4j [1.2.8,?)} **}


*** CONTEXTS IN ERROR: Name -> Error

<UNKNOWN vfsfile:/D:/jboss-5.0.0.CR1/server/jaikiran/deploy/ClassloadingTest.ear/> -> ** UNRESOLVED PackageRequirement{org.apache.log4j [1.2.8,?)} **

Though the message says to look for earlier error messages, there are no error or warn or info logs related to this even in server.log file. I even tried enabling TRACE level logs for appropriate packages, but wasn't of any help.

So here are my questions:

1) Is the above jboss-classloading.xml expected to work? All i am trying to do is define an requirement of 1.2.8 version of org.apache.log4j package for the classloader in my application.

2) I think, the logging of the classloader deployer (or related) packages can be improved to debug these issues.

3) Some of my debugging shows (not sure if this is going to be of any help) that the PackageCapability objects that get created for various packages, always has the default version (0.0.0). Just an example:

PackageCapability{org.jboss.deployers.spi.deployer 0.0.0}, PackageCapability{org.jboss.deployers.spi.structure 0.0.0}, PackageCapability{org.jboss.deployers.vfs.spi.structure.helpers 0.0.0}, PackageCapability{com.ctc.wstx.sw 0.0.0}, PackageCapability{org.jboss.deployers.spi.attachments 0.0.0}, PackageCapability{org.jboss.system.server.jmx 0.0.0}, PackageCapability{org.jboss.deployers.spi.annotations 0.0.0},

Note that i decided to use log4j.jar for this example, but i have even tried it with some other jars with the same result.

[alesj]

I guess you failed to look/understand where I tried to point you to with my manifest+osgi metadata deployers.

If you can wait, I'll try to get this working as a simple example how to define jboss-classloading in my future demos.

But you're still welcome to play with it. :-)

[jaikiran]

"alesj" wrote:
I guess you failed to look/understand where I tried to point you to with my manifest+osgi metadata deployers.

Yup, failed to understand. Let me give it a second look with more dedicated interest :-)

[alesj]

"jaikiran" wrote:
Yup, failed to understand. Let me give it a second look with more dedicated interest :-)

:-)
OK, just a little tip.
You need to include those deployers, since they are not there by default.
And even then it might not work, since I haven't done any serious testing.
But if you're willing to have a crack at it, and report then, that would be great. ;-)

[jaikiran]

"alesj" wrote:

OK, just a little tip.
You need to include those deployers, since they are not there by default.

Thanks for that tip.

"alesj" wrote:

And even then it might not work, since I haven't done any serious testing.

Doesn't matter :-) I'm actually testing this on a sample application to just understand how its supposed to be configured with this new approach.

"alesj" wrote:

But if you're willing to have a crack at it, and report then, that would be great. ;-)

Sure.