svn commit: r230403 - in /jakarta/commons/proper/lang/trunk/src: java/org/apache/commons/lang/exception/NestableDelegate.java test/org/apache/commons/lang/exception/NestableDelegateTestCase.java

[ggregory]

Author: ggregory
Date: Thu Aug  4 23:16:19 2005
New Revision: 230403

URL: http://svn.apache.org/viewcvs?rev=230403view=rev
Log:
Slightly increments the test coverage for NestableDelegate. Includes a rework 
of the getMessage(String) method. Courtesy of Nathan Beyer [EMAIL PROTECTED]

Modified:

jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java

jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/exception/NestableDelegateTestCase.java

Modified: 
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java?rev=230403r1=230402r2=230403view=diff
==
--- 
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
 (original)
+++ 
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
 Thu Aug  4 23:16:19 2005
@@ -106,68 +106,54 @@
 }
 
 /**
- * Returns the error message of the codeThrowable/code in the chain
- * of codeThrowable/codes at the specified index, numbered from 0.
- *
- * @param index the index of the codeThrowable/code in the chain of
- * codeThrowable/codes
- * @return the error message, or null if the codeThrowable/code at the
- * specified index in the chain does not contain a message
- * @throws IndexOutOfBoundsException if the codeindex/code argument is
- * negative or not less than the count of codeThrowable/codes in the
- * chain
+ * Returns the error message of the codeThrowable/code in the chain of 
codeThrowable/codes at the
+ * specified index, numbered from 0.
+ * 
+ * @param index
+ *the index of the codeThrowable/code in the chain of 
codeThrowable/codes
+ * @return the error message, or null if the codeThrowable/code at the 
specified index in the chain does not
+ * contain a message
+ * @throws IndexOutOfBoundsException
+ * if the codeindex/code argument is negative or not less 
than the count of codeThrowable/codes
+ * in the chain
  * @since 2.0
  */
 public String getMessage(int index) {
 Throwable t = this.getThrowable(index);
 if (Nestable.class.isInstance(t)) {
 return ((Nestable) t).getMessage(0);
-} else {
-return t.getMessage();
 }
+return t.getMessage();
 }
 
 /**
- * Returns the full message contained by the codeNestable/code
- * and any nested codeThrowable/codes.
- *
- * @param baseMsg the base message to use when creating the full
- * message. Should be generally be called via
- * codenestableHelper.getMessage(super.getMessage())/code,
- * where codesuper/code is an instance of [EMAIL PROTECTED]
- * java.lang.Throwable}.
- * @return The concatenated message for this and all nested
- * codeThrowable/codes
+ * Returns the full message contained by the codeNestable/code and any 
nested codeThrowable/codes.
+ * 
+ * @param baseMsg
+ *the base message to use when creating the full message. 
Should be generally be called via
+ *codenestableHelper.getMessage(super.getMessage())/code, 
where codesuper/code is an
+ *instance of [EMAIL PROTECTED] java.lang.Throwable}.
+ * @return The concatenated message for this and all nested 
codeThrowable/codes
  * @since 2.0
  */
 public String getMessage(String baseMsg) {
-StringBuffer msg = new StringBuffer();
-if (baseMsg != null) {
-msg.append(baseMsg);
-}
-
 Throwable nestedCause = ExceptionUtils.getCause(this.nestable);
-if (nestedCause != null) {
-String causeMsg = nestedCause.getMessage();
-if (causeMsg != null) {
-if (baseMsg != null) {
-msg.append(: );
-}
-msg.append(causeMsg);
-}
-
+String causeMsg = nestedCause == null ? null : 
nestedCause.getMessage();
+if (nestedCause == null || causeMsg == null) {
+return baseMsg; // may be null, which is a valid result
+}
+if (baseMsg == null) {
+return causeMsg;
 }
-return msg.length()  0 ? msg.toString() : null;
+return baseMsg + :  + causeMsg;
 }
 
 /**
- * Returns the error message of this and any nested codeThrowable/codes
- * in an array of Strings, one element for each message. Any
- * codeThrowable/code not containing a message is represented in the
- * array by a null. This has the effect of cause the length of the returned
- * array to be equal to the result of the [EMAIL PROTECTED] 

RE: [lang][patch] NestableDelegate Small Test Increase and Optimization

[Gary Gregory]

Nathan:

 

Thank you. Patches applied and slightly tweaked. Clover report is here: 

http://people.apache.org/~ggregory/commons-lang/2.2-dev/docs/clover/

 

Gary

 



From: Nathan Beyer [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 04, 2005 9:48 PM
To: 'Jakarta Commons Developers List'
Subject: [lang][patch] NestableDelegate Small Test Increase and
Optimization

 

The attached patch slightly increments the test coverage for
NestableDelegate. It also includes a small rework of the getMessage()
method to minimize StringBuffer creation. The application of the latter
piece is up to the discretion of the committers, obviously.

 

-Nathan Beyer

Re: Project Proposal?

[Henri Yandell]

Out of interest, why java.net and not sandbox? :)

Before that sounds like a witch-hunt, I'm as guilty in that I start
all my stuff at osjava.org and I can definitely list some reasons why.

Some may be bad:
* Embaressment for dumb ideas :)
* Don't want to be weighed down by a weighty release system.
* Big painful website.
* Might compete with another Commons component.

Some may be good:
* Does the ASF want single-person codebases when an idea doesn't pan out.
* If it fails, I'd then be forking it elsewhere which feels worse than
just starting elsewhere.

What if we had a location within which ASF committers can bring their
half-cocked component ideas? Try to encourage migration to the ASF and
its benefits:

* bandwidth, though sf.net and java.net can solve that too. So can
building your own system to the level of Codehaus.
* legal protection.
* better user acceptance.
* community.

If we couple this with:

* much better management of the sandbox, and components that have failed.
* a plan for mature components.

could we pick things up in terms of vibrancy? My biggest worry would
be whether the mailing list becomes a bottleneck.

Half-baked idea (it's late): Each component has its own mail alias
which gets forwarded to particular lists. These lists could represent
the state of maturity of a component. Probably crap, just throwing it
out.

One question I'd like to ask is whether we would accept mature components. 

Take http://www.osjava.org/norbert/, HttpClient said they were
interested in using it and the thought was to put it in Commons. My
only concern is that I can't see a lot more to do with it code-wise,
so I'm hesitant to dump it in Commons, and yet I think it's a good
tiny component that could do with being more open.

Hen

On 8/4/05, James Carman [EMAIL PROTECTED] wrote:
 Well, I went ahead and started the project over at java.net, but we can move
 it later if need be.  It's a dependency injection framework called
 syringe.  The project uses the Apache License, Version 2.0.  It's still
 pending approval at java.net, so you guys won't be able to see anything
 yet.  It should be approved soon though.

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

RE: Project Proposal?

[Simon Kitching]

The sandbox is available to any apache committer - but only to apache
committers.

So if an existing apache project is factoring out some code into a
module that other projects can take advantage of then the sandbox is a
good place for that; the existing committers on that project can all
work in the sandbox then promote the result to commons proper when it's
stable. In fact, this scenario is one of the main reasons commons and
the sandbox were created AFAIK.

When working on an experimental refactoring/rewrite of an existing
commons project, the sandbox might be appropriate too - though now we
are using subversion with branch management than CVS a branch of the
base project might be a better choice.

When starting a project where 3 or more apache committers are already
interested in being involved, the sandbox may also be a reasonable place
to do it.

But if a project is being started where the initial development
community contains non-apache members, or a project which hopes to draw
contributors from outside Apache, then I think the sandbox is an awkward
place to work as those new contributors can't be granted commit access.
Somewhere external is probably a better choice. If the project is
successful it could then be brought back to apache if the development
team want that later. Of course in the latter case things are much
easier if the APL is used for the code.

Regards,

Simon

On Thu, 2005-08-04 at 22:21 -0400, James Carman wrote:
 Well, I went ahead and started the project over at java.net, but we can move
 it later if need be.  It's a dependency injection framework called
 syringe.  The project uses the Apache License, Version 2.0.  It's still
 pending approval at java.net, so you guys won't be able to see anything
 yet.  It should be approved soon though.
 
 
 -Original Message-
 From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, August 04, 2005 7:43 PM
 To: Jakarta Commons Developers List
 Subject: Re: Project Proposal?
 
 Brett Porter wrote:
  http://jakarta.apache.org/commons/charter.html
  
  As far as I understand, as a Jakarta committer, you are entitled to just
  start something in the sandbox - however I guess you are much more
  likely to have the component succeed if you gather up some people who
  want to work on it in advance.
 
 True. Also, its often good to open an email discussion, or a more formal 
 proposal document (as found in each commons project) to hone your idea.
 
 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]
 


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

svn commit: r230407 - in /jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider: local/DefaultLocalFileProvider.java local/LocalFileSystem.java temp/TemporaryFileProvider.java

[imario]

Author: imario
Date: Fri Aug  5 00:43:16 2005
New Revision: 230407

URL: http://svn.apache.org/viewcvs?rev=230407view=rev
Log:
fix: pass down FileSystemOptions for local filesytem too. Reported By: Siarhei 
Baidun

Modified:

jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java

jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileSystem.java

jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/temp/TemporaryFileProvider.java

Modified: 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java?rev=230407r1=230406r2=230407view=diff
==
--- 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java
 (original)
+++ 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java
 Fri Aug  5 00:43:16 2005
@@ -112,7 +112,7 @@
 {
 // Create the file system
 final LocalFileName rootName = (LocalFileName) name;
-return new LocalFileSystem(rootName, rootName.getRootFile());
+return new LocalFileSystem(rootName, rootName.getRootFile(), 
fileSystemOptions);
 }
 
 public Collection getCapabilities()

Modified: 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileSystem.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileSystem.java?rev=230407r1=230406r2=230407view=diff
==
--- 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileSystem.java
 (original)
+++ 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileSystem.java
 Fri Aug  5 00:43:16 2005
@@ -20,6 +20,7 @@
 import org.apache.commons.vfs.FileSelector;
 import org.apache.commons.vfs.FileSystem;
 import org.apache.commons.vfs.FileSystemException;
+import org.apache.commons.vfs.FileSystemOptions;
 import org.apache.commons.vfs.provider.AbstractFileSystem;
 
 import java.io.File;
@@ -39,9 +40,10 @@
 private final String rootFile;
 
 public LocalFileSystem(final FileName rootName,
-   final String rootFile)
+   final String rootFile,
+   final FileSystemOptions opts)
 {
-super(rootName, null, null);
+super(rootName, null, opts);
 this.rootFile = rootFile;
 }
 

Modified: 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/temp/TemporaryFileProvider.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/temp/TemporaryFileProvider.java?rev=230407r1=230406r2=230407view=diff
==
--- 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/temp/TemporaryFileProvider.java
 (original)
+++ 
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/temp/TemporaryFileProvider.java
 Fri Aug  5 00:43:16 2005
@@ -1,12 +1,12 @@
 /*
  * Copyright 2002-2005 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.
@@ -108,7 +108,7 @@
 getContext().parseURI(scheme + : + FileName.ROOT_PATH);
 // final FileName rootName =
 //new LocalFileName(scheme, scheme + :, FileName.ROOT_PATH);
-filesystem = new LocalFileSystem(rootName, 
rootFile.getAbsolutePath());
+filesystem = new LocalFileSystem(rootName, 
rootFile.getAbsolutePath(), properties);
 addFileSystem(this, filesystem);
 }
 



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

DO NOT REPLY [Bug 35970] - [betwixt] White spaces in empty elements with indentation active

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35970.
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=35970


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|white spaces in empty   |[betwixt] White spaces in
   |elements with indentation   |empty elements with
   |active  |indentation active




-- 
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 35459] - [validator] validateDate cannot handle exception

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35459.
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=35459


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|dev@struts.apache.org   |commons-
   ||[EMAIL PROTECTED]
 OS/Version|Windows XP  |All
Summary|validateDate cannot handle  |[validator] validateDate
   |exception   |cannot handle exception




-- 
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 35867] - [io] PipedUtils

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35867.
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=35867


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|PipedUtils  |[io] PipedUtils




-- 
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 35951] - [beanutils] Overriding methods in LazyDynaBean

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35951.
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=35951


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|overriding methods in   |[beanutils] Overriding
   |LazyDynaBean|methods in LazyDynaBean




-- 
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 35958] - [vfs] Multiple taskdefs causes ClassCastException

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35958.
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=35958


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Multiple taskdefs causes|[vfs] Multiple taskdefs
   |ClassCastException  |causes ClassCastException




-- 
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 35926] - [validator] CreditValidator does not handle Visa correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35926.
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=35926


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|other   |All
   Platform|Other   |All
Summary|CreditValidator does not|[validator] CreditValidator
   |handle Visa correctly   |does not handle Visa
   ||correctly




-- 
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 35955] - [collections] Change CollectionUtils.forAllDo to return the Closure

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35955.
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=35955


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Change  |[collections] Change
   |CollectionUtils.forAllDo to |CollectionUtils.forAllDo to
   |return the Closure  |return the Closure




-- 
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 35989] - [beanutils] BeanUtilsBean: Value into scalar section

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35989.
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=35989


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows 2000|All
Summary|BeanUtilsBean: Value into   |[beanutils] BeanUtilsBean:
   |scalar section  |Value into scalar section




-- 
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 35881] - [email] Allow access to MimeMessage from Email class

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35881.
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=35881


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Allow access to MimeMessage |[email] Allow access to
   |from Email class|MimeMessage from Email class




-- 
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 35964] - [lang] Add WordUtils.getInitials(String)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35964.
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=35964


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Add |[lang] Add
   |WordUtils.getInitials(String|WordUtils.getInitials(String
   |)   |)




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

[exec][patch] commons-exec initial contrib

[Niklas Gustavsson]

Brett Porter wrote:


* Would it be a good starting point (if so I'll create a patch for the
code I've cleaned up and removed the Ant specifics from)?



I think so.



(This email with a .zip attachment does not seem to get through to the 
list. And since there's no component for exec in bugzilla, I've uploaded 
the file to 
http://www.protocol7.com/tmp/commons-exec-initial-20050802.zip instead. 
If I should send it somehow different, please enlighten me.)


Attached is the initial contribution, I've zipped it since it's largish. 
Note that there are tons of problems with this code (e.g. design issues, 
dependency on JCL, lack of unit tests/javadoc) but IMHO it's a good 
enough starting point. It uses maven2 for building and builds with the 
latest SVN version of maven2.


If you have any issues with the code, maven2 setup, patch or anything, 
please tell me and I'll get it fixed!


/niklas

--
Niklas Gustavsson
[EMAIL PROTECTED]
http://www.protocol7.com

--
--
Niklas Gustavsson
[EMAIL PROTECTED]
http://www.protocol7.com


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

Re: [exec][patch] commons-exec initial contrib

[Brett Porter]

Thanks! I'll add it to the sandbox shortly and see if there is anything
I can do.

- Brett

Niklas Gustavsson wrote:

 Brett Porter wrote:

 * Would it be a good starting point (if so I'll create a patch for the
 code I've cleaned up and removed the Ant specifics from)?



 I think so.



 (This email with a .zip attachment does not seem to get through to the
 list. And since there's no component for exec in bugzilla, I've
 uploaded the file to
 http://www.protocol7.com/tmp/commons-exec-initial-20050802.zip
 instead. If I should send it somehow different, please enlighten me.)

 Attached is the initial contribution, I've zipped it since it's
 largish. Note that there are tons of problems with this code (e.g.
 design issues, dependency on JCL, lack of unit tests/javadoc) but IMHO
 it's a good enough starting point. It uses maven2 for building and
 builds with the latest SVN version of maven2.

 If you have any issues with the code, maven2 setup, patch or anything,
 please tell me and I'll get it fixed!

 /niklas

 --
 Niklas Gustavsson
 [EMAIL PROTECTED]
 http://www.protocol7.com



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

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

[Stefan Bodewig]

To whom it may engage...

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

Project commons-javaflow has an issue affecting its community integration.
This issue affects 4 projects,
 and has been outstanding for 17 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- commons-javaflow :  Commons Javaflow


Full details are available at:

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-javaflow-05082005.jar] identifier set to project 
name
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/gump_work/build_jakarta-commons-sandbox_commons-javaflow.html
Work Name: build_jakarta-commons-sandbox_commons-javaflow (Type: Build)
Work ended in a state of : Failed
Elapsed: 13 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-05082005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/jci/target/commons-jci-05082005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-05082005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-05082005.jar:/usr/local/gump/public/workspace/jakarta-jmeter/lib/xstream-1.1.2.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

build:start:

java:prepare-filesystem:
[mkdir] Created dir: 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes

java:compile:
[echo] Compiling to 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes
[echo] 
==

  NOTE: Targetting JVM 1.4, classes
  will not run on earlier JVMs

==
  
[javac] Compiling 28 source files to 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes

java:jar-resources:

test:prepare-filesystem:
[mkdir] Created dir: 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes
[mkdir] Created dir: 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports

test:test-resources:

test:compile:
[javac] Compiling 10 source files to 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes

test:test:
[junit] Running org.apache.commons.javaflow.ContinuationTestCase
[junit] Tests run: 3, Failures: 0, Errors: 2, Time elapsed: 1.814 sec
[junit] [ERROR] TEST org.apache.commons.javaflow.ContinuationTestCase FAILED
[junit] Running 
org.apache.commons.javaflow.ContinuationCompilingClassLoaderTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.484 sec
[junit] Running org.apache.commons.javaflow.SerializationTestCase
[junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 1.443 sec
[junit] [ERROR] TEST org.apache.commons.javaflow.SerializationTestCase 
FAILED

BUILD FAILED
File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly
Element... fail
Line.. 181
Column 54

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

[Stefan Bodewig]

To whom it may engage...

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

Project commons-javaflow has an issue affecting its community integration.
This issue affects 4 projects,
 and has been outstanding for 17 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- commons-javaflow :  Commons Javaflow


Full details are available at:

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-javaflow-05082005.jar] identifier set to project 
name
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/gump_work/build_jakarta-commons-sandbox_commons-javaflow.html
Work Name: build_jakarta-commons-sandbox_commons-javaflow (Type: Build)
Work ended in a state of : Failed
Elapsed: 13 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-05082005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/jci/target/commons-jci-05082005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-05082005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-05082005.jar:/usr/local/gump/public/workspace/jakarta-jmeter/lib/xstream-1.1.2.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

build:start:

java:prepare-filesystem:
[mkdir] Created dir: 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes

java:compile:
[echo] Compiling to 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes
[echo] 
==

  NOTE: Targetting JVM 1.4, classes
  will not run on earlier JVMs

==
  
[javac] Compiling 28 source files to 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes

java:jar-resources:

test:prepare-filesystem:
[mkdir] Created dir: 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes
[mkdir] Created dir: 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports

test:test-resources:

test:compile:
[javac] Compiling 10 source files to 
/x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes

test:test:
[junit] Running org.apache.commons.javaflow.ContinuationTestCase
[junit] Tests run: 3, Failures: 0, Errors: 2, Time elapsed: 1.814 sec
[junit] [ERROR] TEST org.apache.commons.javaflow.ContinuationTestCase FAILED
[junit] Running 
org.apache.commons.javaflow.ContinuationCompilingClassLoaderTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.484 sec
[junit] Running org.apache.commons.javaflow.SerializationTestCase
[junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 1.443 sec
[junit] [ERROR] TEST org.apache.commons.javaflow.SerializationTestCase 
FAILED

BUILD FAILED
File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly
Element... fail
Line.. 181
Column 54

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

[dIon Gillard]

To whom it may engage...

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

Project commons-configuration has an issue affecting its community integration.
This issue affects 69 projects,
 and has been outstanding for 9 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-faces :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-jcr :  A jcr: protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- commons-configuration :  Jakarta commons
- commons-jelly-tags-ojb :  Commons Jelly
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- fulcrum-configuration-impl :  Services Framework
- fulcrum-intake :  Services Framework
- fulcrum-parser :  Services Framework
- fulcrum-security-adapter-turbine :  Services Framework
- fulcrum-security-memory :  Services Framework
- fulcrum-security-nt :  Services Framework
- fulcrum-template :  Services Framework
- jakarta-jetspeed :  Enterprise Information Portal
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-3 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- lenya :  Content Management System
- scarab :  Issue Tracking Built for the Ages
- test-ojb :  ObjectRelationalBridge


Full details are available at:

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-configuration-05082005.jar] identifier set to 
project name
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons/commons-configuration/gump_work/build_jakarta-commons_commons-configuration.html
Work Name: build_jakarta-commons_commons-configuration (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dmaven.final.name=commons-configuration-05082005 

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

[dIon Gillard]

To whom it may engage...

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

Project commons-configuration has an issue affecting its community integration.
This issue affects 69 projects,
 and has been outstanding for 9 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-faces :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-jcr :  A jcr: protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- commons-configuration :  Jakarta commons
- commons-jelly-tags-ojb :  Commons Jelly
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- fulcrum-configuration-impl :  Services Framework
- fulcrum-intake :  Services Framework
- fulcrum-parser :  Services Framework
- fulcrum-security-adapter-turbine :  Services Framework
- fulcrum-security-memory :  Services Framework
- fulcrum-security-nt :  Services Framework
- fulcrum-template :  Services Framework
- jakarta-jetspeed :  Enterprise Information Portal
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-3 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- lenya :  Content Management System
- scarab :  Issue Tracking Built for the Ages
- test-ojb :  ObjectRelationalBridge


Full details are available at:

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-configuration-05082005.jar] identifier set to 
project name
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons/commons-configuration/gump_work/build_jakarta-commons_commons-configuration.html
Work Name: build_jakarta-commons_commons-configuration (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dmaven.final.name=commons-configuration-05082005 

svn commit: r230426 - in /jakarta/commons/proper/betwixt/trunk: src/java/org/apache/commons/betwixt/io/BeanWriter.java xdocs/guide/writing.xml xdocs/tasks.xml

[rdonkin]

Author: rdonkin
Date: Fri Aug  5 03:26:18 2005
New Revision: 230426

URL: http://svn.apache.org/viewcvs?rev=230426view=rev
Log:
Added support for configuration of initial indent value for pretty printing. 
Contributed by Alex Ieong. Issue #36053.

Modified:

jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/BeanWriter.java
jakarta/commons/proper/betwixt/trunk/xdocs/guide/writing.xml
jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml

Modified: 
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/BeanWriter.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/BeanWriter.java?rev=230426r1=230425r2=230426view=diff
==
--- 
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/BeanWriter.java
 (original)
+++ 
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/BeanWriter.java
 Fri Aug  5 03:26:18 2005
@@ -102,6 +102,8 @@
 private static final String EOL = getEOL();
 /** text used for end of lines. Defaults to code\n/code*/
 private String endOfLine = EOL;
+/** Initial level of indentation (starts at 1 with the first element by 
default) */
+private int initialIndentLevel = 1;
 /** indentation text */
 private String indent;
 
@@ -117,7 +119,7 @@
 private boolean closedStartTag = true;
 /** Should an end tag be added for empty elements? */
 private boolean addEndTagForEmptyElement = false;
-/** Current level of indentation (starts at 1 with the first element) */
+/** Current level of indentation */
 private int indentLevel;
 /** USed to determine how body content should be encoded before being 
output*/
 private MixedContentEncodingStrategy mixedContentEncodingStrategy 
@@ -250,6 +252,24 @@
 }
 
 /** 
+ * Gets the initial indent level 
+ *
+ * @return the initial level for indentation 
+ */
+public int getInitialIndentLevel() {
+return initialIndentLevel;
+}
+
+/** 
+ * Sets the initial indent level used for pretty print indents  
+ * @param indent use this codeint/code to start with
+ */
+public void setInitialIndentLevel(int initialIndentLevel) {
+this.initialIndentLevel = initialIndentLevel;
+}
+
+
+/** 
  * Gets the indent string 
  *
  * @return the string used for indentation 
@@ -478,7 +498,7 @@
  */
 private void indent() throws IOException {
 if ( indent != null ) {
-for ( int i = 0; i  indentLevel; i++ ) {
+for ( int i = 1 - initialIndentLevel; i  indentLevel; i++ ) {
 writer.write( getIndent() );
 }
 }

Modified: jakarta/commons/proper/betwixt/trunk/xdocs/guide/writing.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/betwixt/trunk/xdocs/guide/writing.xml?rev=230426r1=230425r2=230426view=diff
==
--- jakarta/commons/proper/betwixt/trunk/xdocs/guide/writing.xml (original)
+++ jakarta/commons/proper/betwixt/trunk/xdocs/guide/writing.xml Fri Aug  5 
03:26:18 2005
@@ -113,5 +113,31 @@
/p
/subsection
 /section
+section name='Pretty Print'
+subsection name='Pretty Printing'
+p
+codeBeanWriter/code supports pretty printing. When pretty printing, extra 
white space will be inserted
+with the aim of making the xml produced more readible by humans. Pretty 
printing is off by default.
+Call codeenablePrettyPrint/code to switch it on. For example:
+/p
+source
+BeanWriter writer = ...
+...
+writer.enablePrettyPrinting();
+/source
+/subsection
+subsection name='Setting Initial Indent'
+p
+Pretty printing indents elements so that the xml can be read more easily. The 
number of indentations
+for the root element defaults to one. Some users may prefer this to start at 
zero. This value is configurable through 
+the codeinitialIndentLevel/code property of codeBeanWriter/code. For 
example
+/p
+source
+BeanWriter writer = ...
+...
+writer.setInitialIndentLevel(0);
+/source
+/subsection
+/section
 /body
 /document

Modified: jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml?rev=230426r1=230425r2=230426view=diff
==
--- jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml (original)
+++ jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml Fri Aug  5 03:26:18 
2005
@@ -190,6 +190,9 @@
 section name='Completed'
 subsection name='Since 0.7'
 ul
+li
+Made intitial indent level used for pretty printing configurable.
+/li
   liAdded guess-name 

DO NOT REPLY [Bug 36035] - [betwixt] BeanWriter configurable initial indent

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36035.
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=36035


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 12:28 ---
Committed. Many thanks.

Decide to leave initial value as 1 for backward compatibility.

For future, creating documentation patches and unit tests for features 
developed is strongly 
recommended. (Though unit testing this one is probably not required.)

Robert

-- 
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: [exec][patch] commons-exec initial contrib

[Kev Jackson]

(This email with a .zip attachment does not seem to get through to the 
list. And since there's no component for exec in bugzilla, I've 
uploaded the file to 
http://www.protocol7.com/tmp/commons-exec-initial-20050802.zip 
instead. If I should send it somehow different, please enlighten me.)


Attached is the initial contribution, I've zipped it since it's 
largish. Note that there are tons of problems with this code (e.g. 
design issues, dependency on JCL, lack of unit tests/javadoc) but IMHO 
it's a good enough starting point. It uses maven2 for building and 
builds with the latest SVN version of maven2.


If you have any issues with the code, maven2 setup, patch or anything, 
please tell me and I'll get it fixed!


I'm not a fan of maven, so I'll write up a quick build file for it, I'll 
also look into javadoc/unit tests as soon as I have some time (perhaps 
tomorrow)


Kev

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

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

[commons-jelly development]

To whom it may engage...

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

Project commons-jelly has an issue affecting its community integration.
This issue affects 41 projects,
 and has been outstanding for 61 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly :  Commons Jelly
- commons-jelly-tags-ant :  Commons Jelly
- commons-jelly-tags-antlr :  Commons Jelly
- commons-jelly-tags-avalon :  Commons Jelly
- commons-jelly-tags-bean :  Commons Jelly
- commons-jelly-tags-beanshell :  Commons Jelly
- commons-jelly-tags-betwixt :  Commons Jelly
- commons-jelly-tags-bsf :  Commons Jelly
- commons-jelly-tags-define :  Commons Jelly
- commons-jelly-tags-dynabean :  Commons Jelly
- commons-jelly-tags-email :  Commons Jelly
- commons-jelly-tags-fmt :  Commons Jelly
- commons-jelly-tags-html :  Commons Jelly
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-interaction :  Commons Jelly
- commons-jelly-tags-jaxme :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jface :  Commons Jelly
- commons-jelly-tags-jms :  Commons Jelly
- commons-jelly-tags-jmx :  Commons Jelly
- commons-jelly-tags-jsl :  Commons Jelly
- commons-jelly-tags-junit :  Commons Jelly
- commons-jelly-tags-log :  Commons Jelly
- commons-jelly-tags-memory :  Commons Jelly
- commons-jelly-tags-quartz :  Commons Jelly
- commons-jelly-tags-regexp :  Commons Jelly
- commons-jelly-tags-soap :  Commons Jelly
- commons-jelly-tags-sql :  Commons Jelly
- commons-jelly-tags-swing :  Commons Jelly
- commons-jelly-tags-swt :  Commons Jelly
- commons-jelly-tags-threads :  Commons Jelly
- commons-jelly-tags-util :  Commons Jelly
- commons-jelly-tags-validate :  Commons Jelly
- commons-jelly-tags-velocity :  Commons Jelly
- commons-jelly-tags-xml :  Commons Jelly
- commons-jelly-tags-xmlunit :  Commons Jelly
- commons-latka :  Functional Testing Suite
- commons-sql :  Basic Services Architecture
- geronimo :  Apache Geronimo, the J2EE server project of the Apache 
Softw...
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools


Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/index.html

That said, some information snippets are provided here.

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



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html
Work Name: build_commons-jelly_commons-jelly (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 1 sec
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH: 

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

[commons-jelly development]

To whom it may engage...

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

Project commons-jelly has an issue affecting its community integration.
This issue affects 41 projects,
 and has been outstanding for 61 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly :  Commons Jelly
- commons-jelly-tags-ant :  Commons Jelly
- commons-jelly-tags-antlr :  Commons Jelly
- commons-jelly-tags-avalon :  Commons Jelly
- commons-jelly-tags-bean :  Commons Jelly
- commons-jelly-tags-beanshell :  Commons Jelly
- commons-jelly-tags-betwixt :  Commons Jelly
- commons-jelly-tags-bsf :  Commons Jelly
- commons-jelly-tags-define :  Commons Jelly
- commons-jelly-tags-dynabean :  Commons Jelly
- commons-jelly-tags-email :  Commons Jelly
- commons-jelly-tags-fmt :  Commons Jelly
- commons-jelly-tags-html :  Commons Jelly
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-interaction :  Commons Jelly
- commons-jelly-tags-jaxme :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jface :  Commons Jelly
- commons-jelly-tags-jms :  Commons Jelly
- commons-jelly-tags-jmx :  Commons Jelly
- commons-jelly-tags-jsl :  Commons Jelly
- commons-jelly-tags-junit :  Commons Jelly
- commons-jelly-tags-log :  Commons Jelly
- commons-jelly-tags-memory :  Commons Jelly
- commons-jelly-tags-quartz :  Commons Jelly
- commons-jelly-tags-regexp :  Commons Jelly
- commons-jelly-tags-soap :  Commons Jelly
- commons-jelly-tags-sql :  Commons Jelly
- commons-jelly-tags-swing :  Commons Jelly
- commons-jelly-tags-swt :  Commons Jelly
- commons-jelly-tags-threads :  Commons Jelly
- commons-jelly-tags-util :  Commons Jelly
- commons-jelly-tags-validate :  Commons Jelly
- commons-jelly-tags-velocity :  Commons Jelly
- commons-jelly-tags-xml :  Commons Jelly
- commons-jelly-tags-xmlunit :  Commons Jelly
- commons-latka :  Functional Testing Suite
- commons-sql :  Basic Services Architecture
- geronimo :  Apache Geronimo, the J2EE server project of the Apache 
Softw...
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools


Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/index.html

That said, some information snippets are provided here.

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



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html
Work Name: build_commons-jelly_commons-jelly (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 1 sec
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH: 

DO NOT REPLY [Bug 35955] - [collections] Change CollectionUtils.forAllDo to return the Closure

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35955.
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=35955





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 13:19 ---
There's only one problem with that.  We're not using JDK5, so the return type
will be Closure, which doesn't have a total() method.  So, you'd have to cast
that return type before calling any methods on it.  Not quite as compact.

-- 
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: Project Proposal?

[James Carman]

I guess I wanted a little more freedom/control over the project at this
phase.  Also, I wasn't too sure about licensing issues with putting stuff in
the codebase that depends upon code outside Apache (the build file
automatically downloads its dependencies from Ibiblio).  

It is early on right now, but I think there are some sound ideas there...

1.  Proxy Factories - All proxies in Syringe are created using a proxy
factory (an interface).  Using syringe, you never have to write the proxying
logic code yourself anymore.  Furthermore, since it's abstracted out, it's
easy to switch between (or mix and match for that matter) proxying
strategies, simply by supplying a different implementation class.  I
currently have implementations using JDK proxies and CGLIB.

2.  Object Providers - Objects are provided to Syringe through
ObjectProviders.  There are two different types of ObjectProviders now, core
object providers and wrapper/decorator providers.  The core providers would
be responsible for constructing/finding the actual implementation object.
It might be a simple JavaBean, or it could be some sort of remote object
(EJB, JAX-RPC, RMI, Burlap, etc.).  The wrapper/decorator providers
supplement these core providers with additional functionality.  For example,
in Syringe, all dependency injection is done using a decorator provider.
So, it's easy for you to extend Syringe with your own providers and still
support DI.  This has been somewhat of a problem in HiveMind.  All of the
dependency injection logic is buried inside the BuilderFactory's
implementation.  

3.  Method Interceptors - Syringe only supports the MethodInterceptor
interface (a proxy factory must know how to create a proxy which goes
through a MethodInterceptor) from the AOP Alliance API.  Since this is
somewhat of a standard API, I don't really see it as a limitation.  If we
see the need to support other mechanisms, maybe we can provide adapter
classes to bridge the gap.



-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 05, 2005 2:37 AM
To: Jakarta Commons Developers List
Subject: Re: Project Proposal?

Out of interest, why java.net and not sandbox? :)

Before that sounds like a witch-hunt, I'm as guilty in that I start
all my stuff at osjava.org and I can definitely list some reasons why.

Some may be bad:
* Embaressment for dumb ideas :)
* Don't want to be weighed down by a weighty release system.
* Big painful website.
* Might compete with another Commons component.

Some may be good:
* Does the ASF want single-person codebases when an idea doesn't pan out.
* If it fails, I'd then be forking it elsewhere which feels worse than
just starting elsewhere.

What if we had a location within which ASF committers can bring their
half-cocked component ideas? Try to encourage migration to the ASF and
its benefits:

* bandwidth, though sf.net and java.net can solve that too. So can
building your own system to the level of Codehaus.
* legal protection.
* better user acceptance.
* community.

If we couple this with:

* much better management of the sandbox, and components that have failed.
* a plan for mature components.

could we pick things up in terms of vibrancy? My biggest worry would
be whether the mailing list becomes a bottleneck.

Half-baked idea (it's late): Each component has its own mail alias
which gets forwarded to particular lists. These lists could represent
the state of maturity of a component. Probably crap, just throwing it
out.

One question I'd like to ask is whether we would accept mature components. 

Take http://www.osjava.org/norbert/, HttpClient said they were
interested in using it and the thought was to put it in Commons. My
only concern is that I can't see a lot more to do with it code-wise,
so I'm hesitant to dump it in Commons, and yet I think it's a good
tiny component that could do with being more open.

Hen

On 8/4/05, James Carman [EMAIL PROTECTED] wrote:
 Well, I went ahead and started the project over at java.net, but we can
move
 it later if need be.  It's a dependency injection framework called
 syringe.  The project uses the Apache License, Version 2.0.  It's still
 pending approval at java.net, so you guys won't be able to see anything
 yet.  It should be approved soon though.

-
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: r230452 [3/3] - in /jakarta/commons/sandbox/exec/trunk: ./ src/ src/bin/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/commons/ src/main/java/org/apache/commons/exec/ src/main/java/org/apache...

[brett]

Added: 
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/VmsCommandLauncher.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/VmsCommandLauncher.java?rev=230452view=auto
==
--- 
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/VmsCommandLauncher.java
 (added)
+++ 
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/VmsCommandLauncher.java
 Fri Aug  5 05:21:46 2005
@@ -0,0 +1,91 @@
+package org.apache.commons.exec.launcher;
+
+import java.io.File;
+import java.io.FileWriter;
+import java.io.IOException;
+import java.io.PrintWriter;
+import java.util.Iterator;
+import java.util.Set;
+import java.util.Map.Entry;
+
+import org.apache.commons.exec.CommandLine;
+import org.apache.commons.exec.CommandLineImpl;
+import org.apache.commons.exec.environment.Environment;
+
+/**
+ * A command launcher for VMS that writes the command to a temporary DCL script
+ * before launching commands. This is due to limitations of both the DCL
+ * interpreter and the Java VM implementation.
+ */
+public class VmsCommandLauncher extends Java13CommandLauncher {
+
+public VmsCommandLauncher() throws NoSuchMethodException {
+super();
+}
+
+/**
+ * Launches the given command in a new process.
+ */
+public Process exec(final CommandLine cmd, final Environment env)
+throws IOException {
+CommandLine vmsCmd = new CommandLineImpl();
+vmsCmd.setExecutable(createCommandFile(cmd, env).getPath());
+
+return super.exec(vmsCmd, env);
+}
+
+/**
+ * Launches the given command in a new process, in the given working
+ * directory. Note that under Java 1.3.1, 1.4.0 and 1.4.1 on VMS this 
method
+ * only works if codeworkingDir/code is null or the logical
+ * JAVA$FORK_SUPPORT_CHDIR needs to be set to TRUE.
+ */
+public Process exec(final CommandLine cmd, final Environment env,
+final File workingDir) throws IOException {
+CommandLine vmsCmd = new CommandLineImpl();
+vmsCmd.setExecutable(createCommandFile(cmd, env).getPath());
+
+return super.exec(vmsCmd, env, workingDir);
+}
+
+/*
+ * Writes the command into a temporary DCL script and returns the
+ * corresponding File object. The script will be deleted on exit.
+ */
+private File createCommandFile(final CommandLine cmd, final Environment 
env)
+throws IOException {
+File script = File.createTempFile(ANT, .COM);
+script.deleteOnExit();
+PrintWriter out = null;
+try {
+out = new PrintWriter(new FileWriter(script));
+
+// add the environment as logicals to the DCL script
+if (env != null) {
+Set entries = env.entrySet();
+
+for (Iterator iter = entries.iterator(); iter.hasNext();) {
+Entry entry = (Entry) iter.next();
+out.print($ DEFINE/NOLOG );
+out.print(entry.getKey());
+out.print( \);
+out.print(entry.getValue());
+out.println('\');
+}
+}
+
+out.print($  + cmd.getExecutable());
+String[] args = cmd.getArguments();
+for (int i = 0; i  args.length; i++) {
+out.println( -);
+out.print(args[i]);
+}
+} finally {
+if (out != null) {
+out.close();
+}
+}
+return script;
+}
+
+}

Propchange: 
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/VmsCommandLauncher.java
--
svn:eol-style = native

Propchange: 
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/VmsCommandLauncher.java
--
svn:keywords = Author Date Id Revision

Added: 
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/WinNTCommandLauncher.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/WinNTCommandLauncher.java?rev=230452view=auto
==
--- 
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/WinNTCommandLauncher.java
 (added)
+++ 
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/launcher/WinNTCommandLauncher.java
 Fri Aug  5 05:21:46 2005
@@ -0,0 +1,51 @@
+package org.apache.commons.exec.launcher;
+
+import java.io.File;
+import java.io.IOException;
+
+import org.apache.commons.exec.CommandLine;

RE: Project Proposal?

[Stephen Colebourne]

While interesting, this would have caused issues in
commons. The commons charter explicitly avoids
frameworks, and this is definitely a framework.

Longer term though, with Spring, Hivemind and Pico
already in this space, and EJB3 making some moves
there must be a limit on having a new injection
framework. So, why not just improve Hivemind?

Stephen

--- James Carman [EMAIL PROTECTED] wrote:
 I guess I wanted a little more freedom/control over
 the project at this
 phase.  Also, I wasn't too sure about licensing
 issues with putting stuff in
 the codebase that depends upon code outside Apache
 (the build file
 automatically downloads its dependencies from
 Ibiblio).  
 
 It is early on right now, but I think there are some
 sound ideas there...
 
 1.  Proxy Factories - All proxies in Syringe are
 created using a proxy
 factory (an interface).  Using syringe, you never
 have to write the proxying
 logic code yourself anymore.  Furthermore, since
 it's abstracted out, it's
 easy to switch between (or mix and match for that
 matter) proxying
 strategies, simply by supplying a different
 implementation class.  I
 currently have implementations using JDK proxies and
 CGLIB.
 
 2.  Object Providers - Objects are provided to
 Syringe through
 ObjectProviders.  There are two different types of
 ObjectProviders now, core
 object providers and wrapper/decorator providers. 
 The core providers would
 be responsible for constructing/finding the actual
 implementation object.
 It might be a simple JavaBean, or it could be some
 sort of remote object
 (EJB, JAX-RPC, RMI, Burlap, etc.).  The
 wrapper/decorator providers
 supplement these core providers with additional
 functionality.  For example,
 in Syringe, all dependency injection is done using a
 decorator provider.
 So, it's easy for you to extend Syringe with your
 own providers and still
 support DI.  This has been somewhat of a problem in
 HiveMind.  All of the
 dependency injection logic is buried inside the
 BuilderFactory's
 implementation.  
 
 3.  Method Interceptors - Syringe only supports the
 MethodInterceptor
 interface (a proxy factory must know how to create a
 proxy which goes
 through a MethodInterceptor) from the AOP Alliance
 API.  Since this is
 somewhat of a standard API, I don't really see it
 as a limitation.  If we
 see the need to support other mechanisms, maybe we
 can provide adapter
 classes to bridge the gap.
 
 
 
 -Original Message-
 From: Henri Yandell [mailto:[EMAIL PROTECTED] 
 Sent: Friday, August 05, 2005 2:37 AM
 To: Jakarta Commons Developers List
 Subject: Re: Project Proposal?
 
 Out of interest, why java.net and not sandbox? :)
 
 Before that sounds like a witch-hunt, I'm as guilty
 in that I start
 all my stuff at osjava.org and I can definitely list
 some reasons why.
 
 Some may be bad:
 * Embaressment for dumb ideas :)
 * Don't want to be weighed down by a weighty release
 system.
 * Big painful website.
 * Might compete with another Commons component.
 
 Some may be good:
 * Does the ASF want single-person codebases when an
 idea doesn't pan out.
 * If it fails, I'd then be forking it elsewhere
 which feels worse than
 just starting elsewhere.
 
 What if we had a location within which ASF
 committers can bring their
 half-cocked component ideas? Try to encourage
 migration to the ASF and
 its benefits:
 
 * bandwidth, though sf.net and java.net can solve
 that too. So can
 building your own system to the level of Codehaus.
 * legal protection.
 * better user acceptance.
 * community.
 
 If we couple this with:
 
 * much better management of the sandbox, and
 components that have failed.
 * a plan for mature components.
 
 could we pick things up in terms of vibrancy? My
 biggest worry would
 be whether the mailing list becomes a bottleneck.
 
 Half-baked idea (it's late): Each component has its
 own mail alias
 which gets forwarded to particular lists. These
 lists could represent
 the state of maturity of a component. Probably crap,
 just throwing it
 out.
 
 One question I'd like to ask is whether we would
 accept mature components. 
 
 Take http://www.osjava.org/norbert/, HttpClient said
 they were
 interested in using it and the thought was to put it
 in Commons. My
 only concern is that I can't see a lot more to do
 with it code-wise,
 so I'm hesitant to dump it in Commons, and yet I
 think it's a good
 tiny component that could do with being more open.
 
 Hen
 
 On 8/4/05, James Carman [EMAIL PROTECTED]
 wrote:
  Well, I went ahead and started the project over at
 java.net, but we can
 move
  it later if need be.  It's a dependency injection
 framework called
  syringe.  The project uses the Apache License,
 Version 2.0.  It's still
  pending approval at java.net, so you guys won't
 be able to see anything
  yet.  It should be approved soon though.
 

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

svn commit: r230457 - in /jakarta/commons/sandbox/exec/trunk: pom.xml src/site/site.xml

[brett]

Author: brett
Date: Fri Aug  5 05:43:27 2005
New Revision: 230457

URL: http://svn.apache.org/viewcvs?rev=230457view=rev
Log:
add extra metadata

Modified:
jakarta/commons/sandbox/exec/trunk/pom.xml
jakarta/commons/sandbox/exec/trunk/src/site/site.xml

Modified: jakarta/commons/sandbox/exec/trunk/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/exec/trunk/pom.xml?rev=230457r1=230456r2=230457view=diff
==
--- jakarta/commons/sandbox/exec/trunk/pom.xml (original)
+++ jakarta/commons/sandbox/exec/trunk/pom.xml Fri Aug  5 05:43:27 2005
@@ -33,7 +33,23 @@
   emailniklas AT protocol7 DOT com/email
 /contributor
   /contributors
+  scm
+
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/sandbox/exec/trunk/connection
+
developerConnectionscm:svn:https://svn.apache.org/repos/asf/jakarta/commons/sandbox/exec/trunk/developerConnection
+
urlhttp://svn.apache.org/repos/asf/jakarta/commons/sandbox/exec/trunk/url
+  /scm
   !-- TODO: these will be moved to a commons parent eventually --
+  organization
+nameThe Apache Software Foundation/name
+urlhttp://jakarta.apache.org/url
+  /organization
+  licenses
+license
+  nameThe Apache Software License, Version 2.0/name
+  url/LICENSE.txt/url
+  distributionrepo/distribution
+/license
+  /licenses
   reporting
 plugins
   plugin
@@ -42,4 +58,42 @@
   /plugin
 /plugins
   /reporting
+  mailingLists
+mailingList
+  nameCommons Dev List/name
+  subscribe[EMAIL PROTECTED]/subscribe
+  unsubscribe[EMAIL PROTECTED]/unsubscribe
+  postcommons-dev@jakarta.apache.org/post
+  
archivehttp://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/archive
+/mailingList
+mailingList
+  nameCommons User List/name
+  subscribe[EMAIL PROTECTED]/subscribe
+  unsubscribe[EMAIL PROTECTED]/unsubscribe
+  postcommons-user@jakarta.apache.org/post
+  
archivehttp://mail-archives.apache.org/mod_mbox/jakarta-commons-user/archive
+/mailingList
+  /mailingLists
+  distributionManagement
+!-- No releases until out of sandbox, besides - m2 repo not up yet
+repository
+  idapache.releases/id
+  nameApache Release Repository/name
+  
urlscp://minotaur.apache.org/www/www.apache.org/dist/maven-repository/url
+/repository
+--
+!-- TODO: setup m2 repo in new layout --
+snapshotRepository
+  idapache.snapshots/id
+  nameApache Snapshot Repository/name
+  urlscp://minotaur.apache.org/www/cvs.apache.org/repository/url
+  layoutlegacy/layout
+/snapshotRepository
+site
+  idwebsite/id
+  nameApache Website/name
+  
urlscp://minotaur.apache.org/www/jakarta.apache.org/commons/sandbox/exec//url
+/site
+  /distributionManagement
 /project
+

Modified: jakarta/commons/sandbox/exec/trunk/src/site/site.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/exec/trunk/src/site/site.xml?rev=230457r1=230456r2=230457view=diff
==
--- jakarta/commons/sandbox/exec/trunk/src/site/site.xml (original)
+++ jakarta/commons/sandbox/exec/trunk/src/site/site.xml Fri Aug  5 05:43:27 
2005
@@ -1,6 +1,7 @@
 site
   bannerLeft
 nameJakarta Commons/name
+srchttp://jakarta.apache.org/images/jakarta-logo.gif/src
   /bannerLeft
   bannerRight
 namecommons-exec/name



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

Re: [slf4j-dev] Common Logging API

[Ceki Gülcü]

By convention, I use labels [N] a document references. The list of
references can be found at the end of this message.

Hello Joerg,

The jury is still out on the question of the ideal logging API. I do
not expect them (the jury) to make up their mind anytime soon. :-)

Niclas Hedman has been gently trying to convince us to add a
getChildLogger() method in the Logger interface [1] for quite some
time now. It is becoming increasingly clear that IoC frameworks yearn
for such functionality.

Version 1.0beta5 of SLF4J (not yet released) makes several important
enhancements to the Logger interface. You can find the javadocs for
beta5 at [2]. Please note that these javadocs a quite different than
the publicly advertised javadocs on the Documentation page [3].

If I understand correctly, you would like to see the following two
methods added to the org.slf4j.Logger interface:

  String getName()
  Logger getChildLogger(String)

The first method, namely getName(), sounds most legitimate. If the
developer retrieves loggers by name, it is only natural for those
loggers to have a name. The only exception is the NOPLogger
singleton. If SLF4J is bound to the NOP implementation, the logger
factory will always hand the user the same NOPLogger instance,
regardless of the name of the logger requested by her.

Thus, it seems quite reasonable to add the getName() method, with the
caveat that the name you get may be different than the name you asked
for. :-)

Your second request is both interesting and more problematic. You are
essentially asking for org.slf4j.Logger instances to have
manufacturing capability. As you are probably aware, manufacturing the
correct Logger instance of the correct type in every application
context is a very difficult problem. This is another area where IoC
frameworks lend a helping hand. If possible, I think it wiser for
SLF4J to decouple logging capability from manufacturing capability.

As you can see in SLF4J 1.0-beta5 [2], there is a clear separation
between org.slf4j.Logger and org.slf4j.ILoggerFactory
interfaces. Instances of the latter interface build instances of the
former. The LoggerFactory class wraps a particular instance of
ILoggerFactory (normally bound at compile time).

Wouldn't it be possible for your IoC framework to inject
ILoggerFactory instances instead of Logger instances to the component
being configured? More concretely, Niclas' MyClass/MyOtherClass
example in [1] can be modified to use the ILoggerFactory approach [4].

Do you see any disadvantages to the ILoggerFactory injection approach?
Alternatively, do you see any advantages?

In any case, I would like to thank you for taking the time to express
the requirements as seen from the point of view of a IOC developer.
Your input is most appreciated.

Cheers,

[1] http://www.slf4j.org/pipermail/dev/2005-May/49.html
[2] http://www.slf4j.org/api-1.0-beta5/
[3] http://www.slf4j.org/docs.html
[4] http://www.slf4j.org/pipermail/dev/2005-July/000212.html

At 09:32 PM 8/4/2005, Joerg Hohwiller wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

I am new to slf4j.
Actually I startet a thread called [logging] proposal
on commons-dev@jakarta.apache.org to discuss about an API extension
for commons-logging.
My major goal or vision about all of this is that we -the entire java
community- will have one API for a Logger. Basically I think that
commons logging is a good approach towards this but still after having
commons logging there are still a lot of projects inventing their own
logger API. Searching for the reason for that by discussing
with the people of those projects on their mailing lists gave me the
conclusion that the only point is that org.apache.commons.logging.Log is
missing an important feature: A method to create a child logger:
getChildLogger(String).
I am also one of these IoC Container guys thesedays and
so my suggestion was to add another interface called
org.apache.commons.logging.Logger that extends Log and adds the methods:

String getName()
Logger getChildLogger(String)

I posted a list of various open-source projects that invented thier own
logger interface that is pretty much the same as commons logging's Log
but has these two additional methods (maybe they have a slightly
different signature).

It seems that slf4j is different from those IoC frameworks and more like
  commons logging in the way that you also focus on the logging itself
and intend to be widely used for logging - if I guessed this right.

Now cross-posting on different mailing lists is not to easy. So we will
see how we will get a long. But I would love to see your points about
the true logging API. Unfortunately we do not have Smalltalk here but
JAVA so in the end we need an Interface in a concrete classpath
namespace. But hopefully a come together would be possible somehow.
I do not expect it to happen that the classpath will be
java.util.logging2.Logger :)
For me org.apache.commons.logging.Logger would be good enough and
since 

svn commit: r230459 - /jakarta/commons/sandbox/exec/trunk/pom.xml

[brett]

Author: brett
Date: Fri Aug  5 05:50:45 2005
New Revision: 230459

URL: http://svn.apache.org/viewcvs?rev=230459view=rev
Log:
fix artifactId

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

Modified: jakarta/commons/sandbox/exec/trunk/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/exec/trunk/pom.xml?rev=230459r1=230458r2=230459view=diff
==
--- jakarta/commons/sandbox/exec/trunk/pom.xml (original)
+++ jakarta/commons/sandbox/exec/trunk/pom.xml Fri Aug  5 05:50:45 2005
@@ -1,7 +1,7 @@
 project
   modelVersion4.0.0/modelVersion
   groupIdorg.apache.commons/groupId
-  artifactIdexec/artifactId
+  artifactIdcommons-exec/artifactId
   version1.0-SNAPSHOT/version
   nameCommons Exec/name
   urlhttp://jakarta.apache.org/commons/sandbox/exec//url



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

Re: [exec][patch] commons-exec initial contrib

[Brett Porter]

Kev Jackson wrote:

 I'm not a fan of maven, so I'll write up a quick build file for it,
 I'll also look into javadoc/unit tests as soon as I have some time
 (perhaps tomorrow)

I've autogenerated the Ant build script for you. You'll need m2 to do
the site at this point.

Niklas, I made a couple of small structural changes, fleshed out the
POM, and added a front page on the site:
http://jakarta.apache.org/commons/sandbox/exec/

Pushed up build #1:
http://cvs.apache.org/repository/org.apache.commons/jars/

Ok, I'll take a closer look and provide more feedback.

Thanks!

- Brett


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

svn commit: r230460 - /jakarta/commons/sandbox/exec/trunk/pom.xml

[brett]

Author: brett
Date: Fri Aug  5 06:00:47 2005
New Revision: 230460

URL: http://svn.apache.org/viewcvs?rev=230460view=rev
Log:
add bugzilla. We'll use the Sandbox component, with a prefix of [exec]

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

Modified: jakarta/commons/sandbox/exec/trunk/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/exec/trunk/pom.xml?rev=230460r1=230459r2=230460view=diff
==
--- jakarta/commons/sandbox/exec/trunk/pom.xml (original)
+++ jakarta/commons/sandbox/exec/trunk/pom.xml Fri Aug  5 06:00:47 2005
@@ -95,5 +95,9 @@
   
urlscp://minotaur.apache.org/www/jakarta.apache.org/commons/sandbox/exec//url
 /site
   /distributionManagement
+  issueManagement
+systembugzilla/system
+urlhttp://issues.apache.org/bugzilla//url
+  /issueManagement
 /project
 



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

DO NOT REPLY [Bug 36041] New: - Include class loader information when LogFactoryImpl throws LogConfigurationException.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36041.
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=36041

   Summary: Include class loader information when LogFactoryImpl
throws LogConfigurationException.
   Product: Commons
   Version: 1.0.4
  Platform: Other
OS/Version: other
Status: NEW
  Keywords: ErrorMessage
  Severity: enhancement
  Priority: P2
 Component: Logging
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


LogFactoryImpl#getLogConstructor throws a LogConfigurationException when the
same class is detected in multiple class loaders. The error message is as 
follows:

Invalid class loader hierarchy. You have more than one version of class-name
visible, which is not allowed.

We could improve the usefulness of the error message by including classloader
details such as ClassLoader#getClass, etc. It would greatly reduce the time
spent hunting down multiple copies of Commons Logging (which can frequently
occur when deploying to application servers such as JBoss and WebLogic, as they
often have a version of Commons Logging stowed away in their own class path).

-- 
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: [exec][patch] commons-exec initial contrib

[Niklas Gustavsson]

Brett Porter wrote:

Niklas, I made a couple of small structural changes, fleshed out the
POM, and added a front page on the site:
http://jakarta.apache.org/commons/sandbox/exec/


Yeah, the POM was a bit... limited :-)

