[DAEMON] Tagging 1.0.13

[Mladen Turk]

Hi,

I plan to tag and push for a release Daemon 1.0.13 later today.
We have some regression, or better to say an old problem
which manifested with new version which requires a new release.
The fix was already confirmed by Tomcat folks.


Regards
--
^TM

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

Re: svn commit: r1442739 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/ClassLoaderBuilder.java

[Simone Tripodi]

Guten Morgen,

> +/**
> + * Use a custom {@link ClassLoader} for loading the class.
> + *
> + * @param classLoader the {@link ClassLoader} to load the class.
> + * @return the {@link ClassAccessor} for the class being loaded.
> + */
>  ClassAccessor loadWithClassLoader( ClassLoader classLoader );

I think we can reduce this sentence to `loadWith( ClassLoader
classLoader )` since the ClassLoader is the object, WDYT?
best,
-Simo

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

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

Re: [vfs] New feature request: configurable socket timeout for HTTP and WebDAV in VFS

[Mark Fortner]

Perhaps not for local file systems, but I would imagine that any kind of
distributed file system would have need of a socket timeout.

Cheers,

Mark



On Tue, Feb 5, 2013 at 1:59 PM, Gary Gregory  wrote:

> On Tue, Feb 5, 2013 at 4:54 PM, Mark Fortner  wrote:
>
> > Just out of curiousity, is there a reason that socket timeouts shouldn't
> > also apply to all file systems in general?
> >
>
> How does a socket timeout make sense for a local file system, ZIP, and so
> on?
>
> Gary
>
>
> >
> > Cheers,
> >
> > Mark
> >
> >
> >
> > On Tue, Feb 5, 2013 at 8:58 AM, Gary Gregory 
> > wrote:
> >
> > > Sure, make sure you base you patch on the latest from trunk.
> > >
> > > Gary
> > >
> > >
> > > On Tue, Feb 5, 2013 at 11:50 AM, Jean-Marc Borer 
> > > wrote:
> > >
> > > > Hello list members,
> > > >
> > > > We need to be able to specify socket timeouts in VFS for HTTP and
> > > > WebDAV in our project so that request will no hang for ever in
> certain
> > > > conditions.
> > > >
> > > >  I have modified the sources of HttpFileSystemConfigBuilder and
> > > > HttpClientFactory to be able to configure this in HttpClient.
> > > >
> > > > Do you want me to propose a patch for that?
> > > >
> > > > Cheers,
> > > >
> > > > Jean-marc
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> > > Spring Batch in Action: http://bit.ly/bqpbCK
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [vfs] New feature request: configurable socket timeout for HTTP and WebDAV in VFS

[Gary Gregory]

On Tue, Feb 5, 2013 at 4:54 PM, Mark Fortner  wrote:

> Just out of curiousity, is there a reason that socket timeouts shouldn't
> also apply to all file systems in general?
>

How does a socket timeout make sense for a local file system, ZIP, and so
on?

Gary


>
> Cheers,
>
> Mark
>
>
>
> On Tue, Feb 5, 2013 at 8:58 AM, Gary Gregory 
> wrote:
>
> > Sure, make sure you base you patch on the latest from trunk.
> >
> > Gary
> >
> >
> > On Tue, Feb 5, 2013 at 11:50 AM, Jean-Marc Borer 
> > wrote:
> >
> > > Hello list members,
> > >
> > > We need to be able to specify socket timeouts in VFS for HTTP and
> > > WebDAV in our project so that request will no hang for ever in certain
> > > conditions.
> > >
> > >  I have modified the sources of HttpFileSystemConfigBuilder and
> > > HttpClientFactory to be able to configure this in HttpClient.
> > >
> > > Do you want me to propose a patch for that?
> > >
> > > Cheers,
> > >
> > > Jean-marc
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> > Spring Batch in Action: http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [vfs] New feature request: configurable socket timeout for HTTP and WebDAV in VFS

[Mark Fortner]

Just out of curiousity, is there a reason that socket timeouts shouldn't
also apply to all file systems in general?

Cheers,

Mark



On Tue, Feb 5, 2013 at 8:58 AM, Gary Gregory  wrote:

> Sure, make sure you base you patch on the latest from trunk.
>
> Gary
>
>
> On Tue, Feb 5, 2013 at 11:50 AM, Jean-Marc Borer 
> wrote:
>
> > Hello list members,
> >
> > We need to be able to specify socket timeouts in VFS for HTTP and
> > WebDAV in our project so that request will no hang for ever in certain
> > conditions.
> >
> >  I have modified the sources of HttpFileSystemConfigBuilder and
> > HttpClientFactory to be able to configure this in HttpClient.
> >
> > Do you want me to propose a patch for that?
> >
> > Cheers,
> >
> > Jean-marc
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

[vfs] New feature request: configurable socket timeout for HTTP and WebDAV in VFS

