DO NOT REPLY [Bug 38792] - [lang] Memory "leak" in StringUtils

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-07 07:52 ---
(In reply to comment #3)
I agree to this proposal, would be my preferred solution.

-- 
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: [all] Proposal: Jakarta Language Components

[Henri Yandell]

Would it be possible for this proposal and modifications based on the
following 26 emails to be sent to [EMAIL PROTECTED] for greater
discussion?

Hen

On 3/5/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> Time to stop being negative, here is what I would like to happen next.
>
>
> I hereby propose the creation of a new Jakarta entity named 'Jakarta
> Language Components'.
>
> This will be formed from the following codebases:
> [lang]
> [io]
> [collections] - expected to divide
> [primitives]
> [codec]
> [id] - on exit from sandbox
> [convert] - if ever developed
>
> I currently believe these are related, but out of scope:
> [beanutils] - logging is an issue
> [pool] - is pooling more J2EE than J2SE
> [oro]/[regexp] - specialised knowledge
> [math] - specialised, has dependencies
>
> Jakarta Language Components will:
> - develop multiple independent components
> - each component will have no dependencies
> - each component will have no configuration
> - each component provides an extension to the J2SE
> - code judged by would it be out of place in the J2SE
> - a component typically has a broad API (many callable methods)
> - each method typically does relatively little processing
> - have mailing lists (user/dev/commit)
> - not have a sandbox
> - use jakarta-general (or jakarta-dev?) for cross group issues
>
>
> For some, this may invoke an immediate negative reaction. But I'd ask
> you to pause and reflect a while. This change allows a new approach to
> commons to be tried - smaller and more focussed. The new group is large
> enough to not be inactive, yet small enough to be manageable. To succeed
> however, it will need to support of those developers who do commit to
> these components at present.
>
> 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]

svn commit: r383786 - in /jakarta/commons/proper/logging/contrib/simon/jcl2: core-dynamic/java/org/apache/commons/logging/ core/java/org/apache/commons/logging/ simple/java/org/apache/commons/logging/

[skitching]

Author: skitching
Date: Mon Mar  6 21:15:27 2006
New Revision: 383786

URL: http://svn.apache.org/viewcvs?rev=383786&view=rev
Log:
Checkstyle-related fixes.

Modified:

jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/java/org/apache/commons/logging/LogFactoryDynamic.java

jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogConfigurationException.java

jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Utils.java

jakarta/commons/proper/logging/contrib/simon/jcl2/simple/java/org/apache/commons/logging/simple/SimpleLog.java

jakarta/commons/proper/logging/contrib/simon/jcl2/simple/java/org/apache/commons/logging/simple/SimpleLogHandler.java

Modified: 
jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/java/org/apache/commons/logging/LogFactoryDynamic.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/java/org/apache/commons/logging/LogFactoryDynamic.java?rev=383786&r1=383785&r2=383786&view=diff
==
--- 
jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/java/org/apache/commons/logging/LogFactoryDynamic.java
 (original)
+++ 
jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/java/org/apache/commons/logging/LogFactoryDynamic.java
 Mon Mar  6 21:15:27 2006
