Re: Using classloader for Junit
On Fri, 2003-06-20 at 06:23, Costin Manolache wrote:
> Nick Chalko wrote:
>
> > After I slept on it, I thought of how I could extend the antclassloader
> > to handle the situations I need.
> > I am considering a
> > That will explicitly allow the optional ant task to be loaded in the
> > child classloader.
> > I may even go so far as automatically adding this fileset
> > ${ant.home}/lib/ant-*.jar to the classloader.
> >
> > That should handle the usecase I have in mind.
>
> Are you talking about a single child loader for all optional tasks ?
> This may work - if you use normal delegation. The code that instantiate
> the tasks needs to have a reference to the child loader, and I don't
> think core tasks have dependencies on the classes in the optional.
>
> > peter reilly wrote:
> >
> >>Ah, I see.
> >>That would be nice, but the classloader task is not
> >>yet complete.
Hi Costin,
looking at classloader, it seems to imply that it can
be used at to ant's default classloader, to help in defining
tasks/types.
However when I try to do:
hello
hello
The first myecho works, but the second does not.
Peter.
>
> The part that loads junit.jar to the main loader is complete.
>
> There are other possible enhancements to create arbitrary loaders
> or support reloading which are not yet implemented.
>
> Costin
>
>
>
> >>
> >>Peter
> >>
> >>On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
> >>
> >>
> >>>peter reilly wrote:
> >>>
> >>>
> >>>
> Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
> In essence you need to place the junit.jar file in ${ant.home}/lib
>
>
>
>
>
> >>>I had hoped that was what the task would let me avoid.
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
Costin Manolache wrote:
The part that loads junit.jar to the main loader is complete.
There are other possible enhancements to create arbitrary loaders
or support reloading which are not yet implemented.
That still failed for me.
I tried this
Fails with
$ ant
Buildfile: build.xml
BUILD FAILED
C:\tools\ant-head\tools\antlibs\junit-0.1.1-dev-20030618.antlib\build.xml:12:
ta
skdef: A class needed by class
org.apache.tools.ant.taskdefs.optional.junit.JUni
tTask cannot be found: junit/framework/TestListener
Total time: 1 second
btw my hack to allow optional tasks to be loaded by a childloader worked.
Costin
Peter
On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
peter reilly wrote:
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
I had hoped that was what the task would let me avoid.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Using classloader for Junit
Nick Chalko wrote:
> After I slept on it, I thought of how I could extend the antclassloader
> to handle the situations I need.
> I am considering a
> That will explicitly allow the optional ant task to be loaded in the
> child classloader.
> I may even go so far as automatically adding this fileset
> ${ant.home}/lib/ant-*.jar to the classloader.
>
> That should handle the usecase I have in mind.
Are you talking about a single child loader for all optional tasks ?
This may work - if you use normal delegation. The code that instantiate
the tasks needs to have a reference to the child loader, and I don't
think core tasks have dependencies on the classes in the optional.
> peter reilly wrote:
>
>>Ah, I see.
>>That would be nice, but the classloader task is not
>>yet complete.
The part that loads junit.jar to the main loader is complete.
There are other possible enhancements to create arbitrary loaders
or support reloading which are not yet implemented.
Costin
>>
>>Peter
>>
>>On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
>>
>>
>>>peter reilly wrote:
>>>
>>>
>>>
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
>>>I had hoped that was what the task would let me avoid.
>>>
>>>
>>>
>>>
>>
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
Conor MacNeill wrote: >> >BTW, I don;t really agree with the task being used to >> >modify >> > the effective classpath of running ClassLoaders. I'm sure this will >> > cause trouble too. >> >> Seems to break some of the "properties are immutable" philosophy of ant. > > No - not really an Ant level issue. I am concerned by the scenario where a > classloader with a child can not find a class on the first instance > causing the child to load the class. If that class is later added to the > loader's classpath, it becomes possible for parent to load the class and > then we have a parent and child loader with the same class loaded > > bad stuff happens. That's a pretty common case in tomcat or any container using reverse loaders, and usually nothing bad happens. Jboss is also using a flat loader where classes are added dynamically - and seems to be fine in most cases ( or at least more reliable than other alternative ). The scheme is actually much safer than what jboss is using. I'm sure there will be some combination of loaders where may generate an error, but it's better than any other scheme that I know or tried so far. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
It might appear to work but can fail in subtle ways. I have had instances
where the second invocation of a task would cause an error because it would
bring classes into the VM which were there already leading to two different
class instances with the same classname being reachable (loader constraint
violation).
This can be quite non-deterministic. If I installed a delay, the first load of
classes would be GC'd avoiding the constaint violation by the second
instance. So, I urge caution :-)
Unless I do this I see only two choices
1. put Junit.jar and every other dep.jar in the ${ant.home}/lib
2. remove ant-junit.jar and other optional from ${ant.home}/lib
I hate 1 and I don't wan't to insist users change there ant environment
unless I have to.
I'll see what happens when I try tonight.
R,
Nick
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Using classloader for Junit
On Fri, 20 Jun 2003 01:40 am, Nick Chalko wrote:
>
> The
> if (resourceName.startsWith("org.apache.tools.ant.taskdefs.optional."))
> {return useParentFirst;}
> HACK worked last night.
>
> I will try something a little cleaner tonight.
It might appear to work but can fail in subtle ways. I have had instances
where the second invocation of a task would cause an error because it would
bring classes into the VM which were there already leading to two different
class instances with the same classname being reachable (loader constraint
violation).
This can be quite non-deterministic. If I installed a delay, the first load of
classes would be GC'd avoiding the constaint violation by the second
instance. So, I urge caution :-)
>
> >BTW, I don;t really agree with the task being used to modify
> > the effective classpath of running ClassLoaders. I'm sure this will cause
> > trouble too.
>
> Seems to break some of the "properties are immutable" philosophy of ant.
No - not really an Ant level issue. I am concerned by the scenario where a
classloader with a child can not find a class on the first instance causing
the child to load the class. If that class is later added to the loader's
classpath, it becomes possible for parent to load the class and then we have
a parent and child loader with the same class loaded > bad stuff happens.
Conor
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
Conor MacNeill wrote:
On Fri, 20 Jun 2003 12:17 am, Nick Chalko wrote:
I'll be interested to see if this works :-) I have my doubts. As soon as you
go into the main loader to find the task classes
(org.apache.tools.ant.taskdefs.optional.junit.JUnitTask), you won't be able
to see the Junit classes from the child loader. If you play class loader
games to avoid this then you are headed for LinkageErrors. Forking is almost
always more preferable.
The
if (resourceName.startsWith("org.apache.tools.ant.taskdefs.optional."))
{return useParentFirst;}
HACK worked last night.
I will try something a little cleaner tonight.
BTW, I don;t really agree with the task being used to modify the
effective classpath of running ClassLoaders. I'm sure this will cause trouble
too.
Seems to break some of the "properties are immutable" philosophy of ant.
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
-
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Using classloader for Junit
On Fri, 20 Jun 2003 12:17 am, Nick Chalko wrote:
> After I slept on it, I thought of how I could extend the antclassloader
> to handle the situations I need.
> I am considering a
> That will explicitly allow the optional ant task to be loaded in the
> child classloader.
> I may even go so far as automatically adding this fileset
> ${ant.home}/lib/ant-*.jar to the classloader.
>
> That should handle the usecase I have in mind.
>
I'll be interested to see if this works :-) I have my doubts. As soon as you
go into the main loader to find the task classes
(org.apache.tools.ant.taskdefs.optional.junit.JUnitTask), you won't be able
to see the Junit classes from the child loader. If you play class loader
games to avoid this then you are headed for LinkageErrors. Forking is almost
always more preferable.
BTW, I don;t really agree with the task being used to modify the
effective classpath of running ClassLoaders. I'm sure this will cause trouble
too.
Conor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
After I slept on it, I thought of how I could extend the antclassloader
to handle the situations I need.
I am considering a
That will explicitly allow the optional ant task to be loaded in the
child classloader.
I may even go so far as automatically adding this fileset
${ant.home}/lib/ant-*.jar to the classloader.
That should handle the usecase I have in mind.
peter reilly wrote:
Ah, I see.
That would be nice, but the classloader task is not
yet complete.
Peter
On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
peter reilly wrote:
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
I had hoped that was what the task would let me avoid.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Using classloader for Junit
Ah, I see.
That would be nice, but the classloader task is not
yet complete.
Peter
On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
> peter reilly wrote:
>
> >Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
> >In essence you need to place the junit.jar file in ${ant.home}/lib
> >
> >
> >
> I had hoped that was what the task would let me avoid.
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
peter reilly wrote:
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
I had hoped that was what the task would let me avoid.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Using classloader for Junit
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
Cheers,
Peter
On Thu, 2003-06-19 at 08:43, Nick Chalko wrote:
>
>
>
>
>
>
>
>
> classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask"/>
>
>
> Fails with
> $ ant
> Buildfile: build.xml
>
> BUILD FAILED
> C:\tools\ant-head\tools\antlibs\junit-0.1.1-dev-20030618.antlib\build.xml:12:
> ta
> skdef: A class needed by class
> org.apache.tools.ant.taskdefs.optional.junit.JUni
> tTask cannot be found: junit/framework/TestListener
>
> Total time: 1 second
>
>
> How is this suppose to work?
>
> I see the use parent for org.apache.tools.ant.
> and the then use loader for org.apache.tools.ant.taskdefs.optional.
> But it does not seem to work. Any ideas?
>
> R,
> Nick
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
Btw
I can make this work if I include junit.jar and ant-junit.jar in the path.
And hack AntClassloader.
private boolean isParentFirst(String resourceName) {
// default to the global setting and then see
// if this class belongs to a package which has been
// designated to use a specific loader first
// (this one or the parent one)
// XXX - shouldn't this always return false in isolated mode?
boolean useParentFirst = parentFirst;
// HERE IS MY HACK
if
(resourceName.startsWith("org.apache.tools.ant.taskdefs.optional."))
{return useParentFirst;}
for (Enumeration e = systemPackages.elements();
e.hasMoreElements();) {
String packageName = (String) e.nextElement();
if (resourceName.startsWith(packageName)) {
useParentFirst = true;
log(resourceName+" is a system package["+packageName+"
in"+systemPackages+"] use parent loader",Project.MSG_DEBUG);
break;
}
}
for (Enumeration e = loaderPackages.elements();
e.hasMoreElements();) {
String packageName = (String) e.nextElement();
if (resourceName.startsWith(packageName)) {
useParentFirst = false;
log(resourceName+" is a loader package use this
loader",Project.MSG_DEBUG);
break;
}
}
return useParentFirst;
}
smime.p7s
Description: S/MIME Cryptographic Signature
Using classloader for Junit
Fails with $ ant Buildfile: build.xml BUILD FAILED C:\tools\ant-head\tools\antlibs\junit-0.1.1-dev-20030618.antlib\build.xml:12: ta skdef: A class needed by class org.apache.tools.ant.taskdefs.optional.junit.JUni tTask cannot be found: junit/framework/TestListener Total time: 1 second How is this suppose to work? I see the use parent for org.apache.tools.ant. and the then use loader for org.apache.tools.ant.taskdefs.optional. But it does not seem to work. Any ideas? R, Nick smime.p7s Description: S/MIME Cryptographic Signature
