Re: antlibs and classloaders #2
I meant to respond to this earlier, but did not get the chance.
1) use of classpath in an antlib.
I have tested using a classpath within an antlib:
~/.ant/lib/x_call.jar containing:
x/antlib.xml
antlib
typedef resource=x/antlib.xml
classpath path=${user.home}/apps/x/x.jar/
/typedef
/antlib
This works fine, but depends on a possible bug in ant
see: bugzilla 28782
http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
The problem is that the typedef in the antlib should pick up
two antlib.xml resources, the one in ${user.home}/apps/x/x.jar
and the one in x_call.jar (itself). This will should
cause no-ending recursion.
The bug means that this does no happen - the resources in the parent
classloader are currently not visible to the child classloaders.
If the bug is fixed, an infinite recursion will happen.
This could be stopped by typedef checking if it has already been
executed. This can be done by using user properties - but this
will pollute the property names, or by exending (again) Project to
have a map of objects that gets copied to its child projects. Using
non-user properties or references will not work as *ant* tasks can
stop the non-user properties and references being copied to the
child processes. Using a static map in typedef will not work as
sibling projects will incorrectly interact.
2) antlibresolve
I like the idea of antlibresolve:
antlibresolve uri=antlib:net.sf.antcontrib.cpptasks
classpath path=${CPP_HOME}/cpptasks.jar/
/antlibresolve
This would use ComponentHelper#checkedNamespaces to see
if the antlib has been resolved or not, which means that
it can be called many times without a problems.
Using:
project xmlns:cpp=antlib:net.sf.antcontrib.cpptasks
.
.
cpp:antlibresolve
classpath path=${CPP_HOME}/cpptasks.jar/
/cpp:antlibresolve
/project
May be considered as a short-hand (antlibresolve is now a reserved
name and may not be used as a task/type in an antlib).
However:
antlibresolve prefix=cpp
/antlibresolve
is very problematic. - for example the antlibresolve may be in a
macrodef:
macrodef name=resolve
...
antlibresolve prefix=@{myprefix}/
antlibresolve prefix=x xmlns:x=antlib:a.b.c/
...
/macrodef
resolve myprefix=x xmlns:x=antlib:x.y.z/
Peter
Jose Alberto Fernandez wrote:
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
Let me get this right.. this task would define the antlib classes the
moment it is invoked, and it should be used on the top level
buildfile,
this way the subbuilds/subants/ant/antcall targets have the antlib
already loaded, right?
I explain a bit my build files structure for testing:
[snip...]
Up to this moment I need to define the tasks in boths includes using
typedef uri= loaderref=... classpathref=.../ because I
cannot pass classpath to antlibs. I also added in both includes an
ifnotisset property=antlibs.define//notthen...the typedef
stuff. /if to do this only once for all the builds.
I use a lot of subant, antcall, ants and it is very difficult
to control
in all the builds that the do use inheritall=true, since
otherwise the
if would not find the property and redefine the tasks.
Here I would advocate to have the new condition isDefined/
that I mentioned before. Which will not rely on inheritAll
but will look at the definintion dictionalries directly.
Could you put this structure as it would be in 1.6.2 with the
antlibresolve and antlib classpath, at least what you imagine
it might be?
I like the antlibresolve solution, as long as it does not
redefine the
tasks, or at least there is an option not to do so. Would it
be possible
to add to typedef that possibility?
antlibresolve/ the only thing it does is make sure the antlib URI
gets processed. As if you were calling task in the space of the antlib.
Actually on the incarnation as mylib:antlibresolve/
it would have been a noop task whose only side-effect is causing the
loading of the antlib. If you call it 20 times it would only load
the antlib the first time, like any other task would.
(humm this may be still the best solution, just make every antlib define
this task).
How to deal with your classloaders, that is a different thing
completely.
- Is it possible to define them inside the antlib (or are they buildfile
dependent)?
- I had proposed in the past a naming convention to associate a
classpath/loader
with a particular URI. But all this is just open talk at the moment.
- Maybe antlibresolve/ can do some of this, but then its definition is
not as clean
as one would want.
Jose Alberto
Thanks for the help on this matter.
MAriano
Jose Alberto Fernandez wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 10 May 2004, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
Would the following solve this problem generically?
!--
This task is automatically available for every ANTLIB
and its only function is to force the loading of the library
if necessary. Force the lazy loading.
--
RE: antlibs and classloaders #2
From: Peter Reilly [mailto:[EMAIL PROTECTED]
I meant to respond to this earlier, but did not get the chance.
1) use of classpath in an antlib.
I have tested using a classpath within an antlib:
~/.ant/lib/x_call.jar containing:
x/antlib.xml
antlib
typedef resource=x/antlib.xml
classpath path=${user.home}/apps/x/x.jar/
/typedef
/antlib
This works fine, but depends on a possible bug in ant
see: bugzilla 28782
http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
The problem is that the typedef in the antlib should pick up
two antlib.xml resources, the one in
${user.home}/apps/x/x.jar and the one in x_call.jar
(itself). This will should cause no-ending recursion.
The bug means that this does no happen - the resources in the
parent classloader are currently not visible to the child
classloaders.
If the bug is fixed, an infinite recursion will happen.
This could be stopped by typedef checking if it has already
been executed. This can be done by using user properties -
but this will pollute the property names, or by exending
(again) Project to have a map of objects that gets copied to
its child projects. Using non-user properties or references
will not work as *ant* tasks can stop the non-user
properties and references being copied to the child
processes. Using a static map in typedef will not work as
sibling projects will incorrectly interact.
This things sound like we are using the wrong abstraction here.
typedef/ inside an antlib/ should use the antlib classloader
as the parent for any subsequent classloader.
I do not see why that should cause an infinite recursion.
I feel like we have a conceptual mismatch between antlib the jar
with the code, and antlib the resource with the XML definitions.
We are not treating them in a symetric way or as a unit. And
hence we are get into all this conflicting behaviour.
2) antlibresolve
I like the idea of antlibresolve:
antlibresolve uri=antlib:net.sf.antcontrib.cpptasks
classpath path=${CPP_HOME}/cpptasks.jar/ /antlibresolve
This would use ComponentHelper#checkedNamespaces to see
if the antlib has been resolved or not, which means that
it can be called many times without a problems.
Using:
project xmlns:cpp=antlib:net.sf.antcontrib.cpptasks
.
.
cpp:antlibresolve
classpath path=${CPP_HOME}/cpptasks.jar/
/cpp:antlibresolve
/project
May be considered as a short-hand (antlibresolve is now a
reserved name and may not be used as a task/type in an antlib).
You are right, but I like it since it reduces the amount of retyping
of long URIs that we would have otherwise. As, how to treat such
reserve word, is to be automatically added by antlib/ as a
predefined
task of all namespaces.
However:
antlibresolve prefix=cpp
/antlibresolve
is very problematic. - for example the antlibresolve may be in a
macrodef:
macrodef name=resolve
...
antlibresolve prefix=@{myprefix}/
antlibresolve prefix=x xmlns:x=antlib:a.b.c/
...
/macrodef
resolve myprefix=x xmlns:x=antlib:x.y.z/
I see the problems...
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
This things sound like we are using the wrong abstraction here. typedef/ inside an antlib/ should use the antlib classloader as the parent for any subsequent classloader. I do not see why that should cause an infinite recursion. I feel like we have a conceptual mismatch between antlib the jar with the code, and antlib the resource with the XML definitions. We are not treating them in a symetric way or as a unit. And hence we are get into all this conflicting behaviour. I would like to pick from here and try to describe my understanding of the concepts. Antlib: I see this as a a definition of tasks within a namespace that involves all the jars required to resolve the execution of the tasks. To put it plainly, I see it as the antlib.xml with a classpath. So for me that defines completely the antlib and the extra classpath should be added to the antlib classpath. Also, for me is accidental that the antlibs should be located in the $ANT_HOME/lib or in a -lib path, actually the antlib definition should start from the antlib.xml, wherever it is, and then create a classloader based on the antlib definition. For the special case were the antlib jars are located in the base ant classpath ($ANT_HOME/lib or -lib path) I would not allow adding a classpath since the antlib should be completely contained within the base ant classpath, only when the antlib jars are outside I would allow defining an extra classpath. Also, defining antlibs in either way (being inside base ant classpath or outside) should behave the same way, they should be idempotent, meaning that once they are defined, they should not be overriden, I understand that it is not wise to use the same uri for different antlibs, the user should always try to pick unique names for the antlibs, otherwise we go back to a single namespace. This is my understanding of antlibs, it is probably out of synch with what you envision on this, but I wanted to let you know what I thought antlibs were about. My 2 cents. MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
I would agree with you on all points (I think). Mariano Benitez wrote: This things sound like we are using the wrong abstraction here. typedef/ inside an antlib/ should use the antlib classloader as the parent for any subsequent classloader. I do not see why that should cause an infinite recursion. I feel like we have a conceptual mismatch between antlib the jar with the code, and antlib the resource with the XML definitions. We are not treating them in a symetric way or as a unit. And hence we are get into all this conflicting behaviour. I would like to pick from here and try to describe my understanding of the concepts. Antlib: I see this as a a definition of tasks within a namespace that involves all the jars required to resolve the execution of the tasks. To put it plainly, I see it as the antlib.xml with a classpath. This classpath could be defined by a antlibresolve/ task. So for me that defines completely the antlib and the extra classpath should be added to the antlib classpath. Also, for me is accidental that the antlibs should be located in the $ANT_HOME/lib or in a -lib path, actually the antlib definition should start from the antlib.xml, wherever it is, and then create a classloader based on the antlib definition. For the special case were the antlib jars are located in the base ant classpath ($ANT_HOME/lib or -lib path) I would not allow adding a classpath since the antlib should be completely contained within the base ant classpath, only when the antlib jars are outside I would allow defining an extra classpath. Also, defining antlibs in either way (being inside base ant classpath or outside) should behave the same way, they should be idempotent, meaning that once they are defined, they should not be overriden, I understand that it is not wise to use the same uri for different antlibs, the user should always try to pick unique names for the antlibs, otherwise we go back to a single namespace. One antlib may resolve other antlibs if antlibresolve was an allowed task in an antlib. Peter This is my understanding of antlibs, it is probably out of synch with what you envision on this, but I wanted to let you know what I thought antlibs were about. My 2 cents. MAriano - 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: antlibs and classloaders #2
Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
I meant to respond to this earlier, but did not get the chance.
1) use of classpath in an antlib.
I have tested using a classpath within an antlib:
~/.ant/lib/x_call.jar containing:
x/antlib.xml
antlib
typedef resource=x/antlib.xml
classpath path=${user.home}/apps/x/x.jar/
/typedef
/antlib
This works fine, but depends on a possible bug in ant
see: bugzilla 28782
http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
The problem is that the typedef in the antlib should pick up
two antlib.xml resources, the one in
${user.home}/apps/x/x.jar and the one in x_call.jar
(itself). This will should cause no-ending recursion.
The bug means that this does no happen - the resources in the
parent classloader are currently not visible to the child
classloaders.
If the bug is fixed, an infinite recursion will happen.
This could be stopped by typedef checking if it has already
been executed. This can be done by using user properties -
but this will pollute the property names, or by exending
(again) Project to have a map of objects that gets copied to
its child projects. Using non-user properties or references
will not work as *ant* tasks can stop the non-user
properties and references being copied to the child
processes. Using a static map in typedef will not work as
sibling projects will incorrectly interact.
This things sound like we are using the wrong abstraction here.
typedef/ inside an antlib/ should use the antlib classloader
as the parent for any subsequent classloader.
In this case the parent is the antlib classloader (it is the default
classloader).
I do not see why that should cause an infinite recursion.
The problem is that the typedef resource=net/.../antlib.xml
classpath path=cpptasks.jar/ /typedef in
the antlib will pick up the antlib.xml resoure that contains typedef
resource=net/.../antlib.xml
task which will pick up .,
This does not happen with the current ant code, as the typedef
resource=net/.../antlib.xml
classpath path=cpptasks.jar//typedef
task will not see the antlib.xml resource in the parent classloader.
Another way to work-around this is for the typedef to use a thread
specific stack to check
for recursive loading of xml resources.
This probally should be done in any case:
recursive.xml
antlib
typedef file=recursive.xml/
/antlib
build.xml:
project
typedef file=recursive.xml/
/project
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlibs and classloaders #2
From: Peter Reilly [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: This things sound like we are using the wrong abstraction here. typedef/ inside an antlib/ should use the antlib classloader as the parent for any subsequent classloader. In this case the parent is the antlib classloader (it is the default classloader). So what happens if the toplevel antlib gets loaded from a different classloader (because I defined classpaths and such). Would the typedef/ inside pick-up that as the classloader? Or would it pickup some default one? I do not see why that should cause an infinite recursion. The problem is that the typedef resource=net/.../antlib.xml classpath path=cpptasks.jar/ /typedef in the antlib will pick up the antlib.xml resoure that contains typedef resource=net/.../antlib.xml task which will pick up ., This does not happen with the current ant code, as the typedef resource=net/.../antlib.xml classpath path=cpptasks.jar//typedef task will not see the antlib.xml resource in the parent classloader. Another way to work-around this is for the typedef to use a thread specific stack to check for recursive loading of xml resources. This probally should be done in any case: recursive.xml antlib typedef file=recursive.xml/ /antlib build.xml: project typedef file=recursive.xml/ /project What is the difference between this and what we do for import/s. In both cases we need to make sure we do not go into an infinite loop. It should not matter whether the XML is an import fragment or an antlib.xml Jose Alberto Peter - 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: antlibs and classloaders #2
Jose Alberto Fernandez wrote: From: Peter Reilly [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: This things sound like we are using the wrong abstraction here. typedef/ inside an antlib/ should use the antlib classloader as the parent for any subsequent classloader. In this case the parent is the antlib classloader (it is the default classloader). So what happens if the toplevel antlib gets loaded from a different classloader (because I defined classpaths and such). Would the typedef/ inside pick-up that as the classloader? Or would it pickup some default one? Currently it would use the default ant classloader. I do not see why that should cause an infinite recursion. The problem is that the typedef resource=net/.../antlib.xml classpath path=cpptasks.jar/ /typedef in the antlib will pick up the antlib.xml resoure that contains typedef resource=net/.../antlib.xml task which will pick up ., This does not happen with the current ant code, as the typedef resource=net/.../antlib.xml classpath path=cpptasks.jar//typedef task will not see the antlib.xml resource in the parent classloader. Another way to work-around this is for the typedef to use a thread specific stack to check for recursive loading of xml resources. This probally should be done in any case: recursive.xml antlib typedef file=recursive.xml/ /antlib build.xml: project typedef file=recursive.xml/ /project What is the difference between this and what we do for import/s. In both cases we need to make sure we do not go into an infinite loop. It should not matter whether the XML is an import fragment or an antlib.xml Yes, that that the point!. A warning should be issued and the antlib should not be loaded again. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlibs and classloaders #2
Mariano, I also agree with you and what you are saying. However I think we have several different parts of the proposal that are too loose and hence allow to break this general concept as you put it. For example we have: 1) The jars containing the antlig code (which is defined by a classpath or classloader) 2) The URI for the antlib, which can be specified implicitely with an antlib:uri or explicitly with the uri parameter of typedef. Using typedef, you can load several antlibs to the same namespace and such. 3) antlib.xml file or resource which contains the XML definitions of the tasks and types. Now, all this things can be used in a systemetic way to achieve your goals (I think), but they can be used to act in a quite different way and bringing all kinds of problems. So, are our objectives just the suggested user patterns for ANTLIBs or are they mandatory behaviour of antlibs. Depending on what we want, it will change the way we teach people how to write effective reusable antlibs. As oppose to only will work on my machine kind of antlibs. This is what I do not think we have a clear understanding. How are people to use all this moving parts in a consistent way that promotes reusability, etc, etc. Jose Alberto -Original Message- From: Mariano Benitez [mailto:[EMAIL PROTECTED] Sent: 17 May 2004 13:29 To: Ant Developers List Subject: Re: antlibs and classloaders #2 This things sound like we are using the wrong abstraction here. typedef/ inside an antlib/ should use the antlib classloader as the parent for any subsequent classloader. I do not see why that should cause an infinite recursion. I feel like we have a conceptual mismatch between antlib the jar with the code, and antlib the resource with the XML definitions. We are not treating them in a symetric way or as a unit. And hence we are get into all this conflicting behaviour. I would like to pick from here and try to describe my understanding of the concepts. Antlib: I see this as a a definition of tasks within a namespace that involves all the jars required to resolve the execution of the tasks. To put it plainly, I see it as the antlib.xml with a classpath. So for me that defines completely the antlib and the extra classpath should be added to the antlib classpath. Also, for me is accidental that the antlibs should be located in the $ANT_HOME/lib or in a -lib path, actually the antlib definition should start from the antlib.xml, wherever it is, and then create a classloader based on the antlib definition. For the special case were the antlib jars are located in the base ant classpath ($ANT_HOME/lib or -lib path) I would not allow adding a classpath since the antlib should be completely contained within the base ant classpath, only when the antlib jars are outside I would allow defining an extra classpath. Also, defining antlibs in either way (being inside base ant classpath or outside) should behave the same way, they should be idempotent, meaning that once they are defined, they should not be overriden, I understand that it is not wise to use the same uri for different antlibs, the user should always try to pick unique names for the antlibs, otherwise we go back to a single namespace. This is my understanding of antlibs, it is probably out of synch with what you envision on this, but I wanted to let you know what I thought antlibs were about. My 2 cents. MAriano - 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: antlibs and classloaders #2
From: Peter Reilly [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: From: Peter Reilly [mailto:[EMAIL PROTECTED] In this case the parent is the antlib classloader (it is the default classloader). So what happens if the toplevel antlib gets loaded from a different classloader (because I defined classpaths and such). Would the typedef/ inside pick-up that as the classloader? Or would it pickup some default one? Currently it would use the default ant classloader. That, to me, is wrong. While inside an antlib, you are in the context of that antlib and hence you need to have access to all classes defined by it. I do not see why that should cause an infinite recursion. The problem is that the typedef resource=net/.../antlib.xml classpath path=cpptasks.jar/ /typedef in the antlib will pick up the antlib.xml resoure that contains typedef resource=net/.../antlib.xml task which will pick up ., This does not happen with the current ant code, as the typedef resource=net/.../antlib.xml classpath path=cpptasks.jar//typedef task will not see the antlib.xml resource in the parent classloader. Another way to work-around this is for the typedef to use a thread specific stack to check for recursive loading of xml resources. This probally should be done in any case: recursive.xml antlib typedef file=recursive.xml/ /antlib build.xml: project typedef file=recursive.xml/ /project What is the difference between this and what we do for import/s. In both cases we need to make sure we do not go into an infinite loop. It should not matter whether the XML is an import fragment or an antlib.xml Yes, that that the point!. A warning should be issued and the antlib should not be loaded again. Agreed. Jose Alberto Peter - 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: antlibs and classloaders #2
On Mon, 10 May 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Would the following solve this problem generically? !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ looks like a reasonable compromise. The alternative would be a built-in task that takes the antlib URI, this wouldn't even require any magic taskname. antlibresolve uri=.../ or even antlibresolve prefix=.../. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlibs and classloaders #2
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 10 May 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Would the following solve this problem generically? !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ looks like a reasonable compromise. The alternative would be a built-in task that takes the antlib URI, this wouldn't even require any magic taskname. antlibresolve uri=.../ or even antlibresolve prefix=.../. I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix--uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: antlibresolve prefix=mylib/ or antlibresolve mylib:ns=ignored value / In this second, we get the URI from ns attribute which is in that space. the implementation could use the new NS aware features that were added recently. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
Let me get this right.. this task would define the antlib classes the
moment it is invoked, and it should be used on the top level buildfile,
this way the subbuilds/subants/ant/antcall targets have the antlib
already loaded, right?
I explain a bit my build files structure for testing:
we have a local/tests directory were all tests modules reside (20+), we
have a build.xml at the top level for global cleans builds, runs, etc,
and at the module dir, anothere build.xml for single module runs. I use
an import file=${basedir}/include/xml/ to define stuff at the module
level, and a import file=${basedir}/server-include.xml/ for global
tests runs.
Up to this moment I need to define the tasks in boths includes using
typedef uri= loaderref=... classpathref=.../ because I
cannot pass classpath to antlibs. I also added in both includes an
ifnotisset property=antlibs.define//notthen...the typedef
stuff. /if to do this only once for all the builds.
I use a lot of subant, antcall, ants and it is very difficult to control
in all the builds that the do use inheritall=true, since otherwise the
if would not find the property and redefine the tasks.
Could you put this structure as it would be in 1.6.2 with the
antlibresolve and antlib classpath, at least what you imagine it might be?
I like the antlibresolve solution, as long as it does not redefine the
tasks, or at least there is an option not to do so. Would it be possible
to add to typedef that possibility?
Thanks for the help on this matter.
MAriano
Jose Alberto Fernandez wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 10 May 2004, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
Would the following solve this problem generically?
!--
This task is automatically available for every ANTLIB
and its only function is to force the loading of the library
if necessary. Force the lazy loading.
--
mylib:antlibresolve/
looks like a reasonable compromise.
The alternative would be a built-in task that takes the
antlib URI, this wouldn't even require any magic taskname.
antlibresolve uri=.../ or even antlibresolve prefix=.../.
I have no problem, one way or another, as long as I do not have to type
the whole URI again ;-) This is why I want to use the NS prefix instead.
Is there an way for the task to get the information needed (the URI)?
Since a lot of this is resolved by the parser (prefix--uri) mapping,
I was trying to make sure we do not get bog by the design. So as long as
we can get the info necessary by just saying:
antlibresolve prefix=mylib/
or
antlibresolve mylib:ns=ignored value /
In this second, we get the URI from ns attribute which is in that
space.
the implementation could use the new NS aware features that were added
recently.
Jose Alberto
-
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: antlibs and classloaders #2
From: Mariano Benitez [mailto:[EMAIL PROTECTED] Let me get this right.. this task would define the antlib classes the moment it is invoked, and it should be used on the top level buildfile, this way the subbuilds/subants/ant/antcall targets have the antlib already loaded, right? I explain a bit my build files structure for testing: [snip...] Up to this moment I need to define the tasks in boths includes using typedef uri= loaderref=... classpathref=.../ because I cannot pass classpath to antlibs. I also added in both includes an ifnotisset property=antlibs.define//notthen...the typedef stuff. /if to do this only once for all the builds. I use a lot of subant, antcall, ants and it is very difficult to control in all the builds that the do use inheritall=true, since otherwise the if would not find the property and redefine the tasks. Here I would advocate to have the new condition isDefined/ that I mentioned before. Which will not rely on inheritAll but will look at the definintion dictionalries directly. Could you put this structure as it would be in 1.6.2 with the antlibresolve and antlib classpath, at least what you imagine it might be? I like the antlibresolve solution, as long as it does not redefine the tasks, or at least there is an option not to do so. Would it be possible to add to typedef that possibility? antlibresolve/ the only thing it does is make sure the antlib URI gets processed. As if you were calling task in the space of the antlib. Actually on the incarnation as mylib:antlibresolve/ it would have been a noop task whose only side-effect is causing the loading of the antlib. If you call it 20 times it would only load the antlib the first time, like any other task would. (humm this may be still the best solution, just make every antlib define this task). How to deal with your classloaders, that is a different thing completely. - Is it possible to define them inside the antlib (or are they buildfile dependent)? - I had proposed in the past a naming convention to associate a classpath/loader with a particular URI. But all this is just open talk at the moment. - Maybe antlibresolve/ can do some of this, but then its definition is not as clean as one would want. Jose Alberto Thanks for the help on this matter. MAriano Jose Alberto Fernandez wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 10 May 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Would the following solve this problem generically? !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ looks like a reasonable compromise. The alternative would be a built-in task that takes the antlib URI, this wouldn't even require any magic taskname. antlibresolve uri=.../ or even antlibresolve prefix=.../. I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix--uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: antlibresolve prefix=mylib/ or antlibresolve mylib:ns=ignored value / In this second, we get the URI from ns attribute which is in that space. the implementation could use the new NS aware features that were added recently. Jose Alberto - 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: antlibs and classloaders #2
Jose Alberto Fernandez wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 10 May 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Would the following solve this problem generically? !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ looks like a reasonable compromise. The alternative would be a built-in task that takes the antlib URI, this wouldn't even require any magic taskname. antlibresolve uri=.../ or even antlibresolve prefix=.../. I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix--uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: antlibresolve prefix=mylib/ This is not currently possible. The prefix-uri mapping is only retained for the element names and the tag names (using the NS dynamic con (The ant-type attribute is the only exception, but this is implemented by a horrid cludge, the parser knows about ant-type and substitutes the value in). or antlibresolve mylib:ns=ignored value / In this second, we get the URI from ns attribute which is in that space. the implementation could use the new NS aware features that were added recently. I assume you mean the NS aware dymanic configurator patch. The second form of the antlibresolve task could use to implement the antlib:ns style attribute, but it feels like a cludge. Peter Jose Alberto - 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: antlibs and classloaders #2
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
but ... If I call typedef for the same file, with the same
task, same
uri, etc, why it redefine the tasks if they are already defined?
BTW, it could help an unless attribute for typedef, not to
do it again :)
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path unless=defined/
property name=defined value=true/
I would advocate for a new condition:
isdefined {uri=uri | name=[NS:]name} /
Which is true for uri if there are things already defined in that uri;
and for name if there is a definition already associated with that
name
(in te particular NS). This should include all kinds of definitions
typedefs, macros, selectors, mappers, etc. We should add a role
also once that issue is sorted out.
Jose Alberto
MAriano
Peter Reilly wrote:
Hi Mariano,
I assume you are calling the typedef commands multiple times.
- hence the different antloaders. But you only need to typedef the
types/tasks once.
You should wrap the taskdefs in a macrodef or a target,
and call them once in the master build file before doing
any subant, or ant calls.
Peter
Mariano Benitez wrote:
I am at the edge of a mental crisis, I need help
Can someone explain how antlib paths and tasks works, I have this
situation that I cannot understand.
I defined this:
project name=fuego.internal.test.include basedir=.
property name=xml.encoding value=ISO-8859-1/
path id=fuego.internal.test.antlibs.path
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/path
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/enterprise/antlib.xml
uri=antlib:fuego.tools.ant.enterprise
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/express/antlib.xml
uri=antlib:fuego.tools.ant.express
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/j2ee/antlib.xml
uri=antlib:fuego.tools.ant.j2ee
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
/project
another Jar fuegocore.jar is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas Loader.
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log([LOADERS] Loader Class [ +
Loader.class.hashCode()
+ / + Loader.class.getClassLoader() + ]);
task.log([LOADERS] Utils Class [ +
Utils.class.hashCode() +
/ + Utils.class.getClassLoader() + ]);
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME
WHILE THE UTILS
CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same
class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run
nightly batch
tests.
Everything is appreciated.
MAriano
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
Mariano Benitez wrote:
another thing, I did the typedef thing because I cannot add
classpath to an antlib definition, so the problems are chained
I hope to get this in for ant 1.6.2.
If I would define antlibs with classpath references directly it would
be better
You would still face the problem.
The antlib: namespace automatic loading of tasks/types is only triggered
if a task or type from
the namespace is used.
for example if you have a master.xml file:
project name=master default=dosubprojects
target name=dosubprojects
subant target=
fileset dir=. includes=**/build.xml/
/subant
/target
/project
and each of the projects had:
project xmlns:cpp=antlib:net.sf.antcontrib.cpptasks default=compile
cpp:compiler id=compiler.flags
...
/project
Each of the subprojects would trigger the task defs for the cpptasks namespace.
The way to work around this would be to do:
project name=master default=dosubprojects
xmlns:cpp=antlib:net.sf.antcontrib.cpptasks
cpp:compiler id=dummy.flags/
target name=dosubprojects
subant target=
fileset dir=. includes=**/build.xml/
/subant
/target
/project
Peter
MAriano
Mariano Benitez wrote:
but ... If I call typedef for the same file, with the same task,
same uri, etc, why it redefine the tasks if they are already defined?
BTW, it could help an unless attribute for typedef, not to do it
again :)
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path unless=defined/
property name=defined value=true/
MAriano
Peter Reilly wrote:
Hi Mariano,
I assume you are calling the typedef commands multiple times.
- hence the different antloaders. But you only need to typedef
the types/tasks once.
You should wrap the taskdefs in a macrodef or a target,
and call them once in the master build file before doing
any subant, or ant calls.
Peter
Mariano Benitez wrote:
I am at the edge of a mental crisis, I need help
Can someone explain how antlib paths and tasks works, I have this
situation that I cannot understand.
I defined this:
project name=fuego.internal.test.include basedir=.
property name=xml.encoding value=ISO-8859-1/
path id=fuego.internal.test.antlibs.path
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/path
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/enterprise/antlib.xml
uri=antlib:fuego.tools.ant.enterprise
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/express/antlib.xml
uri=antlib:fuego.tools.ant.express
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/j2ee/antlib.xml
uri=antlib:fuego.tools.ant.j2ee
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
/project
another Jar fuegocore.jar is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas Loader.
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log([LOADERS] Loader Class [ +
Loader.class.hashCode() + / + Loader.class.getClassLoader() + ]);
task.log([LOADERS] Utils Class [ + Utils.class.hashCode()
+ / + Utils.class.getClassLoader() + ]);
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME WHILE THE
UTILS CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run nightly
batch tests.
Everything is appreciated.
MAriano
-
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: antlibs and classloaders #2
Peter Reilly wrote:
another thing, I did the typedef thing because I cannot add
classpath to an antlib definition, so the problems are chained
I hope to get this in for ant 1.6.2.
This is still in a definition process, I guess, so I cannot make any
work towards this direction.
You would still face the problem.
The antlib: namespace automatic loading of tasks/types is only
triggered if a task or type from
the namespace is used.
From what you said I understand that the antlib definition is lazy and
done from the current ant and descendents, not for the whole ant script,
this is why if the usage of an antlib task is inside subants, then for
each one another classloader is created. That's why if I define it in
the top level ant it applies for all subants.
So, I am thinking of the following workaround for the complete scope of
the problem:
I create a task antlib that performs would look like this:
antlib property=fuego.antlib.defined
classpath
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/classpath
typedef package=fuego.tools.ant.enterprise/
typedef package=fuego.tools.ant.express/
typedef resource=fuego/tools/ant/j2ee/antlib.xml/
typedef resource=fuego/internal/test/ant/myFile.xml/
/antlib
Here I would check with the property, and if not set define a
classloader with that classpath and define the antlibs in that loader,
just what I do in the import file, but inside a task. I can put this
task in the ant -lib path, and use it in the import files.
What do you think?
MAriano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlibs and classloaders #2
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
So, I am thinking of the following workaround for the
complete scope of
the problem:
I create a task antlib that performs would look like this:
antlib property=fuego.antlib.defined
classpath
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/classpath
typedef package=fuego.tools.ant.enterprise/
typedef package=fuego.tools.ant.express/
typedef resource=fuego/tools/ant/j2ee/antlib.xml/
typedef resource=fuego/internal/test/ant/myFile.xml/
/antlib
Would the following solve this problem generically?
project name=X xmlns:mylib=antlib:my.library.package
!--
This task is automatically available for every ANTLIB
and its only function is to force the loading of the library
if necessary. Force the lazy loading.
--
mylib:antlibresolve/
/project
The above assumes somehow we manage to define the classpath required
as part of the ANTLIB itself. If not, the task could have the classpath
information.
This looks much better than calling some task from the antlib with
doggie
parameters.
What do people think?
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
This soulds ok, but it could be done
like this:
onceonly
classpath id=fuego.classpath
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/classpath
typedef uri=antlib:fuego.tools.ant.enterprise
classpathref=fuego.classpath
loaderref=fuego.classpath.loader
resource=fuego/tools/ant/j2ee/antlib.xml/
typedef uri=antlib:fuego.tools.ant.express
loaderref=fuego.classpath.loader
resource=fuego/internal/test/ant/myFile.xml
/onceonly
see:
http://marc.theaimsgroup.com/?l=ant-devm=108331661709918w=2
Peter
Mariano Benitez wrote:
Peter Reilly wrote:
another thing, I did the typedef thing because I cannot add
classpath to an antlib definition, so the problems are chained
I hope to get this in for ant 1.6.2.
This is still in a definition process, I guess, so I cannot make any
work towards this direction.
You would still face the problem.
The antlib: namespace automatic loading of tasks/types is only
triggered if a task or type from
the namespace is used.
From what you said I understand that the antlib definition is lazy and
done from the current ant and descendents, not for the whole ant
script, this is why if the usage of an antlib task is inside subants,
then for each one another classloader is created. That's why if I
define it in the top level ant it applies for all subants.
So, I am thinking of the following workaround for the complete scope
of the problem:
I create a task antlib that performs would look like this:
antlib property=fuego.antlib.defined
classpath
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/classpath
typedef package=fuego.tools.ant.enterprise/
typedef package=fuego.tools.ant.express/
typedef resource=fuego/tools/ant/j2ee/antlib.xml/
typedef resource=fuego/internal/test/ant/myFile.xml/
/antlib
Here I would check with the property, and if not set define a
classloader with that classpath and define the antlibs in that loader,
just what I do in the import file, but inside a task. I can put this
task in the ant -lib path, and use it in the import files.
What do you think?
MAriano
-
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: antlibs and classloaders #2
Jose Alberto Fernandez wrote: Would the following solve this problem generically? project name=X xmlns:mylib=antlib:my.library.package !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ /project The above assumes somehow we manage to define the classpath required as part of the ANTLIB itself. If not, the task could have the classpath information. That sounds like a good idea. It may however be difficult to remember to do this. The only difference will be the speed of the build. Peter This looks much better than calling some task from the antlib with doggie parameters. What do people think? Jose Alberto - 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: antlibs and classloaders #2
Hi Mariano,
I assume you are calling the typedef commands multiple times.
- hence the different antloaders. But you only need to typedef
the types/tasks once.
You should wrap the taskdefs in a macrodef or a target,
and call them once in the master build file before doing
any subant, or ant calls.
Peter
Mariano Benitez wrote:
I am at the edge of a mental crisis, I need help
Can someone explain how antlib paths and tasks works, I have this
situation that I cannot understand.
I defined this:
project name=fuego.internal.test.include basedir=.
property name=xml.encoding value=ISO-8859-1/
path id=fuego.internal.test.antlibs.path
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/path
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/enterprise/antlib.xml
uri=antlib:fuego.tools.ant.enterprise
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/express/antlib.xml
uri=antlib:fuego.tools.ant.express
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/j2ee/antlib.xml
uri=antlib:fuego.tools.ant.j2ee
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
/project
another Jar fuegocore.jar is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas Loader.
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log([LOADERS] Loader Class [ + Loader.class.hashCode()
+ / + Loader.class.getClassLoader() + ]);
task.log([LOADERS] Utils Class [ + Utils.class.hashCode() +
/ + Utils.class.getClassLoader() + ]);
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME WHILE THE UTILS
CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run nightly batch
tests.
Everything is appreciated.
MAriano
-
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: antlibs and classloaders #2
but ... If I call typedef for the same file, with the same task, same
uri, etc, why it redefine the tasks if they are already defined?
BTW, it could help an unless attribute for typedef, not to do it again :)
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path unless=defined/
property name=defined value=true/
MAriano
Peter Reilly wrote:
Hi Mariano,
I assume you are calling the typedef commands multiple times.
- hence the different antloaders. But you only need to typedef
the types/tasks once.
You should wrap the taskdefs in a macrodef or a target,
and call them once in the master build file before doing
any subant, or ant calls.
Peter
Mariano Benitez wrote:
I am at the edge of a mental crisis, I need help
Can someone explain how antlib paths and tasks works, I have this
situation that I cannot understand.
I defined this:
project name=fuego.internal.test.include basedir=.
property name=xml.encoding value=ISO-8859-1/
path id=fuego.internal.test.antlibs.path
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/path
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/enterprise/antlib.xml
uri=antlib:fuego.tools.ant.enterprise
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/express/antlib.xml
uri=antlib:fuego.tools.ant.express
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/j2ee/antlib.xml
uri=antlib:fuego.tools.ant.j2ee
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
/project
another Jar fuegocore.jar is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas Loader.
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log([LOADERS] Loader Class [ + Loader.class.hashCode()
+ / + Loader.class.getClassLoader() + ]);
task.log([LOADERS] Utils Class [ + Utils.class.hashCode() +
/ + Utils.class.getClassLoader() + ]);
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME WHILE THE UTILS
CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run nightly batch
tests.
Everything is appreciated.
MAriano
-
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: antlibs and classloaders #2
another thing, I did the typedef thing because I cannot add classpath
to an antlib definition, so the problems are chained
If I would define antlibs with classpath references directly it would be
better
MAriano
Mariano Benitez wrote:
but ... If I call typedef for the same file, with the same task,
same uri, etc, why it redefine the tasks if they are already defined?
BTW, it could help an unless attribute for typedef, not to do it
again :)
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path unless=defined/
property name=defined value=true/
MAriano
Peter Reilly wrote:
Hi Mariano,
I assume you are calling the typedef commands multiple times.
- hence the different antloaders. But you only need to typedef
the types/tasks once.
You should wrap the taskdefs in a macrodef or a target,
and call them once in the master build file before doing
any subant, or ant calls.
Peter
Mariano Benitez wrote:
I am at the edge of a mental crisis, I need help
Can someone explain how antlib paths and tasks works, I have this
situation that I cannot understand.
I defined this:
project name=fuego.internal.test.include basedir=.
property name=xml.encoding value=ISO-8859-1/
path id=fuego.internal.test.antlibs.path
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/path
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/enterprise/antlib.xml
uri=antlib:fuego.tools.ant.enterprise
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/express/antlib.xml
uri=antlib:fuego.tools.ant.express
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/j2ee/antlib.xml
uri=antlib:fuego.tools.ant.j2ee
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
/project
another Jar fuegocore.jar is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas Loader.
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log([LOADERS] Loader Class [ +
Loader.class.hashCode() + / + Loader.class.getClassLoader() + ]);
task.log([LOADERS] Utils Class [ + Utils.class.hashCode()
+ / + Utils.class.getClassLoader() + ]);
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME WHILE THE
UTILS CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run nightly
batch tests.
Everything is appreciated.
MAriano
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
