DO NOT REPLY [Bug 38730] New: - program hangs while trying to delete a file on a remote FTP Server after downloading same

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38730.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38730

   Summary: program hangs while trying to delete a file on a remote
FTP Server after downloading same
   Product: Commons
   Version: 1.1.0
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Net
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I am using the commons-net-1.1.0.jar to perform FTP related activities. The 
process I am doing is as follows:

1. Logon to the remote FTP Server running on Solaris (which is behind a 
firewall)
2. Download a file
3. Delete the remote file after successful download

But here I am facing a problem, once the file is downloaded, it does not get 
deleted in the remote FTP server and the program hangs. An interrupted IO 
Exception is being thrown and the program just hangs. 

Any suggestions will be appreciated

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



DO NOT REPLY [Bug 38686] - [VFS] Default VFS cache behavior

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38686.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38686





--- Additional Comments From [EMAIL PROTECTED]  2006-02-21 10:29 ---
Hi,

the tmp files are created by the FileReplicator and are deleted during shutdown
of the VFS-Manager.
You may set your own implementation of a FileReplicator (that does a better Job)
via:

((DefaultFileSystemManager) VFS.getManager()).setReplicator(...);

You may gracefully shutdown the default replicator
(VFS.getManager()).getReplicator()) before.

Be sure to do this at application start up!!!

After accessing your tar.gz you should shutdown the implicitly created file
system like so:

((DefaultFileSystemManager)
VFS.getManger()).closeFileSystem(someFileObjectInYourTarGz.getFilesSystem());

This will release the TarFileSystem instance that holds the reference to the tmp
File object.
As far as I know there´s no event (or something like that) to keep track on file
system shutdowns. So you may use a weak reference to the file object (you
replicated) to cleanup the unused temp file:

1. create a class that extends java.lang.ref.WeakReference:
public class WeakFileRef extends WeakReference {
private String absPath;
public WeakFileRef(File file, ReferenceQueue queue) {
super(file, queue);
this.absPath = file.getAbsolutePath();
}
public String getPath() {
return this.absPath;
}
}

2. Do your own FileReplicator implementation. You may copy and slightly modify
org.apache.commons.vfs.impl.DefaultFileReplicator. Attention: don´t use any hard
reference on file objects here - use the WeakFileRef class.

3. In your FileReplicator implementation create a field of type ReferenceQueue
private ReferenceQueue queue = new ReferenceQueue();

4. Change allocateFile(String):
public File allocateFile(final String baseName) throws FileSystemException
{
WeakFileRef fileRef = (WeakFileRef) queue.poll(); // poll the refence queue
and delete finalized files
while (fileRef != null) {
File toDelete = new File(fileRef.getAbsPath());
try {
if (toDelete.exists()) {
toDelete.delete();
}
} catch (IOException) {
// do some exception handling or throw a FileSystemExeption
}
copies.remove(fileRef);
fileRef = (WeakFileRef) queue.poll();
}

// Create a unique-ish file name
final String basename = createFilename(baseName);
filecount++;
final File file = createFile(tempDir, basename);

// Keep track to delete later
copies.add(new WeakFileRef(file, queue)); // - changed

return file;
}

5. Change the close() method - ArrayList 'copies' now holds WeakFileRef 
objects!

Notice that the files are not cleaned up immediately - it depends on garbage
collection.

Hope this helps/(works) ;-)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



RE: [id] Composite identifiers

2006-02-21 Thread Jörg Schaible
Hi Phil,

Phil Steitz wrote on Monday, February 20, 2006 6:28 AM:

 Jörg Schaible wrote:
 Jörg Schaible wrote on Monday, February 06, 2006 9:07 PM:
 
[snip]
 Looks fine. I've added the missing minLength/maxLength
 implementations and made it serializable. I would add a
 ConstantIdentifierGenerator. 
 
 
 What about adding adding a method to
 StringIdentifierGenerator to deal with StringBuffers?
 
 StringBuffer nextIdentifier(StringBuffer buffer);
 
 The implementation should append the next identifier to the
 buffer and return it. This would make the concatenation more
 efficient and may be also useful for other use cases where
 the returned id is added to a String.
 
 Finally getting back into this.  Sorry for the latency. 

