ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: antlib
Date Wed, 21 May 2003 15:02:22 GMT
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
> 
> 
> Well I am glad to hear I am wrong. Until 7 days ago, the code 
> in your proposal 
> was this (Project.java)
> 
>     public Object createInRole(Object container, String type) {
>         Class clz = container.getClass();
>         String roles[] = symbols.findRoles(clz);
>         Object theOne = null;
>         Method add = null;
> 
> It certainly implies the roles are associated with the 
> Container class, not 
> the nested "type" name. findRoles is checking if 
> Role.isImplementedBy(container class). 
> 
> Right now that method has been removed from Project.java and 
> nothing I see 
> calls findRoles. Actually I don't really understand how the proposal 
> currently hangs together. 
> 

It probably does not. There has been so many changes since originally
written that I think something fell out when the last port was done :-(

In any case, the intent of the proposal :-) and the snippet of code above
was to first find on the container which roles it supports (notice the
use of support and not implements), this is the list of roles for which
the container has a method of the form addConfigured(InterfaceOfRole).

Even if the container has only one such method you may finish with multiple 
roles because of multiple role declarations. And you can have multiple
declarations because each may provide a different Adaptor.

The thing is that the symbol
tables where the information was stored have already preprocessed some of
this information and hence the check looked funny (so much for not having 
documented the code properly at the time).

Whatever we adopt, it definetly need to be written from scratch. :-)

> >
> > The reason had to do with been able to deal with object 
> (classes) that may
> > implement multiple interfaces. The code should not pick just
> > any arbitrary interface for which it happens to be an
> > addConfigured(Interface) in the container and just use it. 
> If the object
> > implements 5 interfaces for which we have 
> addConfigured(InterfaceN) which
> > one should we used? Definetly it should not be taken by 
> chance. Part of the
> > reason
> > for the infrastructure is to try to minimize this cases and 
> allow users to
> > resolve when this issues arise.
> >
> 
> Won't this be relatively rare (i.e. a class implementing 
> multiple interfaces 
> being passed to a task accepting more than one of those 
> interfaces)? If the 
> nested element is implementing multiple interfaces won't it 
> also support 
> multiple roles? Or do I need to typedef the same class into 
> two different 
> typenames, one for each role. So, if my circle also implements a 
> org.apache.demo.BlockInterface interface, will it support the 
> "block" role. 
> Is it (extending Antoine's example)
> 
> <roledef name="block" class="org.apache.demo.BlockInterface"/>
> <typedef name="circle" class="org.apache.demo.Circle" 
> role="shape, block"/>
> 
> or
> 
> <roledef name="block" class="org.apache.demo.BlockInterface"/>
> <typedef name="circle" class="org.apache.demo.Circle" role="shape"/>
> <typedef name="circleblock" class="org.apache.demo.Circle" 
> role="block"/>
> 

If there are tasks that concievably may support both roles, then you
most probably will want to provide separate names for the roles.

If on the other hand, it makes little sense to have them in the same task
(like the roles for <jspc>, <ejbjar>, <serverdeploy>) then one could
think of using the same name (although you may prefer using different
classes altoghether).

> The first option would mean roles are no better at selecting 
> a method than a 
> search based on the implemented interfaces. The second would 
> be OK, but I 
> think we are getting pretty messy. An instance supporting 
> multiple interfaces 
> can't be passed to different tasks using different 
> interfaces. A circleblock 
> instance could not be passed to a task taking a 
> ShapeInterface, because it is 
> not in that Role. A class supporting multiple interfaces is 
> probably intended 
> to be used as both types of objects at different times. 
> 

But that is why you have a "circle" name for it. The name determines the
role you want it to play, the object class behind is the same.
In other words the second option is the one defined by the proposal.

You could even reuse the same object on diferent roles.

<task1>
  <circle id="circleBlock">...</circle>
</task1>
<task2>
  <circleblock refid="circleBlock"/>
</task2>



> How does the multiple role situation "allow users to resolve 
> when this issues 
> arise"? What am I missing?
> 

In the old original proposal there was this concept of user renaming
when the antlib is loaded by <antlib/>. The idea was that no matter
how well design the 3rd party library is, you can always have a situation
where a user combines antlibs or defines a new task and you get some of 
this clashes (e.x.: <ejbanddeploy/> which combines <ejbjar> and <deployserver>)

For those cases, the user could override a definitions and assign a diferent
name for an element (diferent from the one specified in antlib.xml).
That way (and because you can separate names per role) a user could 
recover even in the worst cases. Ultimate control of the element names
is on the buildproject writer.

This is why I fill strong about NS being ultimately under user control,
because he is the one doing the mix and match, the 3rd party writer has
a very limiter view of what is out there and definetly cannot cover
everything.

> Overall, I still see it as a lot of complexity for the 
> exceptional case.
> 

It may be possible to simplify, but I think it is important to look
at the whole picture. More than once we have finish patching ANT
a million times, just because we start with such simplistic view
that at the first real heavy usage the thing does not work as people expect.

In particular with something that will finally open up 3rd party
developmnet and integration with force, we need to try to cover a much as
possible. Every time we say "in this case we do not know what to do" we need
to think, what could a user do to solve the problem and being able to 
continue (with no changes to the antlibs).

Jose Alberto

Mime
View raw message