On 19 May 2004, at 23:11, Adam R. B. Jack wrote:
i haven't found time to fix digester, beanutils and struts gump runs
yet but i hope to do so tomorrow. i you could give me some quick
pointers to the best way to do the additional targets, i'll add them
to
my list of stuff to do...
Thanks for doing
On 20 May 2004, at 13:49, Shapira, Yoav wrote:
Anyways, I wanted to point out a small item: the additional
functionality and other changes from log4j 1.2 to 1.3 would easily be
considered by many projects a 2.0 or major release.
but (in log4j's defense), this is consistent with previous log4j
prac
The strategy we adopted when renaming Category as Logger and Priority
as Level at the time log4j 1.2 was released, consisted of having Logger
extending Category, and Level extending Priority. This is quite a
non-intuitive approach but with solid technical reasons behind it.
[1] http://www.geocrawle
At 11:08 PM 5/19/2004, robert burrell donkin wrote:
hi ceki
i've committed a patch along the lines you've proposed. many thanks :)
You are welcome.
i've added some optional unit tests that give me confidence that a
version of commons-logging compiled against log4j CVS HEAD will run
against 1.2.7. i
> Version numbers
> Together with deprecations this makes it easy (well sort of) to see
> which piece of software that is a drop-in replacement and which will
> require changes to your own code. In my book upgrading from 1.0.1 to
> 1.0.2 should be a walk in the park, but upgrading from 1.0 to 2.0
>
, 2004 1:08 PM
To: Jakarta Commons Developers List
Cc: Apache Gump
Subject: Re: [logging][PROPOSAL] a solution to incompatibility between
log4j versions
On the log4j we are making a very serious effort to keep everyone
happy.
And that is greatly appreciated. :)
I really wish you weren
> > If so, the trick would be to run commons-logging unit tests separately
> > from
> > the compile, and run two of them with a dependency on logging-log4j and
> > logging-log4j-12.
>
> something along those lines would probably work.
Basically depend upon C-L to get what you just built, and then
On 19 May 2004, at 22:32, Adam R. B. Jack wrote:
i've added some optional unit tests that give me confidence that a
version of commons-logging compiled against log4j CVS HEAD will run
against 1.2.7. it'd be a good idea to find a way for gump to run this
test (but i'm not too sure at the moment how
> i've added some optional unit tests that give me confidence that a
> version of commons-logging compiled against log4j CVS HEAD will run
> against 1.2.7. it'd be a good idea to find a way for gump to run this
> test (but i'm not too sure at the moment how to do this). i'll probably
> add another
hi ceki
i've committed a patch along the lines you've proposed. many thanks :)
i've added some optional unit tests that give me confidence that a
version of commons-logging compiled against log4j CVS HEAD will run
against 1.2.7. it'd be a good idea to find a way for gump to run this
test (but
> Which is why GUMP should allow projects to specify dependencies
> on SPECIFIC versions of other products
A project may want to track the latest FOO, which forces it to pickup a
newer BAR, too, even though its own use of BAR might want to stay stable.
There are all sorts of possibly dependenc
You guys stopped me in my tracks for a mo, and I am (in my time) trying to
get towards Gump w/ specific versions, but for here and now ...
> "If it ain't broke, don't fix it."
I can understand that for larger projects, but not for
infrastructure/wrappers like C-L. C-L, by it's nature, is sitting
One thing I've noticed is that as a rule of thumb, when something breaks in
GUMP, people tell the dependents to update. Hopefully, as GUMP pervades the
mindset for people, there will be equal pressure on dependencies to
stablize.
This is *not* to say that Log4J is doing anything wrong. I'm makin
solution to incompatibility between
log4j versions
> I wish projects had stopped using deprecated stuff a year ago, heck
> ... or two.
"If it ain't broke, don't fix it."
Stable projects do not like making change for changes sake. Have you
noticed that although Sun depre
> I wish projects had stopped using deprecated stuff a year ago, heck
> ... or two.
"If it ain't broke, don't fix it."
Stable projects do not like making change for changes sake. Have you
noticed that although Sun deprecates methods, they rarely remove them unless
there is a real security concer
On 19 May 2004, at 19:22, Adam R. B. Jack wrote:
FWIIW: I don't know (wish I did) if there was a time in those two
years, a
period of log4j releases, where there were more 'actively used
releases'
that supported Priority than both Priority and Level. I wonder when
would
have been the right time
On 19 May 2004, at 16:32, Noel J. Bergman wrote:
we could also use reflection at all to call those log( methods,
but this might result in an performance loss.
Is logging is THAT performance critical?
definitely yes :)
- robert
-
To
Hi,
>That said, it is an interesting challenge -- aligning the projects is
like
>aligning the stars -- and good inter-project communications (tough in
OSS)
>are critical to this. I don't know if the Java language allowed the
>class/methods to be marked as deprecated, 'cos I'm sure compiler
warnin
Noel J. Bergman wrote:
we could also use reflection at all to call those log( methods,
but this might result in an performance loss.
Is logging is THAT performance critical?
Not for me, but i have seen so many benchmarks about logging-libraries,
that i just wanted to bear in mind that this
> >BTW: I also wish folks had updated long ago, we'd have had a much smaller
> >transition, be having discovered this sooner.
I worded this poorly, and failed to get my point across. I meant ... I wish
projects had stopped using deprecated stuff a year ago, heck ... or two.
Progress has to be allo
At 07:28 PM 5/19/2004, you wrote:
> What about the option of having commons-logging 1.0.3 and earlier work
> with log4j 1.2.8 and earlier, and commons-logging 1.0.4 and later do
> whatever it feels like (since that's now possible with Ceki's recent
> changes)?
> I'm not gung ho about bending over b
Hi,
>BTW: This isn't just C-L.
Whomever: the removed stuff has been deprecated for two years. If a
project hasn't had a release in that long, I'd say it's stable enough
that it doesn't need log4j 1.3 urgently ;)
>BTW: I also wish folks had updated long ago, we'd have had a much
smaller
>transi
> What about the option of having commons-logging 1.0.3 and earlier work
> with log4j 1.2.8 and earlier, and commons-logging 1.0.4 and later do
> whatever it feels like (since that's now possible with Ceki's recent
> changes)?
> I'm not gung ho about bending over backwards in order to not
> remove
Sent: Wednesday, May 19, 2004 1:08 PM
>To: Jakarta Commons Developers List
>Cc: Apache Gump
>Subject: Re: [logging][PROPOSAL] a solution to incompatibility between
>log4j versions
>
>> On the log4j we are making a very serious effort to keep everyone
>> happy.
>
>And
> On the log4j we are making a very serious effort to keep everyone
> happy.
And that is greatly appreciated. :)
I really wish you weren't having to go through this, I can hardly imagine
how frustrating it must be to maintain an old interface for two years,
attempting a clean deprecation, only ru
At 05:48 PM 5/19/2004, Adam R. B. Jack wrote:
> With some changes to log4j HEAD and the following patch to
> commons-logging, it is now possible to compile commons-logging with
> 1.3alpha and run it with both 1.3 *and* 1.2.8.
Is it too late to ask if things in log4j could be put back to where they
> With some changes to log4j HEAD and the following patch to
> commons-logging, it is now possible to compile commons-logging with
> 1.3alpha and run it with both 1.3 *and* 1.2.8.
Is it too late to ask if things in log4j could be put back to where they
were a week ago, while we work together for
> we could also use reflection at all to call those log( methods,
> but this might result in an performance loss.
Is logging is THAT performance critical?
--- Noel
smime.p7s
Description: S/MIME cryptographic signature
Shapira, Yoav wrote:
It'd be easy to do conditional stuff, as Joran for example is completely
new in log4j 1.3, with Ant's tasks and related conditionals.
I am not sure, if the "conditional stuff" helps. If you end up not being
binary-compatible, i think commons-logging needs two compile-steps
Message-
>From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, May 18, 2004 6:20 PM
>To: Jakarta Commons Developers List
>Subject: Re: [logging][PROPOSAL] a solution to incompatibility between
>log4j versions
>
>> i'm very open to suggestions about the bes
> i'm very open to suggestions about the best way to structure the build
> scripts.
You able to benefit from Ant 1.6 (or are they earlier?) selectors? Ant's own
build file uses them (along with
the gump build of log4j has been failing over the last few days. this
has (in turn) lead to a large number of downstream build failures. this
has alerted us to the fact that we're fast approaching the time where
we will have to deal with supporting three binary incompatible major
versions of Lo
32 matches
Mail list logo
