Peter Reilly wrote: > Subject: classloader for 1.7 > > If it is not a little too late, I would like to get a vote on > including classloader into ant 1.7. > (http://issues.apache.org/bugzilla/show_bug.cgi?id=28228)
I've been reading through the documentation on the proposed classloader datatype. My initial reaction was positive and content demonstrates an understanding of the issues involved - however - the initially good feeling moved to a bad feeling as I dug deeper into the proposal. If I have understood things correctly - the classloader datatype provides support for (a) the creation of classloader based on the supply of parent classloader identifies and data resolvable to resources urls, and (b) modification of the state of new and existing classloaders including the system classloader, the classloader established for Ant (the project loader), the context classloader and a couple of other variations on the theme. In my experience the only time I need to modify a classloader is the special case of the system classloader - for example a task that requires a class to be mounted at system level (e.g. URL handler, or XML resolvers, etc.). For *all* other cases the creation of a new classloader at the level of a taskdef is sufficient (although I do recognize that the current taskdef model does not allow this at a script level). My primary concern is the introduction of potential modification of the Ant project classloader state and the impact this can have on classloaders created as children of the project classloader. For example, if an antlib developer publishes a task with the intention that the task be loaded in a classloader created as a child of the Project classloader and another task developer assumes Project classloader extension for a different tool - then the classloader structure created by the first developer can be completely corrupted (e.g. a class added to the Project classloader will be used instead of a class in a child classloader - thereby destroying the runtime integrity). The more I think about this the more I think that we are not dealing with the potential to "shoot oneself in the foot" - but more probably is the scenario where we are creating the potential for "stepping on a landmine". I think that the subjects of system classloader expansion and antlib loading are valid concerns and need to be addressed - but they need to be address as integral elements of the antlib task semantics and implementation. My conclusion is that <classpath> proposal should not be included in 1.7. Cheers, Steve. -------------------------- Stephen McConnell mailto:[EMAIL PROTECTED] http://www.dpml.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
