Dear all,
2012/2/9 Gilles Sadowski :
> On Thu, Feb 09, 2012 at 11:02:36AM +0100, Luc Maisonobe wrote:
>> Le 09/02/2012 10:50, Sébastien Brisard a écrit :
>> > Hi Luc,
>> >>
>> >> I agree with you, enums are much better. There are other places in
>> >> [math] where we use boolean or even ints for s
Hello,
>
> I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
> [Arguments mentioned numerous times in previous discussions...]
>
It's true it has been argued only recently. I was just wondering
whether it might be worth configuring checkstyle so as to make it
complain abo
On 02/10/2012 09:58 AM, Sébastien Brisard wrote:
> Hello,
>>
>> I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
>> [Arguments mentioned numerous times in previous discussions...]
>>
> It's true it has been argued only recently. I was just wondering
> whether it might be
Hi Thomas,
2012/2/10 Thomas Neidhart :
> On 02/10/2012 09:58 AM, Sébastien Brisard wrote:
>> Hello,
>>>
>>> I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
>>> [Arguments mentioned numerous times in previous discussions...]
>>>
>> It's true it has been argued only recen
Le 09/02/2012 22:43, Gilles Sadowski a écrit :
> Hello.
>
Some times ago, we had a discussion about some issues with Android
devices. One issue was that the packaging system for Android did remove
some folders we put inside META-INF. The folder we put there was
localizatio
On 02/10/2012 10:58 AM, Sébastien Brisard wrote:
> Here is a recent thread on this issue (as you can see, this thread was
> caused by a faulty commit from me...).
> Best regards,
> Sébastien
>
> http://mail-archives.apache.org/mod_mbox/commons-dev/201201.mbox/%3C20120113105913.GM6537%40dusk.harfan
On Fri, Feb 10, 2012 at 10:58:30AM +0100, Sébastien Brisard wrote:
> Hi Thomas,
> 2012/2/10 Thomas Neidhart :
> > On 02/10/2012 09:58 AM, Sébastien Brisard wrote:
> >> Hello,
> >>>
> >>> I strongly prefer _not_ to have the (unchecked) exceptions in the
> >>> signature.
> >>> [Arguments mentioned n
On Fri, Feb 10, 2012 at 11:08:12AM +0100, Thomas Neidhart wrote:
> On 02/10/2012 10:58 AM, Sébastien Brisard wrote:
> > Here is a recent thread on this issue (as you can see, this thread was
> > caused by a faulty commit from me...).
> > Best regards,
> > Sébastien
> >
> > http://mail-archives.apa
Le 10/02/2012 11:23, Gilles Sadowski a écrit :
> On Fri, Feb 10, 2012 at 10:58:30AM +0100, Sébastien Brisard wrote:
>> Hi Thomas,
>> 2012/2/10 Thomas Neidhart :
>>> On 02/10/2012 09:58 AM, Sébastien Brisard wrote:
Hello,
>
> I strongly prefer _not_ to have the (unchecked) exceptions in
On 10/02/2012 00:20, Simone Tripodi wrote:
> I have a preference fo juli.
I can work with that.
> IIRC, Tomcat has a bridge from juli to logging impl,
It is actually the other way around. Tomcat uses a package renamed
commons-logging hard-coded to output to juli by default. It provides a
package r
On Feb 10, 2012, at 5:39, Mark Thomas wrote:
> On 10/02/2012 00:20, Simone Tripodi wrote:
>> I have a preference fo juli.
> I can work with that.
Is a dependency on JULI better than on common-logging?
Or is there some confusion talking about JUL vs JULI?
Gary
>
>> IIRC, Tomcat has a bridge fro
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=18606&projectId=98
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 10 Feb 2012 12:20:39 +
Finished at: Fri 10 Feb 2012 12:21:13 +
Total time: 34s
Build Trigger: Schedule
Bui
Hi Gary,
apologize, I meant the native java.util.logging.* APIs.
all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Feb 10, 2012 at 1:16 PM, Gary Gregory wrote:
> On Feb 10, 2012,
Gary Gregory wrote:
>On Feb 10, 2012, at 5:39, Mark Thomas wrote:
>
>> On 10/02/2012 00:20, Simone Tripodi wrote:
>>> I have a preference fo juli.
>> I can work with that.
>
>Is a dependency on JULI better than on common-logging?
>
>Or is there some confusion talking about JUL vs JULI?
I was as
Hi,
ma...@apache.org wrote:
> Gary Gregory wrote:
>
>>On Feb 10, 2012, at 5:39, Mark Thomas wrote:
>>
>>> On 10/02/2012 00:20, Simone Tripodi wrote:
I have a preference fo juli.
>>> I can work with that.
>>
>>Is a dependency on JULI better than on common-logging?
>>
>>Or is there some con
> Author: markt
> Date: Fri Feb 10 11:08:55 2012
> New Revision: 1242742
>
> URL: http://svn.apache.org/viewvc?rev=1242742&view=rev
> Log:
> Target Java 6 since 1.5 is out of support unless you pay for it.
+1!!!
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http:/
Le 10/02/2012 14:51, Gary Gregory a écrit :
> Hi All,
>
> [pool2] just went from Java 5 to Java 6 because Java 5 requires paid-for
> support from Oracle.
>
> How does the ML feel about moving projects that are now on Java 5 to Java 6?
I think it would be a good thing. Now Java 5 seems rather out
On 02/07/2012 01:52 PM, Mladen Turk wrote:
Votes, please. This vote will close in 72 hours
[X] +1 Release Daemon 1.0.9
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Just to record my vote.
Since 72 hour period exceeded, suppose I'll just
decla
Hi All,
If we do logging, JUL is acceptable of course. So is commons-logging.
When it is integration time, we'll need some guidance even if it is just
pointers to HOW-TOs. In my case, what happens when my server to coded to
Log4J and I want all logging to go to the same file? I do not need an
ans
On 10/02/2012 13:25, Jörg Schaible wrote:
> Hi,
>
> ma...@apache.org wrote:
>
>> Gary Gregory wrote:
>>
>>> On Feb 10, 2012, at 5:39, Mark Thomas wrote:
>>>
On 10/02/2012 00:20, Simone Tripodi wrote:
> I have a preference fo juli.
I can work with that.
>>>
>>> Is a dependency on J
Le 10/02/2012 15:41, Ralph Goers a écrit :
In many cases the differences between Java 5 and 6 aren't noticeable. If the
project doesn't require anything from Java 6, why require it? I'm sure there
are quite a few places where it is still being used despite the end of support.
In short, if th
Le 10/02/2012 15:53, Gary Gregory a écrit :
When it is integration time, we'll need some guidance even if it is just
pointers to HOW-TOs. In my case, what happens when my server to coded to
Log4J and I want all logging to go to the same file? I do not need an
answer now but it will be an issue.
On 10/02/2012 14:41, Ralph Goers wrote:
> In many cases the differences between Java 5 and 6 aren't noticeable.
> If the project doesn't require anything from Java 6, why require it?
> I'm sure there are quite a few places where it is still being used
> despite the end of support.
I think there ar
+1 for targeting Java 6 on new releases...
Bill-
On Fri, Feb 10, 2012 at 10:18 AM, Mark Thomas wrote:
> On 10/02/2012 14:41, Ralph Goers wrote:
> > In many cases the differences between Java 5 and 6 aren't noticeable.
> > If the project doesn't require anything from Java 6, why require it?
> >
On Fri, Feb 10, 2012 at 10:15 AM, Emmanuel Bourg wrote:
> Le 10/02/2012 15:53, Gary Gregory a écrit :
>
>
> When it is integration time, we'll need some guidance even if it is just
>> pointers to HOW-TOs. In my case, what happens when my server to coded to
>> Log4J and I want all logging to go t
Le 10/02/2012 16:22, Gary Gregory a écrit :
This would be good to know: What is the performance hit of the two
solutions above?
The question becomes: should pool2 depend on CL?
Bridging JUL is probably not the most efficient solution, but if the
application is not very log intensive I think
On 10 February 2012 14:41, Ralph Goers wrote:
> In many cases the differences between Java 5 and 6 aren't noticeable. If the
> project doesn't require anything from Java 6, why require it? I'm sure there
> are quite a few places where it is still being used despite the end of
> support.
AIUI
On 10 February 2012 14:22, Mladen Turk wrote:
> On 02/07/2012 01:52 PM, Mladen Turk wrote:
>>
>>
>> Votes, please. This vote will close in 72 hours
>>
>> [X] +1 Release Daemon 1.0.9
>>
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>
> Jus
On Fri, Feb 10, 2012 at 11:36 AM, Luc Maisonobe wrote:
> The unwritten consensus here for the last few months seems to be: there
> are different points of view which cannot be reconciled. So we gave up
> on achieving consistency and everyone does as he sees fit.
>
> Thomas and Sébastien, please do
Hi,
Recently a project required doing multipart upload using base64
content-transfer-encoding. After
spring's CommonsMultipartResolver failed to comply and after few hours
of digging into the sources it became apparent that 1) decoding
multiparts isn't implemented, 2) extending the resolver to do i
On 10 February 2012 15:18, Mark Thomas wrote:
> On 10/02/2012 14:41, Ralph Goers wrote:
>> In many cases the differences between Java 5 and 6 aren't noticeable.
>> If the project doesn't require anything from Java 6, why require it?
>> I'm sure there are quite a few places where it is still being
Well damn, got a creeping suspicion right after hitting submit that I
should've checked the version control before posting and as you might
guess, this change was added already about a year ago (how about a
release?)
-Samuli
-
To
Hi *,
I am in the situation where 1.6 would be preferred (and that's why I
expressed my positive feeling on switching to JDK6): for Digester 3 I
had to revert the initial import of the Annotations Processor, because
still using Java5 com.sun.* APT APIs - not present at least in our
Continuum JVM -
Le 10/02/2012 15:22, Mladen Turk a écrit :
> On 02/07/2012 01:52 PM, Mladen Turk wrote:
>>
>> Votes, please. This vote will close in 72 hours
>>
>> [X] +1 Release Daemon 1.0.9
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>
> Just to reco
On 10/02/2012 16:20, sebb wrote:
> On 10 February 2012 15:18, Mark Thomas wrote:
>> On 10/02/2012 14:41, Ralph Goers wrote:
>>> In many cases the differences between Java 5 and 6 aren't noticeable.
>>> If the project doesn't require anything from Java 6, why require it?
>>> I'm sure there are quit
Hi.
This is an issue raised in relation to this JIRA ticket:
https://issues.apache.org/jira/browse/MATH-742
My position is that there should not be a discussion each time someone wants
a class to be "Serializable". Ideally, the rule should be clear enough that
the developer of a new class knows
On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote:
>>
>
> Yeah, that isn't going to work. I really do wish java.util.logging had
> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
> this in Tomcat but even with JULI the APIs just aren't available to do
> this. You could do JVM
On Feb 10, 2012, at 7:40 AM, Emmanuel Bourg wrote:
> Le 10/02/2012 16:22, Gary Gregory a écrit :
>
>> This would be good to know: What is the performance hit of the two
>> solutions above?
>>
>> The question becomes: should pool2 depend on CL?
>
> Bridging JUL is probably not the most efficien
On Feb 10, 2012, at 7:18 AM, Mark Thomas wrote:
> On 10/02/2012 14:41, Ralph Goers wrote:
>> In many cases the differences between Java 5 and 6 aren't noticeable.
>> If the project doesn't require anything from Java 6, why require it?
>> I'm sure there are quite a few places where it is still bei
Hi Ralph,
just for a matter of curiosity and filling my lacks of knowledge, can
you point me please to some doc about the lacks of j.u.l. ?
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
On Feb 10, 2012, at 15:08, Ralph Goers wrote:
>
> On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote:
>
>>>
>>
>> Yeah, that isn't going to work. I really do wish java.util.logging had
>> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
>> this in Tomcat but even with JULI the AP
The better thing to do would be to point you to http://logback.qos.ch or
http://people.apache.org/~rgoers/log4j2/. Compare the features in either of
those against JUL.
When building a framework you can't look at logging in isolation. Nobody wants
to configure JUL and Logback and Log4j, etc.
R
Hi Ralph,
log4j2 looks really promising, I'll join the logging ML.
And nice to see fluido-skin in action :P
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Feb 10, 2012 at 9:34 PM, Ralph Goer
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-exec-test has an issue affecting its community integration.
This i
This is a vote to release Apache Commons NET 3.1 based on RC1.
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...
tag:
https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_1_RC1/ (r1242993)
site:
http://people.apache.org/~sebb/NET_3_1_RC1/site/
The
On Fri, Feb 10, 2012 at 6:36 PM, sebb wrote:
> On 11 February 2012 02:23, James Carman wrote:
>> I am +1 to allowing new major version releases to go to Java 6. Heck,
>> I'm +1 to them choosing to jump straight to Java 7. I don't think we
>> should require it or anything, though.
>
> The Common
On Fri, Feb 10, 2012 at 9:56 PM, Henri Yandell wrote:
> I don't see why we would have to wait on major versions for updates.
>
Well, if we compile foo-1.1 with Java 5 and then compile foo-1.2 with
Java 6 (assuming we don't target 1.5 on the compile), doesn't that
make them effectively binary inco
I'm not involved with [POOL] (so this is mostly from the peanut gallery),
but do strongly think that logging should be minimal for such a low level
component. As such, if there needs to be any logging at all, it should use
JUL. While it would be nice in a development environment so see my bone
While the development team has exploded for [MATH], maintaining Serializable
interfaces is expensive and historically hasn't been kept up. So I would go
for requiring the user to do something like:
public class MyPolynomialSplineFunction extends PolynomialSplineFunction,
implements Serializab
On Fri, Feb 10, 2012 at 7:45 PM, James Carman
wrote:
> On Fri, Feb 10, 2012 at 9:56 PM, Henri Yandell wrote:
>> I don't see why we would have to wait on major versions for updates.
>>
>
> Well, if we compile foo-1.1 with Java 5 and then compile foo-1.2 with
> Java 6 (assuming we don't target 1.5
On Fri, Feb 10, 2012 at 11:44 PM, Henri Yandell wrote:
>
> I'd have thought they'd be fine.
>
> A Java6 user using 1.1 upgrading to 1.2 would be able to drop it in.
>
> A Java5 user wouldn't, but that's dropping support not binary incompatibility.
>
So, would any new features and bug fixes for 1.
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
On Fri, Feb 10, 2012 at 9:38 PM, James Carman
wrote:
> On Fri, Feb 10, 2012 at 11:44 PM, Henri Yandell wrote:
>>
>> I'd have thought they'd be fine.
>>
>> A Java6 user using 1.1 upgrading to 1.2 would be able to drop it in.
>>
>> A Java5 user wouldn't, but that's dropping support not binary
>> i
53 matches
Mail list logo