@@ -69,7 +69,7 @@
 }
 
 private synchronized LogHandler getHandler() {
-ClassLoader tccl = Thread.currentThread().getContextClassLoader();
+final ClassLoader tccl = 
Thread.currentThread().getContextClassLoader();
 LogHandler handler = (LogHandler) handlers.get(tccl);
 if (handler == null) {
 handler = (LogHandler) 
Utils.createServiceInstance(LogHandler.class, tccl);

Modified: 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogConfigurationException.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogConfigurationException.java?rev=383786&r1=383785&r2=383786&view=diff
==
--- 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogConfigurationException.java
 (original)
+++ 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogConfigurationException.java
 Mon Mar  6 21:15:27 2006
@@ -27,7 +27,7 @@
 /**
  * The underlying cause of this exception.
  */
-protected Throwable cause = null;
+protected Throwable cause;
 
 /**
  * Construct a new exception with null as its detail message.

Modified: 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Utils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Utils.java?rev=383786&r1=383785&r2=383786&view=diff
==
--- 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Utils.java
 (original)
+++ 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Utils.java
 Mon Mar  6 21:15:27 2006
@@ -77,8 +77,8 @@
 public static Object createServiceInstance(Class baseClass, ClassLoader 
baseLoader) 
 throws LogConfigurationException {
 
-String serviceName = baseClass.getName();
-String serviceFileName = "META-INF/services/" + serviceName;
+final String serviceName = baseClass.getName();
+final String serviceFileName = "META-INF/services/" + serviceName;
 InputStream is;
 
 if (baseLoader == null) {
@@ -117,7 +117,7 @@
 }
 
 try {
-Class serviceClass = Class.forName(serviceClassName);
+final Class serviceClass = Class.forName(serviceClassName);
 if (!(baseClass.isAssignableFrom(serviceClass))) {
 throw new LogConfigurationException(
 "Class '" + serviceClassName + "' does not implement "
@@ -137,12 +137,13 @@
 }
 
 private static String readServiceClassName(InputStream is) throws 
IOException {
-InputStreamReader isr = new InputStreamReader(is);
-BufferedReader reader = new BufferedReader(isr);
+final InputStreamReader isr = new InputStreamReader(is);
+final BufferedReader reader = new BufferedReader(isr);
 for(;;) {
-String s = reader.readLine();
-if (s == null)
+final String s = reader.readLine();
+if (s == null) {
 return null;
+}
 s.trim();
 if (!s.startsWith("#")) {
 return s;

Modified: 
jakarta/commons/proper/logging/contrib/simon/jcl2/

svn commit: r383785 - in /jakarta/commons/proper/logging/contrib/simon/jcl2: log4j/pom.xml noop/pom.xml simple/pom.xml

[skitching]

Author: skitching
Date: Mon Mar  6 21:12:56 2006
New Revision: 383785

URL: http://svn.apache.org/viewcvs?rev=383785&view=rev
Log:
Add link to parent pom

Modified:
jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml
jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml
jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml?rev=383785&r1=383784&r2=383785&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml Mon Mar  6 
21:12:56 2006
@@ -1,6 +1,16 @@
 http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
   4.0.0
+
+  
+  
+org.apache.commons.logging
+commons-logging
+0.1-SNAPSHOT
+  
+
   org.apache.commons.logging
   commons-logging-log4j
   jar

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml?rev=383785&r1=383784&r2=383785&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml Mon Mar  6 
21:12:56 2006
@@ -1,6 +1,16 @@
 http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
   4.0.0
+
+  
+  
+org.apache.commons.logging
+commons-logging
+0.1-SNAPSHOT
+  
+
   org.apache.commons.logging
   commons-logging-noop
   jar

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml?rev=383785&r1=383784&r2=383785&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml Mon Mar  6 
21:12:56 2006
@@ -1,6 +1,16 @@
 http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
   4.0.0
+
+  
+  
+org.apache.commons.logging
+commons-logging
+0.1-SNAPSHOT
+  
+
   org.apache.commons.logging
   commons-logging-simple
   jar



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

svn commit: r383784 - in /jakarta/commons/proper/logging/contrib/simon/jcl2: checkstyle.xml pom.xml

[skitching]

Author: skitching
Date: Mon Mar  6 21:11:35 2006
New Revision: 383784

URL: http://svn.apache.org/viewcvs?rev=383784&view=rev
Log:
Enable checkstyle report for logging code.

Added:
jakarta/commons/proper/logging/contrib/simon/jcl2/checkstyle.xml
Modified:
jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml

Added: jakarta/commons/proper/logging/contrib/simon/jcl2/checkstyle.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/checkstyle.xml?rev=383784&view=auto
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/checkstyle.xml (added)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/checkstyle.xml Mon Mar  6 
21:11:35 2006
@@ -0,0 +1,62 @@
+
+
+http://www.puppycrawl.com/dtds/configuration_1_1.dtd";>
+
+
+
+  
+
+  
+  
+
+  
+
+
+
+
+
+
+
+  
+
+
+
+
+
+
+
+
+   
+
+
+   
+
+
+
+
+
+   
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
+

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml?rev=383784&r1=383783&r2=383784&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml Mon Mar  6 
21:11:35 2006
@@ -53,15 +53,13 @@
 
   
 
-
 
   
 



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

svn commit: r383772 - in /jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging: Log.java LogFactory.java

[skitching]

Author: skitching
Date: Mon Mar  6 20:18:38 2006
New Revision: 383772

URL: http://svn.apache.org/viewcvs?rev=383772&view=rev
Log:
Whitespace cleanups only

Modified:

jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Log.java

jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogFactory.java

Modified: 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Log.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Log.java?rev=383772&r1=383771&r2=383772&view=diff
==
--- 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Log.java
 (original)
+++ 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/Log.java
 Mon Mar  6 20:18:38 2006
@@ -1,18 +1,18 @@
 /*
  * Copyright 2001-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.
  * 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.logging;

Modified: 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogFactory.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogFactory.java?rev=383772&r1=383771&r2=383772&view=diff
==
--- 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogFactory.java
 (original)
+++ 
jakarta/commons/proper/logging/contrib/simon/jcl2/core/java/org/apache/commons/logging/LogFactory.java
 Mon Mar  6 20:18:38 2006
@@ -1,18 +1,18 @@
 /*
  * Copyright 2001-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.
  * 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.logging;
 



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

svn commit: r383771 - /jakarta/commons/proper/logging/contrib/simon/jcl2/build.xml

[skitching]

Author: skitching
Date: Mon Mar  6 20:17:34 2006
New Revision: 383771

URL: http://svn.apache.org/viewcvs?rev=383771&view=rev
Log:
Ant buildfile now obsolete, replaced by maven2 build.

Removed:
jakarta/commons/proper/logging/contrib/simon/jcl2/build.xml


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

svn commit: r383769 - in /jakarta/commons/proper/logging/contrib/simon/jcl2: log4j/pom.xml noop/pom.xml simple/pom.xml

[skitching]

Author: skitching
Date: Mon Mar  6 20:16:58 2006
New Revision: 383769

URL: http://svn.apache.org/viewcvs?rev=383769&view=rev
Log:
Use valid project name in pom.

Modified:
jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml
jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml
jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml?rev=383769&r1=383768&r2=383769&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/log4j/pom.xml Mon Mar  6 
20:16:58 2006
@@ -5,7 +5,7 @@
   commons-logging-log4j
   jar
   0.1-SNAPSHOT
-  Commons Logging Core
+  Commons Logging Log4J
   http://jakarta.apache.org/commons/logging
   
 

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml?rev=383769&r1=383768&r2=383769&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/noop/pom.xml Mon Mar  6 
20:16:58 2006
@@ -5,7 +5,7 @@
   commons-logging-noop
   jar
   0.1-SNAPSHOT
-  Commons Logging Core
+  Commons Logging NoOp
   http://jakarta.apache.org/commons/logging
   
 

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml?rev=383769&r1=383768&r2=383769&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/simple/pom.xml Mon Mar  6 
20:16:58 2006
@@ -5,7 +5,7 @@
   commons-logging-simple
   jar
   0.1-SNAPSHOT
-  Commons Logging Core
+  Commons Logging Simple
   http://jakarta.apache.org/commons/logging
   
 



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

svn commit: r383768 - /jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml

[skitching]

Author: skitching
Date: Mon Mar  6 20:15:47 2006
New Revision: 383768

URL: http://svn.apache.org/viewcvs?rev=383768&view=rev
Log:
Declare ibiblio repository so codehaus plugins can be used.
Other minor tweaks/cleanups.

Modified:
jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml?rev=383768&r1=383767&r2=383768&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/pom.xml Mon Mar  6 
20:15:47 2006
@@ -3,7 +3,12 @@
   org.apache.commons.logging
   0.1-SNAPSHOT
   commons-logging
+  Commons Logging
   pom
+
+  
   
 core
 core-static
@@ -12,4 +17,51 @@
 simple
 log4j
   
+
+  
+  
+
+  Ibiblio
+  http://www.ibiblio.org/pub/packages/maven2
+
+  
+  
+
+  Ibiblio
+  http://www.ibiblio.org/pub/packages/maven2
+
+  
+
+  
+
+  skitching
+  Simon Kitching
+  [EMAIL PROTECTED]
+  +12
+
+  
+
+  
+
+  Apache License 2.0
+  http://www.apache.org/licenses/LICENSE-2.0.txt
+  repo
+
+  
+
+  
+
+
+
+  
 



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

svn commit: r383766 - /jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/pom.xml

[skitching]

Author: skitching
Date: Mon Mar  6 20:14:19 2006
New Revision: 383766

URL: http://svn.apache.org/viewcvs?rev=383766&view=rev
Log:
Include core files inline in dynamic jar. Other minor pom tweaks.

Modified:
jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/pom.xml

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/pom.xml?rev=383766&r1=383765&r2=383766&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/pom.xml 
(original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/core-dynamic/pom.xml Mon 
Mar  6 20:14:19 2006
@@ -1,11 +1,21 @@
 http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
   4.0.0
+
+  
+  
+org.apache.commons.logging
+commons-logging
+0.1-SNAPSHOT
+  
+  
   org.apache.commons.logging
   commons-logging-core-dynamic
   jar
   0.1-SNAPSHOT
-  Commons Logging Core
+  Commons Logging Dynamic
   http://jakarta.apache.org/commons/logging
   
 
@@ -42,6 +52,47 @@
 
 -->
 
+
+  
+ 
+org.codehaus.mojo
+dependency-maven-plugin
+
+  
+unpack-dependencies
+process-resources
+
+  unpack
+
+  
+
+
+  
+
+  org.apache.commons.logging
+  commons-logging-core
+  0.1-SNAPSHOT
+  jar
+  
${project.build.outputDirectory}
+
+  
+
+  
+
 
   
 



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

svn commit: r383765 - /jakarta/commons/proper/logging/contrib/simon/jcl2/core-static/pom.xml

[skitching]

Author: skitching
Date: Mon Mar  6 20:12:43 2006
New Revision: 383765

URL: http://svn.apache.org/viewcvs?rev=383765&view=rev
Log:
Include core files inline in static jar. Other minor pom tweaks.

Modified:
jakarta/commons/proper/logging/contrib/simon/jcl2/core-static/pom.xml

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/core-static/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/core-static/pom.xml?rev=383765&r1=383764&r2=383765&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/core-static/pom.xml 
(original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/core-static/pom.xml Mon 
Mar  6 20:12:43 2006
@@ -1,11 +1,22 @@
 http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
+
   4.0.0
+
+  
+  
+org.apache.commons.logging
+commons-logging
+0.1-SNAPSHOT
+  
+  
   org.apache.commons.logging
   commons-logging-core-static
   jar
   0.1-SNAPSHOT
-  Commons Logging Core
+  Commons Logging Static
   http://jakarta.apache.org/commons/logging
   
 
@@ -42,6 +53,47 @@
 
 -->
 
+
+  
+ 
+org.codehaus.mojo
+dependency-maven-plugin
+
+  
+unpack-dependencies
+process-resources
+
+  unpack
+
+  
+
+
+  
+
+  org.apache.commons.logging
+  commons-logging-core
+  0.1-SNAPSHOT
+  jar
+  
${project.build.outputDirectory}
+
+  
+
+  
+
 
   
 



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

Reminder to subscribe to general@

[Henri Yandell]

We're discussing various ideas and thoughts on restructuring Jakarta
on the [EMAIL PROTECTED] mailing list. On the off chance that someone
isn't subscribed to the general@jakarta.apache.org mailing list, I
thought I'd drop an email to each of the -dev mailing lists so they
have a chance to be involved.

Hen

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

svn commit: r383747 - /jakarta/commons/proper/dbcp/trunk/project.xml

[psteitz]

Author: psteitz
Date: Mon Mar  6 18:11:52 2006
New Revision: 383747

URL: http://svn.apache.org/viewcvs?rev=383747&view=rev
Log:
Updated siteAddress.

Modified:
jakarta/commons/proper/dbcp/trunk/project.xml

Modified: jakarta/commons/proper/dbcp/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/dbcp/trunk/project.xml?rev=383747&r1=383746&r2=383747&view=diff
==
--- jakarta/commons/proper/dbcp/trunk/project.xml (original)
+++ jakarta/commons/proper/dbcp/trunk/project.xml Mon Mar  6 18:11:52 2006
@@ -45,7 +45,7 @@
   
   jakarta
   http://issues.apache.org/bugzilla/
-  jakarta.apache.org
+  cvs.apache.org
   
/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}/
   
/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}/
 
@@ -176,7 +176,7 @@
  downloaded to your Maven repository, and it's not even
  required on JDK 1.4.  Maybe we should remove it from
  this dependency list so Maven doesn't choke?
--->
+-->   
 
   javax.sql
   jdbc-stdext



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

svn commit: r383746 - /jakarta/commons/proper/dbcp/trunk/xdocs/navigation.xml

[psteitz]

Author: psteitz
Date: Mon Mar  6 18:04:03 2006
New Revision: 383746

URL: http://svn.apache.org/viewcvs?rev=383746&view=rev
Log:
Fixed broken nav link.

Modified:
jakarta/commons/proper/dbcp/trunk/xdocs/navigation.xml

Modified: jakarta/commons/proper/dbcp/trunk/xdocs/navigation.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/dbcp/trunk/xdocs/navigation.xml?rev=383746&r1=383745&r2=383746&view=diff
==
--- jakarta/commons/proper/dbcp/trunk/xdocs/navigation.xml (original)
+++ jakarta/commons/proper/dbcp/trunk/xdocs/navigation.xml Mon Mar  6 18:04:03 
2006
@@ -27,7 +27,7 @@
 
 
 
-http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/doc/"/>
+http://cvs.apache.org/viewcvs.cgi/jakarta/commons/proper/dbcp/trunk/doc/"/>
 
 http://wiki.apache.org/jakarta-commons/DBCP"/>
 



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

Re: [all] Proposal: Jakarta Language Components

[Henri Yandell]

> Henri Yandell wrote:
>  > It all comes back to my main problem - there is no Jakarta community.
>  > You're right about organic growth being the best way, let it happen.
>  > JLC will head off and enjoy its health etc. For Jakarta as a whole
>  > organic-growth of the subcommunities is not good.
>
> I'd actually like to suggest that having two or three viable and active
> communities within Jakarta which want to share stuff will help create
> the Jakarta-level community you so desire. Be patient, and don't force
> it :-)

Rearranging Jakarta into different islands than the islands of today
doesn't convince me that the project will see any change in community
overlap - in fact if it does create overlap, it'll be due to poor
decision making on our part at drawing up the components - or a need
for groupings to be more like taggings (though that'll be a pain in
the arse to deal with I think).

Hen

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

svn commit: r383735 - /jakarta/commons/proper/logging/contrib/simon/jcl2/core/pom.xml

[skitching]

Author: skitching
Date: Mon Mar  6 17:11:50 2006
New Revision: 383735

URL: http://svn.apache.org/viewcvs?rev=383735&view=rev
Log:
Define parent pom

Modified:
jakarta/commons/proper/logging/contrib/simon/jcl2/core/pom.xml

Modified: jakarta/commons/proper/logging/contrib/simon/jcl2/core/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/contrib/simon/jcl2/core/pom.xml?rev=383735&r1=383734&r2=383735&view=diff
==
--- jakarta/commons/proper/logging/contrib/simon/jcl2/core/pom.xml (original)
+++ jakarta/commons/proper/logging/contrib/simon/jcl2/core/pom.xml Mon Mar  6 
17:11:50 2006
@@ -1,6 +1,13 @@
 http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
   4.0.0
+
+  
+org.apache.commons.logging
+commons-logging
+0.1-SNAPSHOT
+  
+  
   org.apache.commons.logging
   commons-logging-core
   jar
@@ -35,8 +42,6 @@
   
 
 -->
-
-
   
 
 



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

svn commit: r383730 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/ test/org/apache/commons/io/

[sandymac]

Author: sandymac
Date: Mon Mar  6 16:49:18 2006
New Revision: 383730

URL: http://svn.apache.org/viewcvs?rev=383730&view=rev
Log:
Cleaned up LineIterator changes include:
* Removed the IOIterator interface, it can be added back later when there is 
more than one
Iterator implementations with a close method.
* Doesn't automatically close the Reader at EOF.
* made LineIterator final because the hasNext method isn't implemented in a 
subclassable way.
* constructor throws an IllegaArgumentException, not a NPE when the argument is 
bogus.

Removed:

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOIterator.java
Modified:

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/LineIteratorTestCase.java

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?rev=383730&r1=383729&r2=383730&view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java 
(original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java 
Mon Mar  6 16:49:18 2006
@@ -24,6 +24,8 @@
 import java.io.InputStream;
 import java.io.OutputStream;
 import java.io.UnsupportedEncodingException;
+import java.io.FileReader;
+import java.io.Reader;
 import java.net.URL;
 import java.util.Collection;
 import java.util.Date;
@@ -923,22 +925,9 @@
 
 /**
  * Return an Iterator for the lines in a File.
- * Please read the javadoc of [EMAIL PROTECTED] LineIterator} to understand
- * whether you should close the iterator.
- * The file is closed if an exception is thrown during this method.
- * 
- * The recommended usage patterm is:
- * 
- * LineIterator it = FileUtils.lineIterator(file, "UTF-8");
- * try {
- *   while (it.hasNext()) {
- * String line = it.nextLine();
- * /// do something with line
- *   }
- * } finally {
- *   LineIterator.closeQuietly(iterator);
- * }
- * 
+ * This neccessitates creating an InputStream for the file. The only ways
+ * to close this stream are to call [EMAIL PROTECTED] 
LineIterator#close()} or let
+ * the LineIterator be garbage collected.
  * 
  * There is no lineIterator method without encoding parameter because
  * the default encoding can differ between platforms and will have

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?rev=383730&r1=383729&r2=383730&view=diff
==
--- jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java 
(original)
+++ jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java 
Mon Mar  6 16:49:18 2006
@@ -509,21 +509,9 @@
 //---
 /**
  * Return an Iterator for the lines in a Reader.
- * Please read the javadoc of [EMAIL PROTECTED] LineIterator} to understand
- * whether you should close the iterator.
- * 
- * The recommended usage pattern is:
- * 
- * LineIterator it = IOUtils.lineIterator(reader);
- * try {
- *   while (it.hasNext()) {
- * String line = it.nextLine();
- * /// do something with line
- *   }
- * } finally {
- *   LineIterator.closeQuietly(iterator);
- * }
- * 
+ * Unless you keep a reference to the InputStream the
+ * only way to close it is to call [EMAIL PROTECTED] LineIterator#close()} 
or
+ * wait for the garbage collector.
  *
  * @param reader  the Reader to read from, not null
  * @return an Iterator of the lines in the reader, never null
@@ -537,21 +525,9 @@
 /**
  * Return an Iterator for the lines in an InputStream, using
  * the character encoding specified (or default encoding if null).
- * Please read the javadoc of [EMAIL PROTECTED] LineIterator} to understand
- * whether you should close the iterator.
- * 
- * The recommended usage pattern is:
- * 
- * LineIterator it = IOUtils.lineIterator(stream, "UTF-8");
- * try {
- *   while (it.hasNext()) {
- * String line = it.nextLine();
- * /// do something with line
- *   }
- * } finally {
- *   LineIterator.closeQuietly(iterator);
- * }
- * 
+ * Unless you keep a reference to the InputStream the
+ * only way to close it is to call [EMAIL PROTECTED

svn commit: r383719 - in /jakarta/commons/sandbox/scxml/trunk: project.xml xdocs/faq.fml xdocs/navigation.xml

[rahul]

Author: rahul
Date: Mon Mar  6 16:06:39 2006
New Revision: 383719

URL: http://svn.apache.org/viewcvs?rev=383719&view=rev
Log:
Add FAQ page.
Remove clover, jellydoc report; add faq report.

Added:
jakarta/commons/sandbox/scxml/trunk/xdocs/faq.fml   (with props)
Modified:
jakarta/commons/sandbox/scxml/trunk/project.xml
jakarta/commons/sandbox/scxml/trunk/xdocs/navigation.xml

Modified: jakarta/commons/sandbox/scxml/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/project.xml?rev=383719&r1=383718&r2=383719&view=diff
==
--- jakarta/commons/sandbox/scxml/trunk/project.xml (original)
+++ jakarta/commons/sandbox/scxml/trunk/project.xml Mon Mar  6 16:06:39 2006
@@ -234,11 +234,10 @@
  maven-changes-plugin
  maven-checkstyle-plugin
  maven-cobertura-plugin
- 
  
+ maven-faq-plugin
  
  maven-javadoc-plugin
- 
  maven-junit-report-plugin
  maven-jxr-plugin
  maven-license-plugin

Added: jakarta/commons/sandbox/scxml/trunk/xdocs/faq.fml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/xdocs/faq.fml?rev=383719&view=auto
==
--- jakarta/commons/sandbox/scxml/trunk/xdocs/faq.fml (added)
+++ jakarta/commons/sandbox/scxml/trunk/xdocs/faq.fml Mon Mar  6 16:06:39 2006
@@ -0,0 +1,142 @@
+
+
+
+
+ 
+
+  General
+
+  
+   
+What is SCXML?
+   
+   
+State Chart XML (SCXML) is a general-purpose event-based state
+machine language that can be used in many ways. It is currently
+a W3C Working Draft, available
+http://www.w3.org/TR/scxml/";>here.
+   
+  
+
+  
+   
+Do you have a simple example where Commons SCXML is used?
+   
+   
+Sure, take a look at the 
+stopwatch usecase.
+   
+  
+
+  
+   
+What are the core requirements of SCXML? Do I need to include
+the JSP and Servlet API or the Faces libraries?
+   
+   
+The "core" requirements for Commons SCXML are Commons Digester and
+Commons Logging. Commons Digester, at the minimum (if you use Commons
+Digester 1.7+), has a runtime dependency on Commons BeanUtils. 
+You do not need to include JSP or Servlet or Faces libraries. These
+are meant to come in via the servlet container (if at
+all you need them). You will need to choose an expression
+language for your SCXML documents (details in next section of this
+FAQ). See the dependencies page
+for details about the dependency versions.
+   
+  
+
+ 
+
+ 
+
+  Expression languages
+
+  
+   
+Which expression languages does the Commons SCXML implementation support?
+   
+   
+Commons SCXML currently supports
+http://jakarta.apache.org/commons/jexl/";>Commons JEXL and
+http://jakarta.apache.org/commons/el/";>Commons EL. For 
details,
+see the trying out and
+contexts and evaluators
+pages of the user guide.
+   
+  
+
+  
+   
+Can I use more than one expression language in the same SCXML document?
+   
+   
+No, the expressions throughout the document must be homogeneous. This
+also applies to any external documents that may be refered by this
+document, for example via "src" attributes.
+   
+  
+
+ 
+
+ 
+
+  The SCXMLExecutor
+
+  
+   
+Once I set up an SCXMLExecutor (call the constructor, set the
+state machine) is there anything I have to do to "activate" it?
+   
+   
+Yes, you must call the marker method, SCXMLExecutor#go().
+This serves as an indication that you have finished configuring the
+SCXMLExecutor instance and are now ready to begin executing the state
+machine described by your SCXML document. For example, you may
+attach zero, one or many SCXMLListeners to interesting "nodes" within
+the SCXML document, such as the document root i.e. the SCXML object,
+and/or particular State and Transition objects as well.
+   
+  
+
+  
+   
+Can I have multiple instances of SCXMLExecutor all working off of
+a single instance of the SCXML class?
+   
+   
+Yes. The Commons SCXML object model does not store any information
+related to a particular execution of the state machine. It is
+therefore possible to use a single SCXML instance as the state
+machine for multiple SCXMLExecutor instances. This also means that
+a SCXML document needs to be parsed only once, irrespective of the
+number of "instances" of the state machine that may execute.
+   
+  
+
+  
+   
+Can multiple threads safely interact with an instance of SCXMLExecutor?
+   
+   
+No. You have to worry about synchronizing access if you need to.
+   
+  
+
+ 
+
+

Propchange: jakarta/commons/sandbox/scxml/trunk/xdocs/faq.fml
--
svn:eol-style = native

Propchange: jakarta/commons/sandbox/scxml/trunk/xdocs/faq.fml
---

Re: [lang] lazy load of PADDING in StringUtils

[Stephen Colebourne]

I'm in favour of dropping this, or limiting it to just ASCII 32-128.

I fear it was a premature optimisation on my part way back when.

Stephen


Gary Gregory wrote:

Seems like a good idea. Since PADDING is private, the change will not
create an incompatibility.

Gary



-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 05, 2006 11:34 PM
To: Jakarta Commons Developers List
Subject: [lang] lazy load of PADDING in StringUtils

Anyone against switching the PADDING variable to lazily load in the
padding function?

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

Hen

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





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




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

Re: [io] LineIterator suggestions [was: LineIterator finalize]

[Stephen Colebourne]

Your patch got lost, but perhaps you could commit it and then I'll review.

I think I agree with most of your points, but I still want to be able to 
manually close the iterator, and to have a closeQuietly to help with 
that (closeQuietly is [io] style)


Stephen


Sandy McArthur wrote:

Attached is the changed I'd make. If no one objects to those changes I
can commit it myself.

On 3/5/06, Sandy McArthur <[EMAIL PROTECTED]> wrote:


On 3/5/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:


Sandy McArthur wrote:
>>>I don't think LineIterator should have a finalizer method and I
>>>believe the JavaDocs in that class about resource leaks are wrong and
>>>unnecessarily alarming.
How is the javadoc over the top? I'll happily make changes, or go ahead
yourself.


I checked out the IO trunk and here is what I'd change relating to the
current LineIterator:

* I think IOIterator should be removed. It's based on the premise that
an Iterator needs special action else it will leak resources. Also
there is only one implementation of this interface, which doesn't
actually leak anything. I don't believe it's utility justify it's
existence. Maybe in a later release if you find yourself adding a
number of Iterators with a close() method you can add it back in and
retro fit LineIterator to implement it.

* Don't automatically closing the Reader when the last line is read.
The LineIterator potentially breaks being used with the
java.io.PushbackReader. PushbackReader lets the Reader backup so to
speak but it cannot do that if the Reader is closed.

* Either make LineIterator final or change the way hasNext works to
allow meaningful subclassing. As hasNext() is currently implemented
there is no way for a sub-class that filters lines that only match a
regex without reimplementing hasNext() completely.

* Remove the static method closeQuietly(LineIterator). I don't think
it's useful enough to justify itself.

* Change the constructor to throw an IllegalArguementException not a
NullPointerException. I personally view an NPE as the result of trying
to dereference a field or method of null. The constructor doesn't
actually dereference reader, we are testing that the argument reader
is a legal and meaningful value to preemptively prevent a future NPE.

--
Sandy McArthur

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





--
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]


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

Re: [io] Release 1.2

[Stephen Colebourne]

Henri Yandell wrote:

Is it intentional for the source to contain the binary jar?

Yes. Guarantees a correct JDK built jar.


Noticed that the binary dists (and previous release of io) put the
javadoc in docs/*. Others seem to do it in docs/api/*. Yet more do it
in docs/apidocs/* if memory serves. No idea if we want to standardise
that.

I suspect that this is a minor point in our current debates.


Do we not keep release notes for various versions on the site? Also,
why 'upgrade notes' instead of release notes?

The upgrade notes are the release notes.


The JDiff report says the the diff is between 1_1 and CURRENT. I
presume that would become 1_1 and 1_2 when you start tagging. The
added pages on the JDiff report point to c:\ and not to http:...
Actually, unless you regen JDiff after tagging you don't get this. And 
I've never managed to get Jdiff to link docs correctly. I'll probably 
take jdiff offline.


Stephen

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

Re: [all] Proposal: Jakarta Language Components

[Stephen Colebourne]

Phil Steitz wrote:

I disagree there, and that is what actually led me to move to +1 for
Stephen's proposal, when I have consistently argued against breaking
j-c up in the past.  I think it is reasonable to attack the "problem"
(which, like some others I am not sure is as much a problem as some of
us think) of lack of organization by letting self-organizing ideas
like the one being discussed here move forward.  In other words,
instead of asking, "OK, so now how to we organize the rest of the
stuff?" we instead focus on getting JLC going and then keep an open
mind for the rest.  Maybe the remaining commons components continue
just fine for another several years.  Maybe the struts components move
over to struts and the JEE-ish things move into Geronimo or JWC really
happens and they mostly move there.  Maybe [math] finally gets a job
and leaves home.  And maybe none of this happens, or it happens slowly
and independently.  The key thing is to have it driven by people who
want to make it happen.


+1. And thanks for typing what I was about to type.

Henri Yandell wrote:
> It all comes back to my main problem - there is no Jakarta community.
> You're right about organic growth being the best way, let it happen.
> JLC will head off and enjoy its health etc. For Jakarta as a whole
> organic-growth of the subcommunities is not good.

I'd actually like to suggest that having two or three viable and active 
communities within Jakarta which want to share stuff will help create 
the Jakarta-level community you so desire. Be patient, and don't force 
it :-)


Stephen

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

svn commit: r383704 - in /jakarta/commons/sandbox/scxml/trunk/xdocs: guide.xml guide/contexts-evaluators.xml navigation.xml

[rahul]

Author: rahul
Date: Mon Mar  6 15:23:08 2006
New Revision: 383704

URL: http://svn.apache.org/viewcvs?rev=383704&view=rev
Log:
Add a section on SCXML Contexts and Evaluators (plugging in an expression 
language).

Added:
jakarta/commons/sandbox/scxml/trunk/xdocs/guide/contexts-evaluators.xml   
(with props)
Modified:
jakarta/commons/sandbox/scxml/trunk/xdocs/guide.xml
jakarta/commons/sandbox/scxml/trunk/xdocs/navigation.xml

Modified: jakarta/commons/sandbox/scxml/trunk/xdocs/guide.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/xdocs/guide.xml?rev=383704&r1=383703&r2=383704&view=diff
==
--- jakarta/commons/sandbox/scxml/trunk/xdocs/guide.xml (original)
+++ jakarta/commons/sandbox/scxml/trunk/xdocs/guide.xml Mon Mar  6 15:23:08 2006
@@ -55,6 +55,8 @@

 Digester - Digesting SCXML
 into the Commons SCXML Java object model.
+Contexts and Evaluators -
+Plugging in the expression language for the document.
 Executor - Instantiating
 an SCXML executor (engine).
 Triggering events - Executing

Added: jakarta/commons/sandbox/scxml/trunk/xdocs/guide/contexts-evaluators.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/xdocs/guide/contexts-evaluators.xml?rev=383704&view=auto
==
--- jakarta/commons/sandbox/scxml/trunk/xdocs/guide/contexts-evaluators.xml 
(added)
+++ jakarta/commons/sandbox/scxml/trunk/xdocs/guide/contexts-evaluators.xml Mon 
Mar  6 15:23:08 2006
@@ -0,0 +1,116 @@
+
+
+
+
+
+ 
+  API notes - Contexts and Evaluators
+  Commons Documentation 
Team
+ 
+
+ 
+
+  
+
+   The SCXML specification allows implementations to support
+  multiple expression languages to enable using SCXML documents
+  in varying environments. These expressions become part of
+  attribute values for executable content, such as:
+
+
+ 
+
+
+  or are used to evaluate the boolean guard conditions that
+  decide whether or not a particular transition is followed
+  once its associated trigger event is received, such as: 
+
+
+ 
+
+
+  To that end, the Context
+  and Evaluator interfaces serve as adapters to the
+  particular expression language APIs for a given usecase.
+
+   Variable resolution bubbles up from the current state up to the
+  document root, similar to variable shadowing via blocks in a
+  procedural language.
+
+   
+The Context is a collection of variables that defines
+   a variable "scope". Each  element within an SCXML
+   document gets its own Context or variable scope.
+   
+
+   
+The root context is the context that may be supplied to the
+   Commons SCXML engine as representing the variables in the
+   "host environment". See
+   SCXMLExecutor#setRootContext(Context) from the
+   Javadoc.
+   
+
+   
+The Evaluator is a component with the capability
+   of parsing and evaluating expressions. It is the "expression
+   language engine".
+   
+
+  
+
+  
+
+   Commons SCXML currently supports using Commons JEXL and
+  Commons EL (JSP 2.0 EL) as the expression language.
+  The expressions throughout the document must be homogeneous.
+  This also applies to any external documents that may be refered
+  by this document, for example via "src" attributes, like so: 
+
+
+ 
+  
+ 
+
+
+  Here, foo.xml must use the same expression language as
+  the document above that hosts the state foo.
+
+  Check out the engine API docs
+  on how to plug in the suitable root context and evaluator
+  tuple.
+
+   
+See
+
+org.apache.commons.scxml.env.jexl package summary for the
+relevant root context and evaluator tuple to use.
+   
+
+   
+See
+
+org.apache.commons.scxml.env.jsp package summary for the
+relevant root context and evaluator tuple to use.
+   
+
+  
+
+ 
+
+

Propchange: 
jakarta/commons/sandbox/scxml/trunk/xdocs/guide/contexts-evaluators.xml
--
svn:eol-style = native

Propchange: 
jakarta/commons/sandbox/scxml/trunk/xdocs/guide/contexts-evaluators.xml
--
svn:keywords = Date Author Id Revision HeadURL

Modified: jakarta/commons/sandbox/scxml/trunk/xdocs/navigation.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/xdocs/navigation.xml?rev=383704&r1=383703&r2=383704&view=diff
==
--- jakarta/commons/sandb

Re: svn commit: r383688 - in /jakarta/commons/proper/pool/trunk/src: java/org/apache/commons/pool/ test/org/apache/commons/pool/

[Rahul Akolkar]

On 3/6/06, Sandy McArthur <[EMAIL PROTECTED]> wrote:
> On 3/6/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> > On 3/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Author: sandymac
> > > Date: Mon Mar  6 14:06:16 2006
> > > New Revision: 383688
> > >
> > > URL: http://svn.apache.org/viewcvs?rev=383688&view=rev
> > > Log:
> > > Updated BaseObjectPools and unit tests to conform to the Pool 2.0 
> > > contract changes.
> > > * getNumIdle/getNumActive now return a negative value when unsupported.
> > > * calling close() more than once no longer throws an exception.
> > >
> > 
> >
> > Get the feeling this needs to be in its own branch towards a 2.0.
>
> I thought the trunk was for Pool 2.0 and there was a branch for Pool 1.3
>
> http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/pool/branches/1_3_RELEASE_BRANCH/
> http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/pool/trunk/
>


Makes perfect sense then, I should've checked what branches exist.

-Rahul


> --
> 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]

Re: svn commit: r383688 - in /jakarta/commons/proper/pool/trunk/src: java/org/apache/commons/pool/ test/org/apache/commons/pool/

[Sandy McArthur]

On 3/6/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 3/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: sandymac
> > Date: Mon Mar  6 14:06:16 2006
> > New Revision: 383688
> >
> > URL: http://svn.apache.org/viewcvs?rev=383688&view=rev
> > Log:
> > Updated BaseObjectPools and unit tests to conform to the Pool 2.0 contract 
> > changes.
> > * getNumIdle/getNumActive now return a negative value when unsupported.
> > * calling close() more than once no longer throws an exception.
> >
> 
>
> Get the feeling this needs to be in its own branch towards a 2.0.

I thought the trunk was for Pool 2.0 and there was a branch for Pool 1.3

http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/pool/branches/1_3_RELEASE_BRANCH/
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/pool/trunk/

--
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 38870] - [dbcp] Examples links on website are broken; CVS->SVN ...

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-06 22:26 ---
Thanks for the report. I have fixed this in SVN. It will be reflected on the
site the next time it is published.

-- 
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]

svn commit: r383694 - /jakarta/commons/proper/dbcp/trunk/xdocs/index.xml

[dennisl]

Author: dennisl
Date: Mon Mar  6 14:23:24 2006
New Revision: 383694

URL: http://svn.apache.org/viewcvs?rev=383694&view=rev
Log:
PR #38870
Fix the broken link to examples.

Modified:
jakarta/commons/proper/dbcp/trunk/xdocs/index.xml

Modified: jakarta/commons/proper/dbcp/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/dbcp/trunk/xdocs/index.xml?rev=383694&r1=383693&r2=383694&view=diff
==
--- jakarta/commons/proper/dbcp/trunk/xdocs/index.xml (original)
+++ jakarta/commons/proper/dbcp/trunk/xdocs/index.xml Mon Mar  6 14:23:24 2006
@@ -49,7 +49,7 @@
 
 Applications can use the commons-dbcp component directly
 or through the existing interface of their container / supporting framework.
-For example the http://jakarta.apache.org/tomcat/";>Tomcat 
+For example the http://tomcat.apache.org/";>Tomcat 
 servlet container presents a DBCP DataSource as a JNDI Datasource.
 http://james.apache.org/";>James (Java Apache Mail Enterprise 
Server) 
 has integrated DBCP into the http://avalon.apache.org/";>Avalon 
framework.
@@ -78,7 +78,7 @@
 package for an overview of how to use DBCP.
 
 There are 
-http://cvs.apache.org/viewcvs.cgi/jakarta-commons/dbcp/doc/";>several 
examples 
+http://cvs.apache.org/viewcvs.cgi/jakarta/commons/proper/dbcp/trunk/doc/";>several
 examples 
 of using DBCP available.
 
 



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

Re: svn commit: r383688 - in /jakarta/commons/proper/pool/trunk/src: java/org/apache/commons/pool/ test/org/apache/commons/pool/

[Rahul Akolkar]

On 3/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: sandymac
> Date: Mon Mar  6 14:06:16 2006
> New Revision: 383688
>
> URL: http://svn.apache.org/viewcvs?rev=383688&view=rev
> Log:
> Updated BaseObjectPools and unit tests to conform to the Pool 2.0 contract 
> changes.
> * getNumIdle/getNumActive now return a negative value when unsupported.
> * calling close() more than once no longer throws an exception.
>


Get the feeling this needs to be in its own branch towards a 2.0.

-Rahul

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

svn commit: r383688 - in /jakarta/commons/proper/pool/trunk/src: java/org/apache/commons/pool/ test/org/apache/commons/pool/

[sandymac]

Author: sandymac
Date: Mon Mar  6 14:06:16 2006
New Revision: 383688

URL: http://svn.apache.org/viewcvs?rev=383688&view=rev
Log:
Updated BaseObjectPools and unit tests to conform to the Pool 2.0 contract 
changes.
* getNumIdle/getNumActive now return a negative value when unsupported.
* calling close() more than once no longer throws an exception.

Modified:

jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/BaseKeyedObjectPool.java

jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/BaseObjectPool.java

jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestBaseKeyedObjectPool.java

jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestBaseObjectPool.java

jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestObjectPool.java

Modified: 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/BaseKeyedObjectPool.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/BaseKeyedObjectPool.java?rev=383688&r1=383687&r2=383688&view=diff
==
--- 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/BaseKeyedObjectPool.java
 (original)
+++ 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/BaseKeyedObjectPool.java
 Mon Mar  6 14:06:16 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 1999-2004 The Apache Software Foundation.
+ * Copyright 1999-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.
@@ -17,11 +17,12 @@
 package org.apache.commons.pool;
 
 /**
- * A simple base impementation of [EMAIL PROTECTED] ObjectPool}.
- * All optional operations are implemented as throwing
- * [EMAIL PROTECTED] UnsupportedOperationException}.
+ * A simple base implementation of [EMAIL PROTECTED] ObjectPool}.
+ * Optional operations are implemented to either do nothing, return a value
+ * indicating it is unsupported or throw [EMAIL PROTECTED] 
UnsupportedOperationException}.
  *
  * @author Rodney Waldhoff
+ * @author Sandy McArthur
  * @version $Revision$ $Date$
  */
 public abstract class BaseKeyedObjectPool implements KeyedObjectPool {
@@ -31,6 +32,8 @@
 
 /**
  * Not supported in this base implementation.
+ * Always throws an [EMAIL PROTECTED] UnsupportedOperationException},
+ * subclasses should override this behavior.
  */
 public void addObject(Object key) throws Exception, 
UnsupportedOperationException {
 throw new UnsupportedOperationException();
@@ -38,30 +41,34 @@
 
 /**
  * Not supported in this base implementation.
+ * @return a negative value.
  */
 public int getNumIdle(Object key) throws UnsupportedOperationException {
-throw new UnsupportedOperationException();
+return -1;
 }
 
 /**
  * Not supported in this base implementation.
+ * @return a negative value.
  */
 public int getNumActive(Object key) throws UnsupportedOperationException {
-throw new UnsupportedOperationException();
+return -1;
 }
 
 /**
  * Not supported in this base implementation.
+ * @return a negative value.
  */
 public int getNumIdle() throws UnsupportedOperationException {
-throw new UnsupportedOperationException();
+return -1;
 }
 
 /**
  * Not supported in this base implementation.
+ * @return a negative value.
  */
 public int getNumActive() throws UnsupportedOperationException {
-throw new UnsupportedOperationException();
+return -1;
 }
 
 /**
@@ -74,8 +81,7 @@
 /**
  * Not supported in this base implementation.
  */
-public void clear(Object key)
-throws Exception, UnsupportedOperationException {
+public void clear(Object key) throws Exception, 
UnsupportedOperationException {
 throw new UnsupportedOperationException();
 }
 
@@ -88,9 +94,10 @@
 
 /**
  * Not supported in this base implementation.
+ * Always throws an [EMAIL PROTECTED] UnsupportedOperationException},
+ * subclasses should override this behavior.
  */
-public void setFactory(KeyedPoolableObjectFactory factory)
-throws IllegalStateException, UnsupportedOperationException {
+public void setFactory(KeyedPoolableObjectFactory factory) throws 
IllegalStateException, UnsupportedOperationException {
 throw new UnsupportedOperationException();
 }
 

Modified: 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/BaseObjectPool.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/BaseObjectPool.java?rev=383688&r1=383687&r2=383688&view=diff
==
--- 
jakarta/commons/proper/pool/trunk/sr

Re: Drinking beer in Vienna/Austria

[Martin Marinschek]

Yes, of course, one beer maximum!

(at a time, per person ;)

regards,

Martin

On 3/6/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'll invite everyone who has some time to a meeting in vienna/austria.
>
> Location: Ma Pitom
> Date: 28.3.2006
> Time: 18:30
>
> We have no free stickers, no t-shirts or any other gift, just a meeting
> to drink a beer - or two - maximum.
> You meet me (if this is of any interest) and some guys from the myfaces
> (which might me more interesting ;-) ) team.
>
> Please send a PM if you plan to come, just to have an oversight of the
> number of people to await.
>
> See you!
> Ciao,
> Mario
>
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

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

svn commit: r383680 - in /jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool: TestAll.java TestPoolUtils.java

[sandymac]

Author: sandymac
Date: Mon Mar  6 13:32:02 2006
New Revision: 383680

URL: http://svn.apache.org/viewcvs?rev=383680&view=rev
Log:
Added TestPoolUtils to the TestAll TestSuit

Modified:

jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestAll.java

jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java

Modified: 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestAll.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestAll.java?rev=383680&r1=383679&r2=383680&view=diff
==
--- 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestAll.java 
(original)
+++ 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestAll.java 
Mon Mar  6 13:32:02 2006
@@ -35,6 +35,7 @@
 suite.addTest(org.apache.commons.pool.TestBaseKeyedObjectPool.suite());
 
suite.addTest(org.apache.commons.pool.TestBasePoolableObjectFactory.suite());
 
suite.addTest(org.apache.commons.pool.TestBaseKeyedPoolableObjectFactory.suite());
+suite.addTest(org.apache.commons.pool.TestPoolUtils.suite());
 suite.addTest(org.apache.commons.pool.impl.TestAll.suite());
 return suite;
 }

Modified: 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java?rev=383680&r1=383679&r2=383680&view=diff
==
--- 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java
 (original)
+++ 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java
 Mon Mar  6 13:32:02 2006
@@ -18,6 +18,8 @@
 
 import junit.framework.TestCase;
 import junit.framework.AssertionFailedError;
+import junit.framework.Test;
+import junit.framework.TestSuite;
 
 import java.lang.reflect.Proxy;
 import java.lang.reflect.InvocationHandler;
@@ -48,6 +50,10 @@
 
 /** Sleep time to let the minIdle tests run CHECK_COUNT times. */
 private static final int CHECK_SLEEP_PERIOD = CHECK_PERIOD * (CHECK_COUNT 
- 1) + CHECK_PERIOD / 2;
+
+public static Test suite() {
+return new TestSuite(TestPoolUtils.class);
+}
 
 public void testJavaBeanInstantiation() {
 new PoolUtils();



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

[RESULT] [VOTE] Accept donation of composite pool code

[robert burrell donkin]

(only votes from jakarta pmc'ers are binding in this case)

i count as follows:

binding +1's
robert burrell donkin
Dion Gillard
Noel J. Bergman

non-binding +1's
Sandy McArthur
Brian K. Wallace
  
if i've missed any votes please post a correction

a bare quorum (3 binding +1's) in favour of acceptance. i'll prepare and
submit the necessary paperwork to the incubator to progress this
donation.

- robert

 




signature.asc
Description: This is a digitally signed message part

Re: [all] Proposal: Jakarta Language Components

[Rahul Akolkar]

On 3/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote:

>  The key thing is to have it driven by people who
> want to make it happen.
>
> So who is going to make JWC happen :-)
>


Given that:

 * I have the drive for working on the RDC taglib, and
 * Taglibs committed itself to JWC last year

unless the second part changes, transitivity seems to suggest there is
atleast me. The rest of the JWC future shall be organic, we'll have an
open mind, and so on ...

(other details may come up on general@, please follow that thread if
you're interested)

-Rahul


> Phil
>

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

Drinking beer in Vienna/Austria

[Mario Ivankovits]

Hi!

I'll invite everyone who has some time to a meeting in vienna/austria.

Location: Ma Pitom
Date: 28.3.2006
Time: 18:30

We have no free stickers, no t-shirts or any other gift, just a meeting
to drink a beer - or two - maximum.
You meet me (if this is of any interest) and some guys from the myfaces
(which might me more interesting ;-) ) team.

Please send a PM if you plan to come, just to have an oversight of the
number of people to await.

See you!
Ciao,
Mario


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

Re: [all] Proposal: Jakarta Language Components

[Henri Yandell]

On 3/6/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On 3/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
> >
> > On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> >
> > 
> >
> > > It might make things simpler to draw up an entire future re-org of
> > > Jakarta. See who gets dropped through the cracks and decide if we have
> > > to kill, accept or leave them to stand alone. There are some obvious
> > > ones for JWC, and some that just don't seem to fit and would have to
> > > stand alone.
> >
> > I disagree there, and that is what actually led me to move to +1 for
> > Stephen's proposal, when I have consistently argued against breaking
> > j-c up in the past.  I think it is reasonable to attack the "problem"
> > (which, like some others I am not sure is as much a problem as some of
> > us think) of lack of organization by letting self-organizing ideas
> > like the one being discussed here move forward.  In other words,
> > instead of asking, "OK, so now how to we organize the rest of the
> > stuff?" we instead focus on getting JLC going and then keep an open
> > mind for the rest.  Maybe the remaining commons components continue
> > just fine for another several years.  Maybe the struts components move
> > over to struts and the JEE-ish things move into Geronimo or JWC really
> > happens and they mostly move there.  Maybe [math] finally gets a job
> > and leaves home.  And maybe none of this happens, or it happens slowly
> > and independently.  The key thing is to have it driven by people who
> > want to make it happen.
>
>
> Nicely said. Exactly. Organic growth.

It all comes back to my main problem - there is no Jakarta community.
You're right about organic growth being the best way, let it happen.
JLC will head off and enjoy its health etc. For Jakarta as a whole
organic-growth of the subcommunities is not good.

Maybe the answer is that we just accept Jakarta as a collection of
communities and find out what the ASF want to do about that.

Hen

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

Re: commons-vfs release

[Henri Yandell]

On 3/6/06, C. Grobmeier <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > What would be the work involved in getting compress released? Any idea?
>
> - - fixing the 3 (or 4) Bugs
> - - preparing an commonly used interface
> - - having functions for deleting files from a compressed file (optional,
> i think)
> - - clean up of the old code
> - - possibly merging with codehaus-code (from Brett Porter)
> - - preparing functions to work with Output/Inputstreams (necessary for VFS)
>
> I have something done and put a draft-compress online (see thread
> "[compress] Discussing compress")
>
> Nothing special, but needs a bit of time. This would be a core release,
> with just the most simple features.

You've got my time if you need it. Push on with getting each one of
these moving, and whenever you hit a karma issue, just hit me and I'll
deal with patches etc.

I'll try to find time to dig into the issues themselves, but far more
realistic to have those interested driving things (yourself, vfs,
others?).

Hen

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

DO NOT REPLY [Bug 38792] - [lang] Memory "leak" in StringUtils

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-06 20:13 ---
One more thing, if it is desirable to keep the number of equal string instances
low then the return could be changed to:

  return sb.toString().intern();

But if Java 1.1 is a target for lang then that shouldn't be used as it will leak
memory. It wasn't until Java 1.2 that the intered string pool would allow unused
intered strings to be garbage collected.

-- 
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 38792] - [lang] Memory "leak" in StringUtils

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-06 20:05 ---
Has it been shown that the PADDING caching actually benefits anything? I think
it should be removed as it's just going to consume more and more memory until
the StringUtils class is unloaded.

Either way the StringUtils.padding(int,char) should be changed to use a
StringBuffer. I'd change the method to:

private static String padding(int repeat, char padChar) {
  StringBuffer sb = new StringBuffer(repeat); 
  while (sb.length() < repeat) {
pad = pad.concat(pad);
  }
  return sb.toString();
}

and remove the PADDING static field.

-- 
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 38870] - [dbcp] Examples links on website are broken; CVS->SVN ...

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Examples links on website   |[dbcp] Examples links on
   |are broken; CVS->SVN ...|website are broken; CVS->SVN
   ||...




-- 
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 38870] New: - Examples links on website are broken; CVS->SVN ...

[bugzilla]

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

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

   Summary: Examples links on website are broken; CVS->SVN ...
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Dbcp
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The links to the examples on the DBCP pages don't work now that the code is in 
SVN

-- 
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: [lang] lazy load of PADDING in StringUtils

[Gary Gregory]

Seems like a good idea. Since PADDING is private, the change will not
create an incompatibility.

Gary

> -Original Message-
> From: Henri Yandell [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 05, 2006 11:34 PM
> To: Jakarta Commons Developers List
> Subject: [lang] lazy load of PADDING in StringUtils
> 
> Anyone against switching the PADDING variable to lazily load in the
> padding function?
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=38792
> 
> Hen
> 
> -
> 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]

DO NOT REPLY [Bug 38792] - [lang] Memory "leak" in StringUtils

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-06 19:18 ---
Seems like a good idea. Since PADDING is private, the change will not create an
incompatibility.

-- 
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 38688] - [net] TelnetInputStream.read sometimes hangs if reader thread is disabled

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-06 19:12 ---
Does anyone have knowledge of this code?

I am willing to put time into a patch, but the documentation for the class is 
VERY sparse. I'm afraid I'll just end up breaking it more.

-- 
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: [all] Proposal: Jakarta Language Components

[Martin Cooper]

On 3/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
>
> On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> 
>
> > It might make things simpler to draw up an entire future re-org of
> > Jakarta. See who gets dropped through the cracks and decide if we have
> > to kill, accept or leave them to stand alone. There are some obvious
> > ones for JWC, and some that just don't seem to fit and would have to
> > stand alone.
>
> I disagree there, and that is what actually led me to move to +1 for
> Stephen's proposal, when I have consistently argued against breaking
> j-c up in the past.  I think it is reasonable to attack the "problem"
> (which, like some others I am not sure is as much a problem as some of
> us think) of lack of organization by letting self-organizing ideas
> like the one being discussed here move forward.  In other words,
> instead of asking, "OK, so now how to we organize the rest of the
> stuff?" we instead focus on getting JLC going and then keep an open
> mind for the rest.  Maybe the remaining commons components continue
> just fine for another several years.  Maybe the struts components move
> over to struts and the JEE-ish things move into Geronimo or JWC really
> happens and they mostly move there.  Maybe [math] finally gets a job
> and leaves home.  And maybe none of this happens, or it happens slowly
> and independently.  The key thing is to have it driven by people who
> want to make it happen.


Nicely said. Exactly. Organic growth.

--
Martin Cooper


So who is going to make JWC happen :-)
>
> Phil
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [all] Proposal: Jakarta Language Components

[Phil Steitz]

On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote:



> It might make things simpler to draw up an entire future re-org of
> Jakarta. See who gets dropped through the cracks and decide if we have
> to kill, accept or leave them to stand alone. There are some obvious
> ones for JWC, and some that just don't seem to fit and would have to
> stand alone.

I disagree there, and that is what actually led me to move to +1 for
Stephen's proposal, when I have consistently argued against breaking
j-c up in the past.  I think it is reasonable to attack the "problem"
(which, like some others I am not sure is as much a problem as some of
us think) of lack of organization by letting self-organizing ideas
like the one being discussed here move forward.  In other words,
instead of asking, "OK, so now how to we organize the rest of the
stuff?" we instead focus on getting JLC going and then keep an open
mind for the rest.  Maybe the remaining commons components continue
just fine for another several years.  Maybe the struts components move
over to struts and the JEE-ish things move into Geronimo or JWC really
happens and they mostly move there.  Maybe [math] finally gets a job
and leaves home.  And maybe none of this happens, or it happens slowly
and independently.  The key thing is to have it driven by people who
want to make it happen.

So who is going to make JWC happen :-)

