> From: Conor MacNeill [mailto:[EMAIL PROTECTED] > > > 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
