My intuition is that packaging modules into jars is the wrong granularity. Component packaging into jars seems a reasonable granularity. There are some issues on how to package helper classes, but this is not too much of a problem. For modules, I think a module should be packaged as a collection of interdepent jars, but the module itself should not be a jar (unless it in turn containes other jars/resources). -Chris. ---------------------------------------------------------------------- Chris Raber, Director Professional Services, GemStone Systems Inc. 100 West Big Beaver, Suite 200, Troy, MI 48084 phone: (248)-680-6691, fax: (248)-680-6689, email: [EMAIL PROTECTED] web: http://www.gemstone.com/ ---------------------------------------------------------------------- > -----Original Message----- > From: MARK HAPNER [SMTP:[EMAIL PROTECTED]] > Sent: Monday, July 12, 1999 11:53 PM > To: [EMAIL PROTECTED] > Subject: Re: ejb-jar file containing EJB dependencies, EJB component > libraries > > Malcolm, > > We looked into this carefully and found that modules are not > automatically decomposable. It is not possible to reliably automatically > subset java code in a jar file. For instance it is not possible to > determine what subtypes of a parameter type are needed for full use of a > Java object. > > J2EE considers all jar files as architecturally indivisible. > > -- Mark > > > Malcolm Sparks wrote: > > > > Hi, > > > > The J2EE specification introduces the notion of modules containing one > > or more components of the same module type (ejb, web, etc..). > > Furthermore, on page 8-1, the J2EE spec. refers to component > > libraries. Suppose that I wish to reuse one of the components from a > > module or library, for example, in a new application assembly. The > > specification as it currently stands means I have to take all the > > components from a module, since there is no way to infer which files > > from the ejb-jar must be extracted. An EJB may have certain > > dependencies, such as other non-EJB Java classes, gif files, etc.. > > > > Would it not be useful to add an entry to the Bean's deployment > descriptor, > > explicitly stating each dependency? > > > > For example, illustrating the use of a possible tag (jar-entry): > > > > <ejb-jar> > > <enterprise-beans> > > > > <session id="Bean1"> > > <ejb-name>MySession</ejb-name> > > <home>com.wombat.empl.EmployeeServiceHome</home> > > <remote>com.wombat.empl.EmployeeService</remote> > > > > <jar-entry>com/wombat/empl/EmployeeServiceAdmin</jar-entry> <!-- > see page 30 of EJB1.1 --> > > <jar-entry>com/wombat/resources/logo.gif</jar-entry> > > > > </session> > > > > <session id="Bean2"> > > <description> > > I'm not interested in using this Bean > > </description> > > </session> > > > > </enterprise-beans> > > </ejb-jar> > > > > This way, if I wanted to use Bean1, but not Bean2, I could extract it > > out of the jar into my new ejb-jar, perhaps to form part of a new > > assembly. > > > > Have I missed something? > > > > Malcolm > > ========================================================================== > = > 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". =========================================================================== 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".