Excellent, I'll sync up right away so that I can get going on the 
development.


/niklas

--
Niklas Gustavsson
[EMAIL PROTECTED]
http://www.protocol7.com


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

RE: Project Proposal?

[James Carman]

The Syringe API lends itself to setting things up with code.  The HiveMind
API wasn't really meant for that.  It was written with the hivemodule.xml
file syntax in mind and with everybody chanting less XML is good, we've
had some folks requesting a more API-based approach.  So, you're right,
Siringe is indeed a framework, but it's a lower-level framework.  Something
like HiveMind would sit on top of syringe (as painful as that may sound).  I
would like, someday, to port HiveMind to use the Syringe API underneath, but
that would be quite an undertaking and there are quite a few folks out there
already using HiveMind (anyone using the newest Tapestry, for example).  I
wanted to start something fresh with no limitations of backward
compatibility and see what I came up with.  Hopefully folks with think that
Syringe is easy to use/extend.  I'm working on an example application right
now to see how really easy it is (eat my own dog food).  Hopefully the
example will serve as documentation and an opportunity to figure out how to
make Syringe that much more usable.

Since it is a framework, would I have to submit a Jakarta PMC TLP
Application if I wanted to eventually move this project to Apache?  Is
there no real incubator inside Jakarta for projects such as this?  Sounds
like I may have chosen the right place for this project for now.


