EJB Tasks

[William Ferguson <wi...@mincom.com>]

Just looking over the EJB Tasks (from Sept 3)and have a few comments
(nice work Tim & Conor):

1) It would be really useful if ejbjar could take a list of
dependent/ancillary classes that should also be packaged into the Jar.
How is everyone else packaging up ancillary classes?

2) The AppServer specific classes: WLStop, WLStart,
WeblogicDeploymentTool, DDCreator, DDCreatorHelper, Ejbc, EjbcHelper
should probably reside in an ejb.weblogic package. This clearly allows
for expansion for other AppServers.



William Ferguson

This transmission is for the intended addressee only and is confidential
information. If you have received this transmission in error, please
delete it and notify the sender. The contents of this E-mail are the
opinion of the writer only and are not endorsed by Mincom Limited unless
expressly stated otherwise.

RE: EJB Tasks

[William Ferguson <wi...@mincom.com>]

Conor,

I agree that there is a large amount of latitude in how you might deploy
support classes. I guess I was really interested in those classes that
are directly referenced by the EJB classes.

A good example is an Operations interface that is inherited by the
Remote interface and implemented by the bean class. This needs to be
part of the jar when you deploy or deployment will fail, even if this
class is already known to the server. At least this is how it happens on
the Sun reference implementation ;-)

So I guess I'm really looking for a way to specify extra classes like
this that need to be added to the jar, but for which there is no place
within the ejb-jar.xml



As to the Ant ejb package namespace, I agree that it seems to be getting
too deep. But in its current state its a little unclear about what is WL
specific (note the Javadoc for EjbJar) and what is generic, and how to
use it. Ant1.1 also doesn't seem to have much doco on the Ejb tasks.

Making a clear distinction between AppServers specifics is probably a
good case for a factory task as was mentioned in another post. But juts
don't ask me how ;-)


William

RE: EJB Tasks

[Conor MacNeill <co...@m64.com>]

William,

>
> Just looking over the EJB Tasks (from Sept 3)and have a few comments
> (nice work Tim & Conor):
>
> 1) It would be really useful if ejbjar could take a list of
> dependent/ancillary classes that should also be packaged into the Jar.
> How is everyone else packaging up ancillary classes?

An interesting question. From a weblogic perspective, I do not think support
classes (ancillary classes) can be "hot deployed". For this reason I'm not
sure whether putting them in the jar is that useful. We also have a number
of beans (and jars) some of which share support classes. So far we have been
putting the support classes together in a jar and adding that to the server
classpath. I'm not sure if there is a better solution. I have talked to a
few other people and they seem to be using the same approach. If anyone has
another approach, I'd be interested to hear it.

>
> 2) The AppServer specific classes: WLStop, WLStart,
> WeblogicDeploymentTool, DDCreator, DDCreatorHelper, Ejbc, EjbcHelper
> should probably reside in an ejb.weblogic package. This clearly allows
> for expansion for other AppServers.
>

Fair enough. My only issue is that this makes the package namespace deeper
and sparser and it is not clear where to stop - should there be a wl451 and
a wl510 package below ejb.weblogic. For now I'd be happy to have support for
more app servers and just have them live in the same package space with
appropriate if/unless controls.

With the ejbjar task, I've tried to make it easy to add support for other
app servers. I'm hoping that someone can build on what is there and
contribute components for other app servers that can plug into ejbjar.

>
>
> William Ferguson
>

Conor