date:20060304

On 3/4/06, James Carman [EMAIL PROTECTED] wrote:
 Wouldn't this class be better named, PoolUtils?

Yea probably, unlike the Collections class the word util doesn't
exist in the full class name. I'll rename it shortly.

--
Sandy McArthur

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

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

Re: svn commit: r383042 - in /jakarta/commons/proper/pool/trunk/src: java/org/apache/commons/pool/Pools.java test/org/apache/commons/pool/TestPools.java


yes, XxxUtils is the commons standard.
Stephen

James Carman wrote:

Wouldn't this class be better named, PoolUtils?


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Saturday, March 04, 2006 12:42 AM

To: [EMAIL PROTECTED]
Subject: svn commit: r383042 - in /jakarta/commons/proper/pool/trunk/src:
java/org/apache/commons/pool/Pools.java
test/org/apache/commons/pool/TestPools.java


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

Re: Problems...

On 3/3/06, Henri Yandell [EMAIL PROTECTED] wrote:
 Taking a step backwards. What are the current problems besetting
 Commons? I'm probably getting ahead on myself on trying to organize
 solutions without consensus on problems.

 We have an inactivity issue, and reflecting that inactivity to the
 users. To solve the latter we've added the dormant concept to the
 Sandbox, and need to do something similar to the main projects.
 Jakarta as a whole has these problems and I'm looking to Commons for
 the solutions. On the former, we've given ourselves a mental wake up
 to get people involved, patching and committing.

snip/

For starters:

 * Do we need a volunteer to call a vote for [latka], move it to
dormant if vote passes etc.?

 * We should do the same for [el]. JSP = 2.1 seems like it will be on
a separate el track for Tomcat, its biggest beneficiary, so probably
sensible to move it to dormant too.

 * Seems there is interest in pulling [modeler] under Tomcat,
post-TLP, so what do we need to do to encourage that? ;-)


 We've got an experimental m2 build in the sandbox, and a couple of
 components which don't have an m1 build. How independent do we want
 components to be. I'm thinking less independent because I want to
 maximise the ease with which people can move between components (to
 deal with inactivity), but the community might want to go the other
 way and be far more bazaar like.

snap/

IMO, until any further consensus, *all* {proper,sandbox} components
should have a {m102,xdoc192} build. Anyone is welcome to make progress
on the m2 side if they wish, but not having a m102 build just makes
those components unavailable for anyone who doesn't want to deal
with m2 yet.


 We have releases going out without our awareness. The commons-cli
 issue to the maven repository a while back; Jakarta had a similar one
 with velocity-dvsl. That's a general Apache problem that I'm
 suggesting solutions to on repository@ and letting what I'm saying
 here be affected by that (which probably makes me seem more illogical
 than usual) - this is one of the reasons why I'm in favour of a
 general Apache solution to group-ids.

snip/

Your suggestions on repository@ seem well thought-out, but I see both
sides of the groupId issue -- while it will make repo management
easier, Maven folks don't necessary seem to care, there is the added
element of confusion to users by the injection of jakarta in the mix
-- *sigh*.


 We have a sprawling site that could be much better - though this is
 entirely my opinion.

snap/

This is the least of my concerns. Like Martin, I don't have any
trouble with the site, I stick to the book. But unlike Martin, I've
built quite a few sites lately (ofcourse, there may still be some
sites that are troublesome, it will be nice to know what the exact
issues are -- apart from not heeding the correct versions of
maven/plugins to build).


 We have a very noisy set of mailing lists. Need to ask how the Jive
 forum is going for Struts (I think I heard that was in place?).
 Watching how the Maven-dev move to separate lists for commits, jira,
 dev, ci goes.

snip/

Personally, not a concern, I like it this way. Again, perhaps
articulate how and what noise bothers you? I don't use forums, posts
from them tend to become noise to me (things such as loss of
formatting, loss of appropriate history before posting bother me).
Ofcourse, anyone can use whatever tools makes them most productive
(one of the key arguments for forums I've heard), likewise recipients
reserve the right to only read email that they find readable.


 We have a need to organize our CI. Apparantly the hold up there is
 twofold:  1) issues over a general build server, or whether it should
 be individual pmcs  2) the zones machine is busy cpu wise and Infra
 don't want us to have a Commons zone that builds a lot just yet.

 The PMC Chair is casting random solutions to Jakarta's oversight and
 community issues and suggesting Commons can absorb Jakarta (apart from
 the bits that leave) as a solution.

snip/

Commons or Web Components, as appropriate?


 Lack of release management. I'm getting over my PGP whining and am
 going to dig in and start volunteering to do some releases again.

snip/

If you're digging in, you're welcome to take a quick (or lasting ;-)
look at [scxml], I'm looking for general opinions about it.


 We've recently raised issues in managing the sandbox promotion/failure cycle.

snap/

I think we've become increasingly particular about sandbox promotion,
and correctly so. I also think we should perhaps cap the sandbox stay
for a component, lest it be left at almost promoted state forever.
That doesn't help anyone.

-Rahul


 Hen


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

Re: svn commit: r383042 - in /jakarta/commons/proper/pool/trunk/src: java/org/apache/commons/pool/Pools.java test/org/apache/commons/pool/TestPools.java

2006-03-04 Thread Henri Yandell

Also, make the constructor public. Allows scripting tools that can't
handle statics to call it. Put a Javadoc comment on the constructor -
see any Lang/Collections/IO XxxUtils class.

Hen

On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
 yes, XxxUtils is the commons standard.
 Stephen

 James Carman wrote:
  Wouldn't this class be better named, PoolUtils?
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Saturday, March 04, 2006 12:42 AM
  To: [EMAIL PROTECTED]
  Subject: svn commit: r383042 - in /jakarta/commons/proper/pool/trunk/src:
  java/org/apache/commons/pool/Pools.java
  test/org/apache/commons/pool/TestPools.java

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

[Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by PhilSteitz

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 PhilSteitz:
http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette

The comment on the change is:
Changed Jakarta to Apache re commit,  combined and updated voting info

--
  
  = Commons Committers =
  
- The commons proper is governed by the same membership rules as any other 
jakarta subproject. That means committers are elected. Unlike the sandbox, 
there are no automatic rights for existing Jakarta committers. 
+ The commons proper is governed by the same membership rules as any other 
jakarta subproject. That means committers are elected. Unlike the sandbox, 
there are no automatic rights for existing Apache committers. 
  
- On the other hand, the barrier to entry for existing Apache committers has 
traditionally been pretty low. If you express an interest, show willing by 
creating a few patches and you're known to existing committers, there's usually 
no problem. VOTEs proposed by commons committers for existing jakarta 
committers listing their achievements have (in the past) been passed very 
quickly.
+ On the other hand, the barrier to entry for existing Apache committers has 
traditionally been pretty low. If you express an interest, show willing by 
creating a few patches and you're known to existing committers, there's usually 
no problem. VOTEs proposed by commons committers for existing Apache committers 
listing their achievements have (in the past) been passed very quickly.
  
  = Commons Etiquette =
  
  Every commons committer has karma to every component. But a point of 
etiquette (enforced by the charter) is that each committer who commits to a 
component must add their name to the STATUS file for that component. It's also 
good form to post a message saying 'hi, i'd like to get involved with component 
foo' before you dive in. Traditionally, adding your name to the STATUS file is 
a committers first commit on a component.
  
- There is one important point about the list on the STATUS file. It is used to 
work out whose VOTEs are binding. (Since there are a lot of commons committers, 
this is more useful than it might first seem.) If you're name isn't on the 
list, your vote won't count :)
- 
  For components that use '''Maven''' as their build tool (and that is most of 
them now), you should add your name to the developers list in the project.xml 
file rather than the STATUS file if you intend to work on a component.
  
- = VOTEs =
+ = VOTEs and POLLS =
  
- The commons-dev mailing list is a busy place. Very much a bazaar rather than 
a Cathedral. This means that VOTE threads have a habit of petering out. It a 
good idea to post a {{{[VOTE][RESULT]}}} which counts the binding VOTEs and 
tells people the result. 
+ A VOTE is an official decision thread. Anyone can express a preference (by 
indicating +1, +0, -0 or -1 in the traditional manner) but only some votes are 
binding. All are encouraged to VOTE but traditionally (to ease the work 
required to tally the vote) ''(non-binding)'' is added by those who know their 
votes are non-binding. Only votes from Jakarta PMC members are binding.
+ 
+ The commons-dev mailing list is a busy place. Very much a bazaar rather than 
a Cathedral. This means that VOTE threads have a habit of petering out. It a 
good idea to post a {{{[VOTE][RESULT]}}} which counts the binding VOTEs and 
tells people the result. The tally should separate binding from non-binding 
VOTES.  It is also good to place a time limit on [VOTE] threads.  Finally, VOTE 
threads often digress into interesting discussions not directly related to the 
VOTE iteslf.  In these cases, it is better to start new threads with 
appropriate subject headers for the side discussions.  This makes it easier to 
navigate the list archives and also keeps the VOTE thread on track (or leads to 
it being stopped, where appropriate).
+ 
+ A POLL is an unofficial decision thread. These are useful for gauging the 
general feeling of the broader user community. Again, preferences should be 
expressed in the usual fashion. In this case, there is no need to indicate 
non-binding (since none are!).
  
  
  
@@ -96, +98 @@

  
  * Please give the proposal enough time to give everything the chance to VOTE. 
I leave promotion VOTEs several days - maybe up to a week. When VOTEs have 
stopped coming in then please the proposer should post a {{{[VOTE][RESULT]}}} 
giving counts. Only the VOTEs of commons committers are binding so please make 
sure that these are tallied separately. The reason why a result email is good 
is that VOTE thread tend to peter out and so without a final email, it's hard 
to look back through the archives and find out what's happened. Another reason 
is that it's a good way to let everyone know what the result was. If there are 
any

Re: Problems...

2006-03-04 Thread Henri Yandell

On 3/4/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
 On 3/3/06, Henri Yandell [EMAIL PROTECTED] wrote:
  Taking a step backwards. What are the current problems besetting
  Commons? I'm probably getting ahead on myself on trying to organize
  solutions without consensus on problems.
 
  We have an inactivity issue, and reflecting that inactivity to the
  users. To solve the latter we've added the dormant concept to the
  Sandbox, and need to do something similar to the main projects.
  Jakarta as a whole has these problems and I'm looking to Commons for
  the solutions. On the former, we've given ourselves a mental wake up
  to get people involved, patching and committing.
 
 snip/

 For starters:

  * Do we need a volunteer to call a vote for [latka], move it to
 dormant if vote passes etc.?

I'll continue to follow this up. My itch to code at Commons is
superceded by my itch to organize - in so much as that organizing
doesn't get irritating.

  * We should do the same for [el]. JSP = 2.1 seems like it will be on
 a separate el track for Tomcat, its biggest beneficiary, so probably
 sensible to move it to dormant too.

Will come up with a list of ones to consider for proper-dormant
(whatever we call it).

  * Seems there is interest in pulling [modeler] under Tomcat,
 post-TLP, so what do we need to do to encourage that? ;-)

This is a definite issue to discuss a lot. The point of Commons is for
other projects to share their components here - however, if no one is
sharing it and it's only being used by one project, is that cause for
it to move back to the original TLP?

  We've got an experimental m2 build in the sandbox, and a couple of
  components which don't have an m1 build. How independent do we want
  components to be. I'm thinking less independent because I want to
  maximise the ease with which people can move between components (to
  deal with inactivity), but the community might want to go the other
  way and be far more bazaar like.
 
 snap/

 IMO, until any further consensus, *all* {proper,sandbox} components
 should have a {m102,xdoc192} build. Anyone is welcome to make progress
 on the m2 side if they wish, but not having a m102 build just makes
 those components unavailable for anyone who doesn't want to deal
 with m2 yet.