Phil

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

Re: commons-vfs release

[C. Grobmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> What would be the work involved in getting compress released? Any idea?

- - fixing the 3 (or 4) Bugs
- - preparing an commonly used interface
- - having functions for deleting files from a compressed file (optional,
i think)
- - clean up of the old code
- - possibly merging with codehaus-code (from Brett Porter)
- - preparing functions to work with Output/Inputstreams (necessary for VFS)

I have something done and put a draft-compress online (see thread
"[compress] Discussing compress")

Nothing special, but needs a bit of time. This would be a core release,
with just the most simple features.

- - Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEDH3Okv8rKBUE/T4RApbFAJ9AND6e4WRu7hB1x3cd+k7OL7HrdQCgjEeX
eOQOG04okgQyRwuSabmSlo8=
=u7xW
-END PGP SIGNATURE-

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

Re: commons-vfs release

[Henri Yandell]

On 3/6/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 3/6/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> > Hi!
> > >>> I'd rather vfs depend on slide then to copy the classes over.
> > >>>
> > >>>
> > >> Yes, this is as it is now, but if slide didnt manage to release we will
> > >> never see a vfs release :-(
> > >>
> > > Is there something that stops a VFS 1.0 with the rest of
> > > the providers (without these three)? Sure, it makes the 1.0 less than
> > > what we'd like it to be, but still probably better than waiting for
> > > slide (or some other foo release).
> > >
> > I can leave slide out, no problem, but compress is hard as the we loose
> > bzip2 and tar support.
> >
> 
>
> I understand. If we must have those, then VFS needs to adopt the five
> classes it needs:
>
> CBZip2{Input,Output}Stream, BZip2Constants, Tar{Entry,InputStream}
>
> Leave them package scoped, switch to compress when its released? I
> realize you'd rather not maintain those classes, but seems like this
> is the option that holds the most promise ATM.

What would be the work involved in getting compress released? Any idea?

Hen

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

Re: [compress] Discussing compress

[C. Grobmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> 1) Please take care to always close your input/output streams. ie. do
> this in a finally() block so that in any case (excpetion) the streams
> were closed

OK, i will check this tonight or tomorrow evening :-)

> 2) you cant handle directories now, maybe something you have on your
> todo list?

