Jose Alberto Fernandez wrote: > The only issue here is how to retrofit all the tasks to be able to use the > new feature, that is quite a big job, I think.
Using the Path.getCachedClassLoader() is almost the same thing with using Project.getReference(..) or a new API. I don't think all tasks will need to be modified - only few of them. I already made a change in Project to create the task instance just before use - and to use the 'core' loader. I think that would take care of a lot of use cases. > This is why I proposed modifying <path> or maybe making <classloader> > extend <path>, that way we would hardly need to do any changes to the > using tasks and could embed all the glue necessary on AntClassLoader.java > itself. <classloader> should extend <path>, I agree. But I think it would be cleaner to keep them separated ( as syntax ). I don't understand very well what you need ( use case ), most of my use cases are covered by the existing code. Tasks that use a separate loader should include the reference to the class loader they want or use the core loader. The code change is very small, and AntClassLoader already have the ability to change its path at runtime ( i.e. add more locations ). > If you pass to the constructor a <classloader> as the Path instance, it > will just delegate all calls to that ClassLoader and efectively implemet > sharing eventhough the code still thinks it is creating separate > ClassLoaders all over the place. Passing something to a constructor is certainly not a good idea :-) I think using a ref is the cleanest solution. BTW, don't forget the thread class loader :-) > Maybe there is a better way, some of the tasks do really strange things > with their Path instances. But hey lets keep on talking. > :-) It would help if you send some specific use cases ( that are not covered by existing code and would need changes in AntClassLoader ). I'm not sure what limitations you see in using a classloader ref. <taskdef> creates the loader implicitely, but you can easily add a <classloader> task to create explicitely whatever loader you want and use whatever id ( you can also specify a parent id, delegation, etc ). My biggest concern is to keep the syntax intuitive and simple - so I can replicate the same syntax in tomcat config file :-) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
