Nicola Ken Barozzi wrote:
>> IntrospectionHelper - there are already plently of libraries for doing
>> introspection, some using advanced features we can't include because of
>> dependencies ( JDK1.3, other libs ). There is also JMX who defines a
>> special mechanism for setting attributes ( if someone would want to
>> transparently support JMX components as tasks - in commons-modeler for
>> example :-).
>
> Hmmm, seems like FlexibilitySyndrome, where anything can be a Task...
> but on the other hand it's really quite cool, 'cause anything can become
> a task without implementing Task... cool, very nice. It could be used
> for example to use JSP taglibs as tasks, no?
:-)
Well - anything can be a Task already ( if it has an execute() method ).
That's "flexibility syndrome" from before ant1.0 I think.
The "core" of ant consist of loosly coupled components - combined with some
simple and flexible beans patterns.
There are 2 benefits of a pluggable IH: ability to use a more efficient
implementation ( if anyone cares - maybe testing or other non-build uses
of ant ). And ability to extend or adapt the patterns. Long ago I proposed
a "do" attribute that would allow "adapted" tasks ( i.e. not extending Task)
to use a different method ( start, stop, action, etc - execute is the
default ).
JMX is very interesting because it works on almost the same principle
as ant: you have simple mbeans, no need to implement any JMX-specific
interface, you have dynamic mbeans that implement an interface, and you
have model mbeans that are similar with the TaskAdapter-based tasks.
And given the potential adoption of JMX ( tomcat is using it heavily
already, and tomcat5 will be fully JMX-based - j2ee requires it, most app
servers, many other apps ) - it makes a lot of sense to have a good ( and
simple ) way to use it in ant ( for testing, control, automation - probably
less for actual compiling ).
Currently I'm trying an mlet-like syntax:
<mbean name="tomcat:type=Server" code="o.a...." />
<jmx-attribute objectName="tomcat:type=Server"
attribute="port"
value="8080" />
I think an ant syntax may be more intuitive:
<mbean id="tomcat" name="" code="" />
<tomcat port="8080" />
Or even have the <mbean> declaration implemented in an antlib plugin.
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