-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 05, 2005 8:39 AM
To: Jakarta Commons Developers List
Subject: RE: Project Proposal?

While interesting, this would have caused issues in
commons. The commons charter explicitly avoids
frameworks, and this is definitely a framework.

Longer term though, with Spring, Hivemind and Pico
already in this space, and EJB3 making some moves
there must be a limit on having a new injection
framework. So, why not just improve Hivemind?

Stephen

--- James Carman [EMAIL PROTECTED] wrote:
 I guess I wanted a little more freedom/control over
 the project at this
 phase.  Also, I wasn't too sure about licensing
 issues with putting stuff in
 the codebase that depends upon code outside Apache
 (the build file
 automatically downloads its dependencies from
 Ibiblio).  
 
 It is early on right now, but I think there are some
 sound ideas there...
 
 1.  Proxy Factories - All proxies in Syringe are
 created using a proxy
 factory (an interface).  Using syringe, you never
 have to write the proxying
 logic code yourself anymore.  Furthermore, since
 it's abstracted out, it's
 easy to switch between (or mix and match for that
 matter) proxying
 strategies, simply by supplying a different
 implementation class.  I
 currently have implementations using JDK proxies and
 CGLIB.
 
 2.  Object Providers - Objects are provided to
 Syringe through
 ObjectProviders.  There are two different types of
 ObjectProviders now, core
 object providers and wrapper/decorator providers. 
 The core providers would
 be responsible for constructing/finding the actual
 implementation object.
 It might be a simple JavaBean, or it could be some
 sort of remote object
 (EJB, JAX-RPC, RMI, Burlap, etc.).  The
 wrapper/decorator providers
 supplement these core providers with additional
 functionality.  For example,
 in Syringe, all dependency injection is done using a
 decorator provider.
 So, it's easy for you to extend Syringe with your
 own providers and still
 support DI.  This has been somewhat of a problem in
 HiveMind.  All of the
 dependency injection logic is buried inside the
 BuilderFactory's
 implementation.  
 
 3.  Method Interceptors - Syringe only supports the
 MethodInterceptor
 interface (a proxy factory must know how to create a
 proxy which goes
 through a MethodInterceptor) from the AOP Alliance
 API.  Since this is
 somewhat of a standard API, I don't really see it
 as a limitation.  If we
 see the need to support other mechanisms, maybe we
 can provide adapter
 classes to bridge the gap.
 
 
 
 -Original Message-
 From: Henri Yandell [mailto:[EMAIL PROTECTED] 
 Sent: Friday, August 05, 2005 2:37 AM
 To: Jakarta Commons Developers List
 Subject: Re: Project Proposal?
 
 Out of interest, why java.net and not sandbox? :)
 
 Before that sounds like a witch-hunt, I'm as guilty
 in that I start
 all my stuff at osjava.org and I can definitely list
 some reasons why.
 
 Some may be bad:
 * Embaressment for dumb ideas :)
 * Don't want to be weighed down by a weighty release
 system.
 * Big painful website.
 * Might compete with another Commons component.
 
 Some may be good:
 * Does the ASF want single-person codebases when an
 idea doesn't pan out.
 * If it fails, I'd then be forking it elsewhere
 which feels worse than
 just starting elsewhere.
 
 What if we had a location within which ASF
 committers can bring their
 half-cocked component ideas? Try to encourage
 migration to the ASF and
 its benefits:
 
 * bandwidth, though sf.net and java.net can solve
 that too. So can
 building your own system to the 

