Guys,
Two years ago (or was it three?) this proposal got nowhere because
it got picked appart to death. And at the end sat there and we finished
with no antlib of any sort.
I am really tired of that and have no energy for that again. I will try to
explain you with what I think it is an intuitive example of how the whole
thing fits toguether. See if ths may work as an starting point, if it does
lets get this sucker in and then nick pick the detail and change it all over
until everyone is happy. If not let just remove it from CVS, forget about it
and someone else can design a different approach from scrath; unless Antoine
wants to keep defending and so on. I do not have the energy for it.
For this example I will put asside the issues of BC which I think we can always
solve (we always have).
1) Let assume we define in core a role used by conditions as part of the
classes implementing conditions, this means that antlib for the core has
something like:
<antlib>
...
<role name="condition"
classname="org.apache.tools.ant.role.Condition"/>
<!-- and a bunch of declarations of conditions -->
<condition name="not" classname="....."/>
...
</antlib>
2) We have the nice ant-contrib library which provides those fabulous tasks we
adore:
<antlib>
<task name="if" classname="net.sf.ant.If" />
...
<antlib>
in this library the If class expresses the fact that it accepts a condition an
one of its
elements by just having a method like:
public addConfigured(org.apache.tools.ant.role.Condition c) {}
the name of the method is irrelevant to this discussion it is just some well
known name.
The only thing the ant-contrib library needs to know is that whatever its pass
to it
implements the role and therefore it can just call the expected method and
that's it.
3) There is now this amaizing.com company that has this beans that you can use
to query
about all kinds of things on an operating environment: Was average CPU
utilization above
95% within the last 5 min? Was latency on the local area network above some
threashold
during some period of time? Is a device more than 98% full? Amazing stuff, all
from java.
Of course, they want to provide this as ANT conditions that you can use from
their antlib.
Their objects are configure following the Beans pattern and getting the yes/no
response
follows an API of their own (their own interface). So what does amizing.com has
to do?
a) Create wrappers for every one of their classes that implement the
Condition role.
(A maintenance nightmare since every future change on their beans
needs to be
kept in sync on the wrappers).
b) Define ONE Adaptor class "com.amazing.ant.ConditionAdaptor" that
implements the
Condition role and knows how to make the query call on their beans
using their API.
Obviously (b) is much better. So they define their antlib as follows:
<antlib>
<condition name="cpuusage"
classname="com.amazing.queries.CpuUsage"
adaptor="com.amazing.ant.ConditionAdaptor"/>
<condition name="latency"
classname="com.amazing.queries.NetLatency"
adaptor="com.amazing.ant.ConditionAdaptor"/>
<condition name="diskfull"
classname="com.amazing.queries.DiskFull"
adaptor="com.amazing.ant.ConditionAdaptor"/>
</antlib>
That's it, zero pain for the amizing.com people.
4) What does ANT do when if finds something like:
<if>
<diskfull device="c:" threshold="95"/>
<then>
<fail>There is not enough space for the build</fail>
</then>
</if>
Ant will find <if> is a task and instantiate it, then it will take a look
nd find that there is no prefefined <diskfull> element for the task so it will
look at the role methods, it finds that the <if> task accepts the role
org.apache.tools.ant.role.Condition, so it looks in the symbol table for things
declared of that role. If finds there <diskfull>, it instantiates it and
configures
it. It then notices it does not implement the role interface so it tries to
find an Adaptor for it, it finds one. It instantiates the adaptor sets the
configured
bean into it and calls addConfigured(org.apache.tools.ant.role.Condition)
passing
the adaptor.
<if> now is ready to go and has no knowledge of the details of <diskfull>.
5) How about beans executed as tasks? No sweat, the core declaration of the
task role
is something like:
<role name="task" classname="...." adaptor="org....TaskAdaptor"/>
If you define a bean as a task and you do not specify a different adaptor, ANT
will use
this default TaskAdaptor which is the code that knows about execute().
But you could define a different Adaptor based on java.lang.Runnable for some
other
beans that work that way.
So this is the end of my example, notice that the ANT code treat everything
that same way
there is no special this or that, there is no special magic, we can think of
additional
features but they are additional and we can add them as we go.
So let me know what you think and if this would fly or not and lets move on.
Jose Alberto
> -----Original Message-----
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> Sent: 23 April 2003 18:48
> To: [EMAIL PROTECTED]
> Subject: RE: antlib
>
>
> Jose Alberto Fernandez wrote:
>
> > This is exactly the point, we should try to type things. Roles
>
> Why ? We have components that can be used in any role. Metadata can
> be extracted and used in a variety of ways - descriptors, interfaces,
> runtime calls ( like in the 3 kinds of mbeans ). But in the
> end the user
> of a component decides in what roles he wants to use it and how.
>
>
> > are this typed interfaces expected by the set/add method.
> The component
> > being declared of a particular role, may or may not implement the
> > interface. If it does cool; if not an adaptor will be used
> to bridge the
> > gap. It is upto the adaptor to decide if the bean is
> compatible or not.
>
> +1 on this part
>
>
> > The guy writing the container (the thing with the set/add
> methods) does
> > not have to deal with introspection or anything of that. As s/he
> > shouldn't. But by allowing adaptors someone can take some
> cool object and
> > bridge it.
>
> I think the "container" is ant. Not sure who should write the
> adapters -
> IMO ant can support this automatically ( by introspection
> since we can't use
> 1.3 features).
>
>
> > So, since now this objects come from somewhere else, if it
> is not typed
> > somehow, any object expecting an instance of the role need to do
> > introspection by hand. Not good.
>
> No. It is easy to provide this service in ant - just like it
> is done in
> JMX. Code using JMX never does introspection - just calls the "invoke"
> method. If JDK1.3 is used, he can get a proxy that implements
> the desired
> interface. ( I think it can be done for JDK1.2 as well, but a
> bit harder ).
>
>
> Costin
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
