[jboss-user] [Installation, Configuration & Deployment] - Re: Shared classpath within an EAR?

[weston.price@jboss.com]

anonymous wrote : 
  | 1) In the case with the EAR/lib directory containing JARs that you mentioned, wouldn't an archive within the EAR still look at EAR/lib JARs even with Java2ParentDelegation set to true?
  | 

Yes, and this is quite often the cause of issues. A good example is wanting to use Hibernate/Xalan/Xerces jars that conflict with thirdparty jars that exist in JBoss. One of the major reasons for classloader isolation is when you want to use a different version of jar offered in your application environment. 

anonymous wrote : 
  | 2) I read that you can have, in the deploy directory itself, a regular JAR file (i.e. I don't mean EJB-JAR, but a regular JAR containing utility or other classes that you may want on your classpath)...is this really possible? 
  | 

Yes, the classes will be added to the LoaderRepository and a UCL created. However, this can create versioning issues rather quickly. Classic example is a jar file that an EJB and WAR depend on. Simply deploying the jar in a hot deployment environment will not work in this case and both the deployment units (WAR/EJB) would have to be redeployed as well. This can get real messy, real quick no matter how much you may think your build/release process can do to help you manage this.

anonymous wrote : 
  | What would it be visible to?
  | 

Everything ;-)

anonymous wrote : 
  | 3) Why should we not use the java module approach? Are there reasons that'd make it difficult to manage (like having to add them all to application.xml) or is it just not the way things are done?
  | 

Largely because this was a mistaken implementation to begin with and was added prior to the J2EE spec defining an well defined Classloading model for utility jars. Technically the 


  | <module>
  |    <java>somejar.jar</module>
  | </module>
  | 

is for J2EE ApplicationClient deployments and should only be used a such.
There is no guarantee that this approach will not be removed in the furture. In fact, I can pretty much guarantee you that it will be. 

While JBoss allows a 'flexible' approach to deployments (and in many ways allows things that it really shouldn't), sometimes this can cause serious deployment/management headachese. Sticking with a standard well know mechanism can often pay dividends in the long run. 






View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991848#3991848

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991848