Re: [ALL] parent pom - update RAT version

[Simone Tripodi]

+1 :)
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Sep 2, 2011 at 4:37 AM, Gary Gregory  wrote:
> Go for it !  :)
>
> Gary
>
> On Sep 1, 2011, at 21:40, sebb  wrote:
>
>> The current parent pom (21) references an old RAT plugin which is not
>> the current Apache version (in Incubator, but available from Maven
>> Central).
>>
>> Also it does not define the plugin in the build or
>> dependencyManagement sections.
>>
>> I propose to correct this for the next parent release.
>>
>> Comments?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Running lang under a security manager and LANG-744

[Stephen Colebourne]

On 2 September 2011 01:20, Gary Gregory  wrote:
> Specifically for StringUtils, should we have a SunStringUtils? This would
> let you know that you are depending on com.sun code.

I really don't like that idea!

Generally, it is non-Sun JVMs including Android that are the problem.
Lets just do the best we can on those.

Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] parent pom - update RAT version

[Gary Gregory]

Go for it !  :)

Gary

On Sep 1, 2011, at 21:40, sebb  wrote:

> The current parent pom (21) references an old RAT plugin which is not
> the current Apache version (in Incubator, but available from Maven
> Central).
>
> Also it does not define the plugin in the build or
> dependencyManagement sections.
>
> I propose to correct this for the next parent release.
>
> Comments?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Monitoring iterative algorithms

[Sébastien Brisard]

