Opps, I hit "Send" instead of "Save Now",
to finish:
We do not have control of the classes loaded in
the Project classloader when ant is called from
the java api, so we cannot make a "the transitive closure of Project".
I think however that ant-launcher can initialize the componentclassloader
with the optional jar files and any files from ~/.ant/lib and those
on the -lib command line and not place them in the classloader used
for Project.
I have a fix for the problem with BSF, ScriptRunner does not
set the Managers classloader, so BSF uses the classloader
of the Manager class to load the language.
Peter
On 9/1/06, Peter Reilly <[EMAIL PROTECTED]> wrote:
I do not want this to be too complicated.
The component classloader should delegate everything to its parent
classloader (the Project.class.getClassLoader()) except for ant's optional
tasks and types.
Ant code has no control over the contents of the classlaoder for
project, it is set up differently in the different IDEs, embedded
ant and ant called from ant(.bat).
A number of projects set up ant using the java api, in this case
we do not have control of which classes of ant are used in
the project classloader context
On 8/31/06, Jesse Glick <[EMAIL PROTECTED]> wrote:
>
> Peter Reilly wrote:
> > I have done a prototype and the results look good:
>
> Does indeed look safer to me.
>
> > b) it intercepts classes with "optional" or "ScriptRunner" in the
> > name and loads these from itself rather than from the parent
> > classloader.
>
> Note that you could exclude all of .taskdefs.** if we just cleaned up
> Ant a bit so that core classes do not refer to any taskdefs. Such a
> cleanup could also be enforced using Lattix or a similar tool, or by
> rearranging Ant sources a bit so that class loader separation is
> mirrored in the physical structure of the project. Of course this kind
> of cleanup could be done at any time.
>
> > <appendcomponentpath>
>
> Workable if a bit verbose. Not sure "component" is very intuitive. Want
> to emphasize analogy to -lib cmdline option.
>
> > <appendcomponentpath>
> > <fileset dir="${ user.home}/lang/bsf" includes="*.jar"/>
> > <fileset dir="${user.home}/lang/beanshell"
> includes="*.jar"/>
> > </appendcomponentpath>
> > <script language="beanshell">
> > System.out.println("Hello world");
> > </script>
>
> Cool.
>
> > a) adding more strings to intercept (fragile)
>
> Alternately, use a positive rather than a negative pattern. More
> specifically: enumerate all packages/classes which should be loaded by
> the core loader, e.g. the transitive closure of Project plus perhaps a
> few things. For all other classes, the component loader should use the
> same classpath entries as the core loader but not delegate. That would
> mean that the component loader would be used for
>
> - all standard tasks
> - all types (incl. filters, conditions, etc.)
> - all standard optional tasks and types
> - anything else given in -lib or ${ant.home}/lib etc.
> - anything else specified in <appendcomponentpath>
>
> This would prevent the problem you mention with -lib bsf.jar +
> <acp>beanshell.jar</acp>, since bsf.jar, beanshell.jar, and
> ant-apache-bsf.jar would all be loaded in the component loader.
>
> Such a separation could also be done on a JAR basis, i.e. check the code
> source (ProtectionDomain/CodeSource) of each class and only use the core
>
> loader for ant.jar, ant-launcher.jar, and (perhaps) the bundled XML
> JARs. Optionally, also split ant.jar into ant-core.jar +
> ant-standard-tasks.jar.
>
> -J.
>
> --
> [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org
> http://google.com/search?q=e%5E%28pi*i%29%2B1
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