Yes, it's on my TODO, this package should only introduce the direction.

> 2) The archiver uses java.io.File in its public interface.
> PLEASE provide Streams too. Internally you can create temp-files or
> whatever you would like to.
> So you might have something like 
> OutputStream os = Archiver.createEntry(String pathname);
> 
> Why?
> From the view of VFS its simply easier to handle ;-) It would be great
> if you could handle this in your abstract archiver.

I think this should be no problem. I have it on my TODO by now.
Regards,
Chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEDGi4kv8rKBUE/T4RAuuOAJ9xrVSwtnBbVcpPD6OXNk08D+h5RQCfeKTJ
9gsb05rxKIUydG4SW7dwo1w=
=Yebv
-END PGP SIGNATURE-

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

Re: [all] Proposal: Jakarta Language Components

[Rahul Akolkar]

On 3/6/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:

> --- Henri Yandell wrote:
> > To effect this, I think that the sandbox should be at
> > the Jakarta level and not at the Commons level.
>
> +1. But I think you may need a jakarta-dev list.
>


Yes, and this should also help in:

 * Getting support from other Jakarta committers rather than expecting
them to be involved in Commons to contribute (and vote).

 * Making it easier for narrow-deep API'ed components to be "accepted".

-Rahul


> Stephen
>

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

