• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Delegation Mode in J2EEApplication isolation mode

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Delegation Mode for the CompoundClassLoader is true in J2EEApplication Mode whereby it was false in Application Mode. This creates unfortunate behavior.
This means that classes that my utility jar file depends on are first loaded by the bootstrap classloader (or something higher up in the priority tree). For something like log4j, this has the unfortunate consequence of making my appender invisible to log4j, as my appender is included in my utility class.
Here are the jar's in play:
ear
war
lib/util.jar (manifest classpath points to ../vendor/log4j.jar)
vendor/log4j.jar
A different log4j.jar somewhere else in war's classpath.
With DelegationMode turned on, not only to I not get the expected version of log4j.jar from my vendor library, but log4j gets loaded by the bootstrap classloader or the ExtClassLoader and classes in util.jar are inaccessible to it. This has created conflicts for every jar file included in the server's bootstrap classpath, e.g. xerces, xalan, jaxp, etc.
Is there any way to override this? ejbDelegationMode doesn't do it. I am stuck using Application or Server mode.
 
Rob Flo
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the 4.0 fixpack 3 release notes:
ftp://ftp.software.ibm.com/software/websphere/appserv/support/fixpacks/was40/fixpack3/docs/rnclassholders.html#appext
This fixes it. Hopefully this will help somebody else who is chaining dependencies through manifest class-path entries.
By default, .war module classloaders attempt to load classes before delegating to the parent classloader, except when using Application--J2EE visibility. With Application--J2EE visibility, .war module classloaders delegate to the parent classloader before attempting to load classes. You can change this behavior by setting the com.ibm.ws.classloader.warDelegationMode JVM system property.
 
reply
    Bookmark Topic Watch Topic
  • New Topic