RE: New Launcher and JPackage RPMs
> From: Conor MacNeill [mailto:[EMAIL PROTECTED] > > > > I think that the code for getCoreLoader() and the new 1.6 > classloader > > code were two separate code paths that did not complete for 1.6. > > > > the CoreLoader is an older attempt to setup Core loaders and > was never really > progressed. It is pure legacy and is not effectively used. It > predates 1.4, I > think. > I see, maybe we should try to get rid of it. BTW there are a couple of tasks that actually use it (and construct their own classloader with it as the parent). We may need to take a look at this issue. The symptom of code using the bootclassloader is the result of AntClassLoader using AntClassLoader.class.getClassLoader() as the parent instead of using getProject().getCoreLoader() or something of to the same effect. We are assuming that whichever classloader loaded AntClassLoader has access to all the ANT core, and that may not be always the case, mostly when in an IDE environement. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
> I think that the code for getCoreLoader() and the new 1.6 classloader > code were > two separate code paths that did not complete for 1.6. > the CoreLoader is an older attempt to setup Core loaders and was never really progressed. It is pure legacy and is not effectively used. It predates 1.4, I think. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
First, I should say that classloader issues makes my head hurt.! Jose Alberto Fernandez wrote: From: Peter Reilly [mailto:[EMAIL PROTECTED] No, the optimization is that if the does not define a classpath, a cached classloader is used. This cached classloader gets set once (the first call). Jose's more general caching solution souds more promising. Peter, I could not work on this during the weekend, but will try to post it tonight. Some additional questions I have (for improvements): 1) It seems that we want a static cache, instead of per project. I can do this, but I am a little concern with IDEs keeping classes longer than we want. An alternative is to pass the parent cache to subproject (or a clone of it). Just like we do with some other system-like properties. Suggestions. This (use of static) is the main reason that I was worried about my patch to antclassloader2. The cache could be copied by ComponentHelper#initSubProject() as this method gets called for each subproject. 2) Looking at the code for createClassLoader(Path), as I mentioned before, we never seemto pass getCoreLoader() as the parent of the classloaders being created, if we were, we would be reusing the parent all the time and maybe gaining some savings. Is this kind of a very scarry change to do? Some of the complaints about the bootclassloader being used, may be fixed by doing such a change. I think that the code for getCoreLoader() and the new 1.6 classloader code were two separate code paths that did not complete for 1.6. 3) Since we do not need to support JDK1.1 anymore, can we get rid of the 1.1 specific reflexion magic in createClassLoader() and use an AntClassLoader2 directly? Opinions? This makes sense. Peter I think I can incorporate some of your input in this regard quite easily. So let me know what you think is best. 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: New Launcher and JPackage RPMs
> From: Peter Reilly [mailto:[EMAIL PROTECTED] > > > No, the optimization is that if the does not define a > classpath, a cached classloader is used. This > cached classloader gets set once (the first call). > > Jose's more general caching solution souds more promising. > Peter, I could not work on this during the weekend, but will try to post it tonight. Some additional questions I have (for improvements): 1) It seems that we want a static cache, instead of per project. I can do this, but I am a little concern with IDEs keeping classes longer than we want. An alternative is to pass the parent cache to subproject (or a clone of it). Just like we do with some other system-like properties. Suggestions. 2) Looking at the code for createClassLoader(Path), as I mentioned before, we never seemto pass getCoreLoader() as the parent of the classloaders being created, if we were, we would be reusing the parent all the time and maybe gaining some savings. Is this kind of a very scarry change to do? Some of the complaints about the bootclassloader being used, may be fixed by doing such a change. 3) Since we do not need to support JDK1.1 anymore, can we get rid of the 1.1 specific reflexion magic in createClassLoader() and use an AntClassLoader2 directly? Opinions? I think I can incorporate some of your input in this regard quite easily. So let me know what you think is best. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
Please ignore. This last comment by me was added in a reply to the wrong message. On Friday 16 January 2004 11:18 am, Steve Cohen wrote: > Well, we at commons-net would have been rushing the release to meet ant's > "deadline" and there are internal refactorings which we would have liked to > have included that we were planning to postpone in the rush, but now will > take the time to get right, so I doubt that commons-net-1.2.0 will be done > in time for ant 1.6.1 and therefore we shouldn't update the ant manual just > yet. > > I think the best procedure will be for commons-net to work at it's own best > pace and when it's done, notify the ant list, via bugzilla and via posts to > the ant-dev and ant-user lists. At that point, any ant users needing this > functionality would be able to grab the commons-net-1.2.0 jar and get the > basic functionality. At that point also, coding could begin on the HEAD > branch of ant and the documentation in time for 1.7 (or maybe 1.6.2 if that > comes to pass). > > On Friday 16 January 2004 9:31 am, Antoine Lévy-Lambert wrote: > > Peter Reilly wrote: > > > Antoine Lévy-Lambert wrote: > > >> I am +1 to get this into ant 1.6.1. > > > > > > (in relation to static map of jarfile->manifest class path in > > > AntClassLoader2). > > > > > > Ok I will commit that. > > > > > > Another optimization I tried was a quick hack to DefBase to have a > > > static field containing the default classloader, so it > > > gets set once. This did speed up the typedef the second and > > > subsequent times and reduced the > > > time for the test to 1.6 second (from 3 and thus below the 1.5.4 times > > > (2 second) when using the crimson xml parser). > > > > Sounds useful. > > > > > However it is a complete hack, and does not deal with non-default > > > classpaths like: > > > > > resource="net/sf/antcontrib/antcontrib.properties"/> > > > > Do you mean : your change is bringing an optimization for taskdefs which > > are done based on jars which have already been loaded by the launcher, > > presumably because they are in $ANT_HOME/lib or in a -lib directory ? > > And not if the taskdef is requiring extra jars or directories which were > > not included when ant got started ? > > > > Cheers, > > > > Antoine > > > > > > > > - > > 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: New Launcher and JPackage RPMs
Well, we at commons-net would have been rushing the release to meet ant's "deadline" and there are internal refactorings which we would have liked to have included that we were planning to postpone in the rush, but now will take the time to get right, so I doubt that commons-net-1.2.0 will be done in time for ant 1.6.1 and therefore we shouldn't update the ant manual just yet. I think the best procedure will be for commons-net to work at it's own best pace and when it's done, notify the ant list, via bugzilla and via posts to the ant-dev and ant-user lists. At that point, any ant users needing this functionality would be able to grab the commons-net-1.2.0 jar and get the basic functionality. At that point also, coding could begin on the HEAD branch of ant and the documentation in time for 1.7 (or maybe 1.6.2 if that comes to pass). On Friday 16 January 2004 9:31 am, Antoine Lévy-Lambert wrote: > Peter Reilly wrote: > > Antoine Lévy-Lambert wrote: > >> I am +1 to get this into ant 1.6.1. > > > > (in relation to static map of jarfile->manifest class path in > > AntClassLoader2). > > > > Ok I will commit that. > > > > Another optimization I tried was a quick hack to DefBase to have a > > static field containing the default classloader, so it > > gets set once. This did speed up the typedef the second and > > subsequent times and reduced the > > time for the test to 1.6 second (from 3 and thus below the 1.5.4 times > > (2 second) when using the crimson xml parser). > > Sounds useful. > > > However it is a complete hack, and does not deal with non-default > > classpaths like: > > > resource="net/sf/antcontrib/antcontrib.properties"/> > > Do you mean : your change is bringing an optimization for taskdefs which > are done based on jars which have already been loaded by the launcher, > presumably because they are in $ANT_HOME/lib or in a -lib directory ? > And not if the taskdef is requiring extra jars or directories which were > not included when ant got started ? > > Cheers, > > Antoine > > > > - > 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: New Launcher and JPackage RPMs
Antoine Lévy-Lambert wrote: Peter Reilly wrote: Antoine Lévy-Lambert wrote: I am +1 to get this into ant 1.6.1. (in relation to static map of jarfile->manifest class path in AntClassLoader2). Ok I will commit that. Another optimization I tried was a quick hack to DefBase to have a static field containing the default classloader, so it gets set once. This did speed up the typedef the second and subsequent times and reduced the time for the test to 1.6 second (from 3 and thus below the 1.5.4 times (2 second) when using the crimson xml parser). Sounds useful. However it is a complete hack, and does not deal with non-default classpaths like: Do you mean : your change is bringing an optimization for taskdefs which are done based on jars which have already been loaded by the launcher, presumably because they are in $ANT_HOME/lib or in a -lib directory ? No, the optimization is that if the does not define a classpath, a cached classloader is used. This cached classloader gets set once (the first call). Jose's more general caching solution souds more promising. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
Jose Alberto Fernandez wrote: From: Peter Reilly [mailto:[EMAIL PROTECTED] Antoine Lévy-Lambert wrote: I am +1 to get this into ant 1.6.1. (in relation to static map of jarfile->manifest class path in AntClassLoader2). Ok I will commit that. Another optimization I tried was a quick hack to DefBase to have a static field containing the default classloader, so it gets set once. This did speed up the typedef the second and subsequent times and reduced the time for the test to 1.6 second (from 3 and thus below the 1.5.4 times (2 second) when using the crimson xml parser). However it is a complete hack, and does not deal with non-default classpaths like: I have some none committed changes (at home) that provide caching for classloaders based on the path object used to create it. Sounds good. This would mean that all the classpaths reused by a refid will reuse the same classloader and hence improve performance. At this point the WeakHashMap I am using is per Project instance which would not help for but I could change that. The antcall's (ant, antall, subant and foreach) is where there is a big problem. Some build systems use these a lot. Do you want me to submit that code? Maybe by tomorrow? Perhaps it could be reviewed first. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
Peter Reilly wrote: Antoine Lévy-Lambert wrote: I am +1 to get this into ant 1.6.1. (in relation to static map of jarfile->manifest class path in AntClassLoader2). Ok I will commit that. Another optimization I tried was a quick hack to DefBase to have a static field containing the default classloader, so it gets set once. This did speed up the typedef the second and subsequent times and reduced the time for the test to 1.6 second (from 3 and thus below the 1.5.4 times (2 second) when using the crimson xml parser). Sounds useful. However it is a complete hack, and does not deal with non-default classpaths like: Do you mean : your change is bringing an optimization for taskdefs which are done based on jars which have already been loaded by the launcher, presumably because they are in $ANT_HOME/lib or in a -lib directory ? And not if the taskdef is requiring extra jars or directories which were not included when ant got started ? Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New Launcher and JPackage RPMs
> From: Peter Reilly [mailto:[EMAIL PROTECTED] > > > Antoine Lévy-Lambert wrote: > > > I am +1 to get this into ant 1.6.1. > > (in relation to static map of jarfile->manifest class path in > AntClassLoader2). > > Ok I will commit that. > > Another optimization I tried was a quick hack to DefBase to have a > static field containing the default classloader, so it > gets set once. This did speed up the typedef the second and > subsequent > times and reduced the > time for the test to 1.6 second (from 3 and thus below the > 1.5.4 times > (2 second) when using the crimson xml parser). > However it is a complete hack, and does not deal with non-default > classpaths like: > resource="net/sf/antcontrib/antcontrib.properties"/> > I have some none committed changes (at home) that provide caching for classloaders based on the path object used to create it. This would mean that all the classpaths reused by a refid will reuse the same classloader and hence improve performance. At this point the WeakHashMap I am using is per Project instance which would not help for but I could change that. Do you want me to submit that code? Maybe by tomorrow? Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
Antoine Lévy-Lambert wrote:
I am +1 to get this into ant 1.6.1.
(in relation to static map of jarfile->manifest class path in
AntClassLoader2).
Ok I will commit that.
Another optimization I tried was a quick hack to DefBase to have a
static field containing the default classloader, so it
gets set once. This did speed up the typedef the second and subsequent
times and reduced the
time for the test to 1.6 second (from 3 and thus below the 1.5.4 times
(2 second) when using the crimson xml parser).
However it is a complete hack, and does not deal with non-default
classpaths like:
Note that the problem is not so bad for the antlib: xml ns shortcut.
..
This will in ant 1.6.1 cause only one typedef of the ant-contrib tasks.
(There
is a bug in 1.6.0 which causes the tasks to be loaded for each ant-call,
this
is fixed in cvs).
Peter
Index: src/main/org/apache/tools/ant/taskdefs/DefBase.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/DefBase.java,v
retrieving revision 1.6
diff -u -r1.6 DefBase.java
--- src/main/org/apache/tools/ant/taskdefs/DefBase.java 22 Sep 2003 08:58:58 - 1.6
+++ src/main/org/apache/tools/ant/taskdefs/DefBase.java 16 Jan 2004 15:06:36 -
@@ -83,7 +83,7 @@
* @ant.attribute ignore="true"
*/
public void setReverseLoader(boolean reverseLoader) {
-this.cpDelegate.setReverseLoader(reverseLoader);
+getDelegate().setReverseLoader(reverseLoader);
log("The reverseloader attribute is DEPRECATED. It will be removed",
Project.MSG_WARN);
}
@@ -92,14 +92,14 @@
* @return the classpath for this definition
*/
public Path getClasspath() {
-return cpDelegate.getClasspath();
+return getDelegate().getClasspath();
}
/**
* @return the reverse loader attribute of the classpath delegate.
*/
public boolean isReverseLoader() {
-return cpDelegate.isReverseLoader();
+return getDelegate().isReverseLoader();
}
/**
@@ -107,7 +107,7 @@
* @return the loader id
*/
public String getLoaderId() {
-return cpDelegate.getClassLoadId();
+return getDelegate().getClassLoadId();
}
/**
@@ -115,7 +115,7 @@
* @return the class path id
*/
public String getClasspathId() {
-return cpDelegate.getClassLoadId();
+return getDelegate().getClassLoadId();
}
/**
@@ -124,7 +124,7 @@
* @param classpath an Ant Path object containing the classpath.
*/
public void setClasspath(Path classpath) {
-this.cpDelegate.setClasspath(classpath);
+getDelegate().setClasspath(classpath);
}
/**
@@ -133,7 +133,7 @@
* @return the classpath of the this definition
*/
public Path createClasspath() {
-return this.cpDelegate.createClasspath();
+return getDelegate().createClasspath();
}
/**
@@ -142,7 +142,7 @@
* @param r the reference to the classpath
*/
public void setClasspathRef(Reference r) {
-this.cpDelegate.setClasspathref(r);
+getDelegate().setClasspathref(r);
}
/**
@@ -158,9 +158,11 @@
* @since Ant 1.5
*/
public void setLoaderRef(Reference r) {
-this.cpDelegate.setLoaderRef(r);
+getDelegate().setLoaderRef(r);
}
+private static ClassLoader defaultLoader;
+
/**
* create a classloader for this definition
* @return the classloader from the cpDelegate
@@ -169,6 +171,13 @@
if (getAntlibClassLoader() != null) {
return getAntlibClassLoader();
}
+if (cpDelegate == null) {
+if (defaultLoader == null) {
+cpDelegate = ClasspathUtils.getDelegate(this);
+defaultLoader = cpDelegate.getClassLoader();
+}
+return defaultLoader;
+}
if (createdLoader == null) {
createdLoader = this.cpDelegate.getClassLoader();
// need to load Task via system classloader or the new
@@ -185,9 +194,13 @@
* @since Ant 1.6
*/
public void init() throws BuildException {
-this.cpDelegate = ClasspathUtils.getDelegate(this);
super.init();
}
-
+private ClasspathUtils.Delegate getDelegate() {
+if (cpDelegate == null) {
+cpDelegate = ClasspathUtils.getDelegate(this);
+}
+return cpDelegate;
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
I am +1 to get this into ant 1.6.1.
Cheers,
Antoine
Peter Reilly wrote:
Antoine Lévy-Lambert wrote:
Hi Peter,
can we improve the new classloader so that the work of inspecting the
jars does not happen each time an is done ?
Yes by keeping a static map of file->manifest class path.
With the following:
Done
and the included patch, the time is reduced from 6 seconds to 3
seconds - not
a great improvement considering that there is 100 ant-calls, but it is
a improvement!
Peter
Index: src/main/org/apache/tools/ant/loader/AntClassLoader2.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/loader/AntClassLoader2.java,v
retrieving revision 1.7
diff -u -r1.7 AntClassLoader2.java
--- src/main/org/apache/tools/ant/loader/AntClassLoader2.java 17 Jul 2003
10:36:27 - 1.7
+++ src/main/org/apache/tools/ant/loader/AntClassLoader2.java 15 Jan 2004
17:34:19 -
@@ -1,7 +1,7 @@
/*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -68,6 +68,9 @@
import java.net.URL;
import java.net.MalformedURLException;
import java.util.zip.ZipEntry;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
import java.util.StringTokenizer;
import org.apache.tools.ant.util.FileUtils;
@@ -81,6 +84,9 @@
/** Instance of a utility class to use for file operations. */
private FileUtils fileUtils;
+/** Static map of jar file/time to manifiest class-path entries */
+private static Map pathMap = Collections.synchronizedMap(new HashMap());
+
/**
* Constructor
*/
@@ -272,36 +278,46 @@
return;
}
+String absPathPlusTimeAndLength =
+pathComponent.getAbsolutePath() + pathComponent.lastModified() +
"-"
++ pathComponent.length();
String classpath = null;
-ZipFile jarFile = null;
-InputStream manifestStream = null;
-try {
-jarFile = new ZipFile(pathComponent);
-manifestStream
-= jarFile.getInputStream(new ZipEntry("META-INF/MANIFEST.MF"));
-
-if (manifestStream == null) {
-return;
-}
-Reader manifestReader
-= new InputStreamReader(manifestStream, "UTF-8");
-org.apache.tools.ant.taskdefs.Manifest manifest
-= new org.apache.tools.ant.taskdefs.Manifest(manifestReader);
-classpath
-= manifest.getMainSection().getAttributeValue("Class-Path");
+classpath = (String) pathMap.get(absPathPlusTimeAndLength);
+if (classpath == null) {
+ZipFile jarFile = null;
+InputStream manifestStream = null;
+try {
+jarFile = new ZipFile(pathComponent);
+manifestStream
+= jarFile.getInputStream(new
ZipEntry("META-INF/MANIFEST.MF"));
+
+if (manifestStream == null) {
+return;
+}
+Reader manifestReader
+= new InputStreamReader(manifestStream, "UTF-8");
+org.apache.tools.ant.taskdefs.Manifest manifest
+= new
org.apache.tools.ant.taskdefs.Manifest(manifestReader);
+classpath
+=
manifest.getMainSection().getAttributeValue("Class-Path");
-} catch (org.apache.tools.ant.taskdefs.ManifestException e) {
-// ignore
-} finally {
-if (manifestStream != null) {
-manifestStream.close();
+} catch (org.apache.tools.ant.taskdefs.ManifestException e) {
+// ignore
+} finally {
+if (manifestStream != null) {
+manifestStream.close();
+}
+if (jarFile != null) {
+jarFile.close();
+}
}
-if (jarFile != null) {
-jarFile.close();
+if (classpath == null) {
+classpath = "";
}
+pathMap.put(absPathPlusTimeAndLength, classpath);
}
-if (classpath != null) {
+if (!"".equals(classpath)) {
URL baseURL = fileUtils.getFileURL(pathComponent);
StringTokenizer st = new StringTokenizer(classpath);
while (st.hasMoreTokens()) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Re: New Launcher and JPackage RPMs
Antoine Lévy-Lambert wrote:
Hi Peter,
can we improve the new classloader so that the work of inspecting the
jars does not happen each time an is done ?
Yes by keeping a static map of file->manifest class path.
With the following:
Done
and the included patch, the time is reduced from 6 seconds to 3 seconds
- not
a great improvement considering that there is 100 ant-calls, but it is a
improvement!
Peter
Index: src/main/org/apache/tools/ant/loader/AntClassLoader2.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/loader/AntClassLoader2.java,v
retrieving revision 1.7
diff -u -r1.7 AntClassLoader2.java
--- src/main/org/apache/tools/ant/loader/AntClassLoader2.java 17 Jul 2003 10:36:27 - 1.7
+++ src/main/org/apache/tools/ant/loader/AntClassLoader2.java 15 Jan 2004 17:34:19 -
@@ -1,7 +1,7 @@
/*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -68,6 +68,9 @@
import java.net.URL;
import java.net.MalformedURLException;
import java.util.zip.ZipEntry;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
import java.util.StringTokenizer;
import org.apache.tools.ant.util.FileUtils;
@@ -81,6 +84,9 @@
/** Instance of a utility class to use for file operations. */
private FileUtils fileUtils;
+/** Static map of jar file/time to manifiest class-path entries */
+private static Map pathMap = Collections.synchronizedMap(new HashMap());
+
/**
* Constructor
*/
@@ -272,36 +278,46 @@
return;
}
+String absPathPlusTimeAndLength =
+pathComponent.getAbsolutePath() + pathComponent.lastModified() + "-"
++ pathComponent.length();
String classpath = null;
-ZipFile jarFile = null;
-InputStream manifestStream = null;
-try {
-jarFile = new ZipFile(pathComponent);
-manifestStream
-= jarFile.getInputStream(new ZipEntry("META-INF/MANIFEST.MF"));
-
-if (manifestStream == null) {
-return;
-}
-Reader manifestReader
-= new InputStreamReader(manifestStream, "UTF-8");
-org.apache.tools.ant.taskdefs.Manifest manifest
-= new org.apache.tools.ant.taskdefs.Manifest(manifestReader);
-classpath
-= manifest.getMainSection().getAttributeValue("Class-Path");
+classpath = (String) pathMap.get(absPathPlusTimeAndLength);
+if (classpath == null) {
+ZipFile jarFile = null;
+InputStream manifestStream = null;
+try {
+jarFile = new ZipFile(pathComponent);
+manifestStream
+= jarFile.getInputStream(new ZipEntry("META-INF/MANIFEST.MF"));
+
+if (manifestStream == null) {
+return;
+}
+Reader manifestReader
+= new InputStreamReader(manifestStream, "UTF-8");
+org.apache.tools.ant.taskdefs.Manifest manifest
+= new org.apache.tools.ant.taskdefs.Manifest(manifestReader);
+classpath
+= manifest.getMainSection().getAttributeValue("Class-Path");
-} catch (org.apache.tools.ant.taskdefs.ManifestException e) {
-// ignore
-} finally {
-if (manifestStream != null) {
-manifestStream.close();
+} catch (org.apache.tools.ant.taskdefs.ManifestException e) {
+// ignore
+} finally {
+if (manifestStream != null) {
+manifestStream.close();
+}
+if (jarFile != null) {
+jarFile.close();
+}
}
-if (jarFile != null) {
-jarFile.close();
+if (classpath == null) {
+classpath = "";
}
+pathMap.put(absPathPlusTimeAndLength, classpath);
}
-if (classpath != null) {
+if (!"".equals(classpath)) {
URL baseURL = fileUtils.getFileURL(pathComponent);
StringTokenizer st = new StringTokenizer(classpath);
while (st.hasMoreTokens()) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
Hi Peter,
can we improve the new classloader so that the work of inspecting the
jars does not happen each time an is done ?
Antoine
Peter Reilly wrote:
Stefan Bodewig wrote:
Hi,
today I found myself discussing with the JPackage folks on their list
about the problems the RPM setup has with the new Launcher.
They put all the installed jars into a single directory and let config
files put together the classpath before they invoke Ant IIUC.
So far we've told people that the new Launcher would pull in all jars
from ANT_HOME/lib (and in addition from ~/.ant/lib, but we didn't say
that very loud) - but this is not true. It pulls in all jars from the
directory containing ant-launcher.jar, no matter where it is.
In stock installs this is the same, but not in the RPM installation
where this behavior pulls in the whole Java universe.
This may have performance implications.
I was looking at slowdowns from 1.5 to 1.6. One issue is
This is slower in 1.6 than it is in 1.5. This is due to the new
classloader (I think). The new classloader added the jars in
${ant.home}/lib to the
classpath and also opens each jar looking for classpath information in
it.
If the is at the top level, this happens each time an
ant-call is
done - so a common idiom causes problems:
( or &common;)
Where common.xml contains:
Peter
I'm not convinced that we need to adjust anything, but it is an
interesting thing to note.
Stefan
-
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: New Launcher and JPackage RPMs
Stefan Bodewig wrote:
Hi,
today I found myself discussing with the JPackage folks on their list
about the problems the RPM setup has with the new Launcher.
They put all the installed jars into a single directory and let config
files put together the classpath before they invoke Ant IIUC.
So far we've told people that the new Launcher would pull in all jars
from ANT_HOME/lib (and in addition from ~/.ant/lib, but we didn't say
that very loud) - but this is not true. It pulls in all jars from the
directory containing ant-launcher.jar, no matter where it is.
In stock installs this is the same, but not in the RPM installation
where this behavior pulls in the whole Java universe.
This may have performance implications.
I was looking at slowdowns from 1.5 to 1.6. One issue is
This is slower in 1.6 than it is in 1.5. This is due to the new
classloader (I think). The new classloader added the jars in
${ant.home}/lib to the
classpath and also opens each jar looking for classpath information in it.
If the is at the top level, this happens each time an ant-call is
done - so a common idiom causes problems:
( or &common;)
Where common.xml contains:
Peter
I'm not convinced that we need to adjust anything, but it is an
interesting thing to note.
Stefan
-
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]