m1.1 is an upcoming issue too :)

  We have releases going out without our awareness. The commons-cli
  issue to the maven repository a while back; Jakarta had a similar one
  with velocity-dvsl. That's a general Apache problem that I'm
  suggesting solutions to on repository@ and letting what I'm saying
  here be affected by that (which probably makes me seem more illogical
  than usual) - this is one of the reasons why I'm in favour of a
  general Apache solution to group-ids.
 
 snip/

 Your suggestions on repository@ seem well thought-out, but I see both
 sides of the groupId issue -- while it will make repo management
 easier, Maven folks don't necessary seem to care, there is the added
 element of confusion to users by the injection of jakarta in the mix
 -- *sigh*.

I'm definitely thinking foundation-wide on the suggestions, rather
than Commons-specific. We like to say that it's nice not having
jakarta in the package name as it allows TLPs to happen more easily -
but that is a short term thing, we can't continually be a TLP
incubation system. At some point we won't be promoting projects
upwards and that reason will have gone.

  We have a sprawling site that could be much better - though this is
  entirely my opinion.
 
 snap/

 This is the least of my concerns. Like Martin, I don't have any
 trouble with the site, I stick to the book. But unlike Martin, I've
 built quite a few sites lately (ofcourse, there may still be some
 sites that are troublesome, it will be nice to know what the exact
 issues are -- apart from not heeding the correct versions of
 maven/plugins to build).