:)
Had some other tasks, too. I basically stopped since the next thing is working 
either on the composite thingy or the UUID classes.

 I like the idea
 above from the standpoint of efficiency, but it looks a
 little odd as an
 API.  Could be nothing wrong with it, just looks odd at first
 blush to me. 

jMock uses such an API for its Constraint.describeTo. Therefore I am used to 
it. Since it does make sense for StringIdentifierGenerators only and the 
implementation are/should be performance optimized, it is worth it IMHO.

 Might be better to change the name to
 appendNextIdentifier, so the
 append semantics are clear.

Well, you don't have to append, an impl might even return another StringBuffer 
(although append *is* the most natural case).

 I will add ConstantIdentifierGenerator in any case.

OK.

- Jörg

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



DO NOT REPLY [Bug 38686] - [VFS] Default VFS cache behavior

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38686.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38686





--- Additional Comments From [EMAIL PROTECTED]  2006-02-21 11:43 ---
Thanks a lot, I'm going to try it 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



Re: [logging] Avalon log not Serializable?

2006-02-21 Thread Simon Kitching
On Tue, 2006-02-21 at 17:59 +1300, Simon Kitching wrote:
 Hi,
 
 I've been checking whether all the standard Log adapter classes are
 Serializable. The Avalon logger declares itself to be Serializable, but
 my reading of the code indicates this won't work. Can someone
 confirm/deny this?

I've done some more work, and it sure looks like AvalonLogger is broken
for Serialization. It's had quite an interesting history.

Craig Mcc has also confirmed it looks broken to him.

Here are the options I can see:
(a) remove AvalonLogger from the JCL 1.1 distribution.
(b) remove Serializable marker interface from AvalonLogger
(c) on deserialize, try to handle things properly (we can under
some circumstances). If not possible, create a dummy Logger
object that just discards all output.

AvalonLogger was only added in the 1.0.4 release (and therefore
obviously was not *deprecated*). However the avalon project is
completely dead AFAIK. One potential issue is that the latest stable
release of Apache FOP is v0.20 which still uses avalon-framework. While
old, I expect Apache FOP is used in quite a few apps. And apps using
Apache FOP *might* redirect JCL via the AvalonLogger adapter to the
avalon logging system. Crazy but possible.

Option b is also reasonable to me. Serialization never worked for
AvalonLogger; any attempt to use a deserialized object would immediately
result in a NullPointerException. By implication, there are no systems
out there using serialization for AvalonLogger objects. And the
existence of the Serializable marker is not a compile-time
incompatibility (except in truly perverse code). So surely dropping the
marker won't do any harm. It does mean we can't claim all standard log
adapters are Serializable but I think we can live with that.

Option c doesn't look too hard; the avalon Logger interface is almost
exactly like the JCL Log interface so we could whip up a dummy class
like NoOpLog which we can create an instance of.


My preference in order would be: B, A, C. 
All seem feasable.

Comments?



BTW, I have checked for unit tests for Serializable behaviour. Log4j,
Simple and Jdk14 all have a unit test checking that a
serialized/deserialized instance works ok.

NoOp, LogKit and AvalonLogger do not have serialization unit tests. As
NoOp has *no* instance members of any sort a test doesn't seem
vital :-). I'm willing to create a serialization test for LogKit..

Cheers,

Simon


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



[EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed

2006-02-21 Thread commons-jelly-tags-xml development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-xml-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-xml-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html
Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 28 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1):
  Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
 x:set You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
 x:set You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1):
Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
 x:set You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
 x:set You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1):  Caused an 
ERROR
[junit] 

[EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed

2006-02-21 Thread commons-jelly-tags-xml development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-xml-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-xml-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html
Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 28 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1):
  Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
 x:set You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
 x:set You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1):
Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
 x:set You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
 x:set You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1):  Caused an 
