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
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 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.
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
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
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
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
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
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
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
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
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
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
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 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
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: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
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 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
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
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 -
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
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
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 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
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 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
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 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
+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 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
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.
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
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
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 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
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
> 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:/
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
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 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,
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
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
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
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 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
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 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
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
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
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
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
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
53 matches
Mail list logo