My site issues are information-architecture/design issues - I think
it's too noisy and big, in many places we don't pay attention to user
manuals but spend too much space on the basic info and we don't treat
the documentation properly in releases. The cop-out is to have a site
per release, but that's ignoring the issue that our sites and
documentation are intermingled.

  We have a very noisy set of mailing lists. Need to ask how the Jive
  forum is going for Struts (I think I heard that was in place?).
  Watching how the Maven-dev move to separate lists for commits, jira,
  dev, ci goes.
 
 snip/

 Personally, not a concern, I like it this way. Again, perhaps
 articulate how and what noise bothers you? I don't use forums, posts
 from them tend to become noise to me (things such as loss of
 formatting, loss of appropriate history before posting bother me).
 Ofcourse, anyone can use whatever tools makes them most productive
 (one of the key arguments for forums I've heard), likewise recipients
 reserve the right to only read email that they find readable.

This one is more repeating

svn commit: r383162 - in /jakarta/commons/proper/pool/trunk/src: java/org/apache/commons/pool/PoolUtils.java java/org/apache/commons/pool/Pools.java test/org/apache/commons/pool/TestPoolUtils.java tes

2006-03-04 Thread sandymac

Author: sandymac
Date: Sat Mar  4 10:11:17 2006
New Revision: 383162

URL: http://svn.apache.org/viewcvs?rev=383162view=rev
Log:
Renamed util class to standard convention for Commons. Pools - PoolUtils
Make contructor public for JavaBean scripting tools.
Expanded until tests for better code coverage aided by Clover.

Added:

jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/PoolUtils.java
   (contents, props changed)
  - copied, changed from r383046, 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/Pools.java

jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java
   (contents, props changed)
  - copied, changed from r383046, 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPools.java
Removed:

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

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

Copied: 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/PoolUtils.java
 (from r383046, 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/Pools.java)
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/PoolUtils.java?p2=jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/PoolUtils.javap1=jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/Pools.javar1=383046r2=383162rev=383162view=diff
==
--- 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/Pools.java 
(original)
+++ 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/PoolUtils.java
 Sat Mar  4 10:11:17 2006
@@ -30,7 +30,7 @@
  * @author Sandy McArthur
  * @version $Revision$ $Date$
  */
-public final class Pools {
+public final class PoolUtils {
 
 /**
  * Timer used to periodically check pools idle object count.
@@ -39,15 +39,17 @@
 private static Timer MIN_IDLE_TIMER;
 
 /**
- * Prevent instantiation.
+ * PoolUtils instances should NOT be constructed in standard programming.
+ * Instead, the class should be used procedurally: PoolUtils.adapt(aPool);.
+ * This constructor is public to permit tools that require a JavaBean 
instance to operate.
  */
-private Pools() {
+public PoolUtils() {
 }
 
 /**
  * Adapt a codeKeyedPoolableObjectFactory/code instance to work where 
a codePoolableObjectFactory/code is
  * needed. This method is the equivalent of calling
- * [EMAIL PROTECTED] #adapt(KeyedPoolableObjectFactory, Object) 
Pools.adapt(aKeyedPoolableObjectFactory, new Object())}.
+ * [EMAIL PROTECTED] #adapt(KeyedPoolableObjectFactory, Object) 
PoolUtils.adapt(aKeyedPoolableObjectFactory, new Object())}.
  *
  * @param keyedFactory the [EMAIL PROTECTED] KeyedPoolableObjectFactory} 
to delegate to.
  * @return a [EMAIL PROTECTED] PoolableObjectFactory} that delegates to 
codekeyedFactory/code with an internal key.
@@ -86,7 +88,7 @@
 
 /**
  * Adapt a codeKeyedObjectPool/code instance to work where an 
codeObjectPool/code is needed. This is the
- * equivalent of calling [EMAIL PROTECTED] #adapt(KeyedObjectPool, Object) 
Pools.adapt(aKeyedObjectPool, new Object())}.
+ * equivalent of calling [EMAIL PROTECTED] #adapt(KeyedObjectPool, Object) 
PoolUtils.adapt(aKeyedObjectPool, new Object())}.
  *
  * @param keyedPool the [EMAIL PROTECTED] KeyedObjectPool} to delegate to.
  * @return an [EMAIL PROTECTED] ObjectPool} that delegates to 
codekeyedPool/code with an internal key.

Propchange: 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/PoolUtils.java
--
svn:eol-style = native

Propchange: 
jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/PoolUtils.java
--
svn:keywords = Date Author Id Revision HeadURL

Copied: 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java
 (from r383046, 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPools.java)
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java?p2=jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.javap1=jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPools.javar1=383046r2=383162rev=383162view=diff
==
--- 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPools.java
 (original)
+++ 
jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/TestPoolUtils.java
 Sat Mar  4 10:11:17 2006
@@ -31,12 +31,12 @@
 import java.util.Iterator;
 
 /**
- * Unit tests

Re: Problems...


Yes we have many, many problems.

Site
Is this really our top priority? Is maven 2 helping here? Is maven 1? I 
have a distinct memory that commons was used as a practice ground pre 
maven-1 to test maven's functionality in a real deployment. Are we about 
to subject ourselves to this again?


Inactivity
Dormant has helped clarify the position. But are we willing to kick 
[beanutils] and [dbcp] into dormant? Since all user requests and bugs 
seem to have been ignored for many months, surely they are dormant? I 
await the screams from the wider community...


CI
How does another thing to worry about help us. Why not focus on Gump?

Commons as the solution
We're not. We're barely holding our head above water.

Leadership
Something Apache counsels against. Often however, the most successful 
projects have a leader who drives the project forward and on occaisions 
takes decisions. In commons we do have this, but only at the component 
level. We feel unwilling, or are unable, or don't want, a cross commons 
leader a lot of the time.



My analysis is that its time for a bit more radical surgery. And I mean 
splitting commons into smaller communities. Jakarta Xxx Components sets 
the naming pattern. If we do this, then each new group will be small 
enough to be able to take decisions by itself, for example on the site.


Stephen


Henri Yandell wrote:

Taking a step backwards. What are the current problems besetting
Commons? I'm probably getting ahead on myself on trying to organize
solutions without consensus on problems.

We have an inactivity issue, and reflecting that inactivity to the
users. To solve the latter we've added the dormant concept to the
Sandbox, and need to do something similar to the main projects.
Jakarta as a whole has these problems and I'm looking to Commons for
the solutions. On the former, we've given ourselves a mental wake up
to get people involved, patching and committing.

We've got an experimental m2 build in the sandbox, and a couple of
components which don't have an m1 build. How independent do we want
components to be. I'm thinking less independent because I want to
maximise the ease with which people can move between components (to
deal with inactivity), but the community might want to go the other
way and be far more bazaar like.

We have releases going out without our awareness. The commons-cli
issue to the maven repository a while back; Jakarta had a similar one
with velocity-dvsl. That's a general Apache problem that I'm
suggesting solutions to on repository@ and letting what I'm saying
here be affected by that (which probably makes me seem more illogical
than usual) - this is one of the reasons why I'm in favour of a
general Apache solution to group-ids.

We have a sprawling site that could be much better - though this is
entirely my opinion.

We have a very noisy set of mailing lists. Need to ask how the Jive
forum is going for Struts (I think I heard that was in place?).
Watching how the Maven-dev move to separate lists for commits, jira,
dev, ci goes.

We have a need to organize our CI. Apparantly the hold up there is
twofold:  1) issues over a general build server, or whether it should
be individual pmcs  2) the zones machine is busy cpu wise and Infra
don't want us to have a Commons zone that builds a lot just yet.

The PMC Chair is casting random solutions to Jakarta's oversight and
community issues and suggesting Commons can absorb Jakarta (apart from
the bits that leave) as a solution.

Lack of release management. I'm getting over my PGP whining and am
going to dig in and start volunteering to do some releases again.

We've recently raised issues in managing the sandbox promotion/failure cycle.

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]

svn commit: r383179 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/io/FileSystemUtils.java src/test/org/apache/commons/io/FileSystemUtilsTestCase.java

Author: scolebourne
Date: Sat Mar  4 11:14:04 2006
New Revision: 383179

URL: http://svn.apache.org/viewcvs?rev=383179view=rev
Log:
FileSystemUtils.freeSpaceKb to normalize free space to kb
bug 38574

Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt

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

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

Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?rev=383179r1=383178r2=383179view=diff
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Sat Mar  4 11:14:04 2006
@@ -42,6 +42,9 @@
 - AgeFileFilter/SizeFileFilter
   New file filters that compares against the age and size of the file
 
+- FileSystemUtils.freeSpaceKb(drive)
+  New method that unifies result to be in kilobytes [38574]
+
 - FileUtils.contentEquals(File,File)
   Performance improved by adding length and file location checking
 

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java?rev=383179r1=383178r2=383179view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java
 Sat Mar  4 11:14:04 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2005 The Apache Software Foundation.
+ * Copyright 2005-2006 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.
@@ -97,7 +97,12 @@
 
 //---
 /**
- * Returns the free space on a drive or volume in a cross-platform manner.
+ * Returns the free space on a drive or volume by invoking
+ * the command line.
+ * This method does not normalize the result, and typically returns
+ * bytes on Windows and Kilobytes on Unix.
+ * See also [EMAIL PROTECTED] #freeSpaceKb(String)}.
+ * p
  * Note that some OS's are NOT currently supported, including OS/390.
  * pre
  * FileSystemUtils.freeSpace(C:);  // Windows
@@ -113,9 +118,33 @@
  * @throws IOException if an error occurs when finding the free space
  */
 public static long freeSpace(String path) throws IOException {
-return INSTANCE.freeSpaceOS(path, OS);
+return INSTANCE.freeSpaceOS(path, OS, false);
+}
+
+//---
+/**
+ * Returns the free space on a drive or volume in kilobytes by invoking
+ * the command line.
+ * Note that some OS's are NOT currently supported, including OS/390.
+ * pre
+ * FileSystemUtils.freeSpace(C:);  // Windows
+ * FileSystemUtils.freeSpace(/volume);  // *nix
+ * /pre
+ * The free space is calculated via the command line.
+ * It uses 'dir /-c' on Windows and 'df -k' on *nix.
+ *
+ * @param path  the path to get free space for, not null, not empty on Unix
+ * @return the amount of free drive space on the drive or volume in 
kilobytes
+ * @throws IllegalArgumentException if the path is invalid
+ * @throws IllegalStateException if an error occurred in initialisation
+ * @throws IOException if an error occurs when finding the free space
+ * @since Commons IO 1.2
+ */
+public static long freeSpaceKb(String path) throws IOException {
+return INSTANCE.freeSpaceOS(path, OS, true);
 }
 
+//---
 /**
  * Returns the free space on a drive or volume in a cross-platform manner.
  * Note that some OS's are NOT currently supported, including OS/390.
@@ -128,20 +157,21 @@
  *
  * @param path  the path to get free space for, not null, not empty on Unix
  * @param os  the operating system code
+ * @param kb  whether to normalize to kilobytes
  * @return the amount of free drive space on the drive or volume
  * @throws IllegalArgumentException if the path is invalid
  * @throws IllegalStateException if an error occurred in initialisation
  * @throws IOException if an error occurs when finding the free space
  */
-long freeSpaceOS(String path, int os) throws IOException {
+long freeSpaceOS(String path, int os, boolean kb) throws IOException {
 if (path == null) {
 throw new IllegalArgumentException(Path must not be empty);
 }
 switch (os) {

DO NOT REPLY [Bug 38574] - [io] FileSystemUtils returns incorrect free space on Linux

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=38574.
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=38574


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-04 20:16 ---
FileSystemUtils.freeSpaceKb(drive)
New method that unifies result to be in kilobytes

Please reopen if you believe that the new method returns the wrong result (I can
on test on Windows)

-- 
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 38093] - [IO][PATCH] - file and directory pollers

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=38093.
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=38093


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement




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

[io] Help with testing on Unix - FileSystemUtils returns incorrect free space on Linux

If anyone has the ability to test FileSystemUtils.freeSpaceKb() on boxes 
other than WindowsXP I'd like to know if the results tally what you'd 
expect by calling dir/df directly.


thanks
Stephen


[EMAIL PROTECTED] wrote:

http://issues.apache.org/bugzilla/show_bug.cgi?id=38574
--- Additional Comments From [EMAIL PROTECTED]  2006-03-04 20:16 ---
FileSystemUtils.freeSpaceKb(drive)
New method that unifies result to be in kilobytes

Please reopen if you believe that the new method returns the wrong result (I can
on test on Windows)



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

[pool] Dependency on Xerces

I was confused for a while because the [pool] website says it is 
dependent on xerces and xml-apis. Now I have downloaded the source, I 
can see the comment about this being for maven only.


Is there any way that these can be removed? The junit one can be removed 
(even though the mavenites tell you not to).


The way the page is generated indicates that [pool] has dependencies, 
when in fact it doesn't.


Stephen

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

Re: [io] Help with testing on Unix - FileSystemUtils returns incorrect free space on Linux

Works4me on RH FC 2, with both Kb and original method returning kbytes.

Looks like there is a cut and paste error in the javadoc for the new
method, though.  The Kb seems to be missing from the examples.

I am also getting test failures for the FileFilterTestCase.  The
newfile tests are failing.  I will look at this some more.

Phil

On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
 If anyone has the ability to test FileSystemUtils.freeSpaceKb() on boxes
 other than WindowsXP I'd like to know if the results tally what you'd
 expect by calling dir/df directly.

 thanks
 Stephen


 [EMAIL PROTECTED] wrote:
  http://issues.apache.org/bugzilla/show_bug.cgi?id=38574
  --- Additional Comments From [EMAIL PROTECTED]  2006-03-04 20:16 ---
  FileSystemUtils.freeSpaceKb(drive)
  New method that unifies result to be in kilobytes
 
  Please reopen if you believe that the new method returns the wrong result 
  (I can
  on test on Windows)
 

 -
 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: r383200 - /jakarta/commons/proper/io/trunk/project.xml

Author: scolebourne
Date: Sat Mar  4 13:22:51 2006
New Revision: 383200

URL: http://svn.apache.org/viewcvs?rev=383200view=rev
Log:
Add version info for v1.1

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

Modified: jakarta/commons/proper/io/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/project.xml?rev=383200r1=383199r2=383200view=diff
==
--- jakarta/commons/proper/io/trunk/project.xml (original)
+++ jakarta/commons/proper/io/trunk/project.xml Sat Mar  4 13:22:51 2006
@@ -77,6 +77,11 @@
   name1.0/name
   tagIO_1_0/tag
 /version
+version
+  id1.1/id
+  name1.1/name
+  tagIO_1_1/tag
+/version
   /versions
 
   developers



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

svn commit: r383201 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java

Author: scolebourne
Date: Sat Mar  4 13:25:59 2006
New Revision: 383201

URL: http://svn.apache.org/viewcvs?rev=383201view=rev
Log:
FileSystemUtils.freeSpaceKb javadoc fix

Modified:

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

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java?rev=383201r1=383200r2=383201view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileSystemUtils.java
 Sat Mar  4 13:25:59 2006
@@ -105,7 +105,7 @@
  * p
  * Note that some OS's are NOT currently supported, including OS/390.
  * pre
- * FileSystemUtils.freeSpace(C:);  // Windows
+ * FileSystemUtils.freeSpace(C:);   // Windows
  * FileSystemUtils.freeSpace(/volume);  // *nix
  * /pre
  * The free space is calculated via the command line.
@@ -127,8 +127,8 @@
  * the command line.
  * Note that some OS's are NOT currently supported, including OS/390.
  * pre
- * FileSystemUtils.freeSpace(C:);  // Windows
- * FileSystemUtils.freeSpace(/volume);  // *nix
+ * FileSystemUtils.freeSpaceKb(C:);   // Windows
+ * FileSystemUtils.freeSpaceKb(/volume);  // *nix
  * /pre
  * The free space is calculated via the command line.
  * It uses 'dir /-c' on Windows and 'df -k' on *nix.



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

svn commit: r383205 - /jakarta/commons/proper/io/trunk/project.properties

Author: scolebourne
Date: Sat Mar  4 13:36:53 2006
New Revision: 383205

URL: http://svn.apache.org/viewcvs?rev=383205view=rev
Log:
Update to compare to v1.1

Modified:
jakarta/commons/proper/io/trunk/project.properties

Modified: jakarta/commons/proper/io/trunk/project.properties
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/project.properties?rev=383205r1=383204r2=383205view=diff
==
--- jakarta/commons/proper/io/trunk/project.properties (original)
+++ jakarta/commons/proper/io/trunk/project.properties Sat Mar  4 13:36:53 2006
@@ -37,7 +37,7 @@
 maven.checkstyle.properties=checkstyle.xml
 
 maven.jdiff.new.tag=CURRENT
-maven.jdiff.old.tag=IO_1_0
+maven.jdiff.old.tag=IO_1_1
 
 # Generate class files for specific VM version (e.g., 1.1 or 1.2). 
 # Note that the default value depends on the JVM that is running Ant. 



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

svn commit: r383206 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java

Author: scolebourne
Date: Sat Mar  4 13:38:10 2006
New Revision: 383206

URL: http://svn.apache.org/viewcvs?rev=383206view=rev
Log:
Fix javadoc and method return type

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

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?rev=383206r1=383205r2=383206view=diff
==
--- jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java 
(original)
+++ jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java 
Sat Mar  4 13:38:10 2006
@@ -509,19 +509,25 @@
 //---
 /**
  * Return an Iterator for the lines in a codeReader/code.
+ * Please read the javadoc of [EMAIL PROTECTED] LineIterator} to understand
+ * whether you should close the iterator.
+ * The file is closed if an exception is thrown.
  *
  * @param reader  the codeReader/code to read from, not null
  * @return an Iterator of the lines in the reader, never null
  * @throws NullPointerException if the reader is null
  * @since Commons IO 1.2
  */
-public static Iterator lineIterator(Reader reader) {
+public static LineIterator lineIterator(Reader reader) {
 return new LineIterator(reader);
 }
 
 /**
  * Return an Iterator for the lines in an codeInputStream/code, using
  * the character encoding specified (or default encoding if null).
+ * Please read the javadoc of [EMAIL PROTECTED] LineIterator} to understand
+ * whether you should close the iterator.
+ * The file is closed if an exception is thrown.
  *
  * @param input  the codeInputStream/code to read from, not null
  * @param encoding  the encoding to use, null means platform default



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

Re: [io] Help with testing on Unix - FileSystemUtils returns incorrect free space on Linux

Found the source of the test failures for me.  I think the code and
test cases are correct, but somehow the clock precision or something
else is messing up the chronology for me.  The tests all pass if I
make spin wait until a full second has elapsed:

private void spin(long now) {
while (System.currentTimeMillis() = now + 1000);  -- add a sec.
}

That slows down the tests a bit, but makes them pass.  Has this been
reported before?

Phil

On 3/4/06, Phil Steitz [EMAIL PROTECTED] wrote:
 Works4me on RH FC 2, with both Kb and original method returning kbytes.

 Looks like there is a cut and paste error in the javadoc for the new
 method, though.  The Kb seems to be missing from the examples.

 I am also getting test failures for the FileFilterTestCase.  The
 newfile tests are failing.  I will look at this some more.

 Phil

 On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
  If anyone has the ability to test FileSystemUtils.freeSpaceKb() on boxes
  other than WindowsXP I'd like to know if the results tally what you'd
  expect by calling dir/df directly.
 
  thanks
  Stephen
 
 
  [EMAIL PROTECTED] wrote:
   http://issues.apache.org/bugzilla/show_bug.cgi?id=38574
   --- Additional Comments From [EMAIL PROTECTED]  2006-03-04 20:16 
   ---
   FileSystemUtils.freeSpaceKb(drive)
   New method that unifies result to be in kilobytes
  
   Please reopen if you believe that the new method returns the wrong result 
   (I can
   on test on Windows)
  
 
  -
  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]

[all] JUnit 3.8.2


The new Junit version has been released - v3.8.2.

http://sourceforge.net/projects/junit

Its main benefit is a better string comparison format.


Unfortunately, it seems to break lots of tests in [io] and [collections] 
when I run with Eclipse.


(I get a NoSuchMethodError when running assetEquals with a boolean, 
float or double - very strange)


Stephen

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

DO NOT REPLY [Bug 38856] New: - Killed user connection causes the setautocomit to fail

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=38856.
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=38856

   Summary: Killed user connection causes the setautocomit to fail
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: major
  Priority: P2
 Component: Pool
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I am running into same issue for which the bug id 22078 was opened for. 22078 
resolutions is been fixed, but I donot see the code changes.

-- 
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: svn commit: r382690 - in /jakarta/commons/sandbox/compress/trunk/src/site: ./ apt/ apt/index.apt site.xml

2006-03-04 Thread Dennis Lundberg


Dennis Lundberg wrote:
The Maven 2 site plugin does not handle xml entities. That's the reason 
for this error. This is known to the Maven community. We will have to 
find a way to replace our current m1 way to create the menus.


What I would like to be able to do is to exclude just the file 
/src/xdocs/navigation.xml from the site generation so that m1 and m2 
builds can coexist for a while. Will investigate this some more...


This was not that hard to do. I've created patches for this and 
submitted them to Jira over in Maven land:

- http://jira.codehaus.org/browse/DOXIA-54
- http://jira.codehaus.org/browse/MSITE-98

--
Dennis Lundberg

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

svn commit: r383220 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java

Author: scolebourne
Date: Sat Mar  4 15:18:46 2006
New Revision: 383220

URL: http://svn.apache.org/viewcvs?rev=383220view=rev
Log:
Add finalize method

Modified:

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

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java?rev=383220r1=383219r2=383220view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
 Sat Mar  4 15:18:46 2006
@@ -150,6 +150,14 @@
 throw new UnsupportedOperationException(Remove unsupported on 
LineIterator);
 }
 
+/**
+ * Finalize which closes the underlying reader.
+ * Do not rely on this method to handle cleanup - call closeQuietly 
yourself.
+ */
+protected void finalize() throws Throwable {
+close();
+}
+
 //---
 /**
  * Closes the iterator, handling null and ignoring exceptions.



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

svn commit: r383221 - in /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io: FileUtils.java IOUtils.java

Author: scolebourne
Date: Sat Mar  4 15:19:02 2006
New Revision: 383221

URL: http://svn.apache.org/viewcvs?rev=383221view=rev
Log:
Improve javadoc

Modified:

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

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?rev=383221r1=383220r2=383221view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java 
(original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java 
Sat Mar  4 15:19:02 2006
@@ -594,6 +594,7 @@
  * @throws NullPointerException if source or destination is null
  * @throws IOException if source or destination is invalid
  * @throws IOException if an IO error occurs during copying
+ * @since Commons IO 1.2
  */
 public static void copyDirectoryToDirectory(File srcDir, File destDir) 
throws IOException {
 if (srcDir == null) {
@@ -856,8 +857,8 @@
  * The file is always closed.
  * p
  * There is no readFileToString method without encoding parameter because
- * the default encoding can differ between platforms and therefore results
- * in inconsistent results.
+ * the default encoding can differ between platforms and will have
+ * inconsistent results.
  *
  * @param file  the file to read
  * @param encoding  the encoding to use, null means platform default
@@ -900,8 +901,8 @@
  * The file is always closed.
  * p
  * There is no readLines method without encoding parameter because
- * the default encoding can differ between platforms and therefore results
- * in inconsistent results.
+ * the default encoding can differ between platforms and will have
+ * inconsistent results.
  *
  * @param file  the file to read
  * @param encoding  the encoding to use, null means platform default
@@ -924,11 +925,24 @@
  * Return an Iterator for the lines in a codeFile/code.
  * Please read the javadoc of [EMAIL PROTECTED] LineIterator} to understand
  * whether you should close the iterator.
- * The file is closed if an exception is thrown.
+ * The file is closed if an exception is thrown during this method.
  * p
- * There is no readLines method without encoding parameter because
- * the default encoding can differ between platforms and therefore results
- * in inconsistent results.
+ * The recommended usage patterm is:
+ * pre
+ * LineIterator it = FileUtils.lineIterator(file, UTF-8);
+ * try {
+ *   while (it.hasNext()) {
+ * String line = it.nextLine();
+ * /// do something with line
+ *   }
+ * } finally {
+ *   LineIterator.closeQuietly(iterator);
+ * }
+ * /pre
+ * p
+ * There is no lineIterator method without encoding parameter because
+ * the default encoding can differ between platforms and will have
+ * inconsistent results.
  *
  * @param file  the file to read
  * @param encoding  the encoding to use, null means platform default
@@ -955,8 +969,8 @@
  * Writes a String to a file creating the file if it does not exist.
  * p
  * There is no writeStringToFile method without encoding parameter because
- * the default encoding can differ between platforms and therefore results
- * in inconsistent results.
+ * the default encoding can differ between platforms and will have
+ * inconsistent results.
  *
  * @param file  the file to write
  * @param data  the content to write to the file
@@ -998,8 +1012,8 @@
  * The specified character encoding and the default line ending will be 
used.
  * p
  * There is no writeLines method without encoding parameter because
- * the default encoding can differ between platforms and therefore results
- * in inconsistent results.
+ * the default encoding can differ between platforms and will have
+ * inconsistent results.
  *
  * @param file  the file to write to
  * @param encoding  the encoding to use, null means platform default
@@ -1018,8 +1032,8 @@
  * The specified character encoding and the line ending will be used.
  * p
  * There is no writeLines method without encoding parameter because
- * the default encoding can differ between platforms and therefore results
- * in inconsistent results.
+ * the default encoding can differ between platforms and will have
+ * inconsistent results.
  *
  * @param file  the file to write to
  * @param encoding  the encoding to use, null means platform default

Modified:

svn commit: r383222 - /jakarta/commons/proper/io/trunk/xdocs/description.xml

Author: scolebourne
Date: Sat Mar  4 15:19:31 2006
New Revision: 383222

URL: http://svn.apache.org/viewcvs?rev=383222view=rev
Log:
Add section on LineIterator

Modified:
jakarta/commons/proper/io/trunk/xdocs/description.xml

Modified: jakarta/commons/proper/io/trunk/xdocs/description.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/xdocs/description.xml?rev=383222r1=383221r2=383222view=diff
==
--- jakarta/commons/proper/io/trunk/xdocs/description.xml (original)
+++ jakarta/commons/proper/io/trunk/xdocs/description.xml Sat Mar  4 15:19:31 
2006
@@ -172,6 +172,26 @@
 
 /section
 
+section name=Line iterator
+p
+   The codeorg.apache.commons.io.LineIterator/code 
class
+   provides a flexible way for working with a line-based 
file.
+   An instance can be created directly, or via factory 
methods on
+   codeFileUtils/code or codeIOUtils/code.
+   The recommended usage pattern is:
+/p
+pre
+  LineIterator it = FileUtils.lineIterator(file, UTF-8);
+  try {
+while (it.hasNext()) {
+  String line = it.nextLine();
+  /// do something with line
+}
+  } finally {
+LineIterator.closeQuietly(iterator);
+  }/pre
+/section
+
 section name=File filters
 p
 The codeorg.apache.commons.io.filefilter/code



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

svn commit: r383223 - /jakarta/commons/proper/io/trunk/project.xml

Author: scolebourne
Date: Sat Mar  4 15:20:14 2006
New Revision: 383223

URL: http://svn.apache.org/viewcvs?rev=383223view=rev
Log:
Disable some reports and switch to cobertura

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

Modified: jakarta/commons/proper/io/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/project.xml?rev=383223r1=383222r2=383223view=diff
==
--- jakarta/commons/proper/io/trunk/project.xml (original)
+++ jakarta/commons/proper/io/trunk/project.xml Sat Mar  4 15:20:14 2006
@@ -250,17 +250,17 @@
 /build
 
   reports
-reportmaven-changelog-plugin/report
-reportmaven-changes-plugin/report
+!--reportmaven-changelog-plugin/report--
+!--reportmaven-changes-plugin/report--
+!--reportmaven-developer-activity-plugin/report--
+!--reportmaven-file-activity-plugin/report--
 reportmaven-checkstyle-plugin/report
-reportmaven-developer-activity-plugin/report
-reportmaven-file-activity-plugin/report
 reportmaven-javadoc-plugin/report
 reportmaven-jdepend-plugin/report
 reportmaven-junit-report-plugin/report
 reportmaven-jxr-plugin/report
 reportmaven-license-plugin/report
-reportmaven-jcoverage-plugin/report
+reportmaven-cobertura-plugin/report
 reportmaven-jdiff-plugin/report
   /reports
 



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

svn commit: r383224 - /jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java

Author: scolebourne
Date: Sat Mar  4 15:24:49 2006
New Revision: 383224

URL: http://svn.apache.org/viewcvs?rev=383224view=rev
Log:
Allow one second to avoid test failures

Modified:

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

Modified: 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java?rev=383224r1=383223r2=383224view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
 Sat Mar  4 15:24:49 2006
@@ -524,7 +524,7 @@
 }
 
 private void spin(long now) {
-while (System.currentTimeMillis() = now);
+while (System.currentTimeMillis() = now + 1000);
 }
 
 }



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

Re: [io] Help with testing on Unix - FileSystemUtils returns incorrect free space on Linux


I've made the change.
Stephen

Phil Steitz wrote:

Found the source of the test failures for me.  I think the code and
test cases are correct, but somehow the clock precision or something
else is messing up the chronology for me.  The tests all pass if I
make spin wait until a full second has elapsed:

private void spin(long now) {
while (System.currentTimeMillis() = now + 1000);  -- add a sec.
}

That slows down the tests a bit, but makes them pass.  Has this been
reported before?

Phil

On 3/4/06, Phil Steitz [EMAIL PROTECTED] wrote:


Works4me on RH FC 2, with both Kb and original method returning kbytes.

Looks like there is a cut and paste error in the javadoc for the new
method, though.  The Kb seems to be missing from the examples.

I am also getting test failures for the FileFilterTestCase.  The
newfile tests are failing.  I will look at this some more.

Phil

On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:


If anyone has the ability to test FileSystemUtils.freeSpaceKb() on boxes
other than WindowsXP I'd like to know if the results tally what you'd
expect by calling dir/df directly.

thanks
Stephen


[EMAIL PROTECTED] wrote:


http://issues.apache.org/bugzilla/show_bug.cgi?id=38574
--- Additional Comments From [EMAIL PROTECTED]  2006-03-04 20:16 ---
FileSystemUtils.freeSpaceKb(drive)
New method that unifies result to be in kilobytes

Please reopen if you believe that the new method returns the wrong result (I can
on test on Windows)



-
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: r383225 - /jakarta/commons/proper/io/trunk/STATUS.html

Author: scolebourne
Date: Sat Mar  4 15:28:33 2006
New Revision: 383225

URL: http://svn.apache.org/viewcvs?rev=383225view=rev
Log:
Fix status info about releases

Modified:
jakarta/commons/proper/io/trunk/STATUS.html

Modified: jakarta/commons/proper/io/trunk/STATUS.html
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/STATUS.html?rev=383225r1=383224r2=383225view=diff
==
--- jakarta/commons/proper/io/trunk/STATUS.html (original)
+++ jakarta/commons/proper/io/trunk/STATUS.html Sat Mar  4 15:28:33 2006
@@ -38,11 +38,7 @@
 a name=Release Info/a
 h33.  RELEASE INFO/h3
 
-pCurrent Release: IO is yet to be released.  We hope it will be RSN./p
-
-pPlanned Next Release:  Real Soon Now :)  See the a
- href=#Action%20ItemsAction Items/a list for tasks that need to be 
completed
-prior to this release./p
+pReleased./p
 
 
 a name=Committers/a



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

Re: [logging] proposal for JCL2 implementation

2006-03-04 Thread Dennis Lundberg


Simon Kitching wrote:

Hi All,


Simon,

Sorry for jumping in late...

While reading through the two JCL design threads an idea struck to me, 
similar to the one you are proposing here. I was thinking in terms of 
having a commons-logging.properties file bundled in each of the jar 
files. The effect would be the same, but I think your services approach 
is better.




As you may have seen from the recent commit, I've added some code to
  proper/logging/contrib/simon/jcl2

Obviously this is very much work-in-progress; I've committed this really
to ensure I don't lose the stuff. I intend to do more testing on this
code to see if it stands up before seriously proposing this as a JCL2
architecture. However if anyone wishes to provide feedback at this very
early stage I'd be happy to see it.



Ok, you're still reading?? Well, then, here's the basic concepts.

This is the result of a idea that suddenly occurred to me. As far as I
can see, it results in pretty much the same effect as static binding,
but needs no compilation or bytecode tricks at all.

Instead the code is based heavily around the standard services pattern
introduced in java1.3, though it should run on any version, together
with a few basic packaging rules that must be followed.

As always in such early code, the code and build process is a bit rough,
but it does build and run.

The resulting jars are:
  core-static.jar:
Log  (interface)
LogHandler (interface)
LogFactory (abstract class)
LogFactoryStatic (concrete subclass of LogFactory)
Utils (static utility class)
META-INF/services/org.apache.commons.logging.LogFactory
 -- points to LogFactoryStatic

  core-dynamic.jar: [not yet implemented :-]
Log  (interface)
LogHandler (interface)
LogFactory (abstract class)
LogFactoryStatic (concrete subclass of LogFactory)
Utils (static utility class)
META-INF/services/org.apache.commons.logging.LogFactory
 -- points to LogFactoryStatic

  noop.jar:
NoOpLog
NoOpLogHandler
META-INF/services/org.apache.commons.logging.LogHandler
 -- points to NoOpLogHandler

  simple.jar
SimpleLog
SimpleLogHandler
META-INF/services/org.apache.commons.logging.LogHandler
 -- points to SimpleLogHandler

   etc

A user would choose one of (core-static, core-dynamic) and then one of
(noop.jar, simple.jar, log4j.jar, jul.jar, whatever).

Directory src/core contains the traditional Log interface, almost

unchanged. It also contains a LogFactory abstract class which provides
the standard getLog(class) and getLog(string) methods; however rather
than implementing any logic itself it just delegates to an underlying
concrete subclass of LogFactory. So far, we've talked about all this
before and I believe hava consensus.

The interesting bit is the way that LogFactory determines which subclass
to instantiate and delegate to. It simply looks for file
META-INF/services/org.apache.commons.logging.LogFactory in the way
recommended for standard java Service Providers. As long as the
following files are *always* bundled together, I can't see any way to
get cross-wiring:
   LogFactory
   [some LogFactory implementation]
   [the service file]

When a classloader is implementing parent-first, then the LogFactory
found will not come from classloader X unless there is no such class in
any ancestor. Therefore when that class looks for the service file and
the specified implementation it should get the ones out of its own
jarfile (because they are never found without an accompanying LogFactory
class).

When a classloader is implementing child-first, then when the
LogFactory looks for the service file and the specified implementation
then they will be served from the same classloader.

Note that the lookup NEVER involves the TCCL; we're effectively trying
to treat the three files above as if they had been statically merged
into a single class so using the TCCL doesn't make sense. 


I believe the result is that we (and users) can provide variants on the
core classes simply by bundling the standard UNMODIFIED LogFactory class
with their own subclass and the appropriate service file to effectively
bind the two together. This makes the build process much cleaner than
the other options we were considering; probably even compatible with
maven2. All we do is duplicate (unmodified) classes
LogFactory/Log/LogHandler/Utils into each jar that provides a different
LogFactory concrete implementation.


The LogFactoryStatic implementation of LogFactory is one that locates
its log adapter class *without* using the TCCL, ie is suitable for apps,
applets etc. And it in turn uses the same standard java Service Provider
approach (META-INF/services) to locate the adapter.

I've introduced the new interface LogHandler; in the old version the
LogFactory class was essentially filling two purposes: implementing an
algorithm for finding a log implementation, and acting as a
logging-lib-specific factory for Log

Re: [logging] JCL2.0 design - Architecture

2006-03-04 Thread Dennis Lundberg


Remy Maucherat wrote:

I am not very enthusiastic (from the container perspective). Let's see:
- Static discovery may look nice to some, but given the most likely
class overloading rules, it means the whole container and its
applications would use a single logging framework (which is ok in many
cases, though). So IMO you need to keep a working dynamic discovery.
- Please continue providing support for using the TCCL (as the TCCL -
or similar - is used in most JNDI impls, doing otherwise is a bit
redudant as far as I am concerned, and JNDI access is most likely
slower).
- If you're changing the API, I think you should consider using
java.util.logging as the facade API to replace the commons-logging 1.0
API. While the API exposed might be a bit sub optimal, this would be
the most standard way from users' perspective.


I haven't used java.util.logging so I might be way off here. How about 
having *both* JCL 1 and j.u.l APIs in JCL 2. I don't even know if this 
is possible, but it could be a nice path forward if, as someone else 
suggested, j.u.l will be *the* logging API 5 years down the road.



snip/

--
Dennis Lundberg

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

Re: Problems...

On 3/4/06, Brett Porter [EMAIL PROTECTED] wrote:
 Henri Yandell wrote:
  IMO, until any further consensus, *all* {proper,sandbox} components
  should have a {m102,xdoc192} build. Anyone is welcome to make progress
  on the m2 side if they wish, but not having a m102 build just makes
  those components unavailable for anyone who doesn't want to deal
  with m2 yet.
 
  m1.1 is an upcoming issue too :)

 m1.1 was intended to be backwards compatible. If it's not, that's a bug.
 Your builds should work with both.

See below.  I would not call it so much a bug as our having relied on
some undocumented behaviors that have changed.


  This is the least of my concerns. Like Martin, I don't have any
  trouble with the site, I stick to the book. But unlike Martin, I've
  built quite a few sites lately (ofcourse, there may still be some
  sites that are troublesome, it will be nice to know what the exact
  issues are -- apart from not heeding the correct versions of
  maven/plugins to build).
 
  My site issues are information-architecture/design issues - I think
  it's too noisy and big, in many places we don't pay attention to user
  manuals but spend too much space on the basic info and we don't treat
  the documentation properly in releases. The cop-out is to have a site
  per release, but that's ignoring the issue that our sites and
  documentation are intermingled.
 

 The thing to consider here is that the site is really hard to work with.
 Some others have gone through considerable pain to get it in a working
 state. So, if there are issues in the future they will be harder to work
 through, and if Hen's design/IA concerns yield suggestions that require
 changes to the structure or appearance of the site, someone is going to
 have to go through that pain again.

 That's not a reason to change now, but its a reason to investigate it
 which is why I'm doing it.


I agree with you, Brett and think our goal should be to make it as
simple as possible to maintain the site.  I also like to be able to
generate individual component sites individually.  There are two
things in the current setup that create challenges:

1.  The custom site.jsl.  That forces xdoc 1.9.2 in m1.  It is also an
ugly and painful thing to even think about maintaining.

2. The entities-based nav includes.  That is what is breaking in m1.1.
 I think that Paul is right that it is not the relative paths per se
that are causing 1.1 to choke.  I can get 1.1 to work by changing the
relative path in the standard navigation.xml to eliminate one of the
../ jumps.  I wish it were possible to put ${basedir} in the dtd
reference or we could just find another way to do this while we
prepare for m2.  One workaround would be to use URL paths to svn, but
that would make it impossible to build sites offline.  Does anyone
care about this?  Any better ideas?

As it stands, things work fine with 1.0.2 and xdoc 1.9.2, so if there
are no objections, I will at least update all of the m1 poms to make
the 1.9.2 dependency explicit (at least for the ones that I can get to
build).

Phil

 - Brett

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



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

Re: Problems...

Stephen Colebourne wrote:
 Yes we have many, many problems.
 
 Site
 Is this really our top priority? Is maven 2 helping here? Is maven 1? I
 have a distinct memory that commons was used as a practice ground pre
 maven-1 to test maven's functionality in a real deployment. Are we about
 to subject ourselves to this again?

My explicit intention was for this not to be the case, which is why I
isolated it to my own components in the sandbox. All I did was add some
requirements based on what commons wanted, so yes, it should help.
However, if you are not having any issues now, you shouldn't have to
concern yourself with it.

 CI
 How does another thing to worry about help us. Why not focus on Gump?

Paying attention to gump and keeping it up to date would be good for
commons as it will help monitor the library externally. That doesn't
really directly help the project but its good to know if the false
positives don't drown them out.

Honestly, I think CI for commons should be a little lower on the list of
things to do. Currently, work is being primarily done by a single person
at a time which doesn't really need it as much. If it is there, it would
be useful to use, but no point pushing on it until it is.

 My analysis is that its time for a bit more radical surgery. And I mean
 splitting commons into smaller communities. Jakarta Xxx Components sets
 the naming pattern. If we do this, then each new group will be small
 enough to be able to take decisions by itself, for example on the site.

The re-Jakarta-isation of Jakarta? :) I thought the whole purpose was to
get rid of the silos, not start building more.

This is essentially the problem. Commons needs to decide if it is a
bunch of independent components, or an ecosystem where all the
components are a part of a single project.

Things for being independent:
* Users don't care. They probably want one library, not them all. They
don't come to commons as their one stop shop for Java components. This
could just because right now, it's not a one stop shop.
* People usually have itches to scratch so will only work on small
parts, not the whole.
* Decisions get made easier. Each can use whatever build system it
wants, whatever documentation system it wants, whatever code convention
it wants.

Things against being independent:
* Some components depend on each other. Building those groups might help
there, but some things will span many (like logging, digester,
collections). Remember the talk of commons-all.
* Building silos makes it harder to get more people involved. Maven's
heavy-handedness about certain things that encourage consistency is not
so that it can rule the world, it is so it is easy for people to move
around. The medicine is good, it probably just needs to taste better.
* Doing things in the same way will mean more people can worry about
working on their components rather than infrastructure.

Personally, I think being one community is better. Users still don't
have to care, but those that want the one stop shop can have that too.
People can still scratch itches and not worry about commons
infrastructure. As for decisions, if you sum up the number of people
interested in making those decisions I think there are few enough that
it won't be that hard as long as everyone is objective.

That's not to say there should be separate lists. We've done that for
big subprojects in Maven and it works just fine. People with special
interests can go there, but all the people active across projects hang
out and discuss on the main dev list.

- Brett

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

Re: Problems...

Phil Steitz wrote:
 I agree with you, Brett and think our goal should be to make it as
 simple as possible to maintain the site.  I also like to be able to
 generate individual component sites individually.  There are two
 things in the current setup that create challenges:

These are what my m2 changes were designed to address. 1) should now be
supported by skinning, and if you need to change the template you can
provide a custom velocity descriptor. it's all self contained. 2) The
navigation is inherited making the menus work without entities.

Honestly, Lukas, Arnaud and Stephane are doing a great job maintaining
and pushing forward on Maven 1.1, so much so that I'm comfortable saying
that I'll never work on it again :) I assume they are aware of the
issues you are having. Particularly for the entities, I believe the
solution is going to be to put Xerces back in the distro as it appears
to just be JDK 1.4 that mishandles the entities.

- Brett

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

svn commit: r383232 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java

Author: billbarker
Date: Sat Mar  4 16:41:25 2006
New Revision: 383232

URL: http://svn.apache.org/viewcvs?rev=383232view=rev
Log:
Allow invoking methods with the same name but different signatures.

Fix for Bug #34959

Modified:

jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java

Modified: 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java?rev=383232r1=383231r2=383232view=diff
==
--- 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java
 (original)
+++ 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java
 Sat Mar  4 16:41:25 2006
@@ -394,7 +394,8 @@
  Method name is null);
 
 if( log.isDebugEnabled()) log.debug(Invoke  + name);
-Method method=(Method)invokeAttMap.get(name);
+   MethodKey mkey = new MethodKey(name, signature);
+Method method=(Method)invokeAttMap.get(mkey);
 if( method==null ) {
 if (params == null)
 params = new Object[0];
@@ -444,7 +445,7 @@
   Cannot find method  + name +
with this signature);
 }
