ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [myrmidon] declaring roles in typelibs
Date Thu, 31 Jan 2002 08:02:56 GMT
On Thu, 31 Jan 2002 17:26, Adam Murdoch wrote:
> > How do you intend to solve the ClassLoader problem - namely can a
> > role only
> > be used by types in the same type library?
> ClassNotFoundException :)

ahh ;)

> For the time being, there's a work-around - rename your typelib to .jar and
> drop it into lib/.


> Longer term, we could do a few things:
> * Allow a typelib to declare itself 'public', so that its classes are
> visible to all the other typelibs.

runaway! runaway! ;)

If something is public then it should just be renamed to jar and placed in  
lib directory and users should accept all the risk associated with that.

> * Or, allow a typelib to declare its dependencies.  Either in the
> descriptor, or in the manifest.  The dependencies would be made visible to
> the typelib (except that multi-parent classloaders might be asking for
> trouble?).

This is possible and already there today - see ExtensionManager ;) Uses the 
standard Optional Package mechanism for dependencies.

However this still does not address the idea of how to share the Class 
objects - this just recreats duplicate instances of class. Inter-antlib comms 
is still possible but it will have to go through a proxy-like system which is 
possibly a bit much ;) 

Anyways we can try stuff out and see how it works.

> I suspect the need for the distinction between roles and types could go
> away if we introduce a type heirarchy - roles are just higher up the type
> hierarchy.  Just a thought.

I disagree but it is worth a try ;)

> > +1
> > As long as they can still construct their own ClassLoaders and explicitly
> > pass in their own registrations. ie If Want to compile atask and
> > then can't
> > bothered to create an antlib I still want to be able to taskdef it?
> Absolutely.  Deployer now allows you to deploy from either a ClassLoader,
> or a File.  They may, but don't have to, contain role descriptors, or type
> descriptors, or both.  There's a bunch of new deployX() methods, so you
> can:
> * Deploy everything in the typelib.
> * Deploy a single type by role/name.  Similar for a converter.
> * Deploy a single type or converter, by explicitly supplying all required
> info.
> What I'd like to do later is add config beans for type, converter and role
> definitions, so that the DefaultDeployer (or a def task for that matter)
> can build them by introspection.  And so we can add stuff to the
> declarations, without having to change the deployer or the def tasks.


> > > * Add TypeManager.registerType( Class roleInterface, String typeName,
> > > TypeFactory factory ), to avoid the type manager having to deal with
> > > classloaders to find the role interface.
> >
> > +0.5 Though something feels a bit icky about this too ;) I think
> > I just have
> > an extreme allergy to passing around Class objects after being
> > burned several
> > times in the past after doing so ;)
> Fair enough.
> Another option is to get rid of the check in MultiSourceTypeFactory that
> makes sure that the instantiated object is an instance of the role
> interface.

I like this check as it offers  early warning system rather than getting a 
wierd reflection error later on. If it turns out to be a wrond idea then we 
can always refactor it away ;)



"You know what a dumbshit the 'average man' on the street is? Well, by
definition, half of them are even dumber than that!"
					J.R. "Bob" Dobbs

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

View raw message