Thanks for this reply Mark.
Just to make things absolutely crystal clear for me, I'd be very
grateful if you could say if you concur with the following:
Say an Application Assembler A uses EJBs from Bean Provider B, in
addition to his own EJBs. The resulting jar would be the union of the
entries in the jar from B, and the other EJBs from A.
For sake of argument, let's suppose B bundles hundreds of EJBs in one
jar (eg. "The Theory Center"). Each application module making use of
as little as one EJB from "The Theory Center" would have to accept the
bloat of the resulting module.
Alternatively, the application assembly could be tagged as requiring
the presence (on the server) of the jar from B. During installation,
as defined by J2EE where media is sent to the J2EE platform, the jar
from B would also be sent across, or atleast a checksum comparison
with the jars already present on the J2EE platform would take place.
Obviously the alternative described would benefit from having some
information in the deployment descriptor, at the bean level, to
describe such a dependency on another module.
I'm beginning to see the wood from the trees now....
The dependency description I require is already provided for in
the <ejb-ref> tag. The jar from the Bean Provider would exist as
a separate module in the same J2EE application unit.
Is this the intention?
Malcolm
On Mon, Jul 12, 1999 at 08:53:23PM -0700, MARK HAPNER wrote:
>
> 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".