Re: Project Proposal?

[Henri Yandell]

On 8/5/05, James Carman [EMAIL PROTECTED] wrote:
 
 Since it is a framework, would I have to submit a Jakarta PMC TLP
 Application if I wanted to eventually move this project to Apache?  Is
 there no real incubator inside Jakarta for projects such as this?  Sounds
 like I may have chosen the right place for this project for now.

I agree, we lack a Jakarta Sandbox.

Could the Commons Sandbox enlarge its scope to cover all of Jakarta?

Hen

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

Re: Project Proposal?

[Brett Porter]

I thought the established process was to use the incubator, promoting to
Jakarta when community strength and diversity was clear. This is what
recently happened with Derby to DB, for example.

- Brett

Henri Yandell wrote:

On 8/5/05, James Carman [EMAIL PROTECTED] wrote:
  

Since it is a framework, would I have to submit a Jakarta PMC TLP
Application if I wanted to eventually move this project to Apache?  Is
there no real incubator inside Jakarta for projects such as this?  Sounds
like I may have chosen the right place for this project for now.



I agree, we lack a Jakarta Sandbox.

Could the Commons Sandbox enlarge its scope to cover all of Jakarta?

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 36047] New: - vfs services

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36047.
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=36047

   Summary: vfs services
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: VFS
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The framework for vfs services and the implementation of svn services