ERROR
[junit] 

[EMAIL PROTECTED]: Project commons-latka (in module jakarta-commons) failed

2006-02-21 Thread Ted Husted
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-latka has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-latka :  Functional Testing Suite


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons/commons-latka/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-latka.jar] identifier set to project name
 -DEBUG- Dependency on jaxen exists, no need to add for property jaxen.jar.
 -INFO- Made directory 
[/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/jakarta-commons/latka/target/test-classes]
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons/commons-latka/gump_work/build_jakarta-commons_commons-latka.html
Work Name: build_jakarta-commons_commons-latka (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Djaxen.jar=/usr/local/gump/public/workspace/jaxen/target/jaxen-21022006.jar 
dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/latka]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes:/usr/local/gump/public/workspace/jakarta-commons/latka/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-21022006.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-21022006.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-21022006.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-21022006.jar
-
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.924 sec
[junit] - Standard Output ---
[junit] log4j:INFO Using URL 
[file:/x1/gump/public/workspace/jakarta-commons/latka/target/classes/log4j.properties]
 for automatic log4j configuration of repository named [default].
[junit] ESE

[junit] [message] boo1

[junit] http://example.net:80/
[junit]   REQUEST ERROR (-1 millis)
[junit] java.net.ConnectException: Connection refused

[junit] [message] boo2

[junit] http://example.org:80/
[junit]   REQUEST SKIPPED (-1 millis)

[junit] [message] boo3

[junit] http://example.net:80/
[junit]   REQUEST ERROR (-1 millis)
[junit] java.net.ConnectException: Connection refused


[junit] SUITE FAILED

[EMAIL PROTECTED]: Project commons-latka (in module jakarta-commons) failed

2006-02-21 Thread Ted Husted
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-latka has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-latka :  Functional Testing Suite


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons/commons-latka/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-latka.jar] identifier set to project name
 -DEBUG- Dependency on jaxen exists, no need to add for property jaxen.jar.
 -INFO- Made directory 
[/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/jakarta-commons/latka/target/test-classes]
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons/commons-latka/gump_work/build_jakarta-commons_commons-latka.html
Work Name: build_jakarta-commons_commons-latka (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Djaxen.jar=/usr/local/gump/public/workspace/jaxen/target/jaxen-21022006.jar 
dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/latka]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes:/usr/local/gump/public/workspace/jakarta-commons/latka/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-21022006.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-21022006.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-21022006.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-21022006.jar
-
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.924 sec
[junit] - Standard Output ---
[junit] log4j:INFO Using URL 
[file:/x1/gump/public/workspace/jakarta-commons/latka/target/classes/log4j.properties]
 for automatic log4j configuration of repository named [default].
[junit] ESE

[junit] [message] boo1

[junit] http://example.net:80/
[junit]   REQUEST ERROR (-1 millis)
[junit] java.net.ConnectException: Connection refused

[junit] [message] boo2

[junit] http://example.org:80/
[junit]   REQUEST SKIPPED (-1 millis)

[junit] [message] boo3

[junit] http://example.net:80/
[junit]   REQUEST ERROR (-1 millis)
[junit] java.net.ConnectException: Connection refused


[junit] SUITE FAILED

[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed

2006-02-21 Thread commons-jelly-tags-html development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-html has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-html :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-html-21022006.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html
Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build)
Work ended in a state of : Failed
Elapsed: 12 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at 

[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed

2006-02-21 Thread commons-jelly-tags-html development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-html has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-html :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-html-21022006.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html
Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build)
Work ended in a state of : Failed
Elapsed: 12 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at 

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2006-02-21 Thread commons-jelly-tags-jsl development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar
-
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234)
[junit] at 
org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78)
[junit] at 

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2006-02-21 Thread commons-jelly-tags-jsl development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar
-
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234)
[junit] at 
org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78)
[junit] at 

[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) failed

