DO NOT REPLY [Bug 25761] New: - JBoss

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25761

JBoss 

   Summary: JBoss
   Product: Ant
   Version: 1.6.0
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Ant are always looking for jbosscmp-jdbc.xml if jboss tag is added to ejbjar, 
and shows an error in red if not found. This file does not always exist (only 
if CMRs are added). The jar is created fine so this is only a "cosmetic" 
broblem i guess.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25765] New: - ant failed to copy a dir just checked out from CVS

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25765

ant failed to copy a dir just checked out from CVS

   Summary: ant failed to copy a dir just checked out from CVS
   Product: Ant
   Version: 1.5.3
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


After I checked out one module from CVS, Ant always failed to copy all files
under that dir to another places at the first time. If I rerun ant for the
second  time, it could complete this "copy" task.
I have 386 files in that dir, 260 files are newest date (my checkout date),
others(126) are older. Ant always only copy that 126 old files at the first
time, while copy all files next time.
We shared ant and uses the same copy for all peoples.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25765] - ant failed to copy a dir just checked out from CVS

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25765

ant failed to copy a dir just checked out from CVS

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-26 10:45 ---
I am sorry that this is not ant's bug.
The files are created after copy process.
So please close this bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory utilization on ANT 1.6.0

[Jose Alberto Fernandez]

> From: Antoine Lévy-Lambert [mailto:[EMAIL PROTECTED] 
> 
> Jose Alberto Fernandez wrote:
> 
> >Given the realization of Peter, maybe we need to embark on
> >a code review of the tasks, at least the most important
> >to make sure we do not keep hold or objects unnecessarily.
> >
> >If you look at the memory utitization numbers I submitted
> >all of them are like much larger, even before the first 
> script gets to 
> >be ran. I think it may have to do with this issue.
> >
> I realized that tasks are never GCed because there was a 
> bugzilla report 
> about the  task. 
> http://nagoya.apache.org/bugzilla/show_bug.cgi> ?id=21505
> 
> ...
>
> Because of these type of issues, a  number of tasks which in 
> the execute 
> method are changing instance variables are resetting these instance 
> variables at the end of the execute method.
> 
> There are lots of constructs like :
> 
> public void execute() {
> 
> savedProperty1 = property1;
> savedProperty2 = property2;
> 
> /* do something */
> 
> property1 = savedProperty1;
> property2 = savedProperty2;
> 
> }
> 
> This does not look too nice and might not be entirely foolproof - in 
> case of exceptions happening somewhere in the execution of 
> the task for 
> instance, and not allowing the instance variables to be 
> resetted to their values prior to execution.
> 

Was this the case in 1.5.x ? Or is it due to some change on how we build
the project now? If the later, is there a way to simulate the previous
behavior? For example by removing the  instance and recomputing
the UnknownObject every time.

I still do not understand the situation Antoine found with 
because I thought that everytime  gets executed a complete
new project instance gets constructed, executed and thrown away.
So a task should never be reused due to repeated calls to .

Am I mistaken? Was something dramatically changed?

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25767] New: - Performance & threading issues in JAXPUtils' use of SAXParser & SAXParserFactory

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25767

Performance & threading issues in JAXPUtils' use of SAXParser & SAXParserFactory

   Summary: Performance & threading issues in JAXPUtils' use of
SAXParser & SAXParserFactory
   Product: Ant
   Version: 1.6.0
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Comments on when JAXPUtils creates new factory / parser / document builder
objects and when it caches them.

1. Correctness:

private static SAXParserFactory parserFactory = null;
public static synchronized SAXParserFactory getParserFactory() {
if (parserFactory == null) {
parserFactory = newParserFactory();
}
return parserFactory;
}

(and similar methods) is likely not correct. An instance of SAXParserFactory is
not thread-safe and might not be reentrant, according to its Javadoc. If more
than one thread in the JVM is calling this method and using the same parser,
random corruption might result - this might happen to someone using ,
for example; or someone running several builds at once using an IDE integration.
Or if this method is called in the middle of a parse for some reason - to parse
some referenced file? - there might be corruption; at least SAX1's Parser says
it is not reentrant.