-- 
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 36047] - vfs services

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36047.
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=36047





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 17:45 ---
Created an attachment (id=15911)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15911action=view)
Diff file for services. has been made for trunk revision 230471


-- 
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 36047] - vfs services

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36047.
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=36047





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 17:47 ---
Created an attachment (id=15912)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15912action=view)
vfs services packages


-- 
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: Project Proposal?

[Henri Yandell]

On 8/5/05, Brett Porter [EMAIL PROTECTED] wrote:
 I thought the established process was to use the incubator, promoting to
 Jakarta when community strength and diversity was clear. This is what
 recently happened with Derby to DB, for example.
 
 - Brett

That's for projects external to Apache.

Are we saying that if 1, 2 or 3 ASF committers have an idea, they
should either develop it externally or work through the incubator
before creating it?

Hen

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

DO NOT REPLY [Bug 36050] New: - [daemon] does not compile under cygwin

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36050.
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=36050

   Summary: [daemon] does not compile under cygwin
   Product: Commons
   Version: 1.0.1 Final
  Platform: PC
OS/Version: other
Status: NEW
  Keywords: PatchAvailable
  Severity: normal
  Priority: P2
 Component: Daemon
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


A comment is not terminated properly so instmain.c does not compile. 
Some functions are not called with the correct arguments leading to compiler
warnings.