2006-02-21 Thread commons-jelly-tags-define development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-define-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html
Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 13 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-21022006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21022006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar
-
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:118)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:208)
[junit] at junit.framework.TestSuite.run(TestSuite.java:203)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536)
[junit] Feb 21, 2006 4:12:14 AM 
org.apache.commons.jelly.expression.xpath.XPathExpression evaluate
[junit] SEVERE: Error constructing xpath
[junit] org.jaxen.XPathSyntaxException: Node-set expected
[junit] at org.jaxen.BaseXPath.init(BaseXPath.java:131)
[junit] at org.jaxen.BaseXPath.init(BaseXPath.java:156)
[junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101)
[junit] at 
org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78)
[junit] at 
org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] at junit.framework.TestCase.runBare(TestCase.java:127)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at 

DO NOT REPLY [Bug 38730] - [net] program hangs while trying to delete a file on a remote FTP Server after downloading same

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38730.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38730


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|program hangs while trying  |[net] program hangs while
   |to delete a file on a remote|trying to delete a file on a
   |FTP Server after downloading|remote FTP Server after
   |same|downloading same




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



Re: [Jakarta-commons Wiki] Update of MavenPlugins by DennisLundberg

2006-02-21 Thread Dennis Lundberg
This might very well be a misunderstanding on my part. Please feel free 
to correct it on the wiki.


Dion Gillard wrote:

I can't see how the jellydoc plugin is Maven 1 specific.

if jelly is ever to move to m2 as a build, we'd need that plugin.

On 2/21/06, Apache Wiki [EMAIL PROTECTED] wrote:

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by DennisLundberg:
http://wiki.apache.org/jakarta-commons/MavenPlugins

The comment on the change is:
Clarify what the columns mean

--

  == Reports ==

- ||'''Plugin'''||'''Where is it''' 
||'''Current release'''||
+ ||'''Plugin'''||'''Where is the M2 version''' 
||'''Current M2 release'''||
  ||maven-changelog-plugin  ||@mojo/ibiblio 
||2.0-beta-1||
  ||maven-changes-plugin||@mojo/ibiblio 
||2.0-beta-1||
  ||maven-checkstyle-plugin ||@maven
||2.0-beta-1||
@@ -34, +34 @@


  == Plugins ==

- ||'''Plugin'''||'''Where is it''' 
||'''Current release'''||
+ ||'''Plugin'''||'''Where is the M2 version''' 
||'''Current M2 release'''||
  ||maven-site-plugin   ||@maven
||2.0-beta-4||
  ||maven-xdoc-plugin   ||[EMAIL PROTECTED], [EMAIL PROTECTED]  
 ||n/a||


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





--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is
afraid of the dark, but because the dark is afraid of Chuck Norris

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





--
Dennis Lundberg

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



DO NOT REPLY [Bug 38742] New: - Fails to apply fieldname

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38742.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38742

   Summary: Fails to apply fieldname
   Product: Commons
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: File Upload
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Fileupload fails when parsing this example multipart request from RFC 1867. It
appears that the attachmements file1.txt and file2.gif are associateed with
the same form field name, pics. However, since the name pics is specified in
the content-disposition header on line [08], it is lost when the
content-disposition header on lines [12] and [17] are parsed. The attachments
are returned in the FileItem but the fieldName properties are null.

I believe the name property from line [8] should be persisted and applied to
both file parts (file1.txt and file2.gif).

[01] Content-type: multipart/form-data, boundary=AaB03x
[02]
[03] --AaB03x
[04] content-disposition: form-data; name=field1
[05]
[06] Joe Blow
[07] --AaB03x
[08] content-disposition: form-data; name=pics
[09] Content-type: multipart/mixed, boundary=BbC04y
[10]
[11] --BbC04y
[12] Content-disposition: attachment; filename=file1.txt
[13] Content-Type: text/plain
[14]
[15] ... contents of file1.txt ...
[16] --BbC04y
[17] Content-disposition: attachment; filename=file2.gif
[18] Content-type: image/gif
[19] Content-Transfer-Encoding: binary
[20]
[21] ...contents of file2.gif...
[22] --BbC04y--
[23] --AaB03x--

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