-invokeAttMap.put( name, method );
+invokeAttMap.put( mkey, method );
 }
 
 // Invoke the selected method on the appropriate object
@@ -1376,5 +1377,41 @@
 if( resource instanceof MBeanRegistration ) {
 ((MBeanRegistration)resource).postDeregister();
 }
+}
+
+static class MethodKey {
+   private String name;
+   private String[] signature;
+
+   MethodKey(String name, String[] signature) {
+   this.name = name;
+   if(signature == null) {
+   signature = new String[0];
+   }
+   this.signature = signature;
+   }
+
+   public boolean equals(Object other) {
+   if(!(other instanceof MethodKey)) {
+   return false;
+   }
+   MethodKey omk = (MethodKey)other;
+   if(!name.equals(omk.name)) {
+   return false;
+   }
+   if(signature.length != omk.signature.length) {
+   return false;
+   }
+   for(int i=0; i  signature.length; i++) {
+   if(!signature[i].equals(omk.signature[i])) {
+   return false;
+   }
+   }
+   return true;
+   }
+
+   public int hashCode() {
+   return name.hashCode();
+   }
 }
 }



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

DO NOT REPLY [Bug 34959] - [modeler] Overloaded operations throw wrong number of parameters exception

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=34959.
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=34959


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-05 01:42 ---
This is fixed now in the SVN trunk.

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

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

