Paul,
I am all for plugin architectures, especially around gui elements. The hard
part is making the gui usable with all of the gui plugins being added, etc.
I have recently played with jEdit, and I don't know if it is a good model,
but it was interesting with all the plugin support, especially a
Hi Kris,
I might be wrong, but I think such an appender already exists in the log4j
framework? I know I have heard this one before...
At any rate, if you are willing to apply an Apache license to the source
code, we can certainly move the appender into the log4j-sandbox, and given
time, document
Endre,
Put together a proposal for adding the TRACE level, code changes and all.
Let's vote on it and decide if we want to add it or not. This was a topic
that was also pushed by the Geronimo team at the last ApacheCon.
-Mark
-Original Message-
From: Endre Stølsvik [mailto:[EMAIL PROTEC
Geir,
Geez, I've been waiting for you to stand up and ask about the vote that was
promised at ApacheCon.
All we need is someone to propose the changes to they can be reviewed (not
torn apart as Endre says) and voted on. The change should be backward
compatible.
-Mark
-Original Message-
This rocks, Paul.
-Mark
-Original Message-
From: Paul Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 6:27 PM
To: '[EMAIL PROTECTED]'
Subject: Chainsaw & Java Web start
For all you bleeding edge Chainsaw people out there I have signed with my
own personal email certificate
Paul, et al,
Thanks for reporting and tracking down this bug! But just to be clear, the
Receiver is going to attempt the reconnect, right? Not the appender? The
whole point of the SocketHubAppender it that it does not spend any
time/resources trying to reconnect socket connections, that way it
Paul,
Cool. Thanks!
-Mark
- Original Message -
From: "Paul Smith" <[EMAIL PROTECTED]>
To: "'Log4J Developers List'" <[EMAIL PROTECTED]>
Sent: Monday, May 24, 2004 8:04 PM
Subject: RE: Receiver Socket connection/reconnect problems (was RE:
reconnecting to SocketHubAppender)
> Appender)
Not everyone is going to use Eclipse, whatever version. But we have
standardized on using Ant for official builds, etc. I think we should stick
with Jalopy via Ant for "official" formatting, but document the relevant
formatting rules so that whatever tool you use, you adhere to the most
important
+1
What is the current plan for the 1.3 release?
-Mark
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: Monday, November 01, 2004 9:35 AM
To: Log4J Developers List
Subject: RE: [POLL] a 1.2.9 release?
+1 if ditto what Yoav said.
Jake
Quoting "Shapira, Yoav" <[EMAI
Andy,
The api for the Receiver is still open to changes. I need to refresh
myself, but I believe it inherits the shutdown() method signature from the
Plugin interface where "shutdown" makes more contextual sense than "close".
At least I thought so at the time of the design.
While they are mirror
I've been out of touch for way too long, and so I
am wondering if there is a current plan in place for the release of log4j
1.3? If not, I am willing to work on creating one. Even if we don't
have specific dates for milestones, if we can come up with a list of required
actions to be taken,
Appender vs shutdown() a Receiver
>
>
>
> Hello Mark,
>
> I also prefer close() instead of shutdown().
>
> Anyway, there were a number of simplifications to the Plugin and
> PluginRegistry code earlier this year. Otherwise, the code
> has remained the
> sam
+1 for alpha 1. I will be looking at reviewing the plugin/receiver stuff
and adding watchdogs. But no reason to stop an alpha 1 release.
-Mark
- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 17, 2004 1:58 AM
Subject: [POLL]
Yeah!
Thanks, Ceki.
-Mark
- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 24, 2004 10:54 AM
Subject: 1.3alpha_1 tagged
Greetings from the pit,
At last, a binary version of 1.3alpha-1 is now available for download
from our web-
Attempting to get my head wrapped around this stuff
before starting on the watchdog design and implementation.
1) You guys beat me to it. I was going to
make the change from a static, separate PluginRegistry to a per-LoggerRepository
instance. Good move. That really simplified the implem
Ceki,
It's a separation of concerns' issue. The PluginRegistry is just a
bag containing plugins, plus keeps track of listeners.
Also keep in mind that we already have a model for configuring log4j
components. It is as follows:
1) Create a new instance of the desired class, call this instance X.
2)
Ceki,
I guess I am missing the context here since we are successfully configuring
plugins today with the old XML configurator.
And looking at the code, the o.a.l.spi.LoggerRepository interface has new
methods to get/return the PR associated with it. The Hierarchy class
implements them, so ther
We have discussed this before, many moons ago. In order to better support
the various types of Watchdogs I want to implement in v1.3, I want to add
the following method to the Configurator interface:
/**
Use an InputStream as a source for configuration and set up log4j
accordingly.
T
trong objections, I will add the changes in tomorrow evening. I
should also have a first version of the FileWatchdog ready tomorrow as well.
Then we can start testing it to make sure it allows web apps to properly
shutdown.
-Mark
- Original Message -
From: "Mark Womack" &l
ot in favor of modifying the Configurator interface.
At 07:24 AM 12/7/2004, Mark Womack wrote:
>We have discussed this before, many moons ago. In order to better support
>the various types of Watchdogs I want to implement in v1.3, I want to add
>the following method to the Configur
In the JMS case, it does not support InputStream, but one can do some work
to cast/wrap the data as an InputStream (in the watchdog), where I cannot
cast/wrap it as a URL very easily, if at all.
In the Socket case, yes, data would be pushed to the watchdog watching the
socket. I do not have my sp
is
called, then I have no objections. Otherwise, if the thread will just
hang there and prevent correct application recycling, then we would
have a serious bug on our hands.
As usual, I'd be glad to see test cases accompanying this new
important contribution.
At 10:03 PM 12/7/2004
I had a heck of a time with the test cases. First it was complaining that
it could not find a ./test/lib directory. Then it was complaining that it
could not find jetty related classes. Then it was complaining about the
test cases being invalid with JUnit.
AGH! I know I have been out of it
My recent commits don't have anything to do with this issue. They certainly
don't extend the Configurator api to include a getErrorList method or a
doConfigure method that takes a list to put errors into.
Just from this description, it appears that only JoranConfigurator has this
"stateful" fe
rs List
Subject: Re: Test Update
Mark,
Things should much smoother with the recent updates. In case of
missing jakarta-oro.jar or junit.jar files, the new failures messages
should also help the user figure out the corrective steps.
At 07:10 AM 12/9/2004, Mark Womack wrote:
>I had a heck of a
---
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Friday, December 10, 2004 2:46 AM
To: Log4J Developers List
Subject: Re: Make Configurators stateless again
At 09:29 PM 12/9/2004, Curt Arnold wrote:
>On Dec 9, 2004, at 12:32 AM, Mark Womack wrote:
>
>It looks like you were adding doC
I agree with Niclas. Unless there is something else going on here, his
suggestion was appropriate. I just did not take any action because I
figured Yoav would fix it the right way when he had a chance. It didn't
look like there were any other dependencies, but hey, I haven't been keeping
track o
So, I have had the opportunity at my job to integrate and
use the o.a.log4j.servlet classes in the sandbox. And I have to say that
the initialization related classes (InitContextListener,
InitShutdownController) really rock! Many thanks to Jake for focusing on
these classes and making the
Well, maybe you guys have had to solve this kind of problem before. I want
to have the log home directory in one place for jboss and another place for
tomcat. So, I was mucking with some code to set the log home base
directory. The mechanism I fellback to was looking at the system
properties. I
Jake,
I have a log4j configuration file per web application, so the appender
settings, etc are per web app. I am trying to control where the files for
each web app are located. It is kind of whacked, but I have been convinced
by Yoav and Andy that having some mechanism to allow for external
conf
For some reason, some of my email messages to log4j dev seem to get caught
up, and others get posted immediately. Testing.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[X] +1, I support Curt's candidacy
[ ] 0, I abstain
[ ] -1, I vote against
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 15, 2004 2:40 PM
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Curt Arnold as a new log4j committer
>
>
> Hello al
[X] +1, I support Curt's candidacy
[ ] 0, I abstain
[ ] -1, I vote against
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 15, 2004 2:40 PM
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Curt Arnold as a new log4j committer
>
>
> Hello al
Hey Jake, comments below.
> -Original Message-
> From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 15, 2004 6:20 PM
> To: Log4J Developers List
> Subject: RE: o.a.log4j.servlet
>
> At 05:39 PM 12/15/2004 -0800, you wrote:
> >>
> >>
> >> >> override="false"
> >
I think "EnterpriseLog" is a bit misnamed. All they really want to add is
internationalization support for log messages of level INFO, WARN, and
FATAL. Seems like there could be a more interesting way to do this than
adding new methods that take generic ResourceBundle parameters, but maybe
not.
s Re: Make Configurators
stateless again)
On Dec 10, 2004, at 11:01 AM, Mark Womack wrote:
> The baseURI issue has nothing to do with URL vs InputStream. It is
> very XML
> protocol specific, and I don't think that any specific protocol issue
> should
> be propagated
Yoav,
This change does not compile. The ErrorHandler interface does not support
error(String,Exception). Not sure how you want to resolve this. I took a
quick look, and there are methods that take an Exception, but they also
require other parameters, like an error code.
[javac]
D:\develo
Yeah, what I am doing is whacked, no doubt about it. "Abandon all hope that
pass this gate..."
I like the JNDI solution, or even requiring a specific system property to be
declared for the container. However, whatever I do here, good chances are
someone will need to do some different kind of cus
Jake,
> > One thing I noticed with the default behavior in InitShutdownController
> is
> > that if you deploy using a war file, then the WEB-INF/log directory
> > typically ends up in the temp directory the container (like jboss) uses
> to
> > expand/explode the war file. Tracking down the locati
I finished up the implementation of the FileWatchdog last night but before
checking it in for general consumption, I want to make sure there are some
decent test cases in place. I am going to use the new JoranConfigurator to
configure a FileWatchdog from an xml config file that is being watched.
What defines the log4j "client API"? o.a.log4j.spi?
-Mark
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 22, 2004 1:55 PM
> To: Log4J Developers List
> Subject: Re: setOption/setOptions duality in PatternConverter
>
> At 10:49 PM 12/22/2004
Not a bad idea per se, but what is the motivation with making it an
interface? Will the outside world need to know about the Component
interface in any way? Do we intend to reference log4j objects as Component
or maybe use it as a marker interface?
If we just need this internally for log4j then
Is there a version of ContextJNDISelector that is compatible with log4j
1.2.8 or 1.2.9? What are folks using for a RepositorySelector in the
pre-1.3 world?
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
> No, log4j objects will not be referenced as Component. It is not a
> marker interface either.
>
> The requirement to have both Component as an interface and
> ComponentBase as a class, stems from the fact that we make the
> distinction between Appender the interface and AppenderSkeleton the
> cl
How about "LoggerRepositoryAware" for the name of the interface? This
follows the pattern the Spring framework uses to name interfaces that define
allowed setter methods (ie ApplicationContextAware interface defines a
method setApplicationContext(ApplicationContext ac)).
ComponentBase could still
Geez! That was a long time ago!
I'll have to review the code to be more up on the issues, but I know I was
not terribly happy with the implementation. It was much too confusing, but
at the time I was trying to work with what was there, not change the
framework.
What kind of change are you conte
Which item is this in Effective Java? He also makes a strong argument (Item
1) to use static factory methods instead of constructors.
I think that going down the constructor path can potentially lead to
"parameter madness" as you add more "required" members that must be set at
construction time.
Could we break it up into 2 jars, log4j-core.jar and log4j-ext.jar, instead
of a multitude of api specific jars? Does this get in the way of what you
are trying to accomplish?
-Mark
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 13, 2005 9:09
I checked in the first round of changes for the Watchdog stuff. There is
just a single test case right now to test FileWatchdog in stand alone usage
using the JoranConfigurator. This test case is not active yet (see below)
and I plan to add more test cases soon.
So, I have already encountered
Yeah, that makes sense. I was not suggesting that there be a different
format for each configurator. Only that we might need to introduce some new
attributes to control the behavior of the configurator.
But I am still looking at the issue before coming to a conclusion yet.
-Mark
- Original
Looking at the behavior I am seeing with my FileWatchdogTestCase, I think
there is a bug in JoranConfigurator or there is something new I don't
understand here.
If I just have this code:
Configurator configurator = new JoranConfigurator();
configurator.doConfigure(configURL, LogManager
log4j.appender.A.layout=org.apache.log4j.PatternLayout
log4j.appender.A.layout.ConversionPattern=%p - %m%n
log4j.logger.org.apache.log4j.watchdog.FileWatchdogTestCase=DEBUG
-Mark
- Original Message -
From: "Mark Womack" <[EMAIL PROTECTED]>
To: "Log4J Developers List"
Thanks. I will clean it up.
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 31, 2005 10:27 AM
> To: log4j-dev@logging.apache.org
> Subject: No need to enclose parameterized messages in isEnabled checks
>
>
> Mark,
>
> I noticed that you were us
Adding a reset-configuration action sounds like a good thing to have. I'll
look into adding it; it will be a good chance to play with Joran.
But I am still curious as to why the JoranConfigurator starts with the
double logging messages right from the very start of the second doConfigure:
DEBUG -
Well, my prediction was wrong. If I call JoranConfigurator subsequent
times, each time using a config file that does not duplicate previous
appenders, etc, then I do not get the double logging. Cool.
So, I started looking at doing my own ResetConfigurationAction class and
attaching it to the Jor
> -Original Message-
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 22, 2005 6:44 PM
> To: log4j-dev@logging.apache.org
> Subject: Chainsaw as seperate CVS module?
>
> Hey All,
>
> Chainsaw is getting big. What does everyone think about moving Chainsaw
> out into
Martin,
Others can chime in here, but my personal opinion is that it is a bad idea
to include configuration files as part of jar files and changing the default
behavior. The configuration of the log4j, what appenders are created, what
logger messages are sent to where, all of that should be compl
Ceki,
This version of the getLoggerRepository method returns the bottom element of
the Joran execution stack (element 0) which is set up by the
JoranConfigurator at the start of configuration. Many of the existing
actions refer to element 0 to grab the LoggerRepository being configured,
but I did
+1 Engage!
> -Original Message-
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 23, 2005 1:19 PM
> To: log4j-dev@logging.apache.org
> Subject: [VOTE]: Chainsaw as seperate module
>
> This is a formalization of the thread 'Chainsaw as seperate CVS module'.
>
> 1.
, February 23, 2005 9:54 AM
> To: Log4J Developers List; 'Log4J Developers List'
> Subject: RE: Chainsaw as seperate CVS module?
>
> At 05:51 PM 2/23/2005, Mark Womack wrote:
>
> >-1 on doing it in Subversion, for now. I think we need to look at the
> SVN
> &g
Should we start thinking about some general release timeframe for v1.3?
It's been a while since we had a major release, and I think we are getting
close with the feature set for v1.3. Is there anything else major that
needs to be done for v1.3?
- Watchdogs (FileWatchdog, HttpWatchdog, SocketWatch
sitory for all Action instances
> that JoranConfigurator refers to. There is no point in adding a
> getLoggerRepository in Action if it is already in ComponentBase.
>
> In other words, the LoggerRepository entry at the bottom of the stack is
> redundant.
>
> Does
This makes sense. I assume all actions are processed by
SimpleRuleStore.addRule().
-Mark
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 24, 2005 11:26 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: logging-log4j/src/java/org/apache/
I saw these LogLog calls when looking into some of the deprecated warnings
during compile. Is there a reason LogLog is still being used here?
-Mark
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 25, 2005 5:49 AM
> To: [EMAIL PROTECTED]
>
r tests
> - Clean up of LoggingEvent, in particular event property MDC merge logic,
> tests,
> - faster LoggingEvent serialization possibly using a new protocol
>
> Only the latter item involves something other then consolidation of the
> existing code.
>
> Comments?
>
OK, every take a deep breath and count to ten. Please keep one thing in
mind. Everyone is acting in what they feel are the best interests of the
project. Ceki is making changes he thinks are important. Curt is
registering concern and reverting changes to keep things in sync. Everyone
is vo
Erik,
This is the right forum.
We have been discussing the time frame for a 1.3 release on and off. The
last discussion centered around a release in the June time frame. I think
that is a bit aggressive, but I believe it will be some time close to that.
We need to get moving to make that releas
JDJ has an article in this month's issue comparing log4j and
java.util.logging. Unfortunately, the article is not available via the web
yet, unless you subscribe to the JDJ digital subscription.
http://www.sys-con.com/magazine/?issueid=581&src=false
"Their differences can be summarized as, 'What
I like the idea of moving commons logging out of Jakarta and into Logging
Services. I have to admit that I have always been a little perplexed that
it was done in Jakarta Commons, but at the time logging within Apache was
very log4j focused. Now that log4j lives in Logging Services, with other
cr
-
> From: Mark Womack [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 24, 2005 9:33 AM
> To: 'Log4J Developers List'
> Subject: RE: JDJ - log4j vs java.util.logging
>
> I like the idea of moving commons logging out of Jakarta and into Logging
> Services. I have to
> I think it is more interesting to open existing solutions (aka backends)
> for
> other frontends and to improve the way to lookup/bind/manage the backend.
> (See also threads discussing classloader issues and dynamic/static
> binding)
> In my opinion there should be no overwhelming frontend f
> I think it is more interesting to open existing solutions (aka
> backends) for other frontends and to improve the way to
> lookup/bind/manage the backend.
> (See also threads discussing classloader issues and dynamic/static
> binding)
> In my opinion there should be no overwhelming frontend
I would prefer to investigate keeping UGLI within ASF. Moving UGLI outside
of Apache will not solve other project's objections to using log4j (or any
other Apache project) as I assume we are not planning to move log4j outside
of the ASF. Quite frankly, I don't have a lot of sympathy for other
pro
Dario,
Thank you for your contribution.
DOMConfigurator is being deprecated in the 1.3 release in favor of a new xml
based configurator named JoranConfigurator. So, I don't think we will be
applying anymore changes to it going forward.
Also, the watchdog mechanism is being expanded and implemen
We started talking about this a while back, but the thread died after some
initial input on the work to be accomplished. So, I am bringing it up
again. From the previous discussion, we had the following items (please
speak up if I have forgotten anything). I have put names next to items
(items t
Hey Curt,
We can put the issues into Bugzilla after we have hashed through it some
here on the list. That being said, another item to add:
- Other:
- Review and resolve open bugs
-Mark
> -Original Message-
> From: Curt Arnold [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 26, 2005 4
Yeah, this is it. Thanks, Paul.
-Mark
> -Original Message-
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 26, 2005 5:13 PM
> To: Log4J Developers List
> Subject: Re: next log4j release?
>
>
> >Documentation Related:
> > - Better documentation (Ceki, et al)
> > - AP
Not sure what you are asking for here. You want the configurator to somehow
call you back or provide information on appenders it creates as part of the
configure call? Or you just want to enumerate all of the appenders used in
a repository?
-Mark
> -Original Message-
> From: Sumit Kumar
OK, so I would have voted for the release, but isn't there a process we are
supposed to follow here? Something about the sub-project voting and the PMC
approving, etc. ?
-Mark
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 29, 2005 11:29 AM
> To:
e was
no burning reason to release it immediately, bypassing the entire thing,
whether you thought it was controversial or not.
I appreciate the work, but this concerns me.
-Mark
> -Original Message-
> From: Mark Womack [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 29, 2005
-1
The process was not followed either at the log4j project level or the LS PMC
level. That alone is reason to pull/cancel this release.
Beyond that, I think that a review of the slf4j support is very relevant and
should have been discussed and reviewed prior to being accepted and
released.
-
This is a spinoff of the discussion regarding slf4j and log4j. I reviewed
Curt's email on the 1.2 branch changes, and I am building on some of his
comments.
I am not a member of the slf4j team, so I cannot speak to it's goals, etc.
As a log4j committer I have no opposition to it being directly
Starting a thread specific to the licensing issue.
Echoing Curt's concerns related to the 1.2.10 release, I told Ceki privately
that we (LS PMC) would need to understand the licensing issues around slf4j
as part of any approval of any release that included it, and it would need
to be explained/p
> -Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 30, 2005 7:41 PM
> To: Log4J Developers List
> Subject: Re: slf4j and log4j
...
> >
> > 2) There is demonstrated consensus from the slf4j organization. I want
> some
> > understanding that their
continued attitudes towards your own fellow
> developers (e.g. that line above), not to mention denying user feedback
> time after time (trace, for gods sake), someone probably will do that with
> log4j itself RSN.
>
> Or someone already have?
>
> http://home.comcast.net/~pdegre
continued attitudes towards your own fellow
> developers (e.g. that line above), not to mention denying user feedback
> time after time (trace, for gods sake), someone probably will do that with
> log4j itself RSN.
>
> Or someone already have?
>
> http://home.comcast.net/~pdegre
f anyone has some feature that they
> believe merits reopening the 1.2 line, they should start a new thread.
>
> On May 3, 2005, at 12:07 PM, Mark Womack wrote:
>
> > Endre,
> >
> > So, besides the trace level being put into the 1.2 branch, what other
> > f
Actually, you beat me to this, but I have a slight alteration to your
proposal:
Current 1.2 branch is tagged/moved to a new branch called 1_2_slf4j and will
be available for modification and "experimental" slf4j builds. The "head"
of the 1.2 branch is reverted to the previous v1.2.9 state. At
gt; Subject: Re: [VOTE] Tag the CVS for 1.2.10 and revert the slf4j related
> changes on 1.2 branch
>
>
> On May 4, 2005, at 9:03 AM, Mark Womack wrote:
>
> > Actually, you beat me to this, but I have a slight alteration to your
> > proposal:
> >
> > Cur
Ceki,
Are you saying that there is no longer any interest to support slf4j in
log4j? I don't speak for you, but I know I am still interested in it. It
sounds like others are as well. Depending on the timeframes for slf4j and
the (currently numbered) v1.3 version of log4j, releasing something on
ustified, honest, disguised or otherwise. In short,
> it is practically impossible for a rejected proposal to get
> subsequently accepted. In any case, I won't be presenting a
> proposal. Now if a heroic soul wishes to try, I wish them all the luck
> in the world.
>
> At
t
> Subject: RE: [VOTE] Tag the CVS for 1.2.10 and revert the slf4j related
> changes on 1.2 branch
>
>
> Mark, I never the questioned the legitimacy of the recall, have I? My
> point
> is that a veto is like an ICBM, once fired you can't take it back, at
> least
>
ut of time for tonight.
-Mark
- Original Message -
From: "Curt Arnold" <[EMAIL PROTECTED]>
To: "Log4J Developers List"
Sent: Wednesday, May 04, 2005 9:28 AM
Subject: Re: [VOTE] Tag the CVS for 1.2.10 and revert the slf4j related
changes on 1.2 branch
On May 4,
I don't entirely agree with you on this. If the goal of the slf4j
implementation is to provide a version that is compatible with all/most
versions of log4j 1.2.x, then a façade implementation is really the only way
to go. And this would provide slf4j with the widest base of possible users,
true.
Glen,
Thanks for the interest and email. Contributions to the contribs directory
can be very straight forward since it does not really require any changes in
the core code. Just submit the source files with the Apache license
embedded at the top (you have to have permission to contribute them un
Yes, the current cvs head is the current 1.3. 1.2 is on its own branch.
-Mark
> -Original Message-
> From: Glen [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 06, 2005 6:34 AM
> To: Log4J Developers List
> Subject: is HEAD the 1.3 branch
>
> Looking to checkout the 1.3 code base. Where
- Original Message -
From: "Lars Eilebrecht" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 08, 2005 5:03 PM
Subject: Information about ApacheCon for ASF Committers
Hi,
below are information about attending ApacheCon Europe
and the Hackathon event.
Attending the conference
OK, this is my opinion here. I want to hear what the other committers have
to say on this topic.
I want to get v1.3 out. I want us to finish what we have started,
consolidate it, test it, and release it. I want it to be released before
the end of the year, preferably more in the Sep/Oct timefra
This is going to sound similar my opinion about the 1.3/2.0 relabeling.
I think we should at least do a 1.2.11 release to pick up Andy McBride's jms
fix. I think we should consider some other *simple*, needed fixes. As much
as it is wanted, I am not sure we should include the TRACE change, mainl
- Original Message -
From: "Paul Smith" <[EMAIL PROTECTED]>
To: "Log4J Developers List"
Sent: Tuesday, May 10, 2005 1:58 PM
Subject: Re: Relabeling log4j 1.3 as 2.0
+1 I am in favour of us putting a line in the sand for 1.3. No more new
features (features we've been talking about doin
1 - 100 of 336 matches
Mail list logo