[Jean-Marc Borer]

Hello list members,

We need to be able to specify socket timeouts in VFS for HTTP and
WebDAV in our project so that request will no hang for ever in certain
conditions.

 I have modified the sources of HttpFileSystemConfigBuilder and
HttpClientFactory to be able to configure this in HttpClient.

Do you want me to propose a patch for that?

Cheers,

Jean-marc

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

Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java

[Benedikt Ritter]

Hi Simo,


2013/2/5 Simone Tripodi 

> Guten Tag, Bene,
>
> > I personally try to avoid static imports.
> > Especially when you come to a legacy code base IMHO it makes the code
> > harder to understand.
>
> as BU2 user, would you write the following sentence
>
> on( testBean ).invoke( "setBooleanProperty" ).with( argument( new
> Boolean( false ) ) );
>
> as
>
> BeanUtils.on( testBean ).invoke( "setBooleanProperty" ).with(
> Argument.argument( new Boolean( false ) ) );
>
> ?
>
> Better switching back to old BU APIs, there's no benefit anymore on
> switching to a functional-style approach APIs.
>

As I said, I haven't decided yet how to handle static imports.
You're right, when pointing out, that not using static imports here is more
verbose. But IMHO BU2 is a step forward compared to BU1 even without static
imports! :)

I personally would probably do something like:
BeanUtils.on( testBean ).invoke( "setBooleanProperty" ).with( argument(
Boolean.valueOf( false ) ) ); // or just valueOf( false )? ;-)

This way I can see what API I'm entering. For the call to
Argument.argument(T) I would use a static import, because it is clear what
context it is coming from. In fact, this is, how I use EasyMock at work. I
qualify calls to expect(), replay(), verify() etc but use static import
when using the factory methods for IExpectationSetters.

Makes sense? Probably only to me :) See, it's just a convention I've found
useful for myself.


>
> > You always have to look, where a method comes from.
>
> Isn't the same thing we have to do with classes? when using a List,
> what ensures you are using java.util.List rather than java.awt.List?
> Why you consider methods case so different to classes?
>

Your right. I'd normally try to import java.util.List, because it is the
most common List implementation and qualify java.awt.List if I have to use
both in the same class. But again this is only a convention I have made for
myself.


>
> > Also you may have the problem, that you accidentally override imported
> > static methods, when defining a new static method with the same name.
>
> same name, same arguments and same return type? It would be possible.
> But, again, that would be possible doing it also with classes, same
> package and same name; as exercise, create a project and import
> commons-beanutils-1.7.0 + commons-collections-3.2.1: which version of
> FastHashMap is taken by the classloader?
>
> I still haven't found the reason why methods should be a special case.
>

I guess I'll just revert that commit and we'll see were it gets us.
Thanks for sharing your thoughts!

Benedikt


>
> What I am sure, there's no rule.
>
> my 0.0002 though,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[Math] Moving on or not?

[Gilles]

Hi.

In the thread about "static import", Stephen noted that decisions on a
component's evolution are dependent on whether the future of the Java
language is taken into account, or not.
A question on the same theme also arose after the presentation of 
Commons

Math in FOSDEM 2013.

If we assume that efficiency is among the important qualities for 
Commons
Math, the future is to allow usage of the tools provided by the 
standard
Java library in order to ease the development of multi-threaded 
algorithms.


Maintaining Java 1.5 source compatibility for the reason that we may 
need

to support legacy applications will turn out to be self-defeating:
1. New users will not consider Commons Math's features that are notably
   apt to parallel processing.
2. Current users might at some point simply switch to another library 
if

   it proves more efficient (because it actually uses multi-threading).
3. New Java developers will be turned away because they will want to 
use

   the more convenient features of the language in order to provide
   potential contributions.

If maintaining 1.5 source compatibility is kept as a requirement, the
consequence is that Commons Math will _become_ a legacy library.
In that perspective, implementing/improving algorithms for which a
parallel version is known to be more efficient is plainly a waste of
development and maintenance time.

In order to mitigate the risks (both of upgrading and of not upgrading
the source compatibility requirement), I would propose to create a new
project (say, "Commons Math MT") where we could implement new 
features[1]

without being encumbered with the 1.5 requirement.[2]
The "Commons Math MT" would depend on "Commons Math" where we would
continue developing single-thread (and thread-safe) "tasks", i.e.
independent units of processing that could be used in algorithms
located in "Commons Math MT".

In summary:
- Commons Math (as usual):
  * single-thread (sequential) algorithms,
  * (pure) Java 5,
  * no dependencies.
- Commons Math MT:
  * multi-thread (parallel) algorithms,
  * Java 7 and beyond,
  * JNI allowed,
  * dependencies allowed (jCuda).

What do you think?


Best regards,
Gilles