-- 
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 36050] - [daemon] does not compile under cygwin

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36050.
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=36050





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 18:51 ---
Created an attachment (id=15913)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15913action=view)
Terminates a comment properly so the code compiles


-- 
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 36050] - [daemon] does not compile under cygwin

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36050.
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=36050





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 18:53 ---
Created an attachment (id=15914)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15914action=view)
corrects return values of callback functions so they match proper prototype


-- 
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 36050] - [daemon] does not compile under cygwin

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36050.
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=36050





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 18:54 ---
Created an attachment (id=15915)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15915action=view)
makes a variable const to fix a gcc warning


-- 
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: [exec][patch] commons-exec initial contrib

[Niklas Gustavsson]

Kev Jackson wrote:
I'm not a fan of maven, so I'll write up a quick build file for it, I'll 
also look into javadoc/unit tests as soon as I have some time (perhaps 
tomorrow)


Great! With regards for the unit tests I personally think that the first 
step should be to refactor the launcher so that they do not directly 
call Runtime.exec(). That currently makes unit testing hard.


/niklas

--
Niklas Gustavsson
[EMAIL PROTECTED]
http://www.protocol7.com


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

DO NOT REPLY [Bug 36051] New: - procname argument is not accepted

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36051.
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=36051

   Summary: procname argument is not accepted
   Product: Commons
   Version: 1.0.1 Final
  Platform: Other