Re: [all] Proposal: Jakarta Language Components

[Rahul Akolkar]

On 3/5/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:

>
> I hereby propose the creation of a new Jakarta entity named 'Jakarta
> Language Components'.
>

>
>
> For some, this may invoke an immediate negative reaction. But I'd ask
> you to pause and reflect a while. This change allows a new approach to
> commons to be tried - smaller and more focussed. The new group is large
> enough to not be inactive, yet small enough to be manageable. To succeed
> however, it will need to support of those developers who do commit to
> these components at present.
>


Makes sense, we've been talking about narrow-deep/shallow-broad for
quite a while (credit to you) and this is a similar take on the
situation. But I think this grouping is the easy part.

To the effect of what Hen says later in this thread, its the
narrow-deep bits that have been the "ugly ducklings", whereas it has
been proven sufficient number of times that both "categories" are
extremely useful (for example, think of the number of ASF projects
that use digester). Just as its said that Jakarta is multiple
communities based on what it has grown into organically, we must also
agree Commons has grown into a community that harbors both flavors of
components.

If this proposal means a departure from the "rest of Commons" of the
part of the community that is interesting only in JLC, then this is a
loss. While you (Stephen) may be inclined towards the shallow-broad
variety, the fact that the latest usecase for scxml comes out of your
slides is still invaluable, IMO. We have to address the future of
*all* of Commons in such proposals, I tend to feel they're a tad
incomplete otherwise.

