ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: [Contribution] EJB Hot deployment task
Date Sun, 24 Mar 2002 18:57:18 GMT
----- Original Message -----
From: <>

> Erik,
> Thanks for the commit.  Regarding your issues:

My pleasure!

> - I originally had it so it could take a list of vendors.  For some
> reason I changed it, but it seems better to have it iterate over
> multiple vendors.  I will change it back.


> - I will patch the default properties next with the next patch.  Should
> I merge my docs with the official html docs?

No need.... I took care of it.  I mentioned it mainly for educational
purposes so future contributions take such things into account.

> - AbstractEjbHotDeploymentTool extends Task so I essentially get the
> attributes set on the vendor-specific elements for free.  I knew it did
> "feel" right, but the only alterative is to have the EjbDeploy task
> support all the attributes for all the vendor-specific elements  and
> pass them down in a config structure class.  I felt this coupled the
> EjbDeploy task too much with the vendor-specific element tasks.  Every
> new attribute that is introduced with a vendor-specific element would
> have to be added to the EjbDeploy task.  Any thoughts?

You do not need to have sub-elements extend from Task to get the attribute
population working.  Ant introspects the object it gets from createWeblogic
(and could you modify that to be addWeblogic instead since that is our
preference?) and finds the setters to call, it does not look for it
extending from Task.  Did you have some issues when it did not extend from
Task?  Heck, even EjbDeploy does not have to extend from Task!  :)

Seriously, try removing the 'extends Task' from AbstractEjbHotDeploymentTool
and see what issues crop up - everything should be ok, but let us know if
problems appear.

> - I totally agree with moving the execute to the abstract element class.
> That actually started bothering me as soon as I submitted the
> contribution.  I will go ahead and make that change.


> I might as well do Jboss with this update.  That way I get a good feel
> as to how flexible the framework is, and I can make any changes that
> need be made then.  Unfortunately, I have never worked with Websphere,
> but once I get stuff done I can check into including their deployment
> stuff.

The WebSphere request was mainly a joke.... I wouldn't wish that upon
anyone!  :)  (any WebSphere/IBM folks here?  No offense intended, but I'm
feeling some serious WebSphere pain at the moment).  Anyone want to tell me
how to automate the generation of Map.mapxmi???  XDoclet can build all the
other ugly deployment descriptors but that one.  And if you mention using
VisualAge I'll scream!


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message