> It's not supposed to. That's the issue that cropped up. Somehow people are/ > were using the <java> element in application.xml to get things on their > 'classpath' for WARs and EJBs in the EAR. This is just plain wrong. What alternative do you propose? AFAIK, although the J2EE 1.3 spec (section 8.1.1.2) requires containers to load dependent jars referenced in the Class-Path manifest entry of EJB jars, it doesn't make the same requirement of WARs (or EARs).
The pertinent part of the spec is: "J2EE products need not support this mechanism [Class-Path entries in the manifest --pb] for reference to classes or resources that are not in .jar files included in the .ear file. However, support for such usage is encouraged. Applications are encouraged to make use of such support only when necessary and where available, although currently such usage is non portable. A future version of this specification may require support for this mechanism to reference "libraries" that are installed separately into a J2EE application server." WARs can stick files into their lib directory, of course, but that's hardly a pleasing way of solving the problem, as it often results in needless duplication and complication. The spec states explicitly that it has no solution to the problem of shared jars: "(Note that it is not currently possible to reference a single copy of an optional package between multiple web modules, for instance. There may need to be multiple copies of the optional package included in the application package, but all copies should be identical.)" So, as far as I can tlel, the "correct" thing to do is to copy every shared library to every lib directory in every WAR, make another copy so that jars can reference it with their Class-Path property. This offends many people's sense of aesthetics. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
