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 logging-log4j-12 has an issue affecting its community integration.
This is
On May 31, 2012, at 22:41, Ralph Goers wrote:
If you don't do that then you end up with a bunch of optional dependencies
that you will forget to include or a bunch of required dependencies that
you may not really need.
Separating the API from the impl is useful as it keeps users from accessing
s
If you don't do that then you end up with a bunch of optional dependencies that
you will forget to include or a bunch of required dependencies that you may not
really need.
Separating the API from the impl is useful as it keeps users from accessing
stuff that wasn't meant to be public - which i
Why would that require a 1.3?
Ralph
On May 31, 2012, at 2:24 PM, "Jacob Kjome" wrote:
>
> The main point is separate the tools from the library. That means each of
> Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from
> Log4j.jar. That's all. This will make Log4j.jar muc
On Thu, May 31, 2012 at 5:24 PM, Jacob Kjome wrote:
>
> The main point is separate the tools from the library. That means each of
> Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from
> Log4j.jar. That's all. This will make Log4j.jar much smaller (by
> extracting Lf5 and Chai
The main point is separate the tools from the library. That means each of
Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from
Log4j.jar. That's all. This will make Log4j.jar much smaller (by extracting
Lf5 and Chainsaw1). Only users that specifically want to use the tools
My beef is that I do not want 10 jars to pick from, this is a low level
components, give me one jar to rule them all. Or at least give me the
option to pick an all-in-one jar. For those who want to save 10KB here and
there, they can cherry pick I suppose.
Gary
On Thu, May 31, 2012 at 3:52 PM, Ral
Log4j 2 is already a multi-module build. I am not at all sure why you would
want to expend all this effort on a 1.3 when 2.0 should be our next target.
Ralph
On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
> Hi all
> following Christian's rant at Google+:
> https://plus.google.com/102440
Hi all
following Christian's rant at Google+:
https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
I started forking Log4j at GitHub:
https://github.com/apetrelli/log4j
The first step I did is providing a stub for a multi-module build.
Assuming that Log4j should be multi-module is funda
On Thu, May 31, 2012 at 7:42 PM, Christian Grobmeier
wrote:
>> Some comments advocated "nuke", but I think the most prescient comments were
>> from Curt[1] and Paul[2], at least those are the ones I agree with. I think
>> Paul's suggestion of a stripped down log4j.jar and a separate
>> log4j-with
> Some comments advocated "nuke", but I think the most prescient comments were
> from Curt[1] and Paul[2], at least those are the ones I agree with. I think
> Paul's suggestion of a stripped down log4j.jar and a separate
> log4j-with-gui.jar is probably the best approach, though I'd go further to
On Thu, 31 May 2012 18:30:05 +0200
Christian Grobmeier wrote:
Looks like we either need to remove the examples from compilation, or at
least remove the lf5 examples from the main build along with the removal of
the lf5 and chainsaw1 packages.
Yes its my fault somehow. I am on the build and
On Thu, May 31, 2012 at 6:03 PM, Jacob Kjome wrote:
>
> Changed subject to make sure my response gets noticed. Read below...
Thanks, I missed your mail.
>> Looks like we either need to remove the examples from compilation, or at
>> least remove the lf5 examples from the main build along with th
Changed subject to make sure my response gets noticed. Read below...
Jake
On Wed, 30 May 2012 13:25:28 -0500
"Jacob Kjome" wrote:
Looks like we either need to remove the examples from compilation, or at
least remove the lf5 examples from the main build along with the removal of
the lf5
https://issues.apache.org/bugzilla/show_bug.cgi?id=44370
grobmeier changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://issues.apache.org/bugzilla/show_bug.cgi?id=48527
grobmeier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.apache.org/bugzilla/show_bug.cgi?id=49932
grobmeier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #57 from grobmeier ---
Folks,
I would like to suggest you to bring this discussion to the mailinglist:
log4j-dev@logging.apache.org
At the moment this discussion gets only a low exposure as we are mainly
discussing new feature
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #56 from Patric Rufflar ---
>Or do I miss something?
I suppose you are.
I'll let some details out but I hope that this helps nevertheless:
The problem is that a ThreadLocal is always implicitly strongly referenced by
the threa
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #55 from smarkwal ---
I don't think that setting tlm = null on shutdown would make a big difference.
When your web application is undeployed, all classes loaded by the web app's
classloader should get unloaded and GC'ed, includ
20 matches
Mail list logo