I forgot a very important question: would this classes be applicable
to ODEs (see Luc's explanations below). If not, I can probably forget
about them, since, I think this package makes the most extensive use
of events at the moment in CM...
Sébastien
>
> So here are the needs for ODE:
>  - callbacks for regular steps when they complete, without
>   any feedback with the algorithm. This is now implemented using
>   StepHandler and FixedStepHandler and the handlerStep method is void,
>   so from the algorithm point of view this monitoring is almost no-op.
>  - callbacks for discrete events, which may provide feedback to the
>   algorithm. This is now implemented using EventHandler and requires
>   a function to define the event (the g function, events occurring at
>   sign changes) and a function to be triggered when the events occurs
>   (the eventOccurred function, which provides the current state and
>   which return value is used by the algorithm to know what to do next,
>   i.e. continue/stop/reset state/reset derivatives.
>
> These needs are really, really important and in fact are one of the main
> feature in Commons Math ODE (and prior to that from Mantissa) that was often
> praised by users.
>
> Do you think we should design something now for 3.0 or should it wait 4.0 ?
> I would love to have such a new feature soon, but fear it could delay 3.0
> too much.
>
> Luc
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ALL] parent pom - update RAT version

[sebb]

The current parent pom (21) references an old RAT plugin which is not
the current Apache version (in Incubator, but available from Maven
Central).

Also it does not define the plugin in the build or
dependencyManagement sections.

I propose to correct this for the next parent release.

Comments?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Monitoring iterative algorithms

[Sébastien Brisard]

Hi,
I'm reviving this thread to let you know that I took the liberty to
create a new JIRA ticket on this issue (see JIRA MATH-655). A few
classes are attached to this ticket for you to review. These classes
provide support for managing the iteration count as well as event
occuring before, during and after the main iteration loop. These
classes do *not* provide yet support for stopping criterion. I am
willing to have a go at this, but it seems it will be difficult to get
it right (see discussions on MATH-413) [1], and I would like to keep
in mind Phil's recommendations
>
> I think if you are careful, you can likely set this up so that you
> can continue to add features to the event framework (or even add the
> framework itself) and stopping criteria without breaking backward
> compatibility in 3.x releases.
>
> I would like to see this in 3.0 if you can get something simple
> completed that can be enhanced incrementally in 3.x and possibly
> refactored in 4.0.
>

Do you think the proposed classes could be useful? Do you think the
above requirements are fulfilled? If the answers are yes, where should
they go?

Best regards,
Sébastien

[1] Whatever is done on stopping criteria, I think that one important
point made in MATH-413 is that a default stopping criterion should be
hard-coded in the algorithm, for two reasons: i. implementation is
usually straightforward (e.g. the residual is already available, and
does not need to be recomputed), and ii. end-users might well be very
happy with this default stopping criterion. So, the stopping criteria
we are talking about here should really be understood as *additional*
stopping criteria.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1164051 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java

[Phil Steitz]

On 9/1/11 6:31 PM, sebb wrote:
> On 2 September 2011 01:23, Phil Steitz  wrote:
>> On 9/1/11 4:59 PM, Mark Thomas wrote:
>>> On 02/09/2011 00:40, Phil Steitz wrote:
 On 9/1/11 5:41 AM, ma...@apache.org wrote:
> Author: markt
> Date: Thu Sep  1 12:41:54 2011
> New Revision: 1164051
>
> URL: http://svn.apache.org/viewvc?rev=1164051&view=rev
> Log:
> Remove sync that wasn't helping.
> Make thread safe
 I agree that the sync wasn't helping; but I am not sure exactly what
 "thread safe" means for this method.
>>> For me, thread safe means that a local copy is taken for any value used
>>> more than once that needs to be consistent between uses. I'm not sure we
>>> can do much more without tying ourselves in synchronisation knots.
>>>
 I have always worried about
 this method.  I have usually been able to convince myself that it's
 incorrectness is harmless (i.e., there are guards to prevent pool
 invariants being violated due to incorrect / inconsistent return
 value), but I am not sure that is right.
>>> My analysis was that if you reduce the limits (maxTotal, maxIdle etc.)
>>> while this method is executing then there is a risk that it could exceed
>>> those limits. However, there is a fair chance that the pool will already
>>> be exceeding the limits when the limits are changed. Therefore, there is
>>> actually very little difference between these two scenarios. In both
>>> cases the pool will conform to the limits as soon as circumstances allow
>>> and once operating within the limits, will not exceed them.
>> I have never worried much about races against setters for maxTotal,
>> MaxIdle, though it is good to fix this as you did.  What I have
>> always worried about is that once we removed the sync on this and
>> the pool statistics getters, what it computes becomes suspect.  For
>> example, if things enter / exit the idle object pool between the
>> time objectDeficit and growLimit are computed, the return value will
>> be incorrect.  As I said, IIRC previous traces through the code, the
>> use of the return value has guards to prevent too much badness from
>> this; but since the correctness of the computation done inside this
>> method depends on the idle instance pool keeping the same size over
>> the duration of its execution, it is neither really threadsafe nor
>> correct.
 It might be good to
 temporarily make this method protected and run some concurrency
 tests directly against it, so we can understand and document what
 happens when instances come in and out of the pool while it is
 executing.
>>> I'm not against that but I don't have the time to do it right now and am
>>> unlikely to any time soon.
>> I will do some tracing and more analysis of the code to verify that
>> the problems that I think may exist in the correctness (or maybe
>> meaningfulness) of the return value are harmless.
> There's another threading issue - the JVM can cache shared variables
> locally in a thread.
> i.e. a reader thread may not see the latest copies of of all variables
> written by another thread.
> (in theory it might even see a half-written long variable)
>
> This is easily fixed by making variables volatile, but that can have a
> performance impact.

The problem that I am referring to has nothing to do with member
fields.  I think Mark's change does all that is necessary to ensure
that the member fields are read consistently.  The problem is that
objectDeque.getIdleObjects().size() is read twice in the method and
can change during execution or after execution before the value is
used.  As I said, there are guards in place (I think) to ensure that
incorrectness of the value returned is harmless; but we dig into the
code and convince ourselves that that is still true.

Phil
>
>> Phil
>>> Mark
>>>
>>>
 Phil
> Modified:
> 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>
> Modified: 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java?rev=1164051&r1=1164050&r2=1164051&view=diff
> ==
> --- 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>  (original)
> +++ 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>  Thu Sep  1 12:41:54 2011
> @@ -1577,25 +1577,30 @@ public class GenericKeyedObjectPool
>   * @param pool the ObjectPool to calculate the deficit for
>   * @return The number of objects to be created
>   */
> -private synchronized int calculateDeficit(ObjectDeque 
> objectDeque) {
> +private int calculateDeficit(ObjectDeque objectDeque

Re: svn commit: r1164051 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java

[sebb]

On 2 September 2011 01:23, Phil Steitz  wrote:
> On 9/1/11 4:59 PM, Mark Thomas wrote:
>> On 02/09/2011 00:40, Phil Steitz wrote:
>>> On 9/1/11 5:41 AM, ma...@apache.org wrote:
 Author: markt
 Date: Thu Sep  1 12:41:54 2011
 New Revision: 1164051

 URL: http://svn.apache.org/viewvc?rev=1164051&view=rev
 Log:
 Remove sync that wasn't helping.
 Make thread safe
>>> I agree that the sync wasn't helping; but I am not sure exactly what
>>> "thread safe" means for this method.
>> For me, thread safe means that a local copy is taken for any value used
>> more than once that needs to be consistent between uses. I'm not sure we
>> can do much more without tying ourselves in synchronisation knots.
>>
>>> I have always worried about
>>> this method.  I have usually been able to convince myself that it's
>>> incorrectness is harmless (i.e., there are guards to prevent pool
>>> invariants being violated due to incorrect / inconsistent return
>>> value), but I am not sure that is right.
>> My analysis was that if you reduce the limits (maxTotal, maxIdle etc.)
>> while this method is executing then there is a risk that it could exceed
>> those limits. However, there is a fair chance that the pool will already
>> be exceeding the limits when the limits are changed. Therefore, there is
>> actually very little difference between these two scenarios. In both
>> cases the pool will conform to the limits as soon as circumstances allow
>> and once operating within the limits, will not exceed them.
>
> I have never worried much about races against setters for maxTotal,
> MaxIdle, though it is good to fix this as you did.  What I have
> always worried about is that once we removed the sync on this and
> the pool statistics getters, what it computes becomes suspect.  For
> example, if things enter / exit the idle object pool between the
> time objectDeficit and growLimit are computed, the return value will
> be incorrect.  As I said, IIRC previous traces through the code, the
> use of the return value has guards to prevent too much badness from
> this; but since the correctness of the computation done inside this
> method depends on the idle instance pool keeping the same size over
> the duration of its execution, it is neither really threadsafe nor
> correct.
>>
>>> It might be good to
>>> temporarily make this method protected and run some concurrency
>>> tests directly against it, so we can understand and document what
>>> happens when instances come in and out of the pool while it is
>>> executing.
>> I'm not against that but I don't have the time to do it right now and am
>> unlikely to any time soon.
>
> I will do some tracing and more analysis of the code to verify that
> the problems that I think may exist in the correctness (or maybe
> meaningfulness) of the return value are harmless.

There's another threading issue - the JVM can cache shared variables
locally in a thread.
i.e. a reader thread may not see the latest copies of of all variables
written by another thread.
(in theory it might even see a half-written long variable)

This is easily fixed by making variables volatile, but that can have a
performance impact.

> Phil
>>
>> Mark
>>
>>
>>> Phil
 Modified:
     
 commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java

 Modified: 
 commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java?rev=1164051&r1=1164050&r2=1164051&view=diff
 ==
 --- 
 commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
  (original)
 +++ 
 commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
  Thu Sep  1 12:41:54 2011
 @@ -1577,25 +1577,30 @@ public class GenericKeyedObjectPool
       * @param pool the ObjectPool to calculate the deficit for
       * @return The number of objects to be created
       */
 -    private synchronized int calculateDeficit(ObjectDeque objectDeque) 
 {
 +    private int calculateDeficit(ObjectDeque objectDeque) {

          if (objectDeque == null) {
              return getMinIdlePerKey();
          }
 +
 +        // Used more than once so keep a local copy so the value is 
 consistent
 +        int maxTotal = getMaxTotal();
 +        int maxTotalPerKey = getMaxTotalPerKey();
 +
          int objectDefecit = 0;
 -
 +
          // Calculate no of objects needed to be created, in order to have
          // the number of pooled objects < maxTotalPerKey();
          objectDefecit = getMinIdlePerKey() - 
 objectDeque.getIdleObjects().size();
 -        if (getMaxTotalPerKey() > 0)

Re: [VOTE] Release Commons Configuration 1.7 based on RC2

[sebb]

On 2 September 2011 01:18, Gary Gregory  wrote:
> On Thu, Sep 1, 2011 at 7:55 PM, sebb  wrote:
>
>> On 1 September 2011 22:42, Gary Gregory  wrote:
>> > On Thu, Sep 1, 2011 at 2:25 PM, sebb  wrote:
>> >
>> >> On 30 August 2011 21:00, Oliver Heger 
>> >> wrote:
>> >> > This is a vote to release Apache Commons Configuration 1.7 based on
>> the
>> >> 2nd
>> >> > RC.
>> >> >
>> >> > There have been the following changes since RC1:
>> >> > * The ant build file has been improved (many thanks to Phil!)
>> >> > * The release notes mention that the optional dependency to Commons
>> VFS
>> >> > requires Java 1.5+. The page listing runtime dependencies has been
>> >> updated
>> >> > correspondingly.
>> >> > * Minor improvements of the building page.
>> >> >
>> >> > Tag:
>> >> >
>> >>
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/
>> >>
>> >> There are quite a few files without AL headers.
>> >> Some are generated Java files, which is OK, but there are some scripts
>> >> and other files which could and should have AL headers (assuming that
>> >> they are ASF files).
>> >>
>> >> For example:
>> >>
>> >> conf/digesterRules.xml
>> >>
>> >
>> > Why doesn't RAT catch this?
>>
>> The POM has been set up to exclude the conf directory tree; no idea
>> why as there is no comment in the POM.
>>
>
> Well, this sounds like a bug in the POM, no?

Yes.

> Gary
>
>>
>> I used RAT, but not via Maven, so it did not exclude the conf files.
>>
>> > Gary
>> >
>> >
>> >>
>> >> If the file is very short (e.g. one-line css file) there is no need to
>> >> add the header.
>> >>
>> >> Not a blocker, but it does make checking releases harder: a lot of the
>> >> source files have
>> >>
>> >> @version $Revision: nnn $, $Date: xxx $
>> >>
>> >> The Date field is Locale-dependent, so my checkout of the SVN tag does
>> >> not agree with the checkout you used to create the source archive.
>> >>
>> >> If you really want to see a date, use $Id: $; otherwise keep the
>> >> $Revision: $ and drop the $Date: $
>> >> Thanks.
>> >>
>> >> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/
>> >> >
>> >> > Maven artifacts:
>> >> > http://people.apache.org/~oheger/configuration-1.7rc2/maven/
>> >> >
>> >> > Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/
>> >>
>> >> Not a blocker, but the description uses Commons Configuration as a
>> >> noun; for trademark purposes it needs to be used as an adjective, at
>> >> least initially.
>> >>
>> >> For example:
>> >>
>> >> The Commons Configuration software library provides a generic
>> configuration
>> >> ...
>> >>
>> >> > [ ] +1 release it
>> >> > [ ] +0 go ahead I don't care
>> >> > [X] -1 no, do not release it because...
>> >>
>> >> Missing AL headers.
>> >>
>> >> Release otherwise looks OK, and builds/tests using Java 1.4 with Maven
>> >> 2.2.1.
>> >>
>> >> > Vote will remain open for 72 hours.
>> >> >
>> >> > Oliver
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Thank you,
>> > Gary
>> >
>> > http://garygregory.wordpress.com/
>> > http://garygregory.com/
>> > http://people.apache.org/~ggregory/
>> > http://twitter.com/GaryGregory
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1164051 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java

[Phil Steitz]

On 9/1/11 4:59 PM, Mark Thomas wrote:
> On 02/09/2011 00:40, Phil Steitz wrote:
>> On 9/1/11 5:41 AM, ma...@apache.org wrote:
>>> Author: markt
>>> Date: Thu Sep  1 12:41:54 2011
>>> New Revision: 1164051
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1164051&view=rev
>>> Log:
>>> Remove sync that wasn't helping.
>>> Make thread safe
>> I agree that the sync wasn't helping; but I am not sure exactly what
>> "thread safe" means for this method.
> For me, thread safe means that a local copy is taken for any value used
> more than once that needs to be consistent between uses. I'm not sure we
> can do much more without tying ourselves in synchronisation knots.
>
>> I have always worried about
>> this method.  I have usually been able to convince myself that it's
>> incorrectness is harmless (i.e., there are guards to prevent pool
>> invariants being violated due to incorrect / inconsistent return
>> value), but I am not sure that is right.
> My analysis was that if you reduce the limits (maxTotal, maxIdle etc.)
> while this method is executing then there is a risk that it could exceed
> those limits. However, there is a fair chance that the pool will already
> be exceeding the limits when the limits are changed. Therefore, there is
> actually very little difference between these two scenarios. In both
> cases the pool will conform to the limits as soon as circumstances allow
> and once operating within the limits, will not exceed them.

I have never worried much about races against setters for maxTotal,
MaxIdle, though it is good to fix this as you did.  What I have
always worried about is that once we removed the sync on this and
the pool statistics getters, what it computes becomes suspect.  For
example, if things enter / exit the idle object pool between the
time objectDeficit and growLimit are computed, the return value will
be incorrect.  As I said, IIRC previous traces through the code, the
use of the return value has guards to prevent too much badness from
this; but since the correctness of the computation done inside this
method depends on the idle instance pool keeping the same size over
the duration of its execution, it is neither really threadsafe nor
correct.
>
>> It might be good to
>> temporarily make this method protected and run some concurrency
>> tests directly against it, so we can understand and document what
>> happens when instances come in and out of the pool while it is
>> executing.
> I'm not against that but I don't have the time to do it right now and am
> unlikely to any time soon.

I will do some tracing and more analysis of the code to verify that
the problems that I think may exist in the correctness (or maybe
meaningfulness) of the return value are harmless.

Phil
>
> Mark
>
>
>> Phil
>>> Modified:
>>> 
>>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>>
>>> Modified: 
>>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java?rev=1164051&r1=1164050&r2=1164051&view=diff
>>> ==
>>> --- 
>>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>>  (original)
>>> +++ 
>>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>>  Thu Sep  1 12:41:54 2011
>>> @@ -1577,25 +1577,30 @@ public class GenericKeyedObjectPool
>>>   * @param pool the ObjectPool to calculate the deficit for
>>>   * @return The number of objects to be created
>>>   */
>>> -private synchronized int calculateDeficit(ObjectDeque objectDeque) {
>>> +private int calculateDeficit(ObjectDeque objectDeque) {
>>>  
>>>  if (objectDeque == null) {
>>>  return getMinIdlePerKey();
>>>  }
>>> +
>>> +// Used more than once so keep a local copy so the value is 
>>> consistent
>>> +int maxTotal = getMaxTotal();
>>> +int maxTotalPerKey = getMaxTotalPerKey();
>>> +
>>>  int objectDefecit = 0;
>>> -
>>> +
>>>  // Calculate no of objects needed to be created, in order to have
>>>  // the number of pooled objects < maxTotalPerKey();
>>>  objectDefecit = getMinIdlePerKey() - 
>>> objectDeque.getIdleObjects().size();
>>> -if (getMaxTotalPerKey() > 0) {
>>> +if (maxTotalPerKey > 0) {
>>>  int growLimit = Math.max(0,
>>> -getMaxTotalPerKey() - 
>>> objectDeque.getIdleObjects().size());
>>> +maxTotalPerKey - objectDeque.getIdleObjects().size());
>>>  objectDefecit = Math.min(objectDefecit, growLimit);
>>>  }
>>>  
>>>  // Take the maxTotal limit into account
>>> -if (getMaxTotal() > 0) {
>>> -int growLimit = Math.max(0, getMaxTo

[lang] Running lang under a security manager and LANG-744

[Gary Gregory]

WRT LANG-744 "StringUtils throws java.security.AccessControlException on
Google App Engine"

Well, I've ruminated, pondered and experimented.

Running all unit tests with a security managers results in:

Tests run: 2046, Failures: 2, Errors: 115, Skipped: 0

Clearly, we need a good overall solution to avoid 117 new Jiras (an
exaggeration I know.)

I've created a JAAS policy file to grant just enough permissions to run the
unit tests in {{src/test/resource/java.policy}}

The file contains instructions for using it with JAAS.

What this shows is that we should either:

# Run all unit tests a second time with JAAS enabled, or
# Run all unit tests with JAAS enabled, always

We should our solution as a pattern for other Commons component.

Specifically for StringUtils, should we have a SunStringUtils? This would
let you know that you are depending on com.sun code.

Thoughts?

-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [VOTE] Release Commons Configuration 1.7 based on RC2

[Gary Gregory]

On Thu, Sep 1, 2011 at 7:55 PM, sebb  wrote:

> On 1 September 2011 22:42, Gary Gregory  wrote:
> > On Thu, Sep 1, 2011 at 2:25 PM, sebb  wrote:
> >
> >> On 30 August 2011 21:00, Oliver Heger 
> >> wrote:
> >> > This is a vote to release Apache Commons Configuration 1.7 based on
> the
> >> 2nd
> >> > RC.
> >> >
> >> > There have been the following changes since RC1:
> >> > * The ant build file has been improved (many thanks to Phil!)
> >> > * The release notes mention that the optional dependency to Commons
> VFS
> >> > requires Java 1.5+. The page listing runtime dependencies has been
> >> updated
> >> > correspondingly.
> >> > * Minor improvements of the building page.
> >> >
> >> > Tag:
> >> >
> >>
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/
> >>
> >> There are quite a few files without AL headers.
> >> Some are generated Java files, which is OK, but there are some scripts
> >> and other files which could and should have AL headers (assuming that
> >> they are ASF files).
> >>
> >> For example:
> >>
> >> conf/digesterRules.xml
> >>
> >
> > Why doesn't RAT catch this?
>
> The POM has been set up to exclude the conf directory tree; no idea
> why as there is no comment in the POM.
>

Well, this sounds like a bug in the POM, no?

Gary

>
> I used RAT, but not via Maven, so it did not exclude the conf files.
>
> > Gary
> >
> >
> >>
> >> If the file is very short (e.g. one-line css file) there is no need to
> >> add the header.
> >>
> >> Not a blocker, but it does make checking releases harder: a lot of the
> >> source files have
> >>
> >> @version $Revision: nnn $, $Date: xxx $
> >>
> >> The Date field is Locale-dependent, so my checkout of the SVN tag does
> >> not agree with the checkout you used to create the source archive.
> >>
> >> If you really want to see a date, use $Id: $; otherwise keep the
> >> $Revision: $ and drop the $Date: $
> >> Thanks.
> >>
> >> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/
> >> >
> >> > Maven artifacts:
> >> > http://people.apache.org/~oheger/configuration-1.7rc2/maven/
> >> >
> >> > Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/
> >>
> >> Not a blocker, but the description uses Commons Configuration as a
> >> noun; for trademark purposes it needs to be used as an adjective, at
> >> least initially.
> >>
> >> For example:
> >>
> >> The Commons Configuration software library provides a generic
> configuration
> >> ...
> >>
> >> > [ ] +1 release it
> >> > [ ] +0 go ahead I don't care
> >> > [X] -1 no, do not release it because...
> >>
> >> Missing AL headers.
> >>
> >> Release otherwise looks OK, and builds/tests using Java 1.4 with Maven
> >> 2.2.1.
> >>
> >> > Vote will remain open for 72 hours.
> >> >
> >> > Oliver
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> > --
> > Thank you,
> > Gary
> >
> > http://garygregory.wordpress.com/
> > http://garygregory.com/
> > http://people.apache.org/~ggregory/
> > http://twitter.com/GaryGregory
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: svn commit: r1164051 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java

[Mark Thomas]

On 02/09/2011 00:40, Phil Steitz wrote:
> On 9/1/11 5:41 AM, ma...@apache.org wrote:
>> Author: markt
>> Date: Thu Sep  1 12:41:54 2011
>> New Revision: 1164051
>>
>> URL: http://svn.apache.org/viewvc?rev=1164051&view=rev
>> Log:
>> Remove sync that wasn't helping.
>> Make thread safe
> 
> I agree that the sync wasn't helping; but I am not sure exactly what
> "thread safe" means for this method.

For me, thread safe means that a local copy is taken for any value used
more than once that needs to be consistent between uses. I'm not sure we
can do much more without tying ourselves in synchronisation knots.

> I have always worried about
> this method.  I have usually been able to convince myself that it's
> incorrectness is harmless (i.e., there are guards to prevent pool
> invariants being violated due to incorrect / inconsistent return
> value), but I am not sure that is right.

My analysis was that if you reduce the limits (maxTotal, maxIdle etc.)
while this method is executing then there is a risk that it could exceed
those limits. However, there is a fair chance that the pool will already
be exceeding the limits when the limits are changed. Therefore, there is
actually very little difference between these two scenarios. In both
cases the pool will conform to the limits as soon as circumstances allow
and once operating within the limits, will not exceed them.

> It might be good to
> temporarily make this method protected and run some concurrency
> tests directly against it, so we can understand and document what
> happens when instances come in and out of the pool while it is
> executing.

I'm not against that but I don't have the time to do it right now and am
unlikely to any time soon.

Mark


> 
> Phil
>>
>> Modified:
>> 
>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>
>> Modified: 
>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java?rev=1164051&r1=1164050&r2=1164051&view=diff
>> ==
>> --- 
>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>  (original)
>> +++ 
>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>  Thu Sep  1 12:41:54 2011
>> @@ -1577,25 +1577,30 @@ public class GenericKeyedObjectPool
>>   * @param pool the ObjectPool to calculate the deficit for
>>   * @return The number of objects to be created
>>   */
>> -private synchronized int calculateDeficit(ObjectDeque objectDeque) {
>> +private int calculateDeficit(ObjectDeque objectDeque) {
>>  
>>  if (objectDeque == null) {
>>  return getMinIdlePerKey();
>>  }
>> +
>> +// Used more than once so keep a local copy so the value is 
>> consistent
>> +int maxTotal = getMaxTotal();
>> +int maxTotalPerKey = getMaxTotalPerKey();
>> +
>>  int objectDefecit = 0;
>> -
>> +
>>  // Calculate no of objects needed to be created, in order to have
>>  // the number of pooled objects < maxTotalPerKey();
>>  objectDefecit = getMinIdlePerKey() - 
>> objectDeque.getIdleObjects().size();
>> -if (getMaxTotalPerKey() > 0) {
>> +if (maxTotalPerKey > 0) {
>>  int growLimit = Math.max(0,
>> -getMaxTotalPerKey() - 
>> objectDeque.getIdleObjects().size());
>> +maxTotalPerKey - objectDeque.getIdleObjects().size());
>>  objectDefecit = Math.min(objectDefecit, growLimit);
>>  }
>>  
>>  // Take the maxTotal limit into account
>> -if (getMaxTotal() > 0) {
>> -int growLimit = Math.max(0, getMaxTotal() - getNumActive() - 
>> getNumIdle());
>> +if (maxTotal > 0) {
>> +int growLimit = Math.max(0, maxTotal - getNumActive() - 
>> getNumIdle());
>>  objectDefecit = Math.min(objectDefecit, growLimit);
>>  }
>>  
>>
>>
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Configuration 1.7 based on RC2

[sebb]

On 1 September 2011 22:42, Gary Gregory  wrote:
> On Thu, Sep 1, 2011 at 2:25 PM, sebb  wrote:
>
>> On 30 August 2011 21:00, Oliver Heger 
>> wrote:
>> > This is a vote to release Apache Commons Configuration 1.7 based on the
>> 2nd
>> > RC.
>> >
>> > There have been the following changes since RC1:
>> > * The ant build file has been improved (many thanks to Phil!)
>> > * The release notes mention that the optional dependency to Commons VFS
>> > requires Java 1.5+. The page listing runtime dependencies has been
>> updated
>> > correspondingly.
>> > * Minor improvements of the building page.
>> >
>> > Tag:
>> >
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/
>>
>> There are quite a few files without AL headers.
>> Some are generated Java files, which is OK, but there are some scripts
>> and other files which could and should have AL headers (assuming that
>> they are ASF files).
>>
>> For example:
>>
>> conf/digesterRules.xml
>>
>
> Why doesn't RAT catch this?

The POM has been set up to exclude the conf directory tree; no idea
why as there is no comment in the POM.

I used RAT, but not via Maven, so it did not exclude the conf files.

> Gary
>
>
>>
>> If the file is very short (e.g. one-line css file) there is no need to
>> add the header.
>>
>> Not a blocker, but it does make checking releases harder: a lot of the
>> source files have
>>
>> @version $Revision: nnn $, $Date: xxx $
>>
>> The Date field is Locale-dependent, so my checkout of the SVN tag does
>> not agree with the checkout you used to create the source archive.
>>
>> If you really want to see a date, use $Id: $; otherwise keep the
>> $Revision: $ and drop the $Date: $
>> Thanks.
>>
>> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/
>> >
>> > Maven artifacts:
>> > http://people.apache.org/~oheger/configuration-1.7rc2/maven/
>> >
>> > Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/
>>
>> Not a blocker, but the description uses Commons Configuration as a
>> noun; for trademark purposes it needs to be used as an adjective, at
>> least initially.
>>
>> For example:
>>
>> The Commons Configuration software library provides a generic configuration
>> ...
>>
>> > [ ] +1 release it
>> > [ ] +0 go ahead I don't care
>> > [X] -1 no, do not release it because...
>>
>> Missing AL headers.
>>
>> Release otherwise looks OK, and builds/tests using Java 1.4 with Maven
>> 2.2.1.
>>
>> > Vote will remain open for 72 hours.
>> >
>> > Oliver
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1164051 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java

[Phil Steitz]

On 9/1/11 5:41 AM, ma...@apache.org wrote:
> Author: markt
> Date: Thu Sep  1 12:41:54 2011
> New Revision: 1164051
>
> URL: http://svn.apache.org/viewvc?rev=1164051&view=rev
> Log:
> Remove sync that wasn't helping.
> Make thread safe

I agree that the sync wasn't helping; but I am not sure exactly what
"thread safe" means for this method.  I have always worried about
this method.  I have usually been able to convince myself that it's
incorrectness is harmless (i.e., there are guards to prevent pool
invariants being violated due to incorrect / inconsistent return
value), but I am not sure that is right.  It might be good to
temporarily make this method protected and run some concurrency
tests directly against it, so we can understand and document what
happens when instances come in and out of the pool while it is
executing.

Phil
>
> Modified:
> 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>
> Modified: 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java?rev=1164051&r1=1164050&r2=1164051&view=diff
> ==
> --- 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>  (original)
> +++ 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>  Thu Sep  1 12:41:54 2011
> @@ -1577,25 +1577,30 @@ public class GenericKeyedObjectPool
>   * @param pool the ObjectPool to calculate the deficit for
>   * @return The number of objects to be created
>   */
> -private synchronized int calculateDeficit(ObjectDeque objectDeque) {
> +private int calculateDeficit(ObjectDeque objectDeque) {
>  
>  if (objectDeque == null) {
>  return getMinIdlePerKey();
>  }
> +
> +// Used more than once so keep a local copy so the value is 
> consistent
> +int maxTotal = getMaxTotal();
> +int maxTotalPerKey = getMaxTotalPerKey();
> +
>  int objectDefecit = 0;
> -
> +
>  // Calculate no of objects needed to be created, in order to have
>  // the number of pooled objects < maxTotalPerKey();
>  objectDefecit = getMinIdlePerKey() - 
> objectDeque.getIdleObjects().size();
> -if (getMaxTotalPerKey() > 0) {
> +if (maxTotalPerKey > 0) {
>  int growLimit = Math.max(0,
> -getMaxTotalPerKey() - 
> objectDeque.getIdleObjects().size());
> +maxTotalPerKey - objectDeque.getIdleObjects().size());
>  objectDefecit = Math.min(objectDefecit, growLimit);
>  }
>  
>  // Take the maxTotal limit into account
> -if (getMaxTotal() > 0) {
> -int growLimit = Math.max(0, getMaxTotal() - getNumActive() - 
> getNumIdle());
> +if (maxTotal > 0) {
> +int growLimit = Math.max(0, maxTotal - getNumActive() - 
> getNumIdle());
>  objectDefecit = Math.min(objectDefecit, growLimit);
>  }
>  
>
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Jacobian dimensions in "AbstractLeastSquaresOptimizer"

[Gilles Sadowski]

Hello Luc.

> > [...]
> 
> In fact, I have always seen Jacobians using this layout, so from my
> point of view it was standard. I am conforted in this view by
> .

That goes without saying, but it does not harm to say it anyway. :-)
[I just happened to pick the wrong layout because it looked more natural for
looping...]

> So I would prefer to see improved documentation rather than
> providing a non-standard layout. I think you have already done this
> doc improvement (I am trying to read all the mails that have arrived
> during my 2 days unconnected ...)

Yes, I've added a note in the "AbstractLeastSquares" class comment.
Please check that it is clear enough.


Best,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Configuration 1.7 based on RC2

[Gary Gregory]

On Thu, Sep 1, 2011 at 2:25 PM, sebb  wrote:

> On 30 August 2011 21:00, Oliver Heger 
> wrote:
> > This is a vote to release Apache Commons Configuration 1.7 based on the
> 2nd
> > RC.
> >
> > There have been the following changes since RC1:
> > * The ant build file has been improved (many thanks to Phil!)
> > * The release notes mention that the optional dependency to Commons VFS
> > requires Java 1.5+. The page listing runtime dependencies has been
> updated
> > correspondingly.
> > * Minor improvements of the building page.
> >
> > Tag:
> >
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/
>
> There are quite a few files without AL headers.
> Some are generated Java files, which is OK, but there are some scripts
> and other files which could and should have AL headers (assuming that
> they are ASF files).
>
> For example:
>
> conf/digesterRules.xml
>

Why doesn't RAT catch this?

Gary


>
> If the file is very short (e.g. one-line css file) there is no need to
> add the header.
>
> Not a blocker, but it does make checking releases harder: a lot of the
> source files have
>
> @version $Revision: nnn $, $Date: xxx $
>
> The Date field is Locale-dependent, so my checkout of the SVN tag does
> not agree with the checkout you used to create the source archive.
>
> If you really want to see a date, use $Id: $; otherwise keep the
> $Revision: $ and drop the $Date: $
> Thanks.
>
> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/
> >
> > Maven artifacts:
> > http://people.apache.org/~oheger/configuration-1.7rc2/maven/
> >
> > Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/
>
> Not a blocker, but the description uses Commons Configuration as a
> noun; for trademark purposes it needs to be used as an adjective, at
> least initially.
>
> For example:
>
> The Commons Configuration software library provides a generic configuration
> ...
>
> > [ ] +1 release it
> > [ ] +0 go ahead I don't care
> > [X] -1 no, do not release it because...
>
> Missing AL headers.
>
> Release otherwise looks OK, and builds/tests using Java 1.4 with Maven
> 2.2.1.
>
> > Vote will remain open for 72 hours.
> >
> > Oliver
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [VOTE] Release Commons Configuration 1.7 based on RC2

[Ralph Goers]

I'm still traveling on vacation. I'm not sure if I will be able to test it (and 
therefore vote) during the 72 hour window.  

Ralph

On Sep 1, 2011, at 10:52 AM, Oliver Heger wrote:

> Here is my +1
> 
> Oliver
> (hoping to remind others to vote as well, otherwise release will be 
> problematic)
> 
> Am 30.08.2011 22:00, schrieb Oliver Heger:
>> This is a vote to release Apache Commons Configuration 1.7 based on the
>> 2nd RC.
>> 
>> There have been the following changes since RC1:
>> * The ant build file has been improved (many thanks to Phil!)
>> * The release notes mention that the optional dependency to Commons VFS
>> requires Java 1.5+. The page listing runtime dependencies has been
>> updated correspondingly.
>> * Minor improvements of the building page.
>> 
>> Tag:
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/
>> 
>> 
>> Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/
>> 
>> Maven artifacts:
>> http://people.apache.org/~oheger/configuration-1.7rc2/maven/
>> 
>> Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
>> 
>> Vote will remain open for 72 hours.
>> 
>> Oliver
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Jacobian dimensions in "AbstractLeastSquaresOptimizer"

[Luc Maisonobe]

Le 31/08/2011 18:09, Gilles Sadowski a écrit :

Hello.


Hi Gilles,



In the "AbstractLeastSquaresOptimizer" class (package "optimization"), there
is (at lines 238-247):
---CUT---
 jF = f.jacobian();
 this.residuals = new double[target.length];

 // Arrays shared with the other private methods.
 point = startPoint.clone();
 rows = target.length;
 cols = point.length;

 weightedResidualJacobian = new double[rows][cols];
 this.weightedResiduals = new double[rows];
---CUT---

Is it necessary to impose the layout of "jF"? Indeed, depending on the
implementation of the "jacobian()" method, one could have
---CUT---
 rows = point.length;
 cols = target.length;
---CUT---
instead. And it is not obvious from the documentation which it should be.

If which data goes into which of the matrix dimensions is not important, is
a way to specify which is which, so that both layout can be used (at the
user's discretion)?

If the layout cannot be decided by the user, it should probably stand out
somewhere in the documentation.


In fact, I have always seen Jacobians using this layout, so from my 
point of view it was standard. I am conforted in this view by 
.


So I would prefer to see improved documentation rather than providing a 
non-standard layout. I think you have already done this doc improvement 
(I am trying to read all the mails that have arrived during my 2 days 
unconnected ...)


best regards,
Luc




Best regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Configuration 1.7 based on RC2

[sebb]

On 30 August 2011 21:00, Oliver Heger  wrote:
> This is a vote to release Apache Commons Configuration 1.7 based on the 2nd
> RC.
>
> There have been the following changes since RC1:
> * The ant build file has been improved (many thanks to Phil!)
> * The release notes mention that the optional dependency to Commons VFS
> requires Java 1.5+. The page listing runtime dependencies has been updated
> correspondingly.
> * Minor improvements of the building page.
>
> Tag:
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/

There are quite a few files without AL headers.
Some are generated Java files, which is OK, but there are some scripts
and other files which could and should have AL headers (assuming that
they are ASF files).

For example:

conf/digesterRules.xml

If the file is very short (e.g. one-line css file) there is no need to
add the header.

Not a blocker, but it does make checking releases harder: a lot of the
source files have

@version $Revision: nnn $, $Date: xxx $

The Date field is Locale-dependent, so my checkout of the SVN tag does
not agree with the checkout you used to create the source archive.

If you really want to see a date, use $Id: $; otherwise keep the
$Revision: $ and drop the $Date: $
Thanks.

> Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/
>
> Maven artifacts:
> http://people.apache.org/~oheger/configuration-1.7rc2/maven/
>
> Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/

Not a blocker, but the description uses Commons Configuration as a
noun; for trademark purposes it needs to be used as an adjective, at
least initially.

For example:

The Commons Configuration software library provides a generic configuration ...

> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [X] -1 no, do not release it because...

Missing AL headers.

Release otherwise looks OK, and builds/tests using Java 1.4 with Maven 2.2.1.

> Vote will remain open for 72 hours.
>
> Oliver
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Configuration 1.7 based on RC2

[Oliver Heger]

Here is my +1

Oliver
(hoping to remind others to vote as well, otherwise release will be 
problematic)


Am 30.08.2011 22:00, schrieb Oliver Heger:

This is a vote to release Apache Commons Configuration 1.7 based on the
2nd RC.

There have been the following changes since RC1:
* The ant build file has been improved (many thanks to Phil!)
* The release notes mention that the optional dependency to Commons VFS
requires Java 1.5+. The page listing runtime dependencies has been
updated correspondingly.
* Minor improvements of the building page.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/


Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc2/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...

Vote will remain open for 72 hours.

Oliver

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Multiple Algorithms

[Greg Sterijevski]

Thanks for the response Phil.

This question has been on my mind for a month or so. I was working on some
Student T approximators (ergo my check in of the NIST data for Student T),
when I noticed that the commons Student T was based on the continuing
fraction version of the incomplete beta formulation. Then I updated my local
working copy and noticed you have made some changes to the Normal
distribution. I looked at that implementation and it is the one based on the
error function. There is nothing wrong with the choices that were made and I
am sure your error function is awesome. However, my experience has been
that, especially in the tails, you want other approximators (typically some
variation on a power series).

As for parallels, I think you are correct, the best one is the commons
implementation schema for random number generators. As I was looking back,
it struck me as odd that the old SVD was ditched. Again, not saying it did
not deserve it, just wanted to make sure I understood the philosophy behind
the decision making.

Thank you,

-Greg





On Thu, Sep 1, 2011 at 1:11 AM, Phil Steitz  wrote:

> On 8/31/11 10:05 PM, Greg Sterijevski wrote:
> > Hello All,
> >
> > This question popped into my head this evening, what is the right way to
> > handle multiple algorithms which purport to calculate the same thing?
> There
> > are, for example, a couple of ways to calculate the student t cdf. What
> is
> > the common's philosophy on deciding:
> >
> > 1. Whether to allow multiple algorithms.
> > 2. How an algorithm is included.
> > a.) Does a 'bug' or shortcoming need to be shown in the current
> > implementation?
> > b.) Say that algorithm a works for a numerical range and b works best
> on
> > another. Are both included? Is a new 'meta' algorithm written which mixes
> > both a and b?
> > 3. Does simplicity count?
> > 4. Does speed matter?
> >
> > A while back, Chris Nix reimplemented the SVD routine. I am not sure I
> > remember the old routine so I cannot say there was anything worth keeping
> > there. However was there a conscious decision to scrap it? Why not have
> it
> > live side by side with the new one? (Again, I am not saying the old
> > algorithm was better-Chris' contribution definitely was valuable). I
> think
> > we will run into these issues often.
> >
> > Thoughts? If this has been discussed already, my apologies.
>
> Well, at a high level, we tried to settle this at the very
> beginning.  Have a look at items 3 and 4 in the "guiding principles"
> on the [math] main page :)  That stuff comes from the original
> proposal for [math] and we have tried to stay more or less faithful
> to the principles laid out there.
>
> The integration, ode and solvers packages all try to do exactly what
> you are suggesting - when multiple algorithms, or even variations on
> an algorithm, exist and no single one can really do the job for all
> practical use cases, we welcome and incorporate implementations of
> multiple different ones.  How we do that varies by package and this
> is one place where our "interface pain" has led to some trauma.
> Initially, we pretty much uniformly separated interfaces from
> implementation precisely for this reason.  You can still see that in
> the distributions package and while it is a little ironic since we
> have been talking about collapsing the interfaces into the impls
> there, the setup now supports multiple different implementations of
> any of the distributions.
>
> I don't want to turn this into an abstract discussion of how best to
> support the strategy pattern in [math].  I think the "how to do it"
> part depends on the problem / package.  What we have tried to do so
> far and I think we should keep trying to do is:
>
> 0) If there is a single best algorithm that really does work well in
> almost all cases, make that "the obvious thing" and try to make our
> implementation of it as robust as possible.  If we provide only one
> implementation, try to make it the best one.  I would say put
> SimpleRegression, or Variance, for example, in this category.
>
> 1) When multiple different standard algorithms exist, make sure our
> API supports adding alternatives - including user-supplied
> alternatives - in the least-confusing way we can think of.  Welcome
> contributions of the alternatives and try to document as best we can
> how and when to use the different implementations.  Try to stick to
> standard algorithms, with good external references, so we don't have
> to turn our javadoc and/or user guide into a numerical analysis
> textbook.
>
> 2) Whenever possible, try to encapsulate the part that varies for
> different implementations, so the API remains simple and the
> variable part can be "plugged in."  Good examples of this are the
> RandomGenerators or the Solvers used by different classes.
>
> The general question is a good one; but the specific answer depends
> on the algorithms and classes involved.  In the two cases that you
> mention (t distributio

Re: svn commit: r1164053 - in /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl: GenericKeyedObjectPool.java GenericObjectPool.java

[sebb]

On 1 September 2011 13:51,   wrote:
> Author: markt
> Date: Thu Sep  1 12:51:04 2011
> New Revision: 1164053
>
> URL: http://svn.apache.org/viewvc?rev=1164053&view=rev
> Log:
> Make close() thread safe and ensure multiple calls to close() are handled 
> correctly
>
> Modified:
>    
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>    
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java
>
> Modified: 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java?rev=1164053&r1=1164052&r2=1164053&view=diff
> ==
> --- 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>  (original)
> +++ 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>  Thu Sep  1 12:51:04 2011
> @@ -1093,15 +1093,26 @@ public class GenericKeyedObjectPool
>       */
>      @Override
>      public void close() throws Exception {
> -         super.close();
> -         clear();
> -         evictionIterator = null;
> -         evictionKeyIterator = null;
> -         startEvictor(-1L);
> -         if (oname != null) {
> -             
> ManagementFactory.getPlatformMBeanServer().unregisterMBean(oname);
> -             oname = null;
> +         if (isClosed()) {
> +             return;
>          }
> +
> +         synchronized (closeLock) {
> +             if (isClosed()) {
> +                 return;
> +             }
> +
> +             super.close();
> +             clear();
> +             evictionIterator = null;
> +             evictionKeyIterator = null;
> +             startEvictor(-1L);
> +             if (oname != null) {
> +                 ManagementFactory.getPlatformMBeanServer().unregisterMBean(
> +                         oname);

 oname = null; // ??

> +             }
> +         }
> +
>      }
>
>
> @@ -1947,6 +1958,9 @@ public class GenericKeyedObjectPool
>      */
>     private K evictionKey = null;
>
> +    /** Object used to ensure closed() is only called once. */
> +    private final Object closeLock = new Object();
> +
>     // JMX specific attributes
>     private static final int AVERAGE_TIMING_STATS_CACHE_SIZE = 100;
>     private AtomicLong borrowedCount = new AtomicLong(0);
>
> Modified: 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java?rev=1164053&r1=1164052&r2=1164053&view=diff
> ==
> --- 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java
>  (original)
> +++ 
> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java
>  Thu Sep  1 12:51:04 2011
> @@ -1002,12 +1002,22 @@ public class GenericObjectPool extend
>      */
>     @Override
>     public void close() throws Exception {
> -        super.close();
> -        clear();
> -        startEvictor(-1L);
> -        if (oname != null) {
> -            
> ManagementFactory.getPlatformMBeanServer().unregisterMBean(oname);
> -            oname = null;
> +        if (isClosed()) {
> +            return;
> +        }
> +
> +        synchronized (closeLock) {
> +            if (isClosed()) {
> +                return;
> +            }
> +
> +            super.close();
> +            clear();
> +            startEvictor(-1L);
> +            if (oname != null) {
> +                ManagementFactory.getPlatformMBeanServer().unregisterMBean(
> +                        oname);

 oname = null; // ??

> +            }
>         }
>     }
>
> @@ -1541,6 +1551,9 @@ public class GenericObjectPool extend
>     /** An iterator for {@link #idleObjects} that is used by the evictor. */
>     private Iterator> evictionIterator = null;
>
> +    /** Object used to ensure closed() is only called once. */
> +    private final Object closeLock = new Object();
> +
>     // JMX specific attributes
>     private static final int AVERAGE_TIMING_STATS_CACHE_SIZE = 100;
>     private AtomicLong borrowedCount = new AtomicLong(0);
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1163864 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java

[Mark Thomas]

On 01/09/2011 00:57, sebb wrote:
> On 1 September 2011 00:10,   wrote:
>> Author: markt
>> Date: Wed Aug 31 23:10:53 2011
>> New Revision: 1163864
>>
>> URL: http://svn.apache.org/viewvc?rev=1163864&view=rev
>> Log:
>> Stop multiple calls to close() triggering an JMX error
>>
>> Modified:
>>
>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>
>> Modified: 
>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java?rev=1163864&r1=1163863&r2=1163864&view=diff
>> ==
>> --- 
>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>  (original)
>> +++ 
>> commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
>>  Wed Aug 31 23:10:53 2011
>> @@ -1098,7 +1098,10 @@ public class GenericKeyedObjectPool
>>  evictionIterator = null;
>>  evictionKeyIterator = null;
>>  startEvictor(-1L);
>> - ManagementFactory.getPlatformMBeanServer().unregisterMBean(oname);
>> + if (oname != null) {
>> + 
>> ManagementFactory.getPlatformMBeanServer().unregisterMBean(oname);
>> + oname = null;
>> + }
>>  }
> 
> If close() can be called from mulitple threads, then it's still
> possible to unregister the bean twice.

Yep. This was more a quick fix to get past the unit test failures.

> I think the only way to fix this would be to synchronise the block -
> making oname volatile would not help here.
> Alternatively, use an atomic boolean to record the fact that the bean
> has been registered.

I'll take a look and see what is cleanest. I'd rather not introduce a
sync on the pool if I can help it.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

To whom it may engage...

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

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


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.157 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

Tests run: 179, Failures: 0, Errors: 1, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Thu Sep 01 10:38:36 UTC 2011
[INFO] Final Memory: 24M/58M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml
- Atom: 
http://vmgump.apache.or