OS/Version: other
Status: NEW
  Keywords: PatchAvailable
  Severity: normal
  Priority: P2
 Component: Daemon
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The -procname argument is designed to allow the process name to be specified on
linux. 

Unfortunately running jsvc -procname xxx results in an Invalid option -procname
warning.

Parsing of the procname argument must occur before the code looks for invalid
arguments, rather than afterwards.

-- 
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 36051] - [daemon] procname argument is not accepted

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36051.
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=36051


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|procname argument is not|[daemon] procname argument
   |accepted|is not accepted




-- 
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 36051] - [daemon] procname argument is not accepted

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36051.
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=36051





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 19:03 ---
Created an attachment (id=15916)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15916action=view)
moves processing of procname argument to occur before invalid argument checking


-- 
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: [slf4j-dev] Common Logging API

[Niclas Hedhman]

On Friday 05 August 2005 19:44, Ceki Gülcü wrote:
 Do you see any disadvantages to the ILoggerFactory injection approach?

It is ugly, and not the norm so far. Components are generally not expected to 
do fabrication, and in the IoC folks view, getChildLogger() is not a 
fabrication, just plain retrieval of something that exists.

 Alternatively, do you see any advantages?

Without checking classloading issues, possibly passing the Logger instance to 
the ILoggerFactory for the creation of a child logger is reasonable. (and not 
that ugly).
One could possibly define a separator for hierarchies, and just go by a 
logger.getName() + Logger.sep + child...


What I am about to say now has been up and about several times, I think.
Why not sponsor more than a single approach under the same umbrella ?
There are several ways to do it, but I think a better IoC support solution is 
desirable, yet without distracting other users.

1. Introduce a IoCLogger interface, and we discuss that with IoC peeps 
thoroughly, i.e. Spring, Pico, HiveMind and possibly Geronimo.

2. If possible, see if there is something that can be done at Factory level to 
allow frameworks to provide implementations that can make the bridge between 
normal and IoC codebases, so that the output is within comprehension.

3. Document the required behaviour when normal Loggers are used in IoC enabled 
frameworks.


AND this issue is more complex now, when Markers has been introduced, as I 
have personally not evaluated the new possibilities this can introduce.



Cheers
Niclas


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

DO NOT REPLY [Bug 36052] New: - Improve documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36052.
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=36052

   Summary: Improve documentation
   Product: Commons
   Version: 1.0.1 Final
  Platform: Other
OS/Version: other
Status: NEW
  Keywords: PatchAvailable
  Severity: minor
  Priority: P2
 Component: Daemon
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


daemon documentation has a number of spelling mistakes and grammatical errors. 
The -procname argument to jsvc is not documented.

-- 
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 36052] - [daemon] Improve documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36052.
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=36052


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Improve documentation   |[daemon] Improve
   ||documentation




-- 
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 36052] - [daemon] Improve documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36052.
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=36052





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 20:29 ---
Created an attachment (id=15918)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15918action=view)
correct main README spelling


-- 
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 36052] - [daemon] Improve documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36052.
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=36052





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 20:32 ---
Created an attachment (id=15919)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15919action=view)
correct grammar


-- 
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 36052] - [daemon] Improve documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36052.
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=36052





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 20:33 ---
Created an attachment (id=15920)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15920action=view)
correct grammar and spelling and document -procname


-- 
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 36052] - [daemon] Improve documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36052.
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=36052





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 20:34 ---
Created an attachment (id=15921)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15921action=view)
correct grammar


-- 
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 36052] - [daemon] Improve documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36052.
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=36052





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 20:36 ---
Created an attachment (id=15922)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15922action=view)
correct grammar and improve readability somewhat


-- 
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 36030] - [daemon] invalid execve() usage

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36030.
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=36030





--- Additional Comments From [EMAIL PROTECTED]  2005-08-05 20:44 ---
You could try

jsvc -procname /usr/bin/jsvc 

although I think you will need to apply patch 36051.

-- 
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 35955] - [collections] Change CollectionUtils.forAllDo to return the Closure

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35955.
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=35955


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-08-06 00:24 ---
I agree with James. Backwards compatability and casting rule this one out.

-- 
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 35955] - [collections] Change CollectionUtils.forAllDo to return the Closure

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35955.
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=35955


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |




--- Additional Comments From [EMAIL PROTECTED]  2005-08-06 00:53 ---
You're right. It should have been:

public BigDecimal getTotal() {
return ((SumTotalClosure)CollectionUtils.forAllDo(lineItems, new
SumTotalClosure())).total();
}

I still like that better. Or I could do (one possible variation):

public BigDecimal getTotal() {
return ((SumTotalClosure)sumItemTotals()).total();
}

private Closure sumItemTotals() {
return CollectionUtils.forAllDo(lineItems, new SumTotalClosure());
}

I don't see how backward compatibility and casting concerns rule this out.
There is no backward compatibility problem -- forAllDo was previously void and
now it returns a value. Casting is my (the client's) problem, not a concern of
the collections package.

Jim

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

[Jakarta-commons Wiki] Update of Logging/UndeployMemoryLeak by SimonKitching

[Apache Wiki]

Dear Wiki user,

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

The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak

The comment on the change is:
Add note about java.beans.Introspector

--
  that are visible to the component is the most obvious example. This causes no 
problems for garbage-collecting of the component. 
  Problems come when the links become ''bidirectional'', and classes within the 
container also have references to classes and objects within
  the components. The servlet and j2ee frameworks are carefully designed to 
avoid this where possible; where that is unavoidable
- the container *knows* about those situations and ensures the necessary 
references are cleared when a component is undeployed [1]
+ the container *knows* about those situations and ensures the necessary 
references are cleared when a component is undeployed [1] [2]
  
  But if users of the container start tossing libraries that aren't designed to 
avoid such references into classloaders that
  are above the classloader of the component and the container does not know 
about these libraries then bidirectional
@@ -48, +48 @@

  
  [1] Except for the brain-dead design of JDBC where jdbc drivers loaded via a 
custom classloader apparently
  get stored in a map within java.sql.!DriverManager thereby causing cyclic 
references to that classloader.
+ 
+ [2] And except for the cache of classes held by the java.beans.Introspector 
class. In at least some versions
+ of java, introspecting a class loaded by component's classloader causes a 
strong reference to that class to be put
+ into a global cache. This means that the component's classloader is then 
prevented from being unloaded. A
+ workaround is to call java.beans.Introspector.flushCaches() when the 
component is unloaded. Some containers
+ may do this automatically; Apache Tomcat 5.x certainly does. In other cases, 
a !ServletContextListener may need
+ to be registered to force this to be done.
  
  == Container libs are responsible for managing themselves ==
  
@@ -148, +155 @@

  model by keeping component libs inside the component will mean this problem 
never
  occurs.
  
- == Comment's by Ceki Gulcu ==
+ == Comments by Ceki Gulcu ==
  
  Simon, I've enjoyed reading your article. Cognizant of the memory leak
  problem you mention, the version of log4j which is currently CVS HEAD,

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

svn commit: r230513 - in /jakarta/commons/proper/collections/trunk: ./ src/java/org/apache/commons/collections/ src/test/org/apache/commons/collections/

[scolebourne]

Author: scolebourne
Date: Fri Aug  5 16:07:00 2005
New Revision: 230513

URL: http://svn.apache.org/viewcvs?rev=230513view=rev
Log:
CollectionUtils/MapUtils.isEmpty/isNotEmpty - Null-safe checks of collection 
emptyness

bug 35890, from Stephen Smith

CollectionUtils.sizeIsEmpty - Checks if a collection, array, map, iterator or 
enumeration is empty

Modified:
jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
jakarta/commons/proper/collections/trunk/project.xml

jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/CollectionUtils.java

jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/MapUtils.java

jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestCollectionUtils.java

jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestMapUtils.java

Modified: jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html?rev=230513r1=230512r2=230513view=diff
==
--- jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html (original)
+++ jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html Fri Aug  5 
16:07:00 2005
@@ -64,8 +64,10 @@
 ul
 liCollectionUtils.addIgnoreNull - Adds to the collection if the value being 
added is not null [30020]/li
 liMapUtils.putAll - Puts an array of key/value pairs into a map [30882]/li
-liExtendedProperties - No longer uses an exception in normal processing 
[30497]/li
+liCollectionUtils/MapUtils.isEmpty/isNotEmpty - Null-safe checks of 
collection emptyness [35890]/li
+liCollectionUtils.sizeIsEmpty - Checks if a collection, array, map, iterator 
or enumeration is empty/li
 liCollectionUtils/ListUtils - retainAll/removeAll that don't change original 
colllection/li
+liExtendedProperties - No longer uses an exception in normal processing 
[30497]/li
 liBlockingBuffer - now includes stack trace if InterupttedException occurs 
[33700]/li
 liBlockingBuffer - new methods that allow get and remove with a timeout 
[27691]/li
 liTransformed*Map - new factory decorateTransform() that transforms any 
existing entries in the map [30959]/li

Modified: jakarta/commons/proper/collections/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/project.xml?rev=230513r1=230512r2=230513view=diff
==
--- jakarta/commons/proper/collections/trunk/project.xml (original)
+++ jakarta/commons/proper/collections/trunk/project.xml Fri Aug  5 16:07:00 
2005
@@ -316,6 +316,9 @@
   nameMichael Smith/name
 /contributor
 contributor
+  nameStephen Smith/name
+/contributor
+contributor
   nameJan Sorensen/name
 /contributor
 contributor

Modified: 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/CollectionUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/CollectionUtils.java?rev=230513r1=230512r2=230513view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/CollectionUtils.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/CollectionUtils.java
 Fri Aug  5 16:07:00 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 2001-2004 The Apache Software Foundation
+ *  Copyright 2001-2005 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.
@@ -52,6 +52,7 @@
  * @author Steven Melzer
  * @author Jon Schewe
  * @author Neil O'Toole
+ * @author Stephen Smith
  */
 public class CollectionUtils {
 
@@ -920,6 +921,76 @@
 return total;
 }
 
+/**
+ * Checks if the specified collection/array/iterator is empty.
+ * p
+ * This method can handles objects as follows
+ * ul
+ * liCollection - via collection isEmpty
+ * liMap - via map isEmpty
+ * liArray - using array size
+ * liIterator - via hasNext
+ * liEnumeration - via hasMoreElements
+ * /ul
+ * p
+ * Note: This method is named to avoid clashing with
+ * [EMAIL PROTECTED] #isEmpty(Collection)}.
+ * 
+ * @param object  the object to get the size of, not null
+ * @return true if empty
+ * @throws IllegalArgumentException thrown if object is not recognised or 
null
+ * @since Commons Collections 3.2
+ */
+public static boolean sizeIsEmpty(Object object) {
+if (object instanceof Collection) {
+return ((Collection) object).isEmpty();
+} else if (object instanceof Map) {
+return ((Map) 

DO NOT REPLY [Bug 35890] - [collections] Implement null-safe CollectionUtils#isEmpty(Collection) and CollectionUtils#isNotEmpty(Collection) methods.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35890.
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=35890


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-08-06 01:07 ---
Code added to CollectionUtils and MapUtils to cover these cases.

thanks

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

[Jakarta-commons Wiki] Update of Logging/FrequentlyAskedQuestions by SimonKitching

[Apache Wiki]

Dear Wiki user,

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

The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions

The comment on the change is:
Added info about java.beans.Introspector

--
  ClassLoader contextClassLoader = 
Thread.currentThread().getContextClassLoader();
  LogFactory.release(contextClassLoader);
  
- // optionally, clean up the underlying concrete logging library too
+ // Optionally, clean up the underlying concrete logging library too. This 
might
+ // require direct calls to methods on library-specific methods. 
+ 
+ // And optionally call java.beans.Introspector.flushCaches if your app 
does any
+ // bean introspection and your container doesn't flush the caches for you 
on
+ // servlet undeploy. Note that this isn't a commons-logging problem; it's 
something
+ // quite unrelated which can also cause memory leaks on undeploy.
}
  }
  }}}
  
  The deployment descriptor for the webapp then needs to be updated to specify 
