Roles

What is a role

I am quoting here Jose Alberto Fernandez 26.04.2003 22:05: Roles allow defining families of objects (members of a role) that can be used by tasks or inner elements developed separately. The developer of the object accepting a particular role as a subelement has no knowledge of the implementation of the object but much more importantly it has no knowledge of the XML element tag used to refer to this subelement in the XML file.

In the antlib proposal, there are two preset roles :

task
datatype

Examples of other roles are :

mapper
filter

What does it all mean? It means we can now write a task, well typed, which can be accept different XML subelements depending on the declarations of other objects present on the build. The vendor specific elements of <ejbjar>, <jspc> and others are typical examples of where this capability can be very useful. Other parts of core could benefit of course.

What do they do that is no possible in ANT

They allow IntrospectionHelper to connect an XML subelement eventhough introspection cannot find a create or add/Configured method for it. It is a well typed methanism, the parent object will only be passed objects that it knows how to deal with. And the parent object does not need to have any knowledge of what currently available members are on the role.

roles versus DynamicConfigurator

The closest thing in ANT today is DynamicConfigurator but its purpose is on the other way around. Given an elementTag with no matching method it is up to the parent object to try to make sense of it. If we were to use this mechanism to accomplish what roles try to do, it would require the parent object implementor to be aware of where to find the correct definition (remember it is a 3rd party implementation) and perform the creation. It will be also its responsibility to resolve type conflicts, name collisions, etc. This are all things that should be done by IntrospectionHelper directly.

Also notice that Roles do not supersede DynamicConfigurator. On one hand roles let external implementations to be considered as possible subelements of a parent object, on the other hand, DynamicConfigurator allows a node to decide given its current state what is the meaning of a particular element. This cannot be done by roles in the general case, and that is good.

Implementation of roles in the proposal

this section quotes Jose Alberto Fernandez

Here I may deviate from the exact code and add thoughts about where do I think it should go.

Usage of Roles

The principle is very simple:

A role is defined by an interface. This interface is the parameter for a new special family of addConfigured(<interface>) methods.
When IntrospectionHelper fails to find a create/add method for the element, it will look at all the roles used in the addConfigured methods and on each of those roles will try to find an object declared with that element-tag name. If one and only one match is found then the instantiation is successful and the new object will be configured; otherwise it is an error and parsing stops.
The configured object may or may not implement the Role interface, if it does not, an Adaptor object may be instantiated as a proxy for the object. Which adaptor is used depends on how the implementation was declared.
The resulting object is passed as an argument to the addConfigured() method.

Declaration of roles

A role definition associates a name with an (Interface,Adaptor) pair. The only reason for associating a name with the role is to ease notation when declaring members of a role.

Notice that the same interface or the same Adaptor may appear in multiple declarations. This only means that depending on the name used the adaptor of choice will be different.

There can only be one pair associated with each name.

Declaration of implementations (members)

A class is declared as belonging to a role by specifying the name to be used when appearing in that role. The same class may belong to multiple roles and may specify the same or different names on each one.

The name used for the role during the declaration only determines which Adaptor will be available, if required.

Within a role-interface there can only be one object associated with each name.

Scoping rules

This is probably the more dificult aspect since given the way <ant> and <antcall> work it means possible redeclarations on every level of recursion. Whether declarations should just supercede one another or be smarter is something to look into.

Syntax

I have left out the issues of how the syntax looks like on purpose.

Syntax is just that and I am sure we can reach agreement somehow. It is also clear that we should provide tasks to define roles and declare members of roles direclty on the build.

Making ant aware of tag/role/class associations

The antlib proposal says : Let's declare explicitly that a tag can be used in a particular role and is implemented by a specific class. The declaration happens inside antlibs in the file META-INF/antlib.xml

  <filter name="escapeunicode" class="org.apache.tools.ant.filters.EscapeUnicode"/>

CM says : A normal typedef is enough to make ant aware of the existence of the class org.apache.tools.ant.filters.EscapeUnicode. Due to the fact that EscapeUnicode implements ChainableReader, the association between EscapeUnicode and the filter role does not need to be stated explicitly.

Method names in parent classes supporting roles

There is a discussion about how methods to add nested elements of a specific roles in a parent class should be called, and what their signature should be like.

CM : addTYPE(TYPE) for instance addChainableReader(ChainableReader a)

PR: to add an element before its own attributes and nested elements are configured. void add(TYPE) to add an already configured element void addConfigured(TYPE)

in the ant code of 1.6 : public Object createDynamicElement(String name)

Cardinality problems

One tag, several implementations

The <weblogic> element in <ejbjar>, <jspc>, <serverdeploy>, has different meanings.

This is an argument to introduce roles in ant, and to associate an XML tag with a role and an implementation class.

Parent classes accepting one interface in different functions

As an example, the dependset task accepts nested filesets for two different functions :

source
target

Stefan Bodewig/Costin Manolache suggest :

 <dependset>
   <zipfileset ant:type="srcfileset">
 </dependset>

adapters

The antlib proposal mentions adapter classes, which would be connected to roles. Costin Manolache says that adapter classes should be tied to components, not roles. The reason : two different components implementing the same interface (AKA role) can require different adapters.

role proposal

slightly modified version of something writte by Jose Alberto Fernandez

<role name="roleName" className="...." [adapter="...."] />
<!-- I have added the possibility to declare a specific adapter per component to take into account what Costin said -->
<component name="elementName" role="roleName" className="....."  [adapter="...."] />