ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: cvs commit: jakarta-ant-myrmidon/framework/src/java/org/apache/myrmidon/framework/filters
Date Thu, 25 Apr 2002 02:48:54 GMT
On Wed, 24 Apr 2002 15:31, Adam Murdoch wrote:
> > > >   Combine role short and long names, so that a role has one name
> > > > only:
> >
> > Dont throw away the long names. If you are going to remove one version of
> > the names then remove the short version as that s only a logical name
> > while the Role name coresponds to interface classname.
> Yes, but using the classname becomes meaningless when the roles are spread
> across different classloaders, and becomes unworkable when multiple
> versions of the same role class need to be referred to (e.g. when multiple
> versions of an antlib are being used, or when multiple versions of the
> container api are being used).  

Currently there can not be multiple roles with same classname but different 
classdata and I can't honestly see where it would be viable. Java is not 
designed to work that way and I can't remember where versioning of single 
interface has ever worked except in big application servers.

Currently the ClassLoader issues are far from being solved and until we go 
there I don't see any need to burden the rest of the system with 
complexitites until we know we are going to use it.

Given that the classname is not meaningless - it accurately describes exactly 
what the role is ;)

> The other case where the classname
> convention isn't
> particularly useful, is where the role is untyped, and has no associated
> interface (as data-type might end up, say).

I would be opposed to untyped roles but you knew I would say that :)

> Given these things, the long name is also just a logical name for the role.
> At the end of the day, the long and short names both have the same
> semantics - each is simply a unique logical name for the role.  The longer
> ones mean less chance of name collision, the shorter ones are easier for
> humans to use. And neither of them really solve the problem.  Hence going
> with the shortname, and ..

The longer ones map to physical representations. It is easy to verify if a 
component actually implements service by checking the interfaces implemented 
by component and see if one of them has same name as role (minus any 
decoration if necessary).

> > The only purpose of the shortname is to make writing deployment
> > descriptors easier. It should not be used in our code at IMHO.
> There's also anywhere that a human needs to refer to a role.  Right now,
> there's <import type="roleshorthand" ... > and <typedef
> type="roleshorthand" ... >, but there's no reason we won't be adding more
> places.

Right - which is exactly why short names were put in ;)

> > > In the meantime, using a single name for a role makes dealing
> > > with roles heaps simpler.
> >
> > I disagree but as long as you put the long names back in there I can live
> > with it ;)
> You don't agree that using a single name is simpler than using 2 different
> names? (don't forget that the 2 names are not interchangable - you have to
> remember which one you can use where, and know how to map short -> long and
> vice versa).

Basically ;) In the code you talk the classname which can easily map to the 
physical representation of role (ie the interface). In the UI you use the 
short name as the classname is too much of a PITA for users to use. 

If you are a user you need not know about physical name or suffer through 
ClassLoader hell. If you are a develoepr you need not know the logical name.


Peter Donald

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message