Jose Alberto Fernandez wrote: > Costin, I think we agree more than you think, > so I will try to explain myself a little more:
I think we are just discussing alternatives and use cases- and the good/bad for each one. After we know all options we can agree ( or disagree ) on one :-) We seem to agree that we need to solve this problem. > The usage of the core loader is fine. Also notice that the additional > methods I suggested for Path (which should be really part of this new > ClassPath or ClassLoader task), are not to be called by the calling tasks > but by deeper infrastructure. So there is no changes to the tasks code. The problem I have - a Path shouldn't have to know about class loaders or have class loader specific code. IMO a ClassPath shouldn't know about class loaders either - you can have the same path used by multiple loaders, and the concepts are different. We need a ClassLoader task - and mechanisms to fine tune the loader options ( delegation, parent, etc ) and a mechanism to have one or several ClassLoaders used by tasks that need it. >> <classloader> should extend <path>, I agree. But I think it would be >> cleaner to keep them separated ( as syntax ). > > I have no problem with that, I agree with you. > So we will have: <path> and we will have <classloader> or <classpath> > (I kind of prefer the latter) which should be used for things that > want a path to load classes. Why do you preffer the latter ? I'm curious, in my mind a classpath (or path) is a different concept from a class loader. One is a collection of paths ( dirs, files, etc ), the other is one object that creates Classes. > This would mean that every <task> that accepts a Path element > today for classes would have to accept something else if they want to use > a predefined classloader. I would like to avoid that. If the cost is mixing the path and loader concepts - I think we'll disagree on something :-) Tasks that use Paths could just construct a classloader and associate it with the path ( that should be few lines of code ). If you need to load classes in a task - you need to create a classloader anyway, and the behavior would be the same if you do Path.createLoader() or ClassLoader.createLoader(Path). > I am talking about the constructor for AntClassLoader which already > has a Path parameter. The point is that if the Path parameter > happens to be a ClassPath (or ClassLoader) instance then it should > try to use its cached java ClassLoader, if possible. And you'll need another parameter to specify if you really want to use the cached loader or not. Having a path associated with multiple loaders is very common ( reloading is all about that - you create another loader from the same path and drop references to the old one ). My primary issue is the separation of the concepts. A loader is not a path, and a path is not a loader. A ClassLoader task may use several path parameters, and may use AntClassLoader as an implementation. > What I am envisioning now is something like: > > <classpath id="compiled-classes"> > <pathelement .../> > <path .../> > </classpath> > > <available classname="my.code" classpathref="compiled-classes" .../> > <available classname="your.code" classpathref="compiled-classes" .../> > > <ejbjar ...> > <!-- this element expects a Path object --> > <classpath refid="compiled-classes"/> > ... > </ejbjar> > > All this things will be using the same ClassLoader cached in <classpath> > but there will be no need for changes in the code of this tasks, > well in most cases. There are some cases where both a path or a loader could be used. That doesn't make them the same thing. For compilation - you need to use a path. For loading classes - you need a loader. For available - you can use either. I don't see a need to have a distinction between path and classpath, but I think it is very important to have loader and (class)path separate concepts. BTW, it is also possible to have a loader that doesn't have any associated path, or has a path that may change during execution ( for example when you load a file from a jar, it may process the manifest and use additiona ClassPath elements ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