-Rahul


> Stephen
>

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

Re: commons-vfs release

[Rahul Akolkar]

On 3/6/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
> >>> I'd rather vfs depend on slide then to copy the classes over.
> >>>
> >>>
> >> Yes, this is as it is now, but if slide didnt manage to release we will
> >> never see a vfs release :-(
> >>
> > Is there something that stops a VFS 1.0 with the rest of
> > the providers (without these three)? Sure, it makes the 1.0 less than
> > what we'd like it to be, but still probably better than waiting for
> > slide (or some other foo release).
> >
> I can leave slide out, no problem, but compress is hard as the we loose
> bzip2 and tar support.
>


I understand. If we must have those, then VFS needs to adopt the five
classes it needs:

CBZip2{Input,Output}Stream, BZip2Constants, Tar{Entry,InputStream}

Leave them package scoped, switch to compress when its released? I
realize you'd rather not maintain those classes, but seems like this
is the option that holds the most promise ATM.

-Rahul



>
> Ciao,
> Mario
>

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

Re: [compress] Discussing compress

[Mario Ivankovits]

Hi!

>
> I have done something and uploaded a draft:
> http://grobmeier.de/commons-compress-draft.zip
I've looked at it a little bit.

1) Please take care to always close your input/output streams. ie. do
this in a finally() block so that in any case (excpetion) the streams
were closed
2) you cant handle directories now, maybe something you have on your
todo list?
2) The archiver uses java.io.File in its public interface.
PLEASE provide Streams too. Internally you can create temp-files or
whatever you would like to.
So you might have something like

OutputStream os = Archiver.createEntry(String pathname);

Why?
>From the view of VFS its simply easier to handle ;-) It would be great
if you could handle this in your abstract archiver.

Ciao,
Mario


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

Re: commons-vfs release

[Mario Ivankovits]

