[jira] Commented: (VFS-106) VFS Truezip provider
[ https://issues.apache.org/jira/browse/VFS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482319 ] Filip Defoort commented on VFS-106: --- Hi, of course, was waiting until I heard you wanted this :-). ok oops, should have stayed in there. it works (using it), but I get your point. Either way works for me. I'll check with the truezip author if he could register it. So far there's one major problem with truezip and that's that the performance in write is dreadful because it's trying to be too smart. It's constantly rolling in and out of zip format instead of partially expanding what it needs and leaving it expanded for future usage. I'll keep you posted on what I hear from the truezip developer. Cheers, - Filip VFS Truezip provider - Key: VFS-106 URL: https://issues.apache.org/jira/browse/VFS-106 Project: Commons VFS Issue Type: New Feature Reporter: Filip Defoort Attachments: TzFileObject.java, TzFileProvider.java, TzFileSystem.java Attached is a quicky truezip provider to allow for read/write access to zip/tar/... archives. See https://truezip.dev.java.net/ for details on truezip. Let me know how you want to proceed with something like this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-129) MockHttpServletRequest doesn't compile against Servlet 2.4
[ https://issues.apache.org/jira/browse/FILEUPLOAD-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-129. Resolution: Fixed Applied MockHttpServletRequest doesn't compile against Servlet 2.4 -- Key: FILEUPLOAD-129 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-129 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Henri Yandell Assigned To: Henri Yandell Priority: Minor Fix For: 1.2.1 I think we lost this patch during the merge of the streaming code. Least I thought it had been applied. http://www.sourcelabs.com/dashboards/sash-1.2/patches/commons-fileupload-1.1-1/SUP-520.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r520302 - in /jakarta/commons/proper/fileupload/trunk: pom.xml project.xml src/changes/changes.xml src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
Author: jochen
Date: Tue Mar 20 00:29:28 2007
New Revision: 520302
URL: http://svn.apache.org/viewvc?view=revrev=520302
Log:
Made the MockHttpServletRequest comply to the servlet 2.4 specification
by applying
http://www.sourcelabs.com/dashboards/sash-1.2/patches/commons-fileupload-1.1-1/SUP-520.diff
PR: FILEUPLOAD-129
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/project.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diffrev=520302r1=520301r2=520302
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Tue Mar 20 00:29:28 2007
@@ -160,7 +160,7 @@
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
- version2.3/version
+ version2.4/version
scopeprovided/scope
/dependency
dependency
Modified: jakarta/commons/proper/fileupload/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/project.xml?view=diffrev=520302r1=520301r2=520302
==
--- jakarta/commons/proper/fileupload/trunk/project.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/project.xml Tue Mar 20 00:29:28 2007
@@ -180,7 +180,7 @@
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
- version2.3/version
+ version2.4/version
urlhttp://java.sun.com/products/servlet//url
properties
scopeprovided/scope
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diffrev=520302r1=520301r2=520302
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Tue Mar 20
00:29:28 2007
@@ -46,6 +46,11 @@
Upgrade to commons-io-1.4-SNAPSHOT, in order to use the new
FileCleaningTracker and fix issues with FileCleaner.
/action
+ action dev=jochen type=fix issue=FILEUPLOAD-129
+Made the MockHttpServletRequest comply to the servlet 2.4 specification
+by applying
+
http://www.sourcelabs.com/dashboards/sash-1.2/patches/commons-fileupload-1.1-1/SUP-520.diff
+ /action
/release
release version=1.2 date=2007-02-13
Modified:
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java?view=diffrev=520302r1=520301r2=520302
==
---
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
Tue Mar 20 00:29:28 2007
@@ -402,6 +402,14 @@
}
/**
+* @see javax.servlet.ServletRequest#getLocalName()
+*/
+ public String getLocalName()
+ {
+ return null;
+ }
+
+/**
* @see javax.servlet.ServletRequest#getServerPort()
*/
public int getServerPort()
@@ -410,6 +418,22 @@
}
/**
+* @see javax.servlet.ServletRequest#getLocalPort()
+*/
+ public int getLocalPort()
+ {
+ return 0;
+ }
+
+ /**
+* @see javax.servlet.ServletRequest#getRemotePort()
+*/
+ public int getRemotePort()
+ {
+ return 0;
+ }
+
+/**
* @see javax.servlet.ServletRequest#getReader()
*/
public BufferedReader getReader() throws IOException
@@ -426,6 +450,14 @@
}
/**
+* @see javax.servlet.ServletRequest#getLocalAddr()
+*/
+ public String getLocalAddr()
+ {
+ return null;
+ }
+
+/**
* @see javax.servlet.ServletRequest#getRemoteHost()
*/
public String getRemoteHost()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-113) NullPointerException during getting InputStream from SftpFileObject
[ https://issues.apache.org/jira/browse/VFS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482326 ] Tim Rademacher commented on VFS-113: It's been a while since I wrote this. ;-) So by now, the only exception I get while trying to reproduce this was this IOException. As far as I remember, this has the same origin as the NullPointerException. But I'll keep on trying to get you a stacktrace of the NullPointerException! Regards, Tim org.apache.commons.vfs.FileSystemException: Could not copy sftp://[EMAIL PROTECTED]/blabla.txt to sftp://[EMAIL PROTECTED]/archive/blabla.txt. at org.apache.commons.vfs.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:919) at org.apache.commons.vfs.provider.AbstractFileObject.moveTo(AbstractFileObject.java:981) at de.inka.service.file.InkaFileSystemConnection.move(InkaFileSystemConnection.java:463) ... 11 more Caused by: org.apache.commons.vfs.FileSystemException: Could not read file sftp://[EMAIL PROTECTED]/blabla.txt. at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1140) at org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:320) at org.apache.commons.vfs.FileUtil.writeContent(FileUtil.java:71) at org.apache.commons.vfs.FileUtil.copyContent(FileUtil.java:103) at org.apache.commons.vfs.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:910) ... 13 more Caused by: 4: at com.jcraft.jsch.ChannelSftp._get(ChannelSftp.java:968) at com.jcraft.jsch.ChannelSftp.get(ChannelSftp.java:861) at com.jcraft.jsch.ChannelSftp.get(ChannelSftp.java:837) at org.apache.commons.vfs.provider.sftp.SftpFileObject.doGetInputStream(SftpFileObject.java:385) at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1136) ... 17 more Caused by: java.io.IOException: inputstream is closed at com.jcraft.jsch.ChannelSftp.fill(ChannelSftp.java:2131) at com.jcraft.jsch.ChannelSftp.header(ChannelSftp.java:2155) at com.jcraft.jsch.ChannelSftp._get(ChannelSftp.java:906) ... 21 more NullPointerException during getting InputStream from SftpFileObject --- Key: VFS-113 URL: https://issues.apache.org/jira/browse/VFS-113 Project: Commons VFS Issue Type: Bug Reporter: Tim Rademacher Fix For: 1.1 Attachments: SftpFileObject.diff Hi, I experienced unregular NullPointerExceptions while getting an InputStream from an SftpFileObject. It only occures in a multithreading environment. I made a patch. By now it seems to work! Regards, Tim -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-113) NullPointerException during getting InputStream from SftpFileObject
[ https://issues.apache.org/jira/browse/VFS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482327 ] Mario Ivankovits commented on VFS-113: -- Yesterday I changed the sftp stuff to no longer read the whole file into memory but to use the stream based methods of jsch, so no it might be that this exception has goon or that it is even worse now ;-) Would be glad if you could give it a try. Thanks! Ciao, Mario NullPointerException during getting InputStream from SftpFileObject --- Key: VFS-113 URL: https://issues.apache.org/jira/browse/VFS-113 Project: Commons VFS Issue Type: Bug Reporter: Tim Rademacher Fix For: 1.1 Attachments: SftpFileObject.diff Hi, I experienced unregular NullPointerExceptions while getting an InputStream from an SftpFileObject. It only occures in a multithreading environment. I made a patch. By now it seems to work! Regards, Tim -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-246) LoopingListIterator behaves unexpected on next and previous mixed
LoopingListIterator behaves unexpected on next and previous mixed
-
Key: COLLECTIONS-246
URL: https://issues.apache.org/jira/browse/COLLECTIONS-246
Project: Commons Collections
Issue Type: Bug
Components: Iterator
Affects Versions: 3.2
Environment: JDK 1.4.2_12
Common Collections 3.2
Reporter: Frank hefter
Priority: Blocker
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 3!
// here I am on 0 too! This wrong.
assertEquals(2, it.previous());
assertEquals(1, it.previous());
assertEquals(0, it.previous());
assertEquals(2, it.previous());
// here I am on 2
assertEquals(2, it.next()); // Wrong ! This should be 0!
// here I am on 2 too! This wrong.
assertEquals(0, it.next());
assertEquals(1, it.next());
// here I am on 1
assertEquals(1, it.previous()); // Wrong ! This should be 0!
}
}
---
Thanks for your help.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-246) LoopingListIterator behaves unexpected on next and previous mixed
[
https://issues.apache.org/jira/browse/COLLECTIONS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank hefter updated COLLECTIONS-246:
-
Description:
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
// here I am on 0 too! This wrong.
assertEquals(2, it.previous());
assertEquals(1, it.previous());
assertEquals(0, it.previous());
assertEquals(2, it.previous());
// here I am on 2
assertEquals(2, it.next()); // Wrong ! This should be 0!
// here I am on 2 too! This wrong.
assertEquals(0, it.next());
assertEquals(1, it.next());
// here I am on 1
assertEquals(1, it.previous()); // Wrong ! This should be 0!
}
}
---
Thanks for your help.
was:
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 3!
// here I am on 0 too! This wrong.
assertEquals(2, it.previous());
assertEquals(1, it.previous());
assertEquals(0, it.previous());
assertEquals(2, it.previous());
// here I am on 2
assertEquals(2, it.next()); // Wrong ! This should be 0!
// here I am on 2 too! This wrong.
assertEquals(0, it.next());
assertEquals(1, it.next());
// here I am on 1
assertEquals(1, it.previous()); // Wrong ! This should be 0!
}
}
---
Thanks for your help.
LoopingListIterator behaves unexpected on next and previous mixed
-
Key: COLLECTIONS-246
URL: https://issues.apache.org/jira/browse/COLLECTIONS-246
Project: Commons Collections
Issue Type: Bug
Components: Iterator
Affects Versions: 3.2
Environment: JDK 1.4.2_12
Common Collections 3.2
Reporter: Frank hefter
Priority: Blocker
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
//
[jira] Updated: (COLLECTIONS-246) LoopingListIterator behaves unexpected on next and previous mixed
[
https://issues.apache.org/jira/browse/COLLECTIONS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank hefter updated COLLECTIONS-246:
-
Description:
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
// here I am on 0 too! This is wrong.
assertEquals(2, it.previous());
assertEquals(1, it.previous());
assertEquals(0, it.previous());
assertEquals(2, it.previous());
// here I am on 2
assertEquals(2, it.next()); // Wrong ! This should be 0!
// here I am on 2 too! This is wrong.
assertEquals(0, it.next());
assertEquals(1, it.next());
// here I am on 1
assertEquals(1, it.previous()); // Wrong ! This should be 0!
}
}
---
Thanks for your help.
was:
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
// here I am on 0 too! This wrong.
assertEquals(2, it.previous());
assertEquals(1, it.previous());
assertEquals(0, it.previous());
assertEquals(2, it.previous());
// here I am on 2
assertEquals(2, it.next()); // Wrong ! This should be 0!
// here I am on 2 too! This wrong.
assertEquals(0, it.next());
assertEquals(1, it.next());
// here I am on 1
assertEquals(1, it.previous()); // Wrong ! This should be 0!
}
}
---
Thanks for your help.
LoopingListIterator behaves unexpected on next and previous mixed
-
Key: COLLECTIONS-246
URL: https://issues.apache.org/jira/browse/COLLECTIONS-246
Project: Commons Collections
Issue Type: Bug
Components: Iterator
Affects Versions: 3.2
Environment: JDK 1.4.2_12
Common Collections 3.2
Reporter: Frank hefter
Priority: Blocker
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
[Collections] Maven help needed
I'm new to maven and apache development, and need some help... I've downloaded Maven 2.0.5, and it isn't able to run the script in the new generics branch of commons collections (http://svn.apache.org/repos/asf/jakarta/commons/proper/collections/branches/collections_jdk5_branch). * There's a project.xml instead of pom.xml * The pom version is 3 instead of 4 * I'm unsure how much of the instructions in the readme are correct Ant is the primary build tool, but I figure that maven is the dependency manager, so I can use that to retrieve the junit jars etc to be able to run the ant scripts (presumably the maven will create build.properties to point stuff to the right place). I think the best thing to do is upgrade the build process to the latest, as it is a completely new project. If this is correct, can someone reply, or raise a ticket for the changes. Thanks Stephen (K) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Collections] Maven help needed
On 3/20/07, Stephen Kestle [EMAIL PROTECTED] wrote: (http://svn.apache.org/repos/asf/jakarta/commons/proper/collections/branches/collections_jdk5_branch). * There's a project.xml instead of pom.xml * The pom version is 3 instead of 4 Looks like you need Maven 1, not 2. Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] administration interface
Oliver Zeigermann oliver.zeigermann at gmail.com writes: This code is to allow calling certain manager methods simply by accessing a certain path. It lacks a flexible configuration using a mapping from suffix to method to be called, though. Hi Oliver, to be honest this way of handling it frightens me a bit. On the one hand it adds yet another concern and much code to the FileResourceManager, on the other hand this choose an unlikely resource path as virtual admin path sounds a bit hacky. Wouldn't it be better to externalize this feature? From what I see on a quick look it should be easily possible to write a VirtualAdminCommandsFileResourceManager wrapping the actual FileResourceManager and delegating all calls to it after having filtered out the admin commands only relevant for itself. Another option I'd consider would be something like JMX - though I have never used it and don't know actually if it is appropriate. Regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[nightly build] fileupload failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070320/fileupload.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] administration interface
Right. Option one (the delegating thing) could be the option of choice for the 1.x branch. For 2.0 the JMX approach sounds like a much better idea. I will modify the code in the 1.x branch ASAP. Would you please add the JMX approach to the 2.0 Wiki page as a cool idea? Thanks for reporing and cheers Oliver 2007/3/20, Joerg Heinicke [EMAIL PROTECTED]: Oliver Zeigermann oliver.zeigermann at gmail.com writes: This code is to allow calling certain manager methods simply by accessing a certain path. It lacks a flexible configuration using a mapping from suffix to method to be called, though. Hi Oliver, to be honest this way of handling it frightens me a bit. On the one hand it adds yet another concern and much code to the FileResourceManager, on the other hand this choose an unlikely resource path as virtual admin path sounds a bit hacky. Wouldn't it be better to externalize this feature? From what I see on a quick look it should be easily possible to write a VirtualAdminCommandsFileResourceManager wrapping the actual FileResourceManager and delegating all calls to it after having filtered out the admin commands only relevant for itself. Another option I'd consider would be something like JMX - though I have never used it and don't know actually if it is appropriate. Regards Jörg - 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: [nightly build] fileupload failed.
Sorry, guys, I have been out the last couple of weeks. It looks to me like this should not be failing and must be some kind of config problem. Hen - the build works fine from my home as me on vmbuild. Where is the script now and where / as who does it run? Phil On 3/19/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 3/19/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070319/fileupload.log I am sorry, but I haven't got a clue what's wrong. I have deployed an instance of commons-io-1.4-SNAPSHOT, so everything should be fine. Any ideas? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r520389 - in /jakarta/commons/proper/transaction/trunk/src: java/org/apache/commons/transaction/file/FileResourceManager.java test/org/apache/commons/transaction/file/FileResourceManagerVi
Author: ozeigermann
Date: Tue Mar 20 06:58:03 2007
New Revision: 520389
URL: http://svn.apache.org/viewvc?view=revrev=520389
Log:
Moved changes for administration command to a sub class in order not to
overload the base implementation.
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/file/FileResourceManagerVirtualAdminCommandsTest.java
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java?view=diffrev=520389r1=520388r2=520389
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Tue Mar 20 06:58:03 2007
@@ -18,7 +18,6 @@
import java.io.BufferedReader;
import java.io.BufferedWriter;
-import java.io.ByteArrayInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
@@ -196,8 +195,6 @@
protected TransactionIdToPathMapper txIdMapper = null;
protected int idCnt = 0;
-
-protected String virtualAdminPath = null;
/*
* --- ctor and general getter / setter methods ---
@@ -205,14 +202,6 @@
*
*/
-public String getVirtualAdminPath() {
-return virtualAdminPath;
-}
-
-public void setVirtualAdminPath(String virutalAdminPath) {
-this.virtualAdminPath = virutalAdminPath;
-}
-
/**
* Creates a new resource manager operation on the specified directories.
*
@@ -728,26 +717,16 @@
}
public boolean resourceExists(Object txId, Object resourceId) throws
ResourceManagerException {
-if (isVirtualAdminId(resourceId)) {
-logger.logFine(Faking existence of virtual administration
command);
-return true;
-}
-
lockResource(resourceId, txId, true);
return (getPathForRead(txId, resourceId) != null);
}
public void deleteResource(Object txId, Object resourceId) throws
ResourceManagerException {
-
-checkForVirtualAdminCommand(resourceId);
-
deleteResource(txId, resourceId, true);
}
public void deleteResource(Object txId, Object resourceId, boolean
assureOnly) throws ResourceManagerException {
-checkForVirtualAdminCommand(resourceId);
-
if (logger.isFineEnabled()) logger.logFine(txId + deleting +
resourceId);
lockResource(resourceId, txId, false);
@@ -781,16 +760,11 @@
}
public void createResource(Object txId, Object resourceId) throws
ResourceManagerException {
-
-checkForVirtualAdminCommand(resourceId);
-
createResource(txId, resourceId, true);
}
public void createResource(Object txId, Object resourceId, boolean
assureOnly) throws ResourceManagerException {
-checkForVirtualAdminCommand(resourceId);
-
if (logger.isFineEnabled()) logger.logFine(txId + creating +
resourceId);
lockResource(resourceId, txId, false);
@@ -824,10 +798,6 @@
}
public void copyResource(Object txId, Object fromResourceId, Object
toResourceId, boolean overwrite) throws ResourceManagerException {
-
-checkForVirtualAdminCommand(fromResourceId);
-checkForVirtualAdminCommand(toResourceId);
-
if (logger.isFineEnabled()) logger.logFine(txId + copying +
fromResourceId + to + toResourceId);
lockResource(fromResourceId, txId, true);
@@ -855,10 +825,6 @@
}
public void moveResource(Object txId, Object fromResourceId, Object
toResourceId, boolean overwrite) throws ResourceManagerException {
-
-checkForVirtualAdminCommand(fromResourceId);
-checkForVirtualAdminCommand(toResourceId);
-
if (logger.isFineEnabled()) logger.logFine(txId + moving +
fromResourceId + to + toResourceId);
lockResource(fromResourceId, txId, false);
@@ -870,12 +836,6 @@
}
public InputStream readResource(Object resourceId) throws
ResourceManagerException {
-
-if (isVirtualAdminId(resourceId)) {
-logger.logWarning(Issuing virtual admin command + resourceId);
-return executeAdminCommand(resourceId);
-}
-
// create temporary light weight tx
Object txId;
synchronized (globalTransactions) {
@@ -895,12 +855,6 @@
}
public InputStream readResource(Object txId, Object resourceId) throws
ResourceManagerException {
-
-if (isVirtualAdminId(resourceId)) {
-String message = You
svn commit: r520390 - /jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/VirtualAdminCommandsFileResourceManager.java
Author: ozeigermann
Date: Tue Mar 20 06:58:37 2007
New Revision: 520390
URL: http://svn.apache.org/viewvc?view=revrev=520390
Log:
Moved changes for administration command to a sub class in order not to
overload the base implementation.
Added:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/VirtualAdminCommandsFileResourceManager.java
Added:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/VirtualAdminCommandsFileResourceManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/VirtualAdminCommandsFileResourceManager.java?view=autorev=520390
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/VirtualAdminCommandsFileResourceManager.java
(added)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/VirtualAdminCommandsFileResourceManager.java
Tue Mar 20 06:58:37 2007
@@ -0,0 +1,304 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.transaction.file;
+
+import java.io.ByteArrayInputStream;
+import java.io.InputStream;
+import java.io.OutputStream;
+
+import org.apache.commons.transaction.util.LoggerFacade;
+
+/**
+ * A resource manager for streamable objects stored in a file system that
+ * features additional administration commands.
+ *
+ * @version $Id: FileResourceManager.java 519647 2007-03-18 17:50:02Z
+ * ozeigermann $
+ */
+public class VirtualAdminCommandsFileResourceManager extends
+FileResourceManager implements ResourceManager,
+ResourceManagerErrorCodes {
+
+protected String virtualAdminPath = null;
+
+public String getVirtualAdminPath() {
+return virtualAdminPath;
+}
+
+public void setVirtualAdminPath(String virutalAdminPath) {
+this.virtualAdminPath = virutalAdminPath;
+}
+
+/**
+ * Creates a new resource manager operation on the specified directories.
+ *
+ * @param storeDir
+ *directory where main data should go after commit
+ * @param workDir
+ *directory where transactions store temporary data
+ * @param urlEncodePath
+ *if set to codetrue/code encodes all paths to allow for
+ *any kind of characters
+ * @param logger
+ *the logger to be used by this store
+ */
+public VirtualAdminCommandsFileResourceManager(String storeDir,
+String workDir, boolean urlEncodePath, LoggerFacade logger) {
+this(storeDir, workDir, urlEncodePath, logger, false);
+}
+
+/**
+ * Creates a new resource manager operation on the specified directories.
+ *
+ * @param storeDir
+ *directory where main data should go after commit
+ * @param workDir
+ *directory where transactions store temporary data
+ * @param urlEncodePath
+ *if set to codetrue/code encodes all paths to allow for
+ *any kind of characters
+ * @param logger
+ *the logger to be used by this store
+ * @param debug
+ *if set to codetrue/code logs all locking information to
+ *transaction.log for debugging inspection
+ */
+public VirtualAdminCommandsFileResourceManager(String storeDir,
+String workDir, boolean urlEncodePath, LoggerFacade logger,
+boolean debug) {
+this(storeDir, workDir, urlEncodePath ? new URLEncodeIdMapper() : null,
+new NoOpTransactionIdToPathMapper(), logger, debug);
+}
+
+/**
+ * Creates a new resource manager operation on the specified directories.
+ * This constructor is reintroduced for backwards API compatibility and is
+ * used by jakarta-slide.
+ *
+ * @param storeDir
+ *directory where main data should go after commit
+ * @param workDir
+ *directory where transactions store temporary data
+ * @param idMapper
+ *mapper for resourceId to path
+ * @param
Re: [transaction] administration interface
Done. 2007/3/20, Oliver Zeigermann [EMAIL PROTECTED]: Right. Option one (the delegating thing) could be the option of choice for the 1.x branch. For 2.0 the JMX approach sounds like a much better idea. I will modify the code in the 1.x branch ASAP. Would you please add the JMX approach to the 2.0 Wiki page as a cool idea? Thanks for reporing and cheers Oliver 2007/3/20, Joerg Heinicke [EMAIL PROTECTED]: Oliver Zeigermann oliver.zeigermann at gmail.com writes: This code is to allow calling certain manager methods simply by accessing a certain path. It lacks a flexible configuration using a mapping from suffix to method to be called, though. Hi Oliver, to be honest this way of handling it frightens me a bit. On the one hand it adds yet another concern and much code to the FileResourceManager, on the other hand this choose an unlikely resource path as virtual admin path sounds a bit hacky. Wouldn't it be better to externalize this feature? From what I see on a quick look it should be easily possible to write a VirtualAdminCommandsFileResourceManager wrapping the actual FileResourceManager and delegating all calls to it after having filtered out the admin commands only relevant for itself. Another option I'd consider would be something like JMX - though I have never used it and don't know actually if it is appropriate. Regards Jörg - 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: [nightly build] fileupload failed.
Still running as you etc. I've also been out with regards to Commons work. Been digging into other things. On 3/20/07, Phil Steitz [EMAIL PROTECTED] wrote: Sorry, guys, I have been out the last couple of weeks. It looks to me like this should not be failing and must be some kind of config problem. Hen - the build works fine from my home as me on vmbuild. Where is the script now and where / as who does it run? Phil On 3/19/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 3/19/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070319/fileupload.log I am sorry, but I haven't got a clue what's wrong. I have deployed an instance of commons-io-1.4-SNAPSHOT, so everything should be fine. Any ideas? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - 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]
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
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-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 102 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-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-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/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] 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/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.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-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-20032007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
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-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 102 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-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-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/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] 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/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.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-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-20032007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
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 102 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: 16 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/commons-cli-1.0.x/target/commons-cli-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
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 102 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: 16 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/commons-cli-1.0.x/target/commons-cli-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-20032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
svn commit: r520582 - /jakarta/commons/proper/transaction/trunk/maven.xml
Author: joerg Date: Tue Mar 20 13:56:08 2007 New Revision: 520582 URL: http://svn.apache.org/viewvc?view=revrev=520582 Log: Maven says: java:jar: [echo] java:jar is deprecated and will be removed. Please use jar:jar Modified: jakarta/commons/proper/transaction/trunk/maven.xml Modified: jakarta/commons/proper/transaction/trunk/maven.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/maven.xml?view=diffrev=520582r1=520581r2=520582 == --- jakarta/commons/proper/transaction/trunk/maven.xml (original) +++ jakarta/commons/proper/transaction/trunk/maven.xml Tue Mar 20 13:56:08 2007 @@ -14,7 +14,7 @@ See the License for the specific language governing permissions and limitations under the License. -- -project default=java:jar +project default=jar:jar xmlns:ant=jelly:ant xmlns:j=jelly:core - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r520583 - /jakarta/commons/proper/transaction/trunk/project.xml
Author: joerg
Date: Tue Mar 20 13:57:40 2007
New Revision: 520583
URL: http://svn.apache.org/viewvc?view=revrev=520583
Log:
at least Maven build works now with Geronimo spec jars from repository
Modified:
jakarta/commons/proper/transaction/trunk/project.xml
Modified: jakarta/commons/proper/transaction/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.xml?view=diffrev=520583r1=520582r2=520583
==
--- jakarta/commons/proper/transaction/trunk/project.xml (original)
+++ jakarta/commons/proper/transaction/trunk/project.xml Tue Mar 20 13:57:40
2007
@@ -25,7 +25,7 @@
shortDescriptionCommons Transaction/shortDescription
descriptionCommons Transaction/description
- currentVersion1.2-rc4/currentVersion
+ currentVersion1.3-dev/currentVersion
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
packageorg.apache.commons.${pom.artifactId.substring(8)}/package
@@ -141,28 +141,19 @@
dependencies
dependency
- groupIdgeronimo-spec/groupId
+ groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
- version1.1/version
- properties
-scopeprovided/scope
- /properties
+ version1.1.1/version
/dependency
dependency
- groupIdgeronimo-spec/groupId
+ groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jta_1.0.1B_spec/artifactId
- version1.1/version
- properties
-scopeprovided/scope
- /properties
+ version1.1.1/version
/dependency
dependency
- groupIdgeronimo-spec/groupId
+ groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-servlet_2.4_spec/artifactId
- version1.1/version
- properties
-scopeprovided/scope
- /properties
+ version1.1.1/version
/dependency
dependency
groupIdcommons-codec/groupId
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r520602 - in /jakarta/commons/proper/transaction/trunk: ./ lib/
Author: joerg
Date: Tue Mar 20 14:15:48 2007
New Revision: 520602
URL: http://svn.apache.org/viewvc?view=revrev=520602
Log:
replace the geronimo spec jars compiled by me at least with the now officially
released ones
(this is only a temporary solution as long as we don't have an Ant build
fetching the jars itself)
Added:
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.1.jar
(with props)
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.1.jar
(with props)
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.1.jar
(with props)
Removed:
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.jar
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.jar
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.pom
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.jar
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.pom
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=520602r1=520601r2=520602
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Tue Mar 20 14:15:48 2007
@@ -36,7 +36,7 @@
property name=compile.deprecation value=true /
property name=compile.optimize value=true /
- property name=version value=1.2-rc4/
+ property name=version value=1.3-dev/
property name=name value=commons-transaction /
property name=title value=Commons Transaction /
property name=package value=org.apache.commons.transaction /
@@ -74,9 +74,9 @@
property name=dist.lib value=${dist.dir}/lib/
property name=dist.deploy value=${dist.dir}/deploy/
- property name=jta.jar
value=${lib.dir}/geronimo-jta_1.0.1B_spec-1.1.jar/
- property name=jca.jar
value=${lib.dir}/geronimo-j2ee-connector_1.5_spec-1.1.jar/
- property name=servlet.jar
value=${lib.dir}/geronimo-servlet_2.4_spec-1.1.jar/
+ property name=jta.jar
value=${lib.dir}/geronimo-jta_1.0.1B_spec-1.1.1.jar/
+ property name=jca.jar
value=${lib.dir}/geronimo-j2ee-connector_1.5_spec-1.1.1.jar/
+ property name=servlet.jar
value=${lib.dir}/geronimo-servlet_2.4_spec-1.1.1.jar/
path id=classpath
pathelement location=${build.classes} /
Added:
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.1.jar
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.1.jar?view=autorev=520602
==
Binary file - no diff available.
Propchange:
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.1.jar
--
svn:mime-type = application/octet-stream
Added:
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.1.jar
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.1.jar?view=autorev=520602
==
Binary file - no diff available.
Propchange:
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.1.jar
--
svn:mime-type = application/octet-stream
Added:
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.1.jar
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.1.jar?view=autorev=520602
==
Binary file - no diff available.
Propchange:
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.1.jar
--
svn:mime-type = application/octet-stream
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Commons Transaction 1.2 Released
Oliver Zeigermann ozeigermann at apache.org writes: Jakarta Commons Transaction 1.2 has been released. Finally :) Oliver (on behalf of the Jakarta community) Thanks, Oliver. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of Brainstorm Transaction 2.0 by JoergHeinicke
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 JoergHeinicke: http://wiki.apache.org/jakarta-commons/Brainstorm_Transaction_2%2e0 -- * use a different package name (e.g. o.a.j.c.transaction2) * discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] * maybe supply a 1.x compatibility package - * only impement a core that does the transactional part + * only implement a core that does the transactional part * leave the rest to optional modules and custion implementations by calling exchangeable implementation of interfaces * use Spring for configuration * modules @@ -20, +20 @@ * What else? * have a default implementation * for all required modules - * keept it slim and rudimentary + * keep it slim and rudimentary * amounts to a transactional file store out of the box Features of the file implementation: - * allow for additional guarenteed deadlock free actions on resources + * allow for additional guaranteed deadlock free actions on resources * move and tree-move * copy and tree-copy * delete and tree-delete - * maintain an explicite tree (graph?) structure + * maintain an explicit tree (graph?) structure + * provide an administration interface based on JMX Open Questions: * Is Jakarta Commons the right place for such a project? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] administration interface
Oliver Zeigermann oliver.zeigermann at gmail.com writes: I will modify the code in the 1.x branch ASAP. That was fast :) Would you please add the JMX approach to the 2.0 Wiki page as a cool idea? Added. Regards Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r520602 - in /jakarta/commons/proper/transaction/trunk: ./ lib/
Author: joerg Date: Tue Mar 20 14:15:48 2007 New Revision: 520602 URL: http://svn.apache.org/viewvc?view=revrev=520602 Log: replace the geronimo spec jars compiled by me at least with the now officially released ones (this is only a temporary solution as long as we don't have an Ant build fetching the jars itself) Somebody offered some time ago to help with converting the Ant build fetching the jars itself or even did it on another Jakarta Commons project. Is he or she still willing to help? ;) What's the best way to do it in Ant? Regards Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] New committer - Stephen Kestle
Stephen has spent a considerable amount of effort in discussions and chivying in the commons area, particularly on commons-collections. In another life he has been heavily involved in one of the existing generics ports of collections - http://collections.sf.net. [ ] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
Does becoming a committer allow me to edit pages such as http://wiki.apache.org/jakarta-commons/Collections? My first action would be to update that so that people can figure out what we're actually doing without trawling mailing lists. Oh, and +1 :) Stephen Colebourne wrote: Stephen has spent a considerable amount of effort in discussions and chivying in the commons area, particularly on commons-collections. In another life he has been heavily involved in one of the existing generics ports of collections - http://collections.sf.net. [ ] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... Stephen - 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]
[collections] Editing the wiki
Stephen Kestle wrote: Does becoming a committer allow me to edit pages such as http://wiki.apache.org/jakarta-commons/Collections? My first action would be to update that so that people can figure out what we're actually doing without trawling mailing lists. You can do that now. Just create a user and make the change. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] findings...
Let's check with Oliver on the commons-configuration-integration. I know that was a subject that's come up a few times (last time I needed a cli type thing, I went with configuration and much preferred it; it just needs a cli like option). I had a short glance at this branch (I was not aware that it existed before). There are the two classes ConfigurationCommandLine and CommandLineConfiguration that implement the integration in both directions. They are pretty simple (probably because the APIs of cli and configuration are similar), but seem to be functional. I am not sure how to proceed here. The code of the CommandLineConfiguration class could be added to CONFIGURATION-211 (enhancement request for a command line configuration). But should configuration declare another dependency to cli? It's optional ... why not? So what is the plan? Move the code to configuration and nuke that particular cli branch? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] bug in parser(s)
Having fixed the bugs, it seemed to work fine for JMeter, so I thought it might be useful for others, and so it was provided as a patch for Commons CLI. Since JMeter has its own copy, it does not matter to us whether the CLI copy is ever released, but it seems a shame as it is working well for us. Well ...no surprises here. Avalon had some good code in there. I had a look recently at SVN with a view to making a release of just the Avalon CLI but I got bogged down. There seemed to be a lot of stuff that was not related to Avalon CLI, and I don't know Maven. Note that the Avalon API is rather different from the CLI1/CLI2 APIs. Actually it has no relation at all to the original CLI. So what about to move just that branch to dormant then as avalon-cli component? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
On 3/20/07, Stephen Colebourne [EMAIL PROTECTED] wrote: Stephen has spent a considerable amount of effort in discussions and chivying in the commons area, particularly on commons-collections. In another life he has been heavily involved in one of the existing generics ports of collections - http://collections.sf.net. [ ] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... +1. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
On 18.03.2007, at 06:51, Mario Ivankovits wrote: Hi! I had a quick look at the filesystem alteration monitor module - looks like could be useful component for people outside of JCI. I was thinking the same. But atm I would rather just get it releases. That probably means as part of JCI. Since it's a multi project there is big difference to a separate component anyway. I know of a couple of projects just using that jar. Yea, in the long term we discussed to replace the VFS's one with this implementation, though, if it is its own component with an abstract FS implementation it would be fine too. Under the hood it is already abstracted. The interface is not exposed though. Happy to have a chat about the details/problems I am seeing with it. commons-io might be a good place then. Big -1! Let's try not to bloat components like IO and LANG too much. IMO it deserves to be its own (sub) component. People are already complaining about the jar sizes of IO and LANG. (although I then point them to http://mojo.codehaus.org/minijar-maven-plugin/ index.html then :-P ) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] findings...
On 3/20/07, Torsten Curdt [EMAIL PROTECTED] wrote: Let's check with Oliver on the commons-configuration-integration. I know that was a subject that's come up a few times (last time I needed a cli type thing, I went with configuration and much preferred it; it just needs a cli like option). I had a short glance at this branch (I was not aware that it existed before). There are the two classes ConfigurationCommandLine and CommandLineConfiguration that implement the integration in both directions. They are pretty simple (probably because the APIs of cli and configuration are similar), but seem to be functional. I am not sure how to proceed here. The code of the CommandLineConfiguration class could be added to CONFIGURATION-211 (enhancement request for a command line configuration). But should configuration declare another dependency to cli? It's optional ... why not? So what is the plan? Move the code to configuration and nuke that particular cli branch? +1. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] bug in parser(s)
On 3/20/07, Torsten Curdt [EMAIL PROTECTED] wrote: Having fixed the bugs, it seemed to work fine for JMeter, so I thought it might be useful for others, and so it was provided as a patch for Commons CLI. Since JMeter has its own copy, it does not matter to us whether the CLI copy is ever released, but it seems a shame as it is working well for us. Well ...no surprises here. Avalon had some good code in there. I had a look recently at SVN with a view to making a release of just the Avalon CLI but I got bogged down. There seemed to be a lot of stuff that was not related to Avalon CLI, and I don't know Maven. Note that the Avalon API is rather different from the CLI1/CLI2 APIs. Actually it has no relation at all to the original CLI. So what about to move just that branch to dormant then as avalon-cli component? +1. Doesn't sound like Sebb/JMeter need it released. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (DAEMON-85) prunsrv.exe fails if filename is less than 4 characters long
[ https://issues.apache.org/jira/browse/DAEMON-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Goddard reopened DAEMON-85: --- It should be noted that the origional description could be confusing. To clarify; The minimum current length of 'prunsrv.exe' is 8 characters because of this ie. 'abcd.exe' is will work but 'abc.exe' will not. I dont see why it should be artificially limited when removing an incorrect check resolves the problem. Why is it irrelevant to rename 'prunsrv.exe' to be say 'abc.exe'? And why do you need to check if the user typed '.exe' on the end of the command or not? I dont understand how 'removing' 3 lines of code that doesn't need to be there and causes problems, doesn't simplify command line parsing. Please just remove the check, it is unnccessary and incorrect. thanks, Michael. prunsrv.exe fails if filename is less than 4 characters long Key: DAEMON-85 URL: https://issues.apache.org/jira/browse/DAEMON-85 Project: Commons Daemon Issue Type: Bug Affects Versions: 1.0.1 Environment: Win2k Reporter: Michael Goddard In cmdline.c, function apxCmdlineParse the following three lines check if the length if arg[0] is greater than the length of .EXE. However on windows, exe's can be executed without their .exe prefix. This means, if prunsrv.exe is renamed to 3 characters or less, the check fails and command line arguments arn't parsed returning an error. I could not figure out why the check is there, it seems to serve no purpose and if commented out the bug goes away. Code at fault: l = lstrlenW(_st_sys_argvw[0]); if (l EXE_SUFFIXLEN) return NULL; To reproduce: 1. Rename prunsrv.exe to say abc.exe 2. Execute the service executable directly as 'abc' in the current folder, do not type 'abc.exe'. (useful to use when debugging the app) 3. See it fail to parse command line arguments To solve: Remove offending lines. Perhaps check if arg[0] length is less than or equal to 0 instead of 4, which would be a valid case to fail in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.1.1 release?
On 3/9/07, Henri Yandell [EMAIL PROTECTED] wrote: Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly ready and just needs to be rolled and voted on. Rescinding this - doesn't look like it's ready in that there's gubbins to do for the build and I'm not clueful on the things needing doing. ie) it became a pain in the arse to contemplate :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
