Johan Eltes wrote: > >they need to find them on the dependent class path, as specified in their >respective manifest files. (valid for J2EE 1.3) > The class-path attribute in the MANIFEST.MF file should be the preferred way to pick up shared interfaces (and required parameter classes etc) that are used by many modules in a .ear. With a decent build system you should only have one physical copy of each .class file in your J2EE application. I am curious though - the wording in the J2EE 1.3 half seems to imply that the class-path manifest entry should only be used by .jar files (not .war) to reference bundled .jars elsewhere (the spec leads have confirmed to me that they're not happy with the current wording). This is probably due to overloading of the meaning of "jar file" (does it mean any java archive or just those that have the fixed '.jar' extension?) and the presence of an alternative mechanism provided in the servlet spec (the WEB-INF/lib ) for .war files. If anyone has tested the level of support the main app servers (WebSphere, Weblogic, JBoss, iPlanet, Sybase, iPortal etc) have for .war files using the (new) manifest class-path attribute, I'd be very interested in hearing your experiences.
IMHO, the servlet spec should deprecate the use of WEB-INF/lib - it predates J2EE which provides a better solution which is based on the J2SE. (I'm also sure the use of the class-path attribute allows the vendors to implement better classloader management for larger J2EE applications). But then again, this is ejb-interest so I'll stop now :-) cheers, John. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
