Wascally Wabbit wrote:
Hi all,
A bit of frustration...
I've just begun upgrading my antlibs to Ant 1.7 and I'm just blown over
by the number of changed assumptions that are now part of base classes
like Task and UnknownElement. It's just surprising coming from a 0.5
revision change. It's becoming harder and harder to upgrade with Ant for
large antlib collections (IMO) because of the lack of a clear lifecyle
structure for data types and tasks (and task containers and probably
AntLibDefinitions too).
Some examples:
+ With Ant 1.7 the inability to execute the same task twice (even if
_you've written it do handle this_)...UE was altered and now this line
breaks (from lines 291:296). UE is one of the great mysteries of Ant for
a extension developer:
// Finished executing the task, null it to allow
// GC do its job
// If this UE is used again, a new "realthing" will be made
realThing = null;
getWrapper().setProxy(null); //OUCH!OUCH!OUCH!
If Task.maybeConfigure is called subsequently it promptly throws a NPE
because it uses the proxy w/o checking for null.
file a bug, with examples, if this is breaking yo.
+ With Ant 1.7 a complete reversal of the ordering of attribute
configuration relative to child configuration...it's not the switching
that's the fundamental problem (implementation details and all that) but
Ant lacks any sort of public lifecycle event that a Task or
TaskContainer implementation can consistently count on from release to
release. It's always an adventure...even between minor minor revisions.
It's even possible for a Task's "init()" method to be called multiple
times...
Perhaps there could be a clear "I'm configured" trigger or event or
callback or method or something before the task's execute method is called.
+1
+ Perhaps DataTypes can also have the ability to know when they've been
completely configured (from Ant's perspective)? I guess this is more of
the same lack-of lifecycle transparency as is the case for Tasks. I
often use "quiet" tasks to get these features, but this is a
heavy-handed solution.
I actually think these are good points. In SmartFrog we have an explicit
lifecyle of
-constructor
-sfDeploy() invoked: you are live, your peers have all been
constructed, but may or not be deployed. Read in your configuration
data, and set any values you can, to share with your peers. validate
anything and throw an exception if something is wrong.
-sfStart() invoked. All your peers are in the deployed state. Start
your work in a new thread. This is roughtly equivalent to execute.
-sfTerminate(). Wake up, time to die. Can happen any time after
sfDeploy() was invoked...you may not have started if a peer failed to
deploy.
-sfPing() : hit you for your system health.
Elegant termination handling is, well messy. Like when you want to issue
SQL commands to the DB on shutdown, but it was the database itself that
triggered the shutdown [yes, I have been doing functional testing of
mysql last week :). How do you test that a database got rolled back on
termination?]
Now, not all of this applies to Ant because it has an inherently
sequential workflow, at least, not until you get into <parallel> where
life gets complex, fast.
-We may want to consider having a formal AntLifecycle interface that
lifecycle things can use -though there is the risk that embedded uses of
tasks wont use it.
-A method telling a datatype that it is configured would be
handy...maybe all ProjectComponents have their componentDeployed()
method called by default. The rationale for datatypes is what if the DT
has some work to do, like download an artifact from a remote site. Once
its been configured, you want it to start its work.
-A componentTerminated() method is useful to say "you are no longer
needed, ever. Clean up. Because finalizers are a no-no, and execute(),
well, it can retain some state, can't it?"
Thoughts? Maybe we can have a little BoF on this topic at ApacheCon in May?
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