[1] Also, we would gradually move there the algorithms that would 
obviously

benefit from a multi-thread implementation (e.g Fourier transform,
genetic algorithms, etc.)
[2] This project would also be a place where people could experiment 
with

"jCuda" (http://www.jcuda.org).


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

Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java

[Simone Tripodi]

Guten Tag, Bene,

> I personally try to avoid static imports.
> Especially when you come to a legacy code base IMHO it makes the code
> harder to understand.

as BU2 user, would you write the following sentence

on( testBean ).invoke( "setBooleanProperty" ).with( argument( new
Boolean( false ) ) );

as

BeanUtils.on( testBean ).invoke( "setBooleanProperty" ).with(
Argument.argument( new Boolean( false ) ) );

?

Better switching back to old BU APIs, there's no benefit anymore on
switching to a functional-style approach APIs.

> You always have to look, where a method comes from.

Isn't the same thing we have to do with classes? when using a List,
what ensures you are using java.util.List rather than java.awt.List?
Why you consider methods case so different to classes?

> Also you may have the problem, that you accidentally override imported
> static methods, when defining a new static method with the same name.

same name, same arguments and same return type? It would be possible.
But, again, that would be possible doing it also with classes, same
package and same name; as exercise, create a project and import
commons-beanutils-1.7.0 + commons-collections-3.2.1: which version of
FastHashMap is taken by the classloader?

I still haven't found the reason why methods should be a special case.

What I am sure, there's no rule.

my 0.0002 though,
-Simo

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

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

Re: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

[Stephen Colebourne]

FYI, the Project Lambda Streams code and JSR-310 in JDK 1.8 are both
written with static imports in mind. Moreover, with support for static
methods in interfaces being added, this is likely to increase as a
pattern. Those facts may or may not affect decisions in commons.

Stephen


On 4 February 2013 21:32, Benedikt Ritter  wrote:
> Hi,
>
> we had a little discussion in BeanUtils2, regarding static imports (see
> below). To increase visibility and get some more feedback, I'm forwarding
> this to [ALL]
>
> We haven't decided yet how to handle static imports. To form some rules,
> we'd like to hear what others think about static imports and what rules of
> thumb you use in your projects.
>
> I'm exited to hear your opinions :)
> Regards,
> Benedikt
>
>
> 2013/2/4 Jörg Schaible 
>
>> Hi,
>>
>> Benedikt Ritter wrote:
>>
>> > Hi Simo,
>> >
>> > thanks for sharing your thoughts! I personally try to avoid static
>> > imports. Especially when you come to a legacy code base IMHO it makes the
>> > code harder to understand. You always have to look, where a method comes
>> > from.
>>
>> Actually I avoid static imports for the same reason.
>>
>> > Also you may have the problem, that you accidentally override
>> > imported static methods, when defining a new static method with the same
>> > name. BU2 is a very small code base, so it would be okay for me to revert
>> > the change.
>> >
>> > Nevertheless I'd be interested to hear what others thing about this
>> topic.
>>
>> my 2¢
>>
>> - Jörg
>>
>>
>> -
>> 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: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

[Benedikt Ritter]

Hey,

thanks for your feedback. It's interesting to see that there seem to be two
opposing opinions:
Some try to avoid static imports as much as possible, while others use them
if it makes the code "more fluent".

I found the Matt's comment especially useful, for pointing out, that we (as
developers of o.a.commons) have have to views/roles.
On the one hand we are creators of APIs that should read fluently without
having to use static imports extensively.
On the other hand we are developers who have to decide how we want to use
static imports internally.

I think that's the core of my question. Do we have any kind of guideline
regarding the use of static imports in commons library code?

Regards,
Benedikt


2013/2/5 Matt Benson 

> I would say that in general the Commons libraries favor *creating* APIs
> such that intent reads most fluently by *not* using static imports.  I
> would venture to say that given the examples of when static imports might
> be desirable, a good rule of thumb wrt *use* of static imports would again
> be "which way does intent read most fluently?"
>
> Using this approach, the answer would be:  it depends on the library
> defining the static member.
>
> Matt
>
>
> On Mon, Feb 4, 2013 at 7:34 PM, Ted Dunning  wrote:
>
> > Another common use is with junit to import assertEquals and such.
> >
> > On Mon, Feb 4, 2013 at 4:41 PM, Gary Gregory 
> > wrote:
> >
> > > On Mon, Feb 4, 2013 at 4:32 PM, Benedikt Ritter 
> > > wrote:
> > >
> > > > ...
> > > > We haven't decided yet how to handle static imports. To form some
> > rules,
> > > > we'd like to hear what others think about static imports and what
> rules
> > > of
> > > > thumb you use in your projects.
> > >
> > > I do not use static imports at work. I do not like using them unless it
> > is
> > > for math like expressions (with PI and the like).
> > >
> > >
> >
>