that the above class should receive context change callbacks.
  
- You can find more information on this topic 
[wiki:Self:Logging/UndeployMemoryLeak here]
+ You can find more information on this topic 
[wiki:Self:Logging/UndeployMemoryLeak here]. 
  
  
  

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

DO NOT REPLY [Bug 23680] - [collections] Collections Javadoc warnings with JDK 1.4.2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23680.
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=23680


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|VERIFIED|CLOSED




-- 
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 35955] - [collections] Change CollectionUtils.forAllDo to return the Closure

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35955.
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=35955


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-08-06 01:13 ---
Changing a method return signature is a binary incompatible change, as we know
to our great cost in [collections]. See
http://eclipse.org/eclipse/development/java-api-evolution.html

Thus, to change this would require adding another method alongside the original
with a different name, something which just isn't justified.

Sorry if this seems harsh, but there's no point getting your hopes up on this 
one.

-- 
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: [exec] Design of commons-exec

[Niklas Gustavsson]

Hi Jerome

Thanks for a lot of really good feedback and ideas! I will come back to 
some of the other stuff later on, but first I think we need to discuss 
on of the points you bring up:


jerome lacoste wrote:

* run on the oldest SDK possible


I think there are three ways to go:
1. Full support for 1.1+
2. Limited support for 1.1-1.2, full support for 1.3+
3. No support for 1.1-1.2, full support 1.3+

Runtime.exec(String[] cmd, String[] env, File workingDir) was added in 
1.3. A lot of the Ant trickery going on the the current code is to 
handle working directories on older (pre 1.3) JVMs. This include most of 
the CommandLaunchers and the shell/Perl scripts.


The middle road would be to only support execution in the current 
directory only on 1.1.


So, what do you all think? I'm personally lucky enough to mostly be on
1.3 and 1.4 these days, but I'm fine with either choice here. If you 
think we should aim for 1.1, I would prefer option 2 to ease our pains a 
little bit. If we make the CommandLaunchers pluggable (and I think we 
should), someone who would really need working directory support on 1.1 
could potentially write their own CommandLauncher.


/niklas

--
Niklas Gustavsson
[EMAIL PROTECTED]
http://www.protocol7.com


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

Re: [exec] Design of commons-exec

[Trygve Laugstøl]

On Sat, Aug 06, 2005 at 01:18:08AM +0200, Niklas Gustavsson wrote:
 Hi Jerome
 
 Thanks for a lot of really good feedback and ideas! I will come back to 
 some of the other stuff later on, but first I think we need to discuss 
 on of the points you bring up:
 
 jerome lacoste wrote:
 * run on the oldest SDK possible
 
 I think there are three ways to go:
 1. Full support for 1.1+
 2. Limited support for 1.1-1.2, full support for 1.3+
 3. No support for 1.1-1.2, full support 1.3+
 
 Runtime.exec(String[] cmd, String[] env, File workingDir) was added in 
 1.3. A lot of the Ant trickery going on the the current code is to 
 handle working directories on older (pre 1.3) JVMs. This include most of 
 the CommandLaunchers and the shell/Perl scripts.
 
 The middle road would be to only support execution in the current 
 directory only on 1.1.
 
 So, what do you all think? I'm personally lucky enough to mostly be on
 1.3 and 1.4 these days, but I'm fine with either choice here. If you 
 think we should aim for 1.1, I would prefer option 2 to ease our pains a 
 little bit. If we make the CommandLaunchers pluggable (and I think we 
 should), someone who would really need working directory support on 1.1 
 could potentially write their own CommandLauncher.

I really see no need to support anything below 1.3. Even 1.3 support is
not something that I would put very much effort into.

--
Trygve


signature.asc
Description: Digital signature

Re: [exec] Design of commons-exec

[Brett Porter]

2 or 3 for me. Sun no longer support them, and I don't think anyone
would be developing new code for them. I don't think commons-exec would
be an important thing to have running on the MS VM :)

- Brett

Niklas Gustavsson wrote:

 Hi Jerome

 Thanks for a lot of really good feedback and ideas! I will come back
 to some of the other stuff later on, but first I think we need to
 discuss on of the points you bring up:

 jerome lacoste wrote:

 * run on the oldest SDK possible


 I think there are three ways to go:
 1. Full support for 1.1+
 2. Limited support for 1.1-1.2, full support for 1.3+
 3. No support for 1.1-1.2, full support 1.3+

 Runtime.exec(String[] cmd, String[] env, File workingDir) was added in
 1.3. A lot of the Ant trickery going on the the current code is to
 handle working directories on older (pre 1.3) JVMs. This include most
 of the CommandLaunchers and the shell/Perl scripts.

 The middle road would be to only support execution in the current
 directory only on 1.1.

 So, what do you all think? I'm personally lucky enough to mostly be on
 1.3 and 1.4 these days, but I'm fine with either choice here. If you
 think we should aim for 1.1, I would prefer option 2 to ease our pains
 a little bit. If we make the CommandLaunchers pluggable (and I think
 we should), someone who would really need working directory support on
 1.1 could potentially write their own CommandLauncher.

 /niklas

 --
 Niklas Gustavsson
 [EMAIL PROTECTED]
 http://www.protocol7.com


 -
 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 35955] - [collections] Change CollectionUtils.forAllDo to return the Closure

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35955.
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=35955





--- Additional Comments From [EMAIL PROTECTED]  2005-08-06 05:36 ---
(In reply to comment #4)
 Changing a method return signature is a binary incompatible change, as we know
 to our great cost in [collections].

I understand. I read enough of the linked document to get a feel for the fear
that has begun to grip the open source community as a result of its own success.
Really is too bad seeing as this position calcifies even the worst design
decisions and prevents the further evolution of otherwise useful software.

Regards,
Jim


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

[Jakarta-commons Wiki] Update of Digester/FAQ by SimonKitching

[Apache Wiki]

Dear Wiki user,

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

The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Digester/FAQ

The comment on the change is:
Fix incorrect info about all Rule classes being stateless.

--
  A much cleaner solution is simply to create a new Digester instance for each 
XML
  document parsed. If you are concerned about performance then you might want 
to 
  create a !RulesBase object, add rule instances to it, then reuse that object 
but 
- create a separate Digester object each time. Unlike the Digester class, the 
Rule
- and !RulesBase classes are not supposed to be modified by the parsing, ie are 
- stateless with respect to the sax parsing stage and so are pretty safe to 
reuse.
+ create a separate Digester object each time. Re-using rule instances can be
+ unsafe, however. The majority of Rule classes are stateless, but some are not.
+ Of the ones that do retain state, they are ''probably'' safe to reuse if the
+ parse was successful. When an error occurred during a digester parse, however,
+ these rules may well have internal state that will cause them to work 
incorrectly
+ on a future parse. Sorry, there is no list indicating which Rule classes are
+ stateless and which are not; you'll have to look at the source code for each
+ Rule class to figure that out.
  
  You can also create a parser object and pass it to the digester constructor, 
to 
  save having to instantiate a new parser object when new Digester objects are

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

DO NOT REPLY [Bug 35955] - [collections] Change CollectionUtils.forAllDo to return the Closure

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35955.
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=35955





--- Additional Comments From [EMAIL PROTECTED]  2005-08-06 06:33 ---
I don't know that I would go so far as to classify this particular method's
signature as one of worst design decisions and not consider Commons
Collections as otherwise useless software (I don't know if your statement was
aimed at this particular case or this particular instance).  I would agree,
though, that backward compatibility does seem to be a pain at times.  However, I
think I've solved your problem.  To make your code a little more palatable, why
don't you write your own helper method in some class...

public static Closure forAllDo( Collection col, Closure closure )
{
  CollectionUtils.forAllDo( col, closure );
  retur closure;
}

You could even make it use generics, if you wish.

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