Hi!
>>> I'd rather vfs depend on slide then to copy the classes over.
>>>
>>>   
>> Yes, this is as it is now, but if slide didnt manage to release we will
>> never see a vfs release :-(
>> 
> Is there something that stops a VFS 1.0 with the rest of
> the providers (without these three)? Sure, it makes the 1.0 less than
> what we'd like it to be, but still probably better than waiting for
> slide (or some other foo release).
>   
I can leave slide out, no problem, but compress is hard as the we loose
bzip2 and tar support.


Ciao,
Mario


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

Re: commons-vfs release

[Rahul Akolkar]

On 3/5/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:

> Now what happend? I was frustrated, and this feeling is still alive. Not
> only due to the fact that this is not allowed, but also while it took so
> long time to appear.
>


I understand some frustration that it look so many RCs to surface, but
you shouldn't have any about it being "not allowed" -- I'd say the
first thing to check when adding dependencies is things such as
license compatibility, released status etc. But thats water under the
bridge, maybe we can begin afresh thinking about a VFS 1.0. So, moving
on to another email in this thread ...


On 3/5/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
> > I'd rather vfs depend on slide then to copy the classes over.
> >
> Yes, this is as it is now, but if slide didnt manage to release we will
> never see a vfs release :-(
>


There are other options too.

Slide affects the webdav provider, compress affects the tar and bzip2
providers. Is there something that stops a VFS 1.0 with the rest of
the providers (without these three)? Sure, it makes the 1.0 less than
what we'd like it to be, but still probably better than waiting for
slide (or some other foo release).

-Rahul



> ---
> Mario
>

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

Re: [compress] Discussing compress

[C. Grobmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi,

> I actually think commons-archiver is a better name (the library I have
> used is plexus-archiver [1], which is derived from the same code and I
> want to merge them here). 
> Note that there is also the unpack/decompress portion as well.

+1 to the archiver thing. In my draft, i renamed all what is "Compress"
to "Archiver".


> I think this is the right way to start. I think investigating more
> performant methods for large archives might be a good idea later too,
> though.
>

Yes, i agree with you and mario.

>> Having this in mind, i will try to write some simple files as a basis at
>> the weekend.
> 
> I don't recall seeing anything come in. Is this still happening? If not,
> can we kick it off again?

I have done something and uploaded a draft:
http://grobmeier.de/commons-compress-draft.zip

Please check it out. Every comments are welcome. Please notice, this is
a draft. It provides the function to zip and unzip an archive. There is
a source folder with an example.

Thanks,
Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEDFzdkv8rKBUE/T4RApQZAJ9N4x5oyiqITIEOyTdvygJC7MJ5XQCfUEHG
cHOhiQ2sx7TnCIgcE7+SDRI=
=Iu3M
-END PGP SIGNATURE-

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

Re: [all] Proposal: Jakarta Language Components

[Thomas Dudziak]

On 3/6/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> --- James Ring wrote:
> > Does CLI fit into the picture? Or do you feel that
> > there are issues with it
> > that would prevent it from becoming part of the
> > proposed JLC?

> CLI has dependencies at present. A slimmed down CLIv2
> might be appropriate. Question is whether we believe
> this would be an appropriate J2SE enhancement.

I probably don't know the history of this, but why would the presence
of dependencies on other JLC components make it unappropriate ?
Shouldn't this be a matter of what it does ?

> Thats why I attempted to describe it clearly.
>
> J2SE-based - so no email, xml, xpath, mbeans, daemon,
> db...
> Suitable for adding to the J2SE, so no validator,
> chain, ...
> Broad-shallow API - many small routines, not one task
> per component

Some of these possibly don't even belong to Jakarta (anymore), e.g.
xml/xpath/digester/betwixt could be handled in XML commons, dbutils in
DB etc.

cheers,
Tom

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

Re: [all] Proposal: Jakarta Language Components

[Henri Yandell]

On 3/5/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> Time to stop being negative, here is what I would like to happen next.
>
>
> I hereby propose the creation of a new Jakarta entity named 'Jakarta
> Language Components'.
>
> This will be formed from the following codebases:
> [lang]
> [io]
> [collections] - expected to divide
> [primitives]
> [codec]
> [id] - on exit from sandbox
> [convert] - if ever developed
>
> I currently believe these are related, but out of scope:
> [beanutils] - logging is an issue

If logging were removed?

> [pool] - is pooling more J2EE than J2SE

Not sure. Should we also consider a J-JEE-C? With this being J-JSE-C?
[pool], [dbcp] and [JCS] all seem related.

> [oro]/[regexp] - specialised knowledge

This is a hard one. Specialised yes, but definitely a JLC fit and
otherwise we'll just have a Jakarta Regexp Components group.

> [math] - specialised, has dependencies

It's not a fit anyway - [math] goes way, way beyond the JDK.

Others:

[bcel]? Again a specialized knowledge one.

[dbutils]? Do we consider jdbc to be JEE?
[email]? JEE?

It might make things simpler to draw up an entire future re-org of
Jakarta. See who gets dropped through the cracks and decide if we have
to kill, accept or leave them to stand alone. There are some obvious
ones for JWC, and some that just don't seem to fit and would have to
stand alone.

Hen

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

Re: [resources][all] Resources status

[Henri Yandell]

On 3/6/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> >
> > Phil's suggestion for FeedParser was:
> >
> > "We need to make a decision on which way to go here...either demote
> > back to sandbox/dormant or have someone step up to drive this
> > component toward a release."
> >
> > I don't see anything that argued with the demoting, though I can only
> > find the thread suggesting the change.
>
>
> Sorry, I didn't follow the FeedParser discussions too closely. What are the
> criteria, then, for deciding between a Proper component going back to the
> sandbox and going straight to dormant? I'm assuming that, should BeanUtils,
> for example, remain inactive, you wouldn't argue for that to go back to the
> sandbox.

Yeah - beanutils couldn't go back. Latka, resources, feedparser have
all not had a solid release - though in Latka's case I'm being a bit
aggressive on a -1.0-alpha1 release. No release => demotion to Sandbox
can occur.

Dealing with the released stuff is the thing that started the
inactive/mature/stable discussions.

JLC pretty much demands that the Sandbox move outside of the J*C
groupings - so I imagine moving from Sandbox to J*C will be a bigger
deal in the future.

Hen

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

svn commit: r383567 - /jakarta/commons/sandbox/jci/trunk/pom.xml

[brett]

Author: brett
Date: Mon Mar  6 07:43:45 2006
New Revision: 383567

URL: http://svn.apache.org/viewcvs?rev=383567&view=rev
Log:
update to be consistent with exec and openpgp for now

Modified:
jakarta/commons/sandbox/jci/trunk/pom.xml

Modified: jakarta/commons/sandbox/jci/trunk/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/pom.xml?rev=383567&r1=383566&r2=383567&view=diff
==
--- jakarta/commons/sandbox/jci/trunk/pom.xml (original)
+++ jakarta/commons/sandbox/jci/trunk/pom.xml Mon Mar  6 07:43:45 2006
@@ -1,22 +1,22 @@
 
   4.0.0
-  jakarta-commons
-  jakarta-commons-jci
+  
+org.apache.commons
+commons-sandbox-parent
+1.0-SNAPSHOT
+  
+  commons-jci
   1.0-SNAPSHOT
   
+  http://jakarta.apache.org/commons/sandbox/jci/
+  Commons JCI
 
- 
-  
-Maven Snapshots
-http://snapshots.maven.codehaus.org/maven2/
-
-  true
-
-
-  false
-
-  
- 
+  
+
+  Maven Snapshots
+  http://snapshots.maven.codehaus.org/maven2/
+
+  
 
   
 src/java
@@ -25,7 +25,6 @@
 
   org.codehaus.mojo.minijar
   maven-minijar-plugin
-  
 
   
 
@@ -67,4 +66,17 @@
   2.3.7
 
   
+  
+
scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk
+
scm:svn:https://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk
+
http://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk
+  
+  
+
+  website
+  Apache Website
+  
scp://minotaur.apache.org/www/jakarta.apache.org/commons/sandbox/jci/
+
+  
 
+



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

Re: [all] Proposal: Jakarta Language Components

[Henri Yandell]

On 3/6/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> --- James Ring wrote:
> > Does CLI fit into the picture? Or do you feel that
> > there are issues with it
> > that would prevent it from becoming part of the
> > proposed JLC?
> CLI has dependencies at present. A slimmed down CLIv2
> might be appropriate. Question is whether we believe
> this would be an appropriate J2SE enhancement.

Looks like  1 import dependency on Lang - and it's in the old CLI 1 API.

So definitely +1 for CLI in JLC with CLI1 removed or CLI2 removed and
the import gone.

Hen

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

Re: [resources][all] Resources status

[Martin Cooper]

On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> On 3/5/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > >
> > > On 3/5/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> > > > Can we establish the status of [resources].
> > > >
> > > > Rahul Akolkar wrote:
> > > >  >  * [resources] Since now it isn't part of Struts 1.3.0, seems
> thats a
> > > >  > setback to interest in releasing.
> > > >
> > > > IFAIK:
> > > > - its unreleased
> > > > - there is little development effort (although something happened in
> > > > November)
> > > > - there could be a overlap with [configuration]
> > > > - its raison d'etre seems to have disappeared
> > > >
> > > >
> > > > Does a [resources] developer want to speak up in its favour?
> > > > Or should we fast track it to dormant?
> > >
> > > Just to confirm - this means putting it back into the sandbox, right?
> >
> >
> > Um, no, I believe "fast track it to dormant" means moving it to
> "dormant". I
> > know that the web site currently describes "dormant" as inactive sandbox
> > components, but that is not accurate. FeedParser was promoted before it
> went
> > dormant, and Resources is in the same boat. The web site is wrong -
> dormant
> > components can come from Proper too.
>
> Phil's suggestion for FeedParser was:
>
> "We need to make a decision on which way to go here...either demote
> back to sandbox/dormant or have someone step up to drive this
> component toward a release."
>
> I don't see anything that argued with the demoting, though I can only
> find the thread suggesting the change.


Sorry, I didn't follow the FeedParser discussions too closely. What are the
criteria, then, for deciding between a Proper component going back to the
sandbox and going straight to dormant? I'm assuming that, should BeanUtils,
for example, remain inactive, you wouldn't argue for that to go back to the
sandbox.

--
Martin Cooper


I'm also unsure why we'd be happy to move FeedParser and Resources
> from Proper to Dormant (without going back to the Sandbox) and yet the
> same doesn't seem to hold true for Jakarta components (referring to
> the thread on general@).
>
> Whatever happens, Latka needs the same to happen for it. It's been
> released, but only a 1.0-alpha1 N years ago. Not sure that even
> counts.
>
> Hen
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: svn commit: r377094 - in /jakarta/commons/sandbox/exec/trunk/src: main/java/org/apache/commons/exec/ main/java/org/apache/commons/exec/environment/ main/java/org/apache/commons/exec/launch

[Brett Porter]

Sorry, lost track of this thread. Where did we get to here?

- Brett

Brett Porter wrote:
> StringBuffer is kind of like it, but don't take that too literally.
> Please reuse the code from plexus-utils if you can! It would make
> porting *much* easier.
> 
> - Brett
> 
> Niklas Gustavsson wrote:
>> Let me rethink this a little bit. For now I'll revert the changes and
>> work on a simpler CommandLine implementation, something in line with
>> StringBuffer.
>>
>> Thanks for the feedback! :-)
>>
>> /niklas
>>
> 
> -
> 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: [resources][all] Resources status

[James Mitchell]

I am also a [resources] developer and while I wish there were more interest 
in supporting it, I just don't see that happening any time soon.  Also, I 
agree with Niall that the API needs a bit of clean up.


At one point, the existing MessageResources (Struts) were to be deprecated 
in favor of commons-resources.  I remember seeing it on it on the roadmap 
and having a few discussions around it, but I can't find the link for it 
right nowwhich says more about my involvement than I like to admit ;)