DO NOT REPLY [Bug 38742] - [fileupload] Fails to apply fieldname

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38742.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38742


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Fails to apply fieldname|[fileupload] Fails to apply
   ||fieldname




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



Re: [logging] interesting performance figures

2006-02-21 Thread robert burrell donkin
On Tue, 2006-02-21 at 00:42 +0100, Remy Maucherat wrote:
 On 2/21/06, robert burrell donkin [EMAIL PROTECTED] wrote:
  i've been running some performance tests: the aim being to check how
  much slower JCL 1.1 runs that the 1.0.x releases. the figures for log4j
  are interesting. the raw data is below (the percentages are normalised
  to 1.0.4 benchmark times).
 
  1. there is a small performance degradation between the 1.0.3, 1.0.4 and
  1.1RC5 but not significant (a few percentiles).
  2. 1.0.2 is a *lot* faster for log4j that the later releases
  3. isDebugEnabled is a *lot* faster than logging
  4. getLog is *slow*
 
  i have some ideas for improving performance against log4j (but testing
  them will have to wait till tomorrow).
 
 As long as isDebugEnabled is fast, I'm happy. In most cases, debug
 level will mean logging a ton of things, so will be slow (of course,
 people have complained that TC was too slow with debug logging). 

i probably should have mentioned that the tests were for debugging to a
disabled category/logger (whichever nomenclature you prefer): something
smells bad :-/

i have an idea what so i'll report back a little later with more
information once i have it...

 Are the figures similar with JDK logging ?

nope :)

except for 1.0.2 (which is very, very slow - suggesting an environmental
issue), these are the times i would have expected from the test. logging
to log4j is about 100 times slower.

i'm not as satisfied with these figures (too many erratic values) but
here they are anyway:

RC5
GetLog: Duration=7324 9661 7329 7318AVG 7908  ~108%
Trace: Duration=50 136 36 36AVG 64.5  ~178%
Debug: Duration=43 25 134 32AVG 58.5  ~184%
isDebugEnabled: Duration=130 17 22 123  AVG 73~75%

1.0.4
GetLog: Duration=6873 8574 6861 6871AVG 7294.75 100%
Trace: Duration=37 36 36 36 AVG 36.25   100%
Debug: Duration=32 31 32 32 AVG 31.75   100%
isDebugEnabled: Duration=122 21 123 122 AVG 97  100%

1.0.3
GetLog: Duration=6921 7006 6919 6906AVG 6938~95%
Trace: Duration=136 34 34 135   AVG 84.75   ~234%
Debug: Duration=32 32 32 31 AVG 31.75   100%
isDebugEnabled: Duration=21 20 21 20AVG 20.521%

1.0.2
GetLog: Duration=6873 6876 6866 6875AVG 6872.5  ~94%
Trace: Duration=28481 28414 28628 28401 AVG 28481   78568%
Debug: Duration=28827 28601 29264 31879 AVG 36958.75  116403%
isDebugEnabled: Duration=176 21 21 123  AVG 85.25 88%

- robert


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



Re: [logging] interesting performance figures

2006-02-21 Thread robert burrell donkin
On Tue, 2006-02-21 at 20:51 +, robert burrell donkin wrote:
 On Tue, 2006-02-21 at 00:42 +0100, Remy Maucherat wrote:
  On 2/21/06, robert burrell donkin [EMAIL PROTECTED] wrote:
   i've been running some performance tests: the aim being to check how
   much slower JCL 1.1 runs that the 1.0.x releases. the figures for log4j
   are interesting. the raw data is below (the percentages are normalised
   to 1.0.4 benchmark times).
  
   1. there is a small performance degradation between the 1.0.3, 1.0.4 and
   1.1RC5 but not significant (a few percentiles).
   2. 1.0.2 is a *lot* faster for log4j that the later releases
   3. isDebugEnabled is a *lot* faster than logging
   4. getLog is *slow*
  
   i have some ideas for improving performance against log4j (but testing
   them will have to wait till tomorrow).
  
  As long as isDebugEnabled is fast, I'm happy. In most cases, debug
  level will mean logging a ton of things, so will be slow (of course,
  people have complained that TC was too slow with debug logging). 
 
 i probably should have mentioned that the tests were for debugging to a
 disabled category/logger (whichever nomenclature you prefer): something
 smells bad :-/

and it was my configuration: log4j is *very* slow which it's not
explicitly configured. with a log4j file, the figures are pretty much
what i'd expect. that's a relief :)

i'm not sure why JCL 1.0.2 is quicker a configuration file. it does use
category (rather than logger)...

- robert


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



svn commit: r379595 - /jakarta/commons/proper/logging/branches/JCL1/

2006-02-21 Thread rdonkin
Author: rdonkin
Date: Tue Feb 21 13:41:05 2006
New Revision: 379595

URL: http://svn.apache.org/viewcvs?rev=379595view=rev
Log:
Created a branch for any ongoing JCL1 work. Future 1.x releases will be cut 
from this branch.

Added:
jakarta/commons/proper/logging/branches/JCL1/
  - copied from r379594, 
jakarta/commons/proper/logging/tags/LOGGING_1_1_0_RC5/


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



[logging] JCL1 branch

2006-02-21 Thread robert burrell donkin
I've cut a branch for any ongoing work needed for JCl1:
http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/branches/JCL1/

future release candidates will be cut from this branch.

- robert


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



Re: [logging] Avalon log not Serializable?

2006-02-21 Thread robert burrell donkin
On Tue, 2006-02-21 at 23:58 +1300, Simon Kitching wrote:

 Craig Mcc has also confirmed it looks broken to him.

yep, broke

 Here are the options I can see:
 (a) remove AvalonLogger from the JCL 1.1 distribution.
 (b) remove Serializable marker interface from AvalonLogger
 (c) on deserialize, try to handle things properly (we can under
 some circumstances). If not possible, create a dummy Logger
 object that just discards all output.

snip

 My preference in order would be: B, A, C. 
 All seem feasable.
 
 Comments?

B, C, A :)

 BTW, I have checked for unit tests for Serializable behaviour. Log4j,
 Simple and Jdk14 all have a unit test checking that a
 serialized/deserialized instance works ok.
 
 NoOp, LogKit and AvalonLogger do not have serialization unit tests. As
 NoOp has *no* instance members of any sort a test doesn't seem
 vital :-). I'm willing to create a serialization test for LogKit.

if it's not going to take too much time, that'd be good. please use the
JCL1 branch.

- robert


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



Re: [logging] Avalon log not Serializable?

2006-02-21 Thread robert burrell donkin
On Tue, 2006-02-21 at 17:59 +1300, Simon Kitching wrote:

 The Log4JLogger class appears to work correctly, because it implements
 getLogger like this:
 public Logger getLogger() {
 if (logger == null) {
 logger = Logger.getLogger(name);
 }
 return (this.logger);
 }
 which reinitialises the logger member after deserialization. Personally
 I would like to see a readObject method do this instead as all other
 methods could then access the logger member directly and avoid a method
 call; however both will work fine. Hmm..perhaps this method call is the
 cause of the slowdown in Log4JLogger since 1.2 revealed by Robert's
 recent tests?

i've tracked this down now. there appears to be big performance
difference between calling category and logger when the log system is
not configured. add a basic, no logging configuration brought the
figures all into line.

so, the good news is that we're about as fast as the other JCL
releases. 

FWIW i also prefer the readObject solution

- robert


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



Re: [logging] new simple logging component?