svn commit: r383233 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/Registry.java

Author: billbarker
Date: Sat Mar  4 16:47:22 2006
New Revision: 383233

URL: http://svn.apache.org/viewcvs?rev=383233view=rev
Log:
Fix obvious (but deadly :) typo.

Fix for Bug #34064

Modified:

jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/Registry.java

Modified: 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/Registry.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/Registry.java?rev=383233r1=383232r2=383233view=diff
==
--- 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/Registry.java
 (original)
+++ 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/Registry.java
 Sat Mar  4 16:47:22 2006
@@ -505,7 +505,7 @@
  * @deprecated Use the instance method
  */
 public static void setServer(MBeanServer mbeanServer) {
-Registry.getRegistry().setServer(mbeanServer);
+Registry.getRegistry().setMBeanServer(mbeanServer);
 }
 
 /**



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

DO NOT REPLY [Bug 34064] - [modeler] setServer stack overflow

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=34064.
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=34064


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-05 01:48 ---
This is now fixed in the SVN trunk

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

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

svn commit: r383235 - /jakarta/commons/proper/io/trunk/xdocs/bestpractices.xml

Author: scolebourne
Date: Sat Mar  4 16:53:09 2006
New Revision: 383235

URL: http://svn.apache.org/viewcvs?rev=383235view=rev
Log:
Fix copyright date

Modified:
jakarta/commons/proper/io/trunk/xdocs/bestpractices.xml

Modified: jakarta/commons/proper/io/trunk/xdocs/bestpractices.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/xdocs/bestpractices.xml?rev=383235r1=383234r2=383235view=diff
==
--- jakarta/commons/proper/io/trunk/xdocs/bestpractices.xml (original)
+++ jakarta/commons/proper/io/trunk/xdocs/bestpractices.xml Sat Mar  4 16:53:09 
2006
@@ -1,6 +1,6 @@
 ?xml version=1.0?
 !--
-Copyright 2002-2005 The Apache Software Foundation.
+Copyright 2002-2006 The Apache Software Foundation.
  
 Licensed under the Apache License, Version 2.0 (the License);
 you may not use this file except in compliance with the License.



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

svn commit: r383237 - /jakarta/commons/proper/io/trunk/xdocs/tasks.xml

Author: scolebourne
Date: Sat Mar  4 16:55:52 2006
New Revision: 383237

URL: http://svn.apache.org/viewcvs?rev=383237view=rev
Log:
Indicate current task status

Modified:
jakarta/commons/proper/io/trunk/xdocs/tasks.xml

Modified: jakarta/commons/proper/io/trunk/xdocs/tasks.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/xdocs/tasks.xml?rev=383237r1=383236r2=383237view=diff
==
--- jakarta/commons/proper/io/trunk/xdocs/tasks.xml (original)
+++ jakarta/commons/proper/io/trunk/xdocs/tasks.xml Sat Mar  4 16:55:52 2006
@@ -1,6 +1,6 @@
 ?xml version=1.0?
 !--
-Copyright 2002-2005 The Apache Software Foundation.
+Copyright 2002-2006 The Apache Software Foundation.
  
 Licensed under the Apache License, Version 2.0 (the License);
 you may not use this file except in compliance with the License.
@@ -28,7 +28,7 @@
 liA proper user guide/li
 liA FileWriter that takes an encoding (base on 
LockableFileWriter)/li
 liA URLUtils class that has many of the FileUtils operations, but 
for a URL/li
-liFilePoller for telling when a file changes. Look in Tomcat, or 
GenJava[bayard]/li
+liFilePoller for telling when a file changes. Look in Tomcat, or 
GenJava[bayard] (One implemented in bugzilla awaiting investigation)/li
 liA hot folder handler which triggers an action when a new file 
has been uploaded to an FTP directory, for example./li
 liJoinReader/ConcatReader. One in GenJava, one submitted to 
Bayard/li
 liFormattedWriter, when it writes out values it uses Format objects 
to output them. /li



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

svn commit: r383238 - /jakarta/commons/proper/io/trunk/project.properties

Author: scolebourne
Date: Sat Mar  4 16:56:57 2006
New Revision: 383238

URL: http://svn.apache.org/viewcvs?rev=383238view=rev
Log:
Remove unused todo tag

Modified:
jakarta/commons/proper/io/trunk/project.properties

Modified: jakarta/commons/proper/io/trunk/project.properties
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/project.properties?rev=383238r1=383237r2=383238view=diff
==
--- jakarta/commons/proper/io/trunk/project.properties (original)
+++ jakarta/commons/proper/io/trunk/project.properties Sat Mar  4 16:56:57 2006
@@ -31,7 +31,6 @@
 maven.javadoc.author=false
 maven.javadoc.links=http://java.sun.com/j2se/1.4/docs/api/
 maven.javadoc.source=1.3
-maven.javadoc.additionalparam=-tag todo:a:To Do:
 maven.javadoc.overview=src/java/org/apache/commons/io/overview.html
 
 maven.checkstyle.properties=checkstyle.xml



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

Re: Problems...

2006-03-04 Thread Arnaud HERITIER

SNIP/



 Honestly, Lukas, Arnaud and Stephane are doing a great job maintaining
 and pushing forward on Maven 1.1, so much so that I'm comfortable saying
 that I'll never work on it again :) I assume they are aware of the
 issues you are having. Particularly for the entities, I believe the
 solution is going to be to put Xerces back in the distro as it appears
 to just be JDK 1.4 that mishandles the entities.


Yes, we are aware about these problems.
We'll ensure that maven 1.1 will allow the commons-dev team to build their
projects.
For the entities problem, we'll certainly put back xerces in the core. I
have also the idea to enhance the xdoc plugin to allow the user to apply a
custom template to the navigation file. I'll do it for the plugins sites in
maven to share our commons links.

Cheers,


Arnaud.

Re: Problems...

On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
 Yes we have many, many problems.

 Site
 Is this really our top priority? Is maven 2 helping here? Is maven 1? I
 have a distinct memory that commons was used as a practice ground pre
 maven-1 to test maven's functionality in a real deployment. Are we about
 to subject ourselves to this again?

Good point.  Agree we want to keep this simple.

 Inactivity
 Dormant has helped clarify the position. But are we willing to kick
 [beanutils] and [dbcp] into dormant? Since all user requests and bugs
 seem to have been ignored for many months, surely they are dormant? I
 await the screams from the wider community...

IMO this is our biggest problem and it has nothing to do with sites,
list noise or how we are organized.  Don't know how to solve it other
than maybe trying a little collective prioritization.  By that I mean
that we maybe agree to focus together for a bit on the two that you
mention above, for example. Don't know exactly how that might work,
but its worth thinking about.


 CI
 How does another thing to worry about help us. Why not focus on Gump?

+1 - Gump works

 Commons as the solution
 We're not. We're barely holding our head above water.

Some better than others ;-)  ... gulp, gasp...

 Leadership
 Something Apache counsels against. Often however, the most successful
 projects have a leader who drives the project forward and on occaisions
 takes decisions. In commons we do have this, but only at the component
 level. We feel unwilling, or are unable, or don't want, a cross commons
 leader a lot of the time.

I don't know about that.  We may have some differences of opinion, but
usually when someone steps up with ideas to help make things better,
we listen collectively.  Like any apache project, we have to make
decisions by consensus, but I hope no one feels like it is not
possible to get anything done here.  Put another way, the same talk a
little, do it and see if the community complains attitude that allows
us to move components along should work for the community stuff.  The
site build mess is a good example. It was painful a couple of years
ago when we got the initial maven site working, but those who drove it
(Mark, Tim and a few others) used JFDI and we all showed patience and
respect for the doers.

If what you mean is focussing efforts and developing action plans for
all of commons, that is an interesting idea that I bet we could do the
same way we do for the components.  Maybe what you are suggesting
below is that we are too big to do that for all of the commons and
could be you are right, but I don't think we have ever really tried. 
The ComminsPeople Wiki page was a first step in that direction.  Maybe
now it is time to think about taking this a couple of steps further.


 My analysis is that its time for a bit more radical surgery. And I mean
 splitting commons into smaller communities. Jakarta Xxx Components sets
 the naming pattern. If we do this, then each new group will be small
 enough to be able to take decisions by itself, for example on the site.

Do you really think the problem is taking decisions?  I think our
biggest challenge is growing and maintaining communities around all of
the code and maintaining quality, consistency and responsiveness
across all of the components.  The only advantage to disaggregation
for that is reduced list noise.  But that also might reduces
visibility / itch-generation.  I also worry about fragmenting the
relatively small active committer base and losing the economies of
scale (common build and release process, for example - painful as it
is to agree and make it work - saves time for all).  Can you explain a
little more what you see the other advantages of splitting things up
to be?

Thanks for bringing this stuff up.

Phil

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

[io] Release 1.2


I am proposing that we release [io] v1.2

RC1 is here:
http://people.apache.org/~scolebourne/commons-io/

Site here:
http://people.apache.org/~scolebourne/commons-io/site/

Not that much has changed (line iterator, two more filters, copy 
directory), but its nice to release early for once.



Any objections, otherwise it'll move to a vote based on these files.

Stephen

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

Re: Problems...

On 3/4/06, Henri Yandell [EMAIL PROTECTED] wrote:
 On 3/4/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
  On 3/3/06, Henri Yandell [EMAIL PROTECTED] wrote:
snip/

 My site issues are information-architecture/design issues - I think
 it's too noisy and big, in many places we don't pay attention to user
 manuals but spend too much space on the basic info and we don't treat
 the documentation properly in releases. The cop-out is to have a site
 per release, but that's ignoring the issue that our sites and
 documentation are intermingled.

snap/

Makes sense to explore long term solutions. For the short term, what
bit of the documentation do you think we don't treat properly? Some
components have started creating per release doc menus, which we
should encourage for now, as an example, see [digester] or [logging].
Also feel free to add any suggestions to:

http://wiki.apache.org/jakarta-commons/ReleaseChecking

That way we can collectively make sure we're hitting the mark.


 This one is more repeating complaints I've heard from people who
 struggle to get involved with Commons. I do think it's a problem on
 getting people involved - Commons should be the easiest project to get
 involved in as the codebase is very modular and you don't have to
 understand a big huge design. However the mailing list is detrimental
 to the newcomer to open-source, it's not a nice one to make your first
 subscribed mailing list.

 No idea on solutions though. Maybe we just acknowledge that newcomers
 to open-source aren't the target audience and focus on committers of
 other projects.

snip/

Oh well ... thats a tough one, IMO. I think we are quite welcoming to
newcomers or otherwise on these lists, but ofcourse, my opinion
doesn't help if that is the general perception ;-) Some of this goes
back to dormancy as well, posts for dormant components tend to get
little responses, and may lead to puzzlement.


 
  Commons or Web Components, as appropriate?

 Web Components would be a grouping in a unified Commons/Jakarta :)

snap/

OK, I see ;-)


 First step - buy a usb key and get PGP setup on my Mac to point to it.
 Some old memories that releasing on Macs was problematic (Java-wise),
 but hopefully that's old news.

 Second step - volunteer to do releases. SCXML getting close then?

snip/

I think so. I got a second opinion from Tim a couple of months back
(its all in the archives), where he pointed to a couple of things that
he thought should be fixed before a release (optimal parsing and
documentation -- see bugzilla tickets on scxml). Fixed the first, user
guide / docs should be in good shape in about a week. Independent
opinions are always welcome.


   We've recently raised issues in managing the sandbox promotion/failure 
   cycle.
  
  snap/
 
  I think we've become increasingly particular about sandbox promotion,
  and correctly so. I also think we should perhaps cap the sandbox stay
  for a component, lest it be left at almost promoted state forever.
  That doesn't help anyone.

 Current state is that at 6 months old a component gets voted on dormancy.

snap/

I'm aware of the 6 month SVN inactivity metric (which really works on
lazy consensus, rather than a vote -- but you know that ;-). I was
probably a bit unclear in that part of my last post, I was thinking
more in terms of whether we can / should make an effort in watching
out for early signs and avoiding getting into [feedparser] like
situations. SVN dormancy is the effect, there are many causes.

Few others (not comparing to FP) that come to mind in the almost
released category (in proper, but not released) are:

 * [resources] Since now it isn't part of Struts 1.3.0, seems thats a
setback to interest in releasing.

 * [vfs] Given the [compress] faux pas, seems we've stalled a release.

We should watch for situations like these, lest it lead to some
frustration down the road. I'd like to help both, currently lacking
cycles.

-Rahul

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

svn commit: r383268 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java

Author: billbarker
Date: Sat Mar  4 18:02:01 2006
New Revision: 383268

URL: http://svn.apache.org/viewcvs?rev=383268view=rev
Log:
Fix the case of the ObjectReference.

Fix for Bug #30647

Modified:

jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java

Modified: 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java?rev=383268r1=383267r2=383268view=diff
==
--- 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java
 (original)
+++ 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java
 Sat Mar  4 18:02:01 2006
@@ -389,7 +389,7 @@
 // Set the managed resource (if any)
 try {
 if (instance != null)
-mbean.setManagedResource(instance, objectReference);
+mbean.setManagedResource(instance, ObjectReference);
 } catch (InstanceNotFoundException e) {
 throw e;
 } catch (InvalidTargetObjectTypeException e) {



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

DO NOT REPLY [Bug 30547] - [modeler] ManagedBean uses the wrong case for ObjectReference

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=30547.
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=30547


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-05 03:03 ---
This has been fixed in the SVN trunk

-- 
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: [io] Release 1.2

On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
 I am proposing that we release [io] v1.2

 RC1 is here:
 http://people.apache.org/~scolebourne/commons-io/

 Site here:
 http://people.apache.org/~scolebourne/commons-io/site/

snip/

How many releases back should we document online? In other words,
should we have documentation sections for 1.0, 1.1 and 1.2?

Haven't checked the RC, but agree to early releasing. Thanks for taking this on.

-Rahul


 Not that much has changed (line iterator, two more filters, copy
 directory), but its nice to release early for once.


 Any objections, otherwise it'll move to a vote based on these files.

 Stephen


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

Re: Problems...

On 3/4/06, Brett Porter [EMAIL PROTECTED] wrote:
snip/

 The thing to consider here is that the site is really hard to work with.
 Some others have gone through considerable pain to get it in a working
 state. So, if there are issues in the future they will be harder to work
 through, and if Hen's design/IA concerns yield suggestions that require
 changes to the structure or appearance of the site, someone is going to
 have to go through that pain again.

 That's not a reason to change now, but its a reason to investigate it
 which is why I'm doing it.

snap/

I understand, and thanks for investigating.

-Rahul


 - Brett


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

Re: Problems...

On 3/4/06, Brett Porter [EMAIL PROTECTED] wrote:
 Phil Steitz wrote:
  I agree with you, Brett and think our goal should be to make it as
  simple as possible to maintain the site.  I also like to be able to
  generate individual component sites individually.  There are two
  things in the current setup that create challenges:

 These are what my m2 changes were designed to address. 1) should now be
 supported by skinning, and if you need to change the template you can
 provide a custom velocity descriptor. it's all self contained. 2) The
 navigation is inherited making the menus work without entities.

snip/

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

Re: Problems...

On 3/4/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
 On 3/4/06, Brett Porter [EMAIL PROTECTED] wrote:
 snip/
 
  The thing to consider here is that the site is really hard to work with.
  Some others have gone through considerable pain to get it in a working
  state. So, if there are issues in the future they will be harder to work
  through, and if Hen's design/IA concerns yield suggestions that require
  changes to the structure or appearance of the site, someone is going to
  have to go through that pain again.
 
  That's not a reason to change now, but its a reason to investigate it
  which is why I'm doing it.
 
 snap/

 I understand, and thanks for investigating.

snip/

Apologies for the previous blank email.

Just wanted to ask whether this has anything to do with m1 build files
not being available for {exec,openpgp} ? If not, they'd be nice to
have, IMO (I can add them too, its not a big task -- I hope).

-Rahul


 -Rahul


  - Brett
 


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

Re: Problems...

Rahul Akolkar wrote:
 Apologies for the previous blank email.
 
 Just wanted to ask whether this has anything to do with m1 build files
 not being available for {exec,openpgp} ? If not, they'd be nice to
 have, IMO (I can add them too, its not a big task -- I hope).

Go ahead, if you need them. I use m2, so I added those. The others
contributing put in an ant script I think, at least for exec. The site
will require m2 for now, but that's an issue to tackle at promotion
time. I'd really rather not write xdocs any more :)

- Brett

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

svn commit: r383269 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java

Author: billbarker
Date: Sat Mar  4 18:22:41 2006
New Revision: 383269

URL: http://svn.apache.org/viewcvs?rev=383269view=rev
Log:
Send notification *after* an attribute has been set instead of before.

Fix for Bug #32362
Based on a Patch by:  Philippe Mouawad  

Modified:

jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java

Modified: 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java?rev=383269r1=383268r2=383269view=diff
==
--- 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java
 (original)
+++ 
jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java
 Sat Mar  4 18:22:41 2006
@@ -569,16 +569,10 @@
 if (attrDesc == null)
 throw new AttributeNotFoundException(Cannot find attribute  + 
name +  descriptor);
 
-try {
-// XXX Is it before or after ?
-Object oldValue=null;
-if( getAttMap.get(name) != null )
-oldValue=getAttribute( name );
-sendAttributeChangeNotification(new Attribute( name, oldValue),
-attribute);
-} catch( Exception ex ) {
-log.error( Error sending notification  + name, ex );
-}
+Object oldValue=null;
+if( getAttMap.get(name) != null )
+oldValue=getAttribute( name );
+
 
 // Extract the method from cache
 Method m=(Method)setAttMap.get( name );
@@ -644,7 +638,12 @@
 throw new MBeanException
 (e, Exception invoking method  + name);
 }
-
+try {
+sendAttributeChangeNotification(new Attribute( name, oldValue),
+attribute);
+} catch(Exception ex) {
+log.error(Error sending notification  + name, ex);
+}
 attributes.put( name, value );
 if( source != null ) {
 // this mbean is asscoiated with a source - maybe we want to 
persist



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

DO NOT REPLY [Bug 32362] - [modeler] AttributeChangeNotification sent before attribute changes

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=32362.
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=32362


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-05 03:24 ---
I agree that it doesn't make sense to send the notification before the 
attribute value has been sent.

Your patch has been partially applied to the SVN trunk.

-- 
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: Problems...

On 3/4/06, Brett Porter [EMAIL PROTECTED] wrote:
 Rahul Akolkar wrote:
  Apologies for the previous blank email.
 
  Just wanted to ask whether this has anything to do with m1 build files
  not being available for {exec,openpgp} ? If not, they'd be nice to
  have, IMO (I can add them too, its not a big task -- I hope).

 Go ahead, if you need them. I use m2, so I added those. The others
 contributing put in an ant script I think, at least for exec. The site
 will require m2 for now, but that's an issue to tackle at promotion
 time. I'd really rather not write xdocs any more :)

snip/

Ah, the ant builds should do it for me. Just wanted to build and try a
couple of things (after a few other things first ;-).

-Rahul


 - Brett


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

DO NOT REPLY [Bug 22078] - [DBCP] testOnBorrow fails if setAutoCommit() throws an exception

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=22078.
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=22078


[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||38856
  nThis||




-- 
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 38856] - [pool] Killed user connection causes the setautocomit to fail

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=38856.
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=38856


[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||22078
Summary|Killed user connection  |[pool] Killed user
   |causes the setautocomit to  |connection causes the
   |fail|setautocomit to fail




-- 
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: svn commit: r383268 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java

2006-03-04 Thread Bill Barker


[EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 Author: billbarker
 Date: Sat Mar  4 18:02:01 2006
 New Revision: 383268

 URL: http://svn.apache.org/viewcvs?rev=383268view=rev
 Log:
 Fix the case of the ObjectReference.

 Fix for Bug #30647


Sorry, should have included:
  Submitted By: Kirk Lund 




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

Re: svn commit: r383268 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java

You can use:

svn propedit --revprop -r383268 svn:log

to fix it.

- Brett

Bill Barker wrote:
 [EMAIL PROTECTED] wrote in message 
 news:[EMAIL PROTECTED]
 Author: billbarker
 Date: Sat Mar  4 18:02:01 2006
 New Revision: 383268

 URL: http://svn.apache.org/viewcvs?rev=383268view=rev
 Log:
 Fix the case of the ObjectReference.

 Fix for Bug #30647

 
 Sorry, should have included:
   Submitted By: Kirk Lund 
 
 
 
 
 -
 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]

[Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by RahulAkolkar

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 RahulAkolkar:
http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette

The comment on the change is:
Use true wiki bullets, put [RESULT] before [VOTE] in result emails.

--
  
  A VOTE is an official decision thread. Anyone can express a preference (by 
indicating +1, +0, -0 or -1 in the traditional manner) but only some votes are 
binding. All are encouraged to VOTE but traditionally (to ease the work 
required to tally the vote) ''(non-binding)'' is added by those who know their 
votes are non-binding. Only votes from Jakarta PMC members are binding.
  
- The commons-dev mailing list is a busy place. Very much a bazaar rather than 
a Cathedral. This means that VOTE threads have a habit of petering out. It a 
good idea to post a {{{[VOTE][RESULT]}}} which counts the binding VOTEs and 
tells people the result. The tally should separate binding from non-binding 
VOTES.  It is also good to place a time limit on [VOTE] threads.  Finally, VOTE 
threads often digress into interesting discussions not directly related to the 
VOTE iteslf.  In these cases, it is better to start new threads with 
appropriate subject headers for the side discussions.  This makes it easier to 
navigate the list archives and also keeps the VOTE thread on track (or leads to 
it being stopped, where appropriate).
+ The commons-dev mailing list is a busy place. Very much a bazaar rather than 
a Cathedral. This means that VOTE threads have a habit of petering out. It a 
good idea to post a {{{[RESULT][VOTE]}}} which counts the binding VOTEs and 
tells people the result. The tally should separate binding from non-binding 
VOTES.  It is also good to place a time limit on [VOTE] threads.  Finally, VOTE 
threads often digress into interesting discussions not directly related to the 
VOTE iteslf.  In these cases, it is better to start new threads with 
appropriate subject headers for the side discussions.  This makes it easier to 
navigate the list archives and also keeps the VOTE thread on track (or leads to 
it being stopped, where appropriate).
  
  A POLL is an unofficial decision thread. These are useful for gauging the 
general feeling of the broader user community. Again, preferences should be 
expressed in the usual fashion. In this case, there is no need to indicate 
non-binding (since none are!).
  
@@ -76, +76 @@

  
  Promotion is basically a beauty contest. If the component can win enough 
votes and few enough people vote against it, then the component is promoted. 
But there is one thing that is most definitely required:
  
- * Compliance with Apache Software Foundation policies. This means a full 
license at the top of every file. It means auditing the dependencies. It means 
ensuring the copyright date is correct on the licenses.
+  * Compliance with Apache Software Foundation policies. This means a full 
license at the top of every file. It means auditing the dependencies. It means 
ensuring the copyright date is correct on the licenses.
  
  There some points of etiqutte and a few criteria that (though they are not 
rules) often seem to influence the voting.
  
- * Evidence of compliance with the charter. This means having the documents 
required in the charter including a PROPOSAL. (Please look through the 
charter.) Please list all committers. Something like 'all jakarta-foo 
committers' isn't acceptable - a list is needed. 
+  * Evidence of compliance with the charter. This means having the documents 
required in the charter including a PROPOSAL. (Please look through the 
charter.) Please list all committers. Something like 'all jakarta-foo 
committers' isn't acceptable - a list is needed. 
  
- * A good PROPOSAL. A good PROPOSAL is clearly written and tightly scoped (ie. 
specific rather than general). Commons components are small, resuable 
components. The commons does not do frameworks and anything frameworkesque is 
likely to be viewed with scepticism. A PROPOSAL that duplicates an existing 
component will probably be viewed with suspicion. This is not because 
duplication is disallowed (overlapping components are specifically allowed by 
the charter) but because it indicates that the PROPOSAL fails to indicate the 
essential difference between the proposed component and the existing one. For 
example, a PROSPOSAL for a small, fast, compact xml-object mapper with minimal 
dependencies would be more likely to succeed than a PROPOSAL for 'a better 
version of commons-digester'.
+  * A good PROPOSAL. A good PROPOSAL is clearly written and tightly scoped 
(ie. specific rather than general). Commons components are small, resuable 
components. The commons does not do frameworks and anything frameworkesque is 
likely to be viewed with scepticism. A PROPOSAL that duplicates an existing

Re: [compress] Discussing compress

Replying to a few of these things. Sorry for neglecting the thread so long.

C. Grobmeier wrote:
I noticed, that compress ist divided into three different APIs, one for
every compression algorithm: Zip, BZip2, Tar.

Tar isn't a compression algorithm.

I actually think commons-archiver is a better name (the library I have
used is plexus-archiver [1], which is derived from the same code and I
want to merge them here).

Note that there is also the unpack/decompress portion as well.

Next problem is the lack of a commonly used interface: it seems one have
to learn everything about the 3 components to use it. This is quite
uncomfortable.

I totally agree. See [2]. Currently this focuses on just a single
creation task, not updating an existing one. I think this API can remain
though, and create() fails if it already existed, update() fails if it
doesn't.

Here are the keypoints. Compress should be used to:

- load or create an existing compressed file,
- add files to compressed file,
- compress a file,
- return a list of stored files
- delete a single file from the compressed file
- in a later release: set special fields, like zip-fields

+1.

Piero Ottuzzi wrote:
Hi Chris,

I was thinking that something like
Compress.getInstance(String compressorType);
like Crypto would be nice.
This way you can get a unique entry point for every compression
algorithm
that can provide its own methods to compress/decompress/add files etc etc.

I agree, but it should be an optional extra. Everything should be able
to be built from a bean with a public empty constructor so I can use
plexus to instantiate them (as you'll see from [3]). Other constructors
and factories are fine as long as they aren't required. BTW, if I use
factories, I usually instantiate them and they have a list of available
providers, then loop through and find ones based on requests, rather
than using the static getInstance( ... ) style because of this. I don't
know what others think of that.

For this to work you need a configuration file, and later it might be
fine to have something like Compress.getInstance(InputStream is).
Often it is not possible to determine the compression based on the
filename extension, you might have to look at the stream or its mime type.

So I think this should be solved by a higher level api.

Said that, I think this should be the part where commons-vfs comes in.

It already provides a unique api to access a wide variety of
filesystems/types.

I disagree, I think this would be useful in compress without vfs. I'm
thinking something like:

Archiver {
boolean canReadFile( File )
boolean canReadStream( InputStream )
bollean canReadMimeType( String )
}

This might just check the extension, or might read the signature or mime
type. That would allow the factory I mentioned above to loop over them,
making plugging in new ones very easy.

Mario Ivankovits wrote:
... but be sure to
only work with streams in your public API. So you might have to
decompress and recompress the archive in a local temp folder to make
those operations work.

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

C. Grobmeier wrote:
Sounds good to me.
Having this in mind, i will try to write some simple files as a basis at
the weekend.

How do i proceed then? Sending it to this list? Creating an bugzilla
issue?

I don't recall seeing anything come in. Is this still happening? If not,
can we kick it off again?

Cheers,
Brett

[1]
http://cvs.codehaus.org/viewrep/plexus/trunk/plexus-components/plexus-archiver
[2]
http://cvs.codehaus.org/viewrep/plexus/trunk/plexus-components/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/Archiver.java?r=2989
[3]
http://cvs.codehaus.org/viewrep/plexus/trunk/plexus-components/plexus-archiver/src/main/resources/META-INF/plexus/components.xml?r=2989

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

Re: svn commit: r383220 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java

I don't see how this benefits anything and it has a negative effect on
the whole JVM.

I would think it's common to use a LineIterator entirely in one method
which means an instance could live entirely in the eden space. The
presence of a finalizer method causes the JVM to register the object
in a queue that eventually executes the finalize method. Since this is
another thread this forces the JVM to promote the object from eden
space to old space in the heap and it requires more work to garbage
collect old space compared to the eden space.

I can dig up more but I found this with a quick google:
http://www-128.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
http://www.javaperformancetuning.com/news/interview041.shtml (see last QA)

Also, I don't see any resource leak in my read of the LineIterator
code. I see a resource clean up delay, if there is such a concept, but
no leak.
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java?view=markup

On 3/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Author: scolebourne
 Date: Sat Mar  4 15:18:46 2006
 New Revision: 383220

 URL: http://svn.apache.org/viewcvs?rev=383220view=rev
 Log:
 Add finalize method

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

 Modified: 
 jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
 URL: 
 http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java?rev=383220r1=383219r2=383220view=diff
 ==
 --- 
 jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
  (original)
 +++ 
 jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
  Sat Mar  4 15:18:46 2006
 @@ -150,6 +150,14 @@
  throw new UnsupportedOperationException(Remove unsupported on 
 LineIterator);
  }

 +/**
 + * Finalize which closes the underlying reader.
 + * Do not rely on this method to handle cleanup - call closeQuietly 
 yourself.
 + */
 +protected void finalize() throws Throwable {
 +close();
 +}
 +
  //---
  /**
   * Closes the iterator, handling null and ignoring exceptions.



--
Sandy McArthur

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

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

Re: svn commit: r383224 - /jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java

How about a Thread.sleep() instead of a busy wait? eg:

private void spin(long now) {
  long end = now  +1000;
  while (System.currentTimeMillis() = end) {
Thread.sleep(Math.max(1, end - System.currentTimeMillis()));
  }
}

On 3/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Author: scolebourne
 Date: Sat Mar  4 15:24:49 2006
 New Revision: 383224

 URL: http://svn.apache.org/viewcvs?rev=383224view=rev
 Log:
 Allow one second to avoid test failures

 Modified:
 
 jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java

 Modified: 
 jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
 URL: 
 http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java?rev=383224r1=383223r2=383224view=diff
 ==
 --- 
 jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
  (original)
 +++ 
 jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
  Sat Mar  4 15:24:49 2006
 @@ -524,7 +524,7 @@
  }

  private void spin(long now) {
 -while (System.currentTimeMillis() = now);
 +while (System.currentTimeMillis() = now + 1000);
  }

  }



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




--
Sandy McArthur

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

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

Re: [io] Release 1.2

On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
 I am proposing that we release [io] v1.2

 Not that much has changed (line iterator, two more filters, copy
 directory), but its nice to release early for once.

 Any objections, otherwise it'll move to a vote based on these files.

I don't think LineIterator should have a finalizer method and I
believe the JavaDocs in that class about resource leaks are wrong and
unnecessarily alarming.

--
Sandy McArthur

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

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

Re: svn commit: r383268 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java

2006-03-04 Thread Bill Barker


Brett Porter [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 You can use:

 svn propedit --revprop -r383268 svn:log

 to fix it.


Thanks for the info :).

 - Brett

 Bill Barker wrote:
 [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
 Author: billbarker
 Date: Sat Mar  4 18:02:01 2006
 New Revision: 383268

 URL: http://svn.apache.org/viewcvs?rev=383268view=rev
 Log:
 Fix the case of the ObjectReference.

 Fix for Bug #30647


 Sorry, should have included:
   Submitted By: Kirk Lund




 -
 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: r383273 - /jakarta/commons/proper/modeler/trunk/project.xml

2006-03-04 Thread brett

Author: brett
Date: Sat Mar  4 19:35:01 2006
New Revision: 383273

URL: http://svn.apache.org/viewcvs?rev=383273view=rev
Log:
update Maven descriptor

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

Modified: jakarta/commons/proper/modeler/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/modeler/trunk/project.xml?rev=383273r1=383272r2=383273view=diff
==
--- jakarta/commons/proper/modeler/trunk/project.xml (original)
+++ jakarta/commons/proper/modeler/trunk/project.xml Sat Mar  4 19:35:01 2006
@@ -39,18 +39,17 @@
   /organization
 
   licenses
-   license
-   nameThe Apache Software License, Version 2.0/name
-   url/LICENSE.txt/url
-   distributionrepo/distribution
-   /license
+license
+  nameThe Apache Software License, Version 2.0/name
+  url/LICENSE.txt/url
+  distributionrepo/distribution
+  /license
   /licenses
   
   gumpRepositoryIdjakarta/gumpRepositoryId
   issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
-  siteAddressjakarta.apache.org/siteAddress
+  siteAddressminotaur.apache.org/siteAddress
   
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
-  
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
   
   repository
 
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
@@ -98,8 +97,8 @@
 
 dependency
   groupIdcommons-logging/groupId
-  artifactIdcommons-logging/artifactId
-  version1.0/version
+  artifactIdcommons-logging-api/artifactId
+  version1.0.4/version
 /dependency
 
 dependency
@@ -109,12 +108,6 @@
 /dependency
 
 dependency
-  groupIdmx4j/groupId
-  artifactIdmx4j-tools/artifactId
-  version1.1/version
-/dependency
-
-dependency
   groupIdxml-apis/groupId
   artifactIdxml-apis/artifactId
   version2.0.2/version
@@ -124,12 +117,18 @@
   groupIdjunit/groupId
   artifactIdjunit/artifactId
   version3.7/version
+  properties
+scopetest/scope
+  /properties
 /dependency
 
 dependency
   groupIdant/groupId
   artifactIdant/artifactId
   version1.5/version
+  properties
+optionaltrue/optional
+  /properties
 /dependency
 
   /dependencies
@@ -154,8 +153,8 @@
   /build
   
   reports
-   reportmaven-changelog-plugin/report
-   reportmaven-changes-plugin/report
+reportmaven-changelog-plugin/report
+reportmaven-changes-plugin/report
 reportmaven-developer-activity-plugin/report
 reportmaven-file-activity-plugin/report
 reportmaven-javadoc-plugin/report



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

[Jakarta-commons Wiki] Update of Pool by SandyMcArthur

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 SandyMcArthur:
http://wiki.apache.org/jakarta-commons/Pool

The comment on the change is:
updated synchronize faq question

--
  Q: If I have multiple threads calling into my method which contains the 
borrowObject call,
  do I have to synchronize around this, or are borrowObject and returnObject 
thread safe?
  
- A: They appear to be thread safe. I haven't extensively studied the source 
the relevant code is synchronized.
+ A: It's implementation dependent. The implementations that come in the 
official download are thread safe. Of course it is possible this may change in 
the future if new implementations are added to the package. Be sure to check 
the !JavaDocs.
  
  
  Q: What is the general purpose of pooling Interfaces ?

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

[Jakarta-commons Wiki] Update of PoolRoadMap by SandyMcArthur