2. Performance: casual examination of the performance of running a tiny build
script w/ several antlib.xml's over and over using a profiler shows some 20-30%
of the CPU time being spent in JAXPUtils.getNamespaceXMLReader(), specifically
calling Xerces' SAXParserImpl.(). Not an especially cheap call since it
sets up a lot of objects of various kinds; you are supposed to cache the result
from call to call if you want good performance and might be parsing a lot of
files. (E.g. a lot of small antlib.xml's, or many little build.xml's with
, etc.) Note that this time is not spent actually parsing the XML or
even opening the input stream to it - just getting a parser object.

Suggested fix to both problems:

1. Rework the helper methods in JAXPUtils to cache not just the factory objects
but the parsers & document builders themselves. I don't know how expensive
getting the factory is - JAXPUtils already caches them, and my profiling only
took place on a "warmed-up" JVM - but invoking the factories' new*() methods is
too expensive to do every time an XML file is parsed.

2. Leave uncached impls as e.g. SAXParser createSAXParser() and so on - these
would always create new ones. Or for compatibility, keep the current method
names, but deprecate them in favor of properly cached versions (see #3).

3. For cached usage, use e.g. SAXParser obtainSAXParser() and void
releaseSAXParser(SAXParser) methods. These should use java.lang.ThreadLocal:

private static final ThreadLocal/**/ saxParser = new ThreadLocal();
public static SAXParser obtainSAXParser() {
SAXParser p = (SAXParser)saxParser.get();
if (p != null) {
saxParser.set(null);
} else {
p = createSAXParser();
}
return p;
}
public static void releaseSAXParser(SAXParser p) {
saxParser.set(p);
}

// Usage:
SAXParser p = obtainSAXParser();
try {
   // parse...
} finally {
releaseSAXParser(p);
}

Forgetting to release a parser is not a big deal, it will just need to be
recreated on the next obtain*() call. Using ThreadLocal ensures that different
threads never share the same object. Setting the ref to null in obtain*()
ensures that reentrant calls (i.e. calling obtain*() while the last-obtained
parser is still in use) will be safe.

One issue is that several utility methods do not return the original cacheable
object, but rather something derived from it, e.g.

return newSAXParser(getNSParserFactory()).getXMLReader();

For this usage you should probably have obtainNamespaceXMLReader +
releaseNamespaceXMLReader, etc. - i.e. keep a separate cache for each kind of
object - since you can't get back to the SAXParser from the XMLReader.

Could try to provide a patch if there is interest - at least modifications to
JAXPUtils, and usage of the new methods in e.g. ProjectHelper2.parse().

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ImportTaskTest fails in Ecllipse

[Nick Chalko]

Running the ImportTaskTest using the JUnit tools in Eclipse, all test fail.
./build.sh -Dtestcase=org.apache.tools.ant.taskdefs.ImportTest 
run-single-test   passes.

Here is the error for testSimpleImport
junit.framework.AssertionFailedError: expecting log to contain "Before 
importIn imported topAfter import" log was "Trying to override old 
definition of task classloaderTrying to override old definition of 
datatype descriptionTrying to override old definition of task 
importTrying to override old definition of task taskdefBefore 
importAfter importIn imported top"
   at junit.framework.Assert.fail(Assert.java:47)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at 
org.apache.tools.ant.BuildFileTest.assertLogContaining(BuildFileTest.java:118)
   at 
org.apache.tools.ant.taskdefs.ImportTest.testSimpleImport(ImportTest.java:79)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:324)
   at junit.framework.TestCase.runTest(TestCase.java:154)
   at junit.framework.TestCase.runBare(TestCase.java:127)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:118)
   at junit.framework.TestSuite.runTest(TestSuite.java:208)
   at junit.framework.TestSuite.run(TestSuite.java:203)
   at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:392)
   at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:276)
   at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:167)

Any Ideas?
R,
Nick
PS CVS Head of ant.
And Eclipse 2.1.2 Build id: 200311030802

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]