ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Chambery" <tchamb...@hotmail.com>
Subject Re: GenericDeploymentTool and ejb
Date Wed, 16 Jan 2002 15:08:31 GMT
----- Original Message -----
From: "Holger Engels" <hengels@mercatis.de>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Sent: Wednesday, January 16, 2002 4:20 AM
Subject: RE: GenericDeploymentTool and ejb


> On Wed, 16 Jan 2002, David Bullock wrote:
>
> > Yup.  Basically, the JAR manifest entry 'Class-Path' rocks :-)  More
Java
> > developers need to know about this one.
> >
> > It is a requirement of the J2EE spec that application servers given an
> > EAR file must respect the Class-Path attribute, and interpret path paths
> > relative to the location of the ejb.jar inside the app.ear file.
> >
> > ie.
> >
> >   /APP.EAR
> >      /ejb.jar
> >         /META-INF
> >            /MAINFEST.MF  ( contains entry 'Class-Path: support.jar' )
> >      /support.jar
> >
> >
> > I feel this is 'best current practice', and is preferrable to putting
all
> > dependent classes in ejb.jar  ...  when the new task is released, it
would
> > be good to NOT make it ship with dependency-bundling turned on by
> > default, IMHO.
> >
>
> Well, I don't like the Manifest-approach. Although I have written a custom
> task, that creates a manifest file with a Class-Path entry from a nested
> path element. I think they should add a war-like mechanism to the
> ejb-spec.
>

I personally like the neatness of the manifest classpath, but a
self-contained EJB jar also has its appeal.  Unfortunately, the jars the new
GDT creates are still dependent on on an "external" (to the ejbjar) support
jar, so what you end up with is big jars that do the same thing as little
jars.  Another weakness comes from dynamic classloading, where
Class.forName(...) refs won't get picked up.  I don't necessarily care about
the size of the jars, I just didn't have an answer when people asked me why
the difference.

Also, if it's not a dead issue, I'd like lobby one more time for looking for
the MANIFEST.MF (or same prepended with the jar name) in the directory of
the generic descriptor.  In the case of my current project, their are many
descriptors, each in their own directory, using the generic naming
convention.  With the current way of picking up the manifest, I have big
bunch of named manifests in the descriptor root, then the rest of the
descriptors neatly tucked away in their own directories.  I think it makes
more sense that the manifest naming convention follow that of the
descriptor, so if it's "ejb-jar.xml" the GDT should look for "MANIFEST.MF",
and if it's "jarname-ejb-jar.xml", look for "jarname-MANIFEST.MF".  Looking
in the current descriptor directory makes it possible to use both the former
and the latter, and also preserves project order.

If the decision has been made for the new GDT, I'll drop this issue.

BTW, if I hadn't said it before, thanks Holger for the work on the WAS tool
and related, it works great and looks good, and made me look good on this
project.

Todd

>
> Conor: yes, I will enhance the ejbjar documentation soon.
>
>
> Cheers,
>
> Holger
>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>
>

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message