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 Fri, 26 Apr 2002 08:11:28 GMT
On Thu, 25 Apr 2002 14:46, Adam Murdoch wrote:
> On Thu, 25 Apr 2002 12:48, Peter Donald wrote:
> > Currently there can not be multiple roles with same classname but
> > different classdata
> Yes, I know.  Doing away with that restriction is the whole point.

good luck - your gonna need it ;)

> > and I can't honestly see where it would be viable.
> We are awful close to being able to drop in two different versions of an
> antlib, and have it work.  Not necessarily in the same project, but
> certainly across projectrefs or <ant> calls.  The main issue is naming -
> obviously this isn't going to work if we have a global role namespace.

Well the RoleManager needs to be scoped at the same level as the Shared 
ClassLoader. If we allow projects to have different Shared ClassLoader 
instances then we can allow them to have different RoleManagers. I hadn't 
really thought about that. Not sure it would be useful but maybe ;)

> > Java is not designed to work that way
> No?  Bugger.  That's going to make things harder, I guess :)

I tried for close to two years :)

If you look in Phoenix you will see all sorts of versioning support for both 
services/interfaces and blocks/components and dependencies between were also 
versioned. However the ClassLoader magic required ended up being too much,  
and nobody used it anyways ;) Minimal support still exists in the metadata 
layer but that is also relatively unused.

The only real place I have seen this sort of versioning occur in real 
applications is in application servers that supported multiple versions of 
specs (ie servlet 2.2 vs servlet 2.3 had backwards incompatabilities so they 
had multiple containers). However they did it at arms length and allowed zero 
interaction between the two systems.

> Ok. I'm not planning on ignoring complexity.  What I'd like to do is to
> *try* to solve the issues we have with roles (can't have more than one with
> the same name, can't have a typeless role, that kinda thing), without
> impacting complexity too much.  If it turns out to be horribly complex,
> then, we just have to let it go.  I think it's worth exploring.

As I said - good luck ;)

> > Given that the classname is not meaningless - it accurately describes
> > exactly what the role is ;)
> Fair enough.  Not meaningless.  But not any more meaningful than the short
> name, either.

Sure it is. You can check if a class satisfies a role by simply by munging 
role name and checking all the interfaces that the object supports. If the 
object does not support have a interface with same name as munged role name 
then we know there has been a configuration screwup. However shortnames 
require lookups in a registry and other magic and that means there is more 
places in which errors can be made.

> > I would be opposed to untyped roles but you knew I would say that :)
> Yeah, I knew.  Would you be opposed to making them available to task
> writers to use, without us using them in myrmidon, and provided they fell
> out of whatever role solution we come up with?

The main reason I oppose them is that the only solutions I can think of imply 
way to much ClassLoader hackery or they imply that users have to know about 
hierarchies rather than flat catgories. If you can come up with a solution 
that does not have those characteristerics then I will be into it :)

> > 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.
> You do if you are writing something that sits between the user and the
> internals.  Like, say, a task.  Or if you happen to be working on the
> infrastructure: What's this name here?  Is is a short name, a long name, a
> class name?  Ug.

The only place a task writer should need to care about a shortname is when 
they are writing TypeDef style tasks - actually even then it shouldn't be 
needed. To be honest I can't think of a single instance where a taskwriter 
needs to know about shortname ... except for XDoclet/documentation of task. 
And I plan to remove the need for shortname in XDoclet process.

Where else do you see taskwriter needing to know the shortname?


Peter Donald

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

View raw message