April 23, 2014

Demystifying the jboss-classloading.xml file in Jboss 5!!

JBoss 5 adds the concepts of custom Meta Data files, one of which is jboss-classloading.xml which let you define exactly how the war classloader is constructed.

Create jboss-classloading.xml:

01.<classloading xmlns="urn:jboss:classloading:1.0"

In the above case, we put the class-loader of WAR in the "TESTSSO_domain". This will shared with all other applications that don't define their own domain.

Also, we choose to look at all other classes exported by other applications by "import-all" and to expose all our classes to other classes by "export-all" options.

When we deploy our war (TESTSSO.war), which contains above jboss-classloading.xml, our Web application classloader will act as top-level Classloader so there will be no conflict with the same classes in the server's library.

Where do I place a jboss-classloading.xml file?
To control class loading behavior, the location of jboss-classloading.xml depends on what you are deploying on Jboss-5 server. If you are deploying..
  • EAR, then place it in the META-INF of the ear, e.g. TESTSSO.ear/META-INF/jboss-classloading.xml
  • WAR, then place it in the WEB-INF of the war, e.g. TESTSSO.war/WEB-INF/jboss-classloading.xml (I am deploying WAR so I placed it inside WEB-INF folder)
  • JAR, then place it in the META-INF of the jar, e.g. testsso.jar/META-INF/jboss-classloading.xml
What are all the attributes in jboss-classloading.xml mean?
  • name - typically the name of war or ear, in my case its. “TESTSSO.war”
  • import-all – (it must contain 'true' or 'false'):  true means make all classes exported from other applications visible to this application
  • export-all – value 'NON_EMPTY', means all classes are exposed to other applications
  • domain – a class-loading domain, can be an arbitrary name but typically you will want to name it the name of your application, e.g. “TESTSSO.ear” or “TESTSSO.war”. If a domain by that name already exists, your app will join that classloading domain.
  • parent-domain – It's default value is 'DefaultDomain', which means it's shared with all other applications that don’t specify a domain.  If you prefer to delegate to an explicit parent domain when a class is not found in yours, then specify an existing domain here, as in delegating to an EAR’s domain, e.g. “TESTSSO.ear”
  • top-level-classloader – It is used to enable embedded apps, such as a war within an EAR, to participate in a top-level domain
  • parent-first- (it must contain 'true' or 'false') : if set to false, the app is in non-j2ee compliance mode, means the app’s domain is searched first for a class before searching the parent domain.  The default for top-level deployed WARs is 'false', however, the default behavior for WARs within EARs is 'true'.

Copyright © 2014 - ScrutinyByKHimaanshu

No comments:

Post a Comment

RSSChomp Blog Directory