2006-02-21 Thread robert burrell donkin
On Sun, 2006-02-19 at 09:22 +0100, Boris Unckel wrote:
 Good Morning,
 
 Torsten Curdt wrote:
  ...and frankly speaking - it will also help marketing wise. JCL1
  has a bit of a bad reputation. JCL2 could help to leave this behind.
 
 JCL 1.0x has a bit of a bad reputation: Some developers/admins 
 (profession) or people who have developer and/or admin jobs (this is not 
 the same)
 expect _any_ software to unzip, click on the start button, and 
 _everything_ works with the default settings. Even more: The whole system
 is completely self healing, regardless which error occurs.
 I understand your remark from the use in tomcat environments. A J2EE 
 server is not a plug'n'play system like a USB-MP3 stick, but some
 people seem to expect that. Until they do not change their mind and 
 recognize that there is software which has the need to read and understand
 documentation you  will have this bit of a bad reputation.

:)

the problem is expectation: we promised automagic configuration

hubris

- robert


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



[logging] discovery and memory leaks

2006-02-21 Thread robert burrell donkin
too much caffine for me yesterday (very bad for me resulting in mental
overdrive and then no sleep). even though i'm tired now, it the manic
phase may have produced a positive side effect - or possibly just
another mad idea...

a lot of difficulties (including issues with hot deployment) arise from
JCL caching classloaders. most of these issues should be addressed by
using a weakhashtable but there are certain cases where even a weak hash
table cannot solve the issue.

the reason for indexing on classloaders is to allow configurations to be
saved on a per classloader basis. it strikes me that identity should be
as good as equality for this indexing. if so, then we could use
System.identityHashCode as the index rather than the actual classloader.

please feel free to spot the flaws with this plan :)

- robert


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



Re: [logging] discovery and memory leaks

2006-02-21 Thread Sandy McArthur
On 2/21/06, robert burrell donkin [EMAIL PROTECTED] wrote:
 the reason for indexing on classloaders is to allow configurations to be
 saved on a per classloader basis. it strikes me that identity should be
 as good as equality for this indexing. if so, then we could use
 System.identityHashCode as the index rather than the actual classloader.

 please feel free to spot the flaws with this plan :)

Just gotta stress the *should*. System.identityHashCode returns an
int, technically that won't cut it for 64 bit Java.

That said if you find a real solution to this problem I'd like to know
because the reference and debug features of composite pool
implementation I submitted currently depend on hoping the
System.identityHashCode doesn't return the same value for two
different instances.

I don't like that code but I don't expect many people to use it in
production. If you expect people to often use that technique in
production I think we should keep looking.

--
Sandy McArthur

He who dares not offend cannot be honest.
- Thomas Paine

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



DO NOT REPLY [Bug 38746] New: - [pool] indicate that ObjectPools.addObject may throw an UnsupportedOperationException

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38746.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38746

   Summary: [pool] indicate that ObjectPools.addObject may throw an
UnsupportedOperationException
   Product: Commons
   Version: 1.2 Final
  Platform: All
OS/Version: All
Status: NEW
  Keywords: PatchAvailable
  Severity: enhancement
  Priority: P4
 Component: Pool
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I missed this change with the last set of javadocs updates. This patch adds
UnsupportedOperationException to the addObject method in the ObjectPool and
KeyedObjectPool interfaces. UOE is a RuntimeException and won't break API
compatability.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



DO NOT REPLY [Bug 38746] - [pool] indicate that ObjectPools.addObject may throw an UnsupportedOperationException

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38746.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38746





--- Additional Comments From [EMAIL PROTECTED]  2006-02-22 05:14 ---
Created an attachment (id=17766)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17766action=view)
ObjectPools-addObject-javadoc.patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



Re: [logging] discovery and memory leaks

