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/.
kool.
> 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.
excellent!
> > > * 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 ;)
--
Cheers,
Pete
"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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