So, +1 for fast track.

I suppose if we need it bad enough for a future release, we can always pull 
it back out and try again.


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring
678.910.8017

- Original Message - 
From: "Martin Cooper" <[EMAIL PROTECTED]>

To: "Jakarta Commons Developers List" 
Sent: Monday, March 06, 2006 1:01 AM
Subject: Re: [resources][all] Resources status


On 3/5/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:


On 3/5/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> Can we establish the status of [resources].






Does a [resources] developer want to speak up in its favour?
> Or should we fast track it to dormant?

If no other commons developers show interest in working on it then +1



Technically, I'm a Resources developer, but I haven't touched it in a _long_
time. Given that most of my coding these days is in JavaScript and
ActionScript, that's not likely to change any time soon, so +1 for
fast-tracking Resources to dormant.

--
Martin Cooper


Niall


> 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]

Re: [all] Proposal: Jakarta Language Components

[Stephen Colebourne]

--- James Ring wrote:
> Does CLI fit into the picture? Or do you feel that
> there are issues with it 
> that would prevent it from becoming part of the
> proposed JLC?
CLI has dependencies at present. A slimmed down CLIv2
might be appropriate. Question is whether we believe
this would be an appropriate J2SE enhancement.

--- James Ring wrote:
> Would the JLC be distributed as one jar file? If so,
> could JLC components 
> depend on each other? What are your opinions on
> distribution issues like that?
I would expect each component to have its own jar.
As with commons, there probably should be a
jlc-combo.jar too, but thats optional.

--- Torsten Curdt wrote:
> ...on the other hand it might hard to decide
> whether some belongs to that grouping or not.
> The definition of "language focussed" is just
> too blurry IMO.
--- Dion Gillard wrote:
> For example, does email fit into the language
components?
--- Henri Yandell wrote:
> csv?

Thats why I attempted to describe it clearly.

J2SE-based - so no email, xml, xpath, mbeans, daemon,
db...
Suitable for adding to the J2SE, so no validator,
chain, ...
Broad-shallow API - many small routines, not one task
per component

CSV is probably JLC.

--- Torsten Curdt wrote:
> What about tagging the components?
Tagging is just a website niceity. It doesn't solve
the size issue of commons. There are too many of us
here. Discussions get drowned out or missed.

--- Phil Steitz wrote:
> I am +1, as long as we agree informally to keep the
> "overlap" stuff mentioned here and elsewhere alive.
We have to. There needs to be a jakarta-wide (no
longer commons-wide) place to discuss shared issues,
and share knowledge.

--- Henri Yandell wrote:
> To effect this, I think that the sandbox should be
at
> the Jakarta level and not at the Commons level.
+1. But I think you may need a jakarta-dev list.

Stephen


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

DO NOT REPLY [Bug 38830] - [net] FTPClient.listFiles() returns incorrect directory names if the directory begins numerically

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-06 10:17 ---
(In reply to comment #1)
> PLease indicate the system of the server you are connecting to and also please
> provide a listing of the directory in which these directories reside from a
> standard FTP program.

The FTP server is IIS running on Windows Server 2003. It reports as Microsoft
FTP Service (Version 5.0).

Using command line ftp from the same UNIX machine that runs my Java app the file
list is reported correctly:
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
10 years and under
11-14 years old
15-17 years old
226 Transfer complete.
54 bytes received in 0.012 seconds (4.43 Kbytes/s)

It seems likely to me that it is the parser used that is stripping out the 10 as
if it is an FTP response code. I haven't been able to verify this myself, 
though.

-- 
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]

svn commit: r383502 - /jakarta/commons/proper/httpclient/trunk/release_notes.txt

[olegk]

Author: olegk
Date: Mon Mar  6 01:43:34 2006
New Revision: 383502

URL: http://svn.apache.org/viewcvs?rev=383502&view=rev
Log:
PR #38818

Modified:
jakarta/commons/proper/httpclient/trunk/release_notes.txt

Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/release_notes.txt?rev=383502&r1=383501&r2=383502&view=diff
==
--- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original)
+++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Mon Mar  6 
01:43:34 2006
@@ -1,5 +1,8 @@
 Changes since Release 3.0:
 
+ * 38818 - Failed CONNECT no longer leaves connection in an inconsistent state
+   Contributed by Oleg Kalnichevski 
+
  * 38636 - Calling HttpState.clearCookies() is now safe from a different 
thread.
Contributed by Peter Dolberg 
 



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

svn commit: r383501 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java

[olegk]

Author: olegk
Date: Mon Mar  6 01:41:35 2006
New Revision: 383501

URL: http://svn.apache.org/viewcvs?rev=383501&view=rev
Log:
PR #38818 (Failed CONNECT leaves connection in an inconsistent state)

Contributed by Oleg Kalnichevski
Reviewed by Roland Weber, Michael Becke, Ortwin Glück

Modified:

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java

Modified: 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java?rev=383501&r1=383500&r2=383501&view=diff
==
--- 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java
 (original)
+++ 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java
 Mon Mar  6 01:41:35 2006
@@ -515,6 +515,7 @@
 this.connectMethod = null;
 return true;
 } else {
+this.conn.close();
 return false;
 }
 }



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

Re: [resources][all] Resources status

[Dion Gillard]

On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> Whatever happens, Latka needs the same to happen for it. It's been
> released, but only a 1.0-alpha1 N years ago. Not sure that even
> counts.
>
+1. Latka is definitely dormant.


--
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

org/apache/commons/net/ftp/FTPFile.java - getTimestamp() method nullifies seconds and milliseconds

[Diana Teplits]

Hello.

 

I'll appreciate your help with the following problem:

 

My program is supposed to connect to ftp server from ftp client and get
files from predefined directory.

 

It works except one thing: 

 

FTPClient ftp = new FTPClient();

...

...

FTPFile[] filesArr = ftp.listFiles();

FTPFile ftpFile = filesArr[0];

Calendar date = ftpFile.getTimestamp();

 

Seconds and milliseconds inside date object have zero values instead of
the correct values.

Is there any way to get ftp file lastModified date including seconds and
milliseconds?

 

P.S.

 

I tried to use FTPClientConfig.setRecentDateFormatStr(..) in order to
solve this problem, but didn't succeed...

 

Thanks in advance,

 

Diana.

 

RE: [beanutils] ISO Date converter

[Jörg Schaible]

Jörg Schaible wrote on Monday, March 06, 2006 9:37 AM:

[snip]
> 
> That would be an IMHO an interesting extension to lang (since
> FastDateFormat provides the necessary functionality and
> DateRangeUtils already deal with ISO8601 symbols). WDYT?

Having a second look at lang I found (again) DateFormatUtils, dealing with 
ISO8601formatting. Therefore I did not suggest this implementation before - I 
just felt it was superfluous.

- Jörg

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

RE: [beanutils] ISO Date converter

[Jörg Schaible]

Henri Yandell wrote on Monday, March 06, 2006 9:02 AM:

> This seems like a useful class to me. Any reason not to add it?
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=38772

It's way from complete. While some ISO8601formats are quite obscure, using UTC  
is really common, otherwise you're dependend on a time zone. With JDK 1.4 you 
can mimik this using the 'Z' formatting symbol ... but that does not exist in 
JDK 1.3 (but in lang.FastDateFormat). Personally I have extended 
SimpleDateFormat to handle a lot of the ISO8601 (and to be able to use the 
symbols of ISO 8601 to define a format):

public void testAllStandardFormatter() {
final Calendar calendar = Calendar.getInstance();
calendar.setTimeZone(TimeZone.getTimeZone("Europe/Berlin"));
calendar.setTimeInMillis(50);
calendar.set(1968, Calendar.MAY, 28, 13, 30, 10);
final Date date = calendar.getTime();
assertEquals("680528", ISO8601DateFormat.BASIC_DATE.format(date));
assertEquals("1968-05-28", 
ISO8601DateFormat.EXTENDED_DATE.format(date));
assertEquals("133010", ISO8601DateFormat.BASIC_TIME.format(date));
assertEquals("13:30:10", ISO8601DateFormat.EXTENDED_TIME.format(date));
assertEquals("133010,050", 
ISO8601DateFormat.BASIC_TIME_FRACTION.format(date));
assertEquals("13:30:10,050", 
ISO8601DateFormat.EXTENDED_TIME_FRACTION.format(date));
assertEquals("123010Z", ISO8601DateFormat.BASIC_TIME_UTC.format(date));
assertEquals("12:30:10Z", 
ISO8601DateFormat.EXTENDED_TIME_UTC.format(date));
assertEquals("123010,050Z", 
ISO8601DateFormat.BASIC_TIME_UTC_FRACTION.format(date));
assertEquals("12:30:10,050Z", 
ISO8601DateFormat.EXTENDED_TIME_UTC_FRACTION.format(date));
assertEquals("123010+", 
ISO8601DateFormat.BASIC_TIME_OFFSET.format(date));
assertEquals("12:30:10+", 
ISO8601DateFormat.EXTENDED_TIME_OFFSET.format(date));
assertEquals("680528T133010", 
ISO8601DateFormat.BASIC_DATE_TIME.format(date));
assertEquals("1968-05-28T13:30:10", 
ISO8601DateFormat.EXTENDED_DATE_TIME.format(date));
assertEquals("680528T133010,050", 
ISO8601DateFormat.BASIC_DATE_TIME_FRACTION.format(date));
assertEquals("1968-05-28T13:30:10,050", 
ISO8601DateFormat.EXTENDED_DATE_TIME_FRACTION.format(date));
assertEquals("680528T123010Z", 
ISO8601DateFormat.BASIC_DATE_TIME_UTC.format(date));
assertEquals("1968-05-28T12:30:10Z", 
ISO8601DateFormat.EXTENDED_DATE_TIME_UTC.format(date));
assertEquals("680528T123010,050Z", 
ISO8601DateFormat.BASIC_DATE_TIME_UTC_FRACTION.format(date));
assertEquals("1968-05-28T12:30:10,050Z", 
ISO8601DateFormat.EXTENDED_DATE_TIME_UTC_FRACTION.format(date));
assertEquals("680528T123010+", 
ISO8601DateFormat.BASIC_DATE_TIME_OFFSET.format(date));
assertEquals("1968-05-28T12:30:10+", 
ISO8601DateFormat.EXTENDED_DATE_TIME_OFFSET.format(date));
}


That would be an IMHO an interesting extension to lang (since FastDateFormat 
provides the necessary functionality and DateRangeUtils already deal with 
ISO8601 symbols). WDYT?

- Jörg

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

Re: [beanutils] ISO Date converter

[Niall Pemberton]

On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> This seems like a useful class to me. Any reason not to add it?
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=38772

Yes, it uses static instances of DateFormat and the DateFormat javadocs say:

"Date formats are not synchronized. It is recommended to create
separate format instances for each thread. If multiple threads access
a format concurrently, it must be synchronized externally"

Niall

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

[beanutils] ISO Date converter

[Henri Yandell]

This seems like a useful class to me. Any reason not to add it?

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

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