2006-02-21 Thread Simon Kitching
On Tue, 2006-02-21 at 22:15 +, robert burrell donkin wrote:
 too much caffine for me yesterday (very bad for me resulting in mental
 overdrive and then no sleep). even though i'm tired now, it the manic
 phase may have produced a positive side effect - or possibly just
 another mad idea...
 
 a lot of difficulties (including issues with hot deployment) arise from
 JCL caching classloaders. most of these issues should be addressed by
 using a weakhashtable but there are certain cases where even a weak hash
 table cannot solve the issue.
 
 the reason for indexing on classloaders is to allow configurations to be
 saved on a per classloader basis. it strikes me that identity should be
 as good as equality for this indexing. if so, then we could use
 System.identityHashCode as the index rather than the actual classloader.
 
 please feel free to spot the flaws with this plan :)

The problem is a shared LogFactory class has a map holding (TCCL,
LogFactoryImpl) pairs. This of course prevents the TCCL from being
collected without an explicit release() call to clear that map entry.

Using a weakref to the TCCL ensures that the map entry is automatically
deleted when the container drops its reference to the TCCL.

Using a stringified TCCL would no longer block the TCCL from being
collected. However it would leave the entry in the map forever, ie would
not allow the LogFactoryImpl instance (and all the Log objects held by
it) to be collected.

And it doesn't fix the corner case leak problems that exist with the
current solution either; these occur because the *value* in the map has
an indirect reference to the TCCL. That's only fixable by an explicit
release as far as I know (hence ServletContextCleaner).

Cheers,

Simon


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



svn commit: r379680 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java

2006-02-21 Thread skitching
Author: skitching
Date: Tue Feb 21 20:53:08 2006
New Revision: 379680

URL: http://svn.apache.org/viewcvs?rev=379680view=rev
Log:
Removed Serializable marker interface as it is not possible to implement this
correctly in all cases. AvalonLogger was introduced in 1.0.4, and was marked
Serializable. However serialization for this class was *completely* broken in
all cases in that release, so removing the Serializable marker is not considered
a binary-incompatible change.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java?rev=379680r1=379679r2=379680view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
 Tue Feb 21 20:53:08 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2001-2004,2006 The Apache Software Foundation.
  * 
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.
@@ -16,8 +16,6 @@
 
 package org.apache.commons.logging.impl;
 
-import java.io.Serializable;
-
 import org.apache.avalon.framework.logger.Logger;
 import org.apache.commons.logging.Log;
 
@@ -41,14 +39,19 @@
  * /li
  * /ul
  * p
- * strongNote:/strong codeAvalonLogger/code implements
- * codeSerializable/code for reasons of consistency and backwards 
compatibility. 
- * However, serializable is not recommended.
+ * strongNote:/strong codeAvalonLogger/code does not implement 
Serializable
+ * because the constructors available for it make this impossible to achieve 
in all
+ * circumstances; there is no way to reconnect to an underlying Logger 
object on
+ * deserialization if one was just passed in to the constructor of the original
+ * object. This class iwas/i marked Serializable in the 1.0.4 release of
+ * commons-logging, but this never actually worked (a NullPointerException 
would 
+ * be thrown as soon as the deserialized object was used), so removing this 
marker
+ * is not considered to be an incompatible change.
  * /p
  * @author a href=mailto:[EMAIL PROTECTED]Neeme Praks/a
  * @version $Revision$ $Date$
  */
-public class AvalonLogger implements Log, Serializable {
+public class AvalonLogger implements Log {
 
 /** Ancesteral avalon logger  */ 
 private static Logger defaultLogger = null;



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



Re: [logging] JCL1 branch

2006-02-21 Thread Simon Kitching
On Tue, 2006-02-21 at 21:46 +, robert burrell donkin wrote:
 I've cut a branch for any ongoing work needed for JCl1:
 http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/branches/JCL1/
 
 future release candidates will be cut from this branch.

I think that a JCL 2.x series would best be served by starting with a
completely fresh directory anyway; the code will be quite different.

So perhaps we could instead remove the JCL1 branch, and run JCL1.x from
trunk for the moment while JCL2.x is a separate dir? Later we could
rename trunk to JCL1 while JCL2 is renamed to trunk...

Please let me know as I have currently committed the AvalonLogger change
(intended for the 1.x series) to trunk only..

Cheers,

Simon



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