You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ceki Gülcü <li...@qos.ch> on 2005/10/05 16:12:48 UTC
Re: upgrading to nlog4j.1.2.17
Hello Nick,
Are you aware of IDEA's (version 5.0) ability to export jar files from
a module (IDEA->Settings->Modules->Order/Export)? For example, if
module X depends on jar file a.jar, it can export a.jar so that module
Y which depends on X can also access a.jar.
Thus, my first suggestion would be to remove the expanded (or
exploded) versions of nlog4j and slf4j from ApacheDS module. When
that's done, try exporting/not exporting nlog4j from the ApacheDS
module.
At 05:39 AM 9/14/2005, Nick Faiz wrote:
> When I run a main method in module1 (which doesn't use ApacheDS) all
> log statements in modules 1, 2 and 3 work quite well. When it finally
> reaches a logging statement in module4, which *does* use ApacheDS, I
> see a NoSuchMethodError:
I could not find documentation about what IDEA does when multiple
modules declare the same dependency. However, given the above, and
given that module4 which depends on ApacheDS, assuming if ApacheDS
exported nlog4j, module4 would no longer need to declare log4j as a
dependency. One could then speculate that the NoSuchMethodError would
no longer occur.
Does that make sense? Even better, does it work?
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Re: upgrading to nlog4j.1.2.17
Posted by Stephane Bailliez <sb...@apache.org>.
Nick Faiz wrote:
> To be brutally honest, I think we have spent too much time on logging
> and have been unproductive by second guessing what might be required
> of it. We've gone to quite a bit of effort to make SLF4J work, and
> we've received negative yield, as far as moving ahead in DS is concerned.
> [...]
>
> We lost the idea of KISS long ago. I'd advocate returning to it, while
> we're back at square one again - use log4j. If we need to fit logging
> into other frameworks we can wire loggers up to factories then.
+1
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@atlassian.com>.
Hi Ceki,
Appreciated. I'm glad that our effort has benefited SLF4J.
Cheers,
Nick
Ceki Gülcü wrote:
>
>
> At 07:58 AM 10/11/2005, Nick Faiz wrote:
>
>> Hi Niclas,
>>
>> To be brutally honest, I think we have spent too much time on logging
>> and have been unproductive by second guessing what might be required
>> of it. We've gone to quite a bit of effort to make SLF4J work, and
>> we've received negative yield, as far as moving ahead in DS is
>> concerned.
>
>
> Nick,
>
> I sympathize with the sentiment. Regardless of what your future
> choices, I would like to thank you for the effort you put in ironing
> our the wrinkles in SLF4J. It was a pleasant experience to work
> with you.
>
>
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
At 07:58 AM 10/11/2005, Nick Faiz wrote:
>Hi Niclas,
>
>To be brutally honest, I think we have spent too much time on logging and
>have been unproductive by second guessing what might be required of it.
>We've gone to quite a bit of effort to make SLF4J work, and we've received
>negative yield, as far as moving ahead in DS is concerned.
Nick,
I sympathize with the sentiment. Regardless of what your future
choices, I would like to thank you for the effort you put in ironing
our the wrinkles in SLF4J. It was a pleasant experience to work
with you.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Re: upgrading to nlog4j.1.2.17
Posted by Maarten Bosteels <mb...@wout-bosteels.be>.
Trustin Lee wrote:
> It would be really great if the ASF members and committers come to a
> mutual agreement on which logging framework we will use.
+1
Re: upgrading to nlog4j.1.2.17
Posted by Niclas Hedhman <ni...@apache.org>.
On Thursday 13 October 2005 00:27, Trustin Lee wrote:
> I was talking about the original monitor pattern which is different from
> yours. It abstracts all log messages into individual hook methods.
Ok, perhaps we read material differently. To the letter, you right of course,
but I see a subtle underlying message;
* Don't "depend" in your code.
* Isolate your dependencies (you still need them) to as few locations
as possible, and you will gain immensely architecturally.
I think that message is much more important than the details about the
monitors that is used. Monitors as described will explode the number of
needed classes, and becomes un-manageable in no time (as I think this project
is aware of).
> if we're going to use dynamic discovery mechanism to find an
> appropriate logging framework.
Point is; don't.
For standalone use, you can set it in advance. You may give your users a
couple of choice, then introduce a simple selector mechanism, all prewired
and ready to go.
For embedded use, put in the setProvider() method in the OurLogFactory which
then instead delegate the creation to a factory instance that the embeddor
provides.
Cheers
Niclas
Re: upgrading to nlog4j.1.2.17
Posted by Trustin Lee <tr...@gmail.com>.
Hi Niclas,
I was talking about the original monitor pattern which is different from
yours. It abstracts all log messages into individual hook methods. For
example:
public MyComplexMonitor {
public void somethingComplexHappened(ComplexStuff stuff) {
log.warn("something complex happened: " + stuff);
}
public void somethingComplexResolved(ComplexStuff stuff) {
log.info("something complex has been resolved: " + stuff);
}
}
You'll have to add a method whenever you have to log something additionally.
What you have done is similar to what MX4J guys have done. It works great,
but we'll have to provide some way for user to specify his or her preferred
logging framework and... it's commons-logging do. It's just like forking
commons-logging into org.apache.ldap.server.logging package unfortunately if
we're going to use dynamic discovery mechanism to find an appropriate
logging framework.
Trustin
2005/10/12, Niclas Hedhman <ni...@hedhman.org>:
>
> If you take it at face value, and don't adopt it to your need, then I
> agree
> that it is over-engineered and an explosion of classes will result.
>
> However, there is a principle in there, which I find good. That you should
> isolate your dependencies to a single point if possible. And in case of
> logging, that is so simple to do.
>
>
> public interface OurLogger
> {
> // Add methods you need.
> boolean isDebugEnabled();
> void debug( String message );
> void info( String message );
> void warn( String message, Throwable t );
> void error( String message, Throwable t );
> }
>
> public class OurLoggerBridgeToLog4J
> {
> private Logger m_logger;
>
> public OurLoggerBridgeToLog4J( Class cls )
> {
> m_logger = Logger.getLogger( cls );
> }
>
> public boolean isDebugEnabled()
> {
> return m_logger.isDebugEnabled();
> }
>
> public void debug( String message )
> {
> m_logger.debug( message );
> }
>
> public void info( String message )
> {
> m_logger.info( message );
> }
>
> public void warn( String message, Throwable t )
> {
> m_logger.warn( message, t );
> }
>
> public void error( String message, Throwable t )
> {
> m_logger.error( message, t );
> }
> }
>
> public class OurLoggerFactory
> {
> public OurLogger getLogger( Class cls )
> {
> // introduce some selector if needed.
> return new OurLoggerBridgeToLog4J( cls );
> }
> }
>
> Ok, that took ~10 minutes.
> To be more embeddor friendly, introduce a delegation mechanism in the
> OurLoggerFactory. Ok, that will take another 10mins.
>
>
> Considering the reduction of depending on external stuff to a single point
> (one class + a factory), the amount of effort required is neglectable.
>
> THAT is what I kept from Hammant's insight. And I am a bit surprised that
> more
> people doesn't see the beauty of this ;o)
>
>
> Cheers
> Niclas
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: upgrading to nlog4j.1.2.17
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 October 2005 08:24, Trustin Lee wrote:
> This monitor pattern is overengineering IMHO. Why should I add extra
> methods whenever I write debug log messages and provide a bridge for known
> logging frameworks? And we can say using monitors is implementing AOP
> almost by hand.
If you take it at face value, and don't adopt it to your need, then I agree
that it is over-engineered and an explosion of classes will result.
However, there is a principle in there, which I find good. That you should
isolate your dependencies to a single point if possible. And in case of
logging, that is so simple to do.
public interface OurLogger
{
// Add methods you need.
boolean isDebugEnabled();
void debug( String message );
void info( String message );
void warn( String message, Throwable t );
void error( String message, Throwable t );
}
public class OurLoggerBridgeToLog4J
{
private Logger m_logger;
public OurLoggerBridgeToLog4J( Class cls )
{
m_logger = Logger.getLogger( cls );
}
public boolean isDebugEnabled()
{
return m_logger.isDebugEnabled();
}
public void debug( String message )
{
m_logger.debug( message );
}
public void info( String message )
{
m_logger.info( message );
}
public void warn( String message, Throwable t )
{
m_logger.warn( message, t );
}
public void error( String message, Throwable t )
{
m_logger.error( message, t );
}
}
public class OurLoggerFactory
{
public OurLogger getLogger( Class cls )
{
// introduce some selector if needed.
return new OurLoggerBridgeToLog4J( cls );
}
}
Ok, that took ~10 minutes.
To be more embeddor friendly, introduce a delegation mechanism in the
OurLoggerFactory. Ok, that will take another 10mins.
Considering the reduction of depending on external stuff to a single point
(one class + a factory), the amount of effort required is neglectable.
THAT is what I kept from Hammant's insight. And I am a bit surprised that more
people doesn't see the beauty of this ;o)
Cheers
Niclas
Re: upgrading to nlog4j.1.2.17
Posted by Maarten <mi...@wout-bosteels.be>.
Trustin Lee wrote:
> It would be really great if the ASF members and committers come to a
> mutual agreement on which logging framework we will use.
+1
Re: upgrading to nlog4j.1.2.17
Posted by Trustin Lee <tr...@gmail.com>.
2005/10/12, Noel J. Bergman <no...@devtech.com>:
>
> Niclas Hedhman wrote:
>
> > Once you understand Paul Hammant's argument of "No Logging",
> > things get very clear indeed.
This monitor pattern is overengineering IMHO. Why should I add extra methods
whenever I write debug log messages and provide a bridge for known logging
frameworks? And we can say using monitors is implementing AOP almost by
hand.
However, as Paul says: "the main point is the proper way to abstract logging
> type and destination is to hide all logging implementation behind an
> interface." I agree. And at this point, since we have a standard, perhaps
> it is time to follow Tomcat's lead: ditch all other logging APIs, and use
> the standard. If the standard needs change, that can happen via the JCP.
> Log4J and others would still have their place as implementations of the
> standard, but as APIs they would go away.
Standard is good, but is java.util.logging de-facto standard really? There
are a lot of projects that use other logging frameworks, and that's why
projects like MX4J provides their own layer of logging which is not that
pretty. Commons-logging was a nice try, but ppl doesn't seem to like it due
to its hard traceability though I think it is OK because we know what
problem is.
It would be really great if the ASF members and committers come to a mutual
agreement on which logging framework we will use.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: upgrading to nlog4j.1.2.17
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
>On Tue, 2005-10-11 at 11:59 -0400, Noel J. Bergman wrote:
><snip/>
>
>
>>And at this point, since we have a standard, perhaps
>>it is time to follow Tomcat's lead: ditch all other logging APIs, and use
>>the standard. If the standard needs change, that can happen via the JCP.
>>Log4J and others would still have their place as implementations of the
>>standard, but as APIs they would go away.
>>
>>
...
>Right now, I'm sure that Alex will give us some clue about how to embed
>ApacheDS in another application, including the way the logging system
>should be used, as he will have a session at San Diego ApacheCon US 2005
>(http://apachecon.com/2005/US/html/sessions.html#1510) (Yeah !)
>
>
Oh boy you're putting me on the spot now :).
Ok I have to reread this thread a few more times. There must be an easy
simple option out there between all the opinions expressed. We just
have to weigh all the options.
Alex
Re: upgrading to nlog4j.1.2.17
Posted by Emmanuel Lecharny <el...@apache.org>.
On Wed, 2005-10-12 at 07:40 +1000, Nick Faiz wrote:
> Hi Emmanuel,
>
>
> On 12/10/2005, at 5:09 AM, Emmanuel Lecharny wrote:
>
>
> > As far as ApacheDS is concerned, and it seems to be, there is no
> > urge to
> > change a choice made back in July, 6.
> >
>
> How is there no urge to make ApacheDS embeddable? We currently cannot
> embed ApacheDS in applications using log4j.
Sorry, but I think that the urgence is to make ApacheDS usable and
stable ... Embeddable is number 3 in the list for 1.0 GA.
That means fixing bugs and adding lacking fonctions. This is what we are
actually working at.
Of course, I just express my very own opinion :)
-- Emmanuel
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@gmail.com>.
Hi Emmanuel,
On 12/10/2005, at 5:09 AM, Emmanuel Lecharny wrote:
> As far as ApacheDS is concerned, and it seems to be, there is no
> urge to
> change a choice made back in July, 6.
>
How is there no urge to make ApacheDS embeddable? We currently cannot
embed ApacheDS in applications using log4j.
> We have a 1.0 version to deliver,
> and we can still change things between the 1.0-beta and 1.0 GA.
>
>
Yes, definitely. :) Which is why we should stop equivocating over
this or that logging framework and just choose one which has a
history of working.
Cheers,
Nick
> Right now, I'm sure that Alex will give us some clue about how to
> embed
> ApacheDS in another application, including the way the logging system
> should be used, as he will have a session at San Diego ApacheCon US
> 2005
> (http://apachecon.com/2005/US/html/sessions.html#1510) (Yeah !)
>
> PS : Ceki, Log4j still rocks ! I personally never met a project using
> Java SDK logging... Darwin again ?
>
> -- Emmanuel
>
>
>
>
>
Re: upgrading to nlog4j.1.2.17
Posted by Alex Karasulu <ao...@bellsouth.net>.
Nick Faiz wrote:
> Ceki,
>
> Thanks for the rapid appearance of the slf4j-log4j binding.
Yah thanks again Ceki.
Alex
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@atlassian.com>.
Ceki,
Thanks for the rapid appearance of the slf4j-log4j binding. I'll
check it out first thing tomorrow.
Cheers,
Nick
On 20/10/2005, at 12:37 AM, Ceki Gülcü wrote:
>
> Forgot to mention that maven/ibilio should be updated shortly.
>
> http://jira.codehaus.org/browse/MAVENUPLOAD-553
>
> At 04:28 PM 10/19/2005, you wrote:
>
>
>
>> Hello all,
>>
>> SLF4J 1.0beta8 has been just released. It ships with the slf4j-
>> log4j binding
>> we talked about.
>>
>>
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
> Improve your Sudoku skills at http://www.sudoku-grok.com/
>
>
>
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
Forgot to mention that maven/ibilio should be updated shortly.
http://jira.codehaus.org/browse/MAVENUPLOAD-553
At 04:28 PM 10/19/2005, you wrote:
>Hello all,
>
>SLF4J 1.0beta8 has been just released. It ships with the slf4j-log4j binding
>we talked about.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Improve your Sudoku skills at http://www.sudoku-grok.com/
Re: upgrading to nlog4j.1.2.17
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
> 2005/10/20, Alex Karasulu <aok123@bellsouth.net
> <ma...@bellsouth.net>>:
>
> Hmmm I guess this is because of the Spring's dep on Log4J right? Then
> let's use Log4J with SLF4J across the board just to be
> consistent. WDYT?
>
>
> Spring uses Commons-Logging AFAIK. Later we will have to completely
> remove Spring dependency and provide ApacheDS-centric configuration
> schema. When we get rid of Spring, we can simply use nlog4j.
Amen to that!
Alex
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@atlassian.com>.
Ceki,
I've just passed a preliminary test with slf4j-log4j12.jar. It's great
to have logging working again.
My test was performed in the IDEA environment we discussed a while ago.
The are four project modules, one of which holds ApacheDS, using
slf4j-log4j12.jar for my config., the others which use log4j.
As a side note, I've just had a chat with Alex about logging in
ApacheDS. I'll send through an email soon with ideas about when to
package a slf4j implementation and which one it should be.
Cheers,
Nick
Ceki Gülcü wrote:
>
> SLF4J version 1.0beta9 was released just a few moments ago.
>
> Due to binary incompatibility between log4j 1.2 and log4j 1.3, the
> new SLF4J distribution includes two distinct bindings for log4j,
> namely, slf4j-log4j12.jar and slf4j-log4j13.jar. This distinction is
> necessary because log4j 1.2 and 1.3 are not run-time
> compatible, although they are mostly compile-time compatible.
>
> See also http://slf4j.org/faq.html#2.6
>
> Needless to say, regardless of what binding of SLF4J you compile
> against, all SLF4J bindings are all interchangeable.
>
>
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
SLF4J version 1.0beta9 was released just a few moments ago.
Due to binary incompatibility between log4j 1.2 and log4j 1.3, the
new SLF4J distribution includes two distinct bindings for log4j,
namely, slf4j-log4j12.jar and slf4j-log4j13.jar. This distinction is
necessary because log4j 1.2 and 1.3 are not run-time
compatible, although they are mostly compile-time compatible.
See also http://slf4j.org/faq.html#2.6
Needless to say, regardless of what binding of SLF4J you compile
against, all SLF4J bindings are all interchangeable.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Improve your Sudoku skills at http://www.sudoku-grok.com/
Re: upgrading to nlog4j.1.2.17
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ceki Gülcü wrote:
> At 06:05 PM 10/19/2005, you wrote:
>
>> 2005/10/20, Alex Karasulu
>> <<m...@bellsouth.net>:
>>
>>> Hmmm I guess this is because of the Spring's dep on Log4J right? Then
>>> let's use Log4J with SLF4J across the board just to be consistent.
>>> WDYT?
>>
>>
>> Spring uses Commons-Logging AFAIK. Later we will have to completely
>> remove Spring dependency and provide ApacheDS-centric configuration
>> schema. When we get rid of Spring, we can simply use nlog4j.
>
>
> Are you aware of jcl104-over-slf4j.jar ?
>
Oh I was not aware. Good to know glad you posted this.
> http://slf4j.org/manual.html#gradual
>
> In other words, you can still use library X, e.g. Spring, which
> depends on JCL. However, if you replace commons-logging.jar with
> jcl104-over-slf4j.jar, then the selection of the underlying logging
> system will be done by SLF4J without the class loader headaches. The
> underlying logging system can be any of NOP, simple, jdk14 logging,
> log4j or NLOG4J. Spring's commons-logging dependency becomes a moot
> issue.
>
That's great.
> I hope this is relevant to the discussion. Is it, by the way?
>
Yes I think so. Glad you chimed in with this additional info.
Thanks,
Alex
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
At 06:05 PM 10/19/2005, you wrote:
>2005/10/20, Alex Karasulu <<m...@bellsouth.net>:
>>Hmmm I guess this is because of the Spring's dep on Log4J right? Then
>>let's use Log4J with SLF4J across the board just to be consistent. WDYT?
>
>Spring uses Commons-Logging AFAIK. Later we will have to completely
>remove Spring dependency and provide ApacheDS-centric configuration
>schema. When we get rid of Spring, we can simply use nlog4j.
Are you aware of jcl104-over-slf4j.jar ?
http://slf4j.org/manual.html#gradual
In other words, you can still use library X, e.g. Spring, which
depends on JCL. However, if you replace commons-logging.jar with
jcl104-over-slf4j.jar, then the selection of the underlying logging
system will be done by SLF4J without the class loader headaches. The
underlying logging system can be any of NOP, simple, jdk14 logging,
log4j or NLOG4J. Spring's commons-logging dependency becomes a moot
issue.
I hope this is relevant to the discussion. Is it, by the way?
>Trustin
>--
>what we call human nature is actually human habit
>--
><http://gleamynode.net/>http://gleamynode.net/
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Improve your Sudoku skills at http://www.sudoku-grok.com/
Re: upgrading to nlog4j.1.2.17
Posted by Trustin Lee <tr...@gmail.com>.
2005/10/20, Alex Karasulu <ao...@bellsouth.net>:
>
> Hmmm I guess this is because of the Spring's dep on Log4J right? Then
> let's use Log4J with SLF4J across the board just to be consistent. WDYT?
Spring uses Commons-Logging AFAIK. Later we will have to completely remove
Spring dependency and provide ApacheDS-centric configuration schema. When we
get rid of Spring, we can simply use nlog4j.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: upgrading to nlog4j.1.2.17
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
> 2005/10/20, Alex Karasulu <aok123@bellsouth.net
> <ma...@bellsouth.net>>:
>
> Trustin Lee wrote:
>
> > Hi Ceki,
> >
> > 2005/10/19, Ceki Gülcü <listid@qos.ch <ma...@qos.ch>
> <mailto:listid@qos.ch <ma...@qos.ch>>>:
> >
> > SLF4J 1.0beta8 has been just released. It ships with the
> > slf4j-log4j binding
> > we talked about.
> >
> >
> > Great to hear this. Is there any Maven repository that I can
> access?
> >
> > Alex, it would be nice if we change our default logger to LOG4J
> (I'm
> > not talking about changing SLF4J itself as you expected.)
>
> You mean use the SLF4J Log4J binding?
>
>
> Yes, in ApacheDS main. For standalone version we could use NLog4J.
> We could simply use slf4j-simple for subprojects for simplicity.
Hmmm I guess this is because of the Spring's dep on Log4J right? Then
let's use Log4J with SLF4J across the board just to be consistent. WDYT?
Alex
Re: upgrading to nlog4j.1.2.17
Posted by Trustin Lee <tr...@gmail.com>.
2005/10/20, Alex Karasulu <ao...@bellsouth.net>:
>
> Trustin Lee wrote:
>
> > Hi Ceki,
> >
> > 2005/10/19, Ceki Gülcü <listid@qos.ch <ma...@qos.ch>>:
> >
> > SLF4J 1.0beta8 has been just released. It ships with the
> > slf4j-log4j binding
> > we talked about.
> >
> >
> > Great to hear this. Is there any Maven repository that I can access?
> >
> > Alex, it would be nice if we change our default logger to LOG4J (I'm
> > not talking about changing SLF4J itself as you expected.)
>
> You mean use the SLF4J Log4J binding?
Yes, in ApacheDS main. For standalone version we could use NLog4J. We could
simply use slf4j-simple for subprojects for simplicity.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: upgrading to nlog4j.1.2.17
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
> Hi Ceki,
>
> 2005/10/19, Ceki Gülcü <listid@qos.ch <ma...@qos.ch>>:
>
> SLF4J 1.0beta8 has been just released. It ships with the
> slf4j-log4j binding
> we talked about.
>
>
> Great to hear this. Is there any Maven repository that I can access?
>
> Alex, it would be nice if we change our default logger to LOG4J (I'm
> not talking about changing SLF4J itself as you expected.)
You mean use the SLF4J Log4J binding?
Alex
Re: upgrading to nlog4j.1.2.17
Posted by Trustin Lee <tr...@gmail.com>.
Hi Ceki,
2005/10/19, Ceki Gülcü <li...@qos.ch>:
>
> SLF4J 1.0beta8 has been just released. It ships with the slf4j-log4j
> binding
> we talked about.
Great to hear this. Is there any Maven repository that I can access?
Alex, it would be nice if we change our default logger to LOG4J (I'm not
talking about changing SLF4J itself as you expected.)
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
Hello all,
SLF4J 1.0beta8 has been just released. It ships with the slf4j-log4j binding
we talked about.
At 07:10 PM 10/13/2005, Alex Karasulu wrote:
>Ceki Gülcü wrote:
>
>>You can expect such a binding to be available on October 21st, but
>>probably before that.
>Perfect! Thanks Ceki and Nick for persevering on this issue.
>
>Alex
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Improve your Sudoku skills at http://www.sudoku-grok.com/
Re: upgrading to nlog4j.1.2.17
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ceki Gülcü wrote:
> A vanilla log4j binding for SLF4J could alleviate nlog4j/log4j
> compatibility problems that we suspect may arise. The vanilla log4j
> binding with SLF4J would be similar to the JDK 1.4 binding that
> currently exists. It would require an official version of log4j.jar
> (as distributed by http://logging.apache.org) to be present on the
> class path.
>
> You can expect such a binding to be available on October 21st, but
> probably before that.
>
> How does that sound?
>
Perfect! Thanks Ceki and Nick for persevering on this issue.
Alex
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
A vanilla log4j binding for SLF4J could alleviate nlog4j/log4j
compatibility problems that we suspect may arise. The vanilla log4j
binding with SLF4J would be similar to the JDK 1.4 binding that
currently exists. It would require an official version of log4j.jar
(as distributed by http://logging.apache.org) to be present on the
class path.
You can expect such a binding to be available on October 21st, but
probably before that.
How does that sound?
At 11:03 PM 10/12/2005, Emmanuel Lecharny wrote:
>Hi Jerome,
>
><snip/>
> > If you go for SLF4J, wouldn't that resolve your problem.
>
>We already are using slf4j since july, 6...
>
>But it seems that it's not enough, as some end-users want to use log4j
>without swapping their log4j.jar for a nlog4j.jar library.
>
>Ceki Gülcü is actually thinking of a way to deal with this issue.
>
>-- Emmanuel
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Re: upgrading to nlog4j.1.2.17
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi Jérôme,
<snip/>
> If you go for SLF4J, wouldn't that resolve your problem.
We already are using slf4j since july, 6...
But it seems that it's not enough, as some end-users want to use log4j
without swapping their log4j.jar for a nlog4j.jar library.
Ceki Güclü is actually thinking of a way to deal with this issue.
-- Emmanuel
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@gmail.com>.
Jerome,
Yes, in standalone mode it isn't an issue.
For embedded, you could switch your underlying implementation if
needed. It would, however, be against the very purpose of the SLF4J
facade to adopt a secondary logging frameworking by switching to a
slf4j alternative logger because your logging library of choice was
log4j!
Also, it introduces some policing to ensure that nlog4j and log4j are
not on the same classpath. It's another factor which could be gotten
wrong.
As Emmanuel said in reply to your email, Ceki is thinking on this
right now.
Cheers,
Nick
On 13/10/2005, at 5:34 AM, Jérôme Baumgarten wrote:
> Hi guys,
>
> On 10/12/05, Nick Faiz <ni...@atlassian.com> wrote:
>
>
> <snip />
>
> Okay. I understand that it might seem like a noisy chat about SLF4J,
> not ApacheDS.
>
> My motive is simple. I am only concerned about logging for ApacheDS.
> It has become an ApacheDS issue.
>
> > - third, I think that Ceki did a lot of good job, he also really
> > helped
> > us, and I don't want him to think that we think that log4j is a
> > pile of
> > bok...
> >
>
> Agreed.
>
>
> Cheers,
> Nick
>
>
>
> If you go for SLF4J, wouldn't that resolve your problem. For
> running in a standalone more, you then can choose whatever SLF4J
> version you want, the one using Simple-Log or nlog4j. Using
> ApacheDS embedded in another application, you can also choose the
> most appropriate SLF4J version. If you may get into troubles
> because of log4j then you go for the Simple-Log based SLF4J. This
> could easily be resolved by externalizing the logging jar.
>
> Jérôme
Re: upgrading to nlog4j.1.2.17
Posted by Jérôme Baumgarten <jb...@gmail.com>.
Hi guys,
On 10/12/05, Nick Faiz <ni...@atlassian.com> wrote:
>
>
>
<snip />
Okay. I understand that it might seem like a noisy chat about SLF4J,
> not ApacheDS.
>
> My motive is simple. I am only concerned about logging for ApacheDS.
> It has become an ApacheDS issue.
>
> > - third, I think that Ceki did a lot of good job, he also really
> > helped
> > us, and I don't want him to think that we think that log4j is a
> > pile of
> > bok...
> >
>
> Agreed.
>
>
> Cheers,
> Nick
If you go for SLF4J, wouldn't that resolve your problem. For running in a
standalone more, you then can choose whatever SLF4J version you want, the
one using Simple-Log or nlog4j. Using ApacheDS embedded in another
application, you can also choose the most appropriate SLF4J version. If you
may get into troubles because of log4j then you go for the Simple-Log based
SLF4J. This could easily be resolved by externalizing the logging jar.
Jérôme
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@atlassian.com>.
Hey Emmanuel,
On 12/10/2005, at 8:02 AM, Emmanuel Lecharny wrote:
>
> Yeah, I used it and still does, but I didn't browsed at the code. I
> didn't saw tomcat as something embeddable, too. I don't know either if
> Tomcat has issue with Logging jars, so I can't say if they have made
> this choice for any good reason, or not.
>
I actually saw a JIRA issue open at JBoss for adopting SLF4J a while
ago. :) I don't know if they did or not.
http://www.jboss.org/?module=bb&op=viewtopic&p=3889840 (after a quick
google).
> Guys, I just want to add three points :
> - first, excuse my english that forgives me to be as subtil and
> diplomatic as I would like to be,
No prob.s. :)
> - second, I really understand Nick point, and I really think it
> should
> be addressed, but I'm just not sure that it's the right pace to do it.
Okay. I understand that it might seem like a noisy chat about SLF4J,
not ApacheDS.
My motive is simple. I am only concerned about logging for ApacheDS.
It has become an ApacheDS issue.
> - third, I think that Ceki did a lot of good job, he also really
> helped
> us, and I don't want him to think that we think that log4j is a
> pile of
> bok...
>
Agreed.
Cheers,
Nick
> -- Emmanuel
>
>
RE: upgrading to nlog4j.1.2.17
Posted by "Noel J. Bergman" <no...@devtech.com>.
Emmanuel Lecharny wrote:
> I just want to add three points :
> - first, excuse my english
No worries. :-)
> second, I really understand Nick point, and I really think it should
> be addressed, but I'm just not sure that it's the right pace to do it.
As one of the projects that would like to embed it, I might have a different
priority, but that's a separate discussion, and far more involved.
> third, [I] I don't want him to think that we think that log4j
> is a pile of bok...
It isn't. But the discussion of which API should be used to access logging
is separable from that of how logging is implemented.
--- Noel
RE: upgrading to nlog4j.1.2.17
Posted by Emmanuel Lecharny <el...@apache.org>.
On Tue, 2005-10-11 at 17:46 -0400, Noel J. Bergman wrote:
<snip/>
> That isn't how I understood the aspect of the thread to which I was
> replying. If so the discussion is moot at this point.
Sorry, 'moot' is not in my dictionnary (basically, I'm french ;).
>
> > I personally never met a project using Java SDK logging.
>
> Ever use Tomcat 5? Not sure if JBoss is also switching or not.
Yeah, I used it and still does, but I didn't browsed at the code. I
didn't saw tomcat as something embeddable, too. I don't know either if
Tomcat has issue with Logging jars, so I can't say if they have made
this choice for any good reason, or not.
Guys, I just want to add three points :
- first, excuse my english that forgives me to be as subtil and
diplomatic as I would like to be,
- second, I really understand Nick point, and I really think it should
be addressed, but I'm just not sure that it's the right pace to do it.
- third, I think that Ceki did a lot of good job, he also really helped
us, and I don't want him to think that we think that log4j is a pile of
bok...
Back to debug session ...
-- Emmanuel
RE: upgrading to nlog4j.1.2.17
Posted by "Noel J. Bergman" <no...@devtech.com>.
Emmanuel Lecharny wrote:
> Noel J. Bergman wrote:
> > And at this point, since we have a standard, perhaps
> > it is time to follow Tomcat's lead: ditch all other
> > logging APIs, and use the standard.
> Not that this thread is boring, but I think that pros/cons of using
> slf4j/log4j/nlog4j/whatever4j could be posted to the best mailing list
> for that : log4XXX-dev or log4XXX-user mailing lists.
The issue is best discussed where it is used, not amongst the biased
developers of each API.
> As far as ApacheDS is concerned, and it seems to be, there is no urge to
> change a choice made back in July, 6.
That isn't how I understood the aspect of the thread to which I was
replying. If so the discussion is moot at this point.
> I personally never met a project using Java SDK logging.
Ever use Tomcat 5? Not sure if JBoss is also switching or not.
--- Noel
RE: upgrading to nlog4j.1.2.17
Posted by Emmanuel Lecharny <el...@apache.org>.
On Tue, 2005-10-11 at 11:59 -0400, Noel J. Bergman wrote:
<snip/>
> And at this point, since we have a standard, perhaps
> it is time to follow Tomcat's lead: ditch all other logging APIs, and use
> the standard. If the standard needs change, that can happen via the JCP.
> Log4J and others would still have their place as implementations of the
> standard, but as APIs they would go away.
Not that this thread is boring, but I think that pros/cons of using
slf4j/log4j/nlog4j/whatever4j could be posted to the best mailing list
for that : log4XXX-dev or log4XXX-user mailing lists.
As far as ApacheDS is concerned, and it seems to be, there is no urge to
change a choice made back in July, 6. We have a 1.0 version to deliver,
and we can still change things between the 1.0-beta and 1.0 GA.
Right now, I'm sure that Alex will give us some clue about how to embed
ApacheDS in another application, including the way the logging system
should be used, as he will have a session at San Diego ApacheCon US 2005
(http://apachecon.com/2005/US/html/sessions.html#1510) (Yeah !)
PS : Ceki, Log4j still rocks ! I personally never met a project using
Java SDK logging... Darwin again ?
-- Emmanuel
RE: upgrading to nlog4j.1.2.17
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> Once you understand Paul Hammant's argument of "No Logging",
> things get very clear indeed.
You refer to http://paulhammant.com/blog/000241.html. Nowhere in there does
it call for Log4J or any other logging interface. It basically works by
proliferating interfaces from the component author to the embedder.
Whenever I embed something with its own monitor interface, someone needs to
build the adapter between how it monitors and how I log. Lovely.
However, as Paul says: "the main point is the proper way to abstract logging
type and destination is to hide all logging implementation behind an
interface." I agree. And at this point, since we have a standard, perhaps
it is time to follow Tomcat's lead: ditch all other logging APIs, and use
the standard. If the standard needs change, that can happen via the JCP.
Log4J and others would still have their place as implementations of the
standard, but as APIs they would go away.
--- Noel
Re: upgrading to nlog4j.1.2.17
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 11 October 2005 14:13, Noel J. Bergman wrote:
> Or to depend on STANDARD APIs, since some library developers seems to have
> lost their way with respect to preserving absolute compatibility across
> versions.
Why "depend"??
Once you understand Paul Hammant's argument of "No Logging", things get very
clear indeed.
How long does it take for a project to define its own LoggerFactory and Logger
interface??
Discounting the argumentations, probably 30mins.
Add a provider for Log4J and JDK; 2 hours.
Everything else; 1000s of hours.
You want a new feature; Great, add it.
It is not compatible; Well, only affects this project, so who cares?
So, instead of;
import org.apache.log4j.Logger;
Logger logger = Logger.getLogger( Abc.class );
why not
import org.apache.directory.logging.LoggerFactory;
import org.apache.directory.logging.Logger;
Logger logger = LogFactory.getInstance().getLogger( Abc.class );
And you have a single place to swap in and out providers, and can easily
extend with mechanisms for embeddors to swap in whatever provider they want.
So, instead of having 400 classes depending on Log4J, JULI, UGLI, SLF4J or
what not, why not have ONE implementation class depend on either or all of
them, and everything else is an internal affair.
Cheers
Niclas
RE: upgrading to nlog4j.1.2.17
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> IMHO, it is getting more and more apparent that "libraries" and
> apps expected to get embedded to not depend on external logging
> frameworks in their code.
Or to depend on STANDARD APIs, since some library developers seems to have
lost their way with respect to preserving absolute compatibility across
versions.
The logging situation makes the case for something like JULI, and using the
JCP-defined logging interfaces that come standard in J2SE.
--- Noel
ref: http://svn.apache.org/repos/asf/tomcat/connectors/trunk/juli/
http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/package-sum
mary.html
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@atlassian.com>.
Hi Niclas,
Niclas Hedhman wrote:
IMHO, it is getting more and more apparent that "libraries" and apps expected
to get embedded to not depend on external logging frameworks in their code.
I totally agree.
To be brutally honest, I think we have spent too much time on logging
and have been unproductive by second guessing what might be required of
it. We've gone to quite a bit of effort to make SLF4J work, and we've
received negative yield, as far as moving ahead in DS is concerned.
We're back at square one, effectively. Square one, several months ago,
was where we made our original mistake:
Alex and I had a #directory-dev chat about introducing a proper logging
framework to ApacheDS. We decided to put in log4j. I made an initial
patch. The use of log4j was questioned. We opened a vote on which
logging framework to use. I initially voted for log4j. Some of us wanted
it, some of us didn't care, some of us argued for Commons Logging. Alex
ruled out Commons Logging, due its history of complexity. Someone
suggested SLF4J. I conceded on SLF4J, with the understanding that it was
compatible with Log4j. I made another patch ...
We lost the idea of KISS long ago. I'd advocate returning to it, while
we're back at square one again - use log4j. If we need to fit logging
into other frameworks we can wire loggers up to factories then.
Cheers,
Nick
>Instead, create an ApacheDS specific, LoggerFactory and Logger instance that
>is used throughout the Apache code. The LoggerFactory for standalone mode,
>can default to Log4J if you like to, but it should allow for embeddors to
>replace with their own provider.
>
>Think IoC :o)
>"If it is not provided to you, you can't use it."
>
>Cheers
>Niclas
>
>
Re: upgrading to nlog4j.1.2.17
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 10 October 2005 21:37, Nick Faiz wrote:
> Given the constraint that it is now an either/or scenario between
> log4j and nlog4j, if ApacheDS were to be embedded in an existing
> log4j application, the log4j jar would have to be removed
IMHO, it is getting more and more apparent that "libraries" and apps expected
to get embedded to not depend on external logging frameworks in their code.
Instead, create an ApacheDS specific, LoggerFactory and Logger instance that
is used throughout the Apache code. The LoggerFactory for standalone mode,
can default to Log4J if you like to, but it should allow for embeddors to
replace with their own provider.
Think IoC :o)
"If it is not provided to you, you can't use it."
Cheers
Niclas
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
Hi Nick,
At 12:31 AM 10/11/2005, Nick Faiz wrote:
>Hi Ceki,
>
>Are you sure that this conflict is unavoidable? It would be great if
>all of the methods present in the original log4j Logger could be
>represented in the nlog4j implementation (down to identical method
>arguments). It was my understanding that we were seeing this issue
>because some of the arguments had changed in nlog4j.
First, I think asking whether the conflict is unavoidable is exactly
the right questions to ask. So thank you for raising the question.
Unfortunately, I am unable to give a definitive answer. My kneejerk
reaction would be to say, it is unavoidable because I tend to believe
that in case multiple copies of xlog4j.jar lie on the class path the
conflicts are bound to arise independent of the changes between log4j
method signatures and nlog4j method signatures.
Let me give you an example. Assume log4j.jar and nlog4j.jar are both
on the class path. Further assume that somehow classes found in
log4j.jar are seen before those found in nlog4j.jar. For instance,
assume that the copy org.apache.log4j.Logger class found in log4j.jar
is found before the copy of o.a.l.Logger class found in nlog4j.jar.
In the current implementation of SLF4J which ships with nlog4j.jar,
the org.slf4j.LoggerFactory class is set to use the
org.apache.log4j.Logger class at compile time. However, the actual
loading of the org.apache.log4j.Loggger is made at runtime by the
JVM. If the copy of the o.a.l.Logger class found in log4j.jar has
precedence, then the Logger instances returned by
org.slf4j.LoggerFactory would be of the wrong type (without SLF4J
support) independently of the signature changes in nlog4j.
Returning to the problem reported by Thom, what does the stack trace
say?
Date: Thu, 29 Sep 2005 12:13:44 -0700
Subject:: Problem embedding 0.92 ApacheDS...
From: "Thom Park" <Th...@borland.com>
Exception in thread "main" java.lang.IncompatibleClassChangeError
at
org.apache.ldap.server.jndi.ServerContextFactory.startLdapProtocol(ServerContextFactory.java:222)
at
org.apache.ldap.server.jndi.ServerContextFactory.afterStartup(ServerContextFactory.java:108)
at
org.apache.ldap.server.jndi.DefaultContextFactoryService.startup(DefaultContextFactoryService.java:204)
at
org.apache.ldap.server.jndi.AbstractContextFactory.getInitialContext(AbstractContextFactory.java:99)
The failure occurs on line 222 of the
o.a.l.s.jndi.ServerContextFactory class class [1]. I would have
thought that problem would arise much sooner, for example when the
Logger instance was retrieved on line 62. Why doesn't line 62 throw a
ClassCastException since org.apache.log4j.Logger in log4j 1.2 does
not implement the org.slf4j.Logger interface?
Perhaps Thom is using log4j 1.3 as found in log4j CVS which indeed
implements the org.slf4j.Logger interface.
Another more plausible explanation, is that ApacheDS2 was compiled
against one version of nlog4j.jar and somehow Thom has another version
of nlog4j.jar on the classpath. Otherwise, it is not possible to
fail on line 222 but not on 62. Does anyone has a better explanation?
Thus, it seems to me that in Thom's case, the problem is not a
log4j/nlog4j incompatibility but an nlog4j/nlog4j
incompatibility. :-) However, without further information from Thom, it's
all conjecturing on my part..
[1-tiny] http://tinyurl.com/9pmlh
[1-original]
http://svn.apache.org/viewcvs.cgi/*checkout*/directory/apacheds/tags/release-0.9.2/main/src/main/java/org/apache/ldap/server/jndi/ServerContextFactory.java?rev=264732&content-type=text%2Fplain
>I think slf4j loses quite a bit of 'adoptability' by not being able
>to function alongside log4j.
I suggest that the problem be identified clearly before reaching a
definitive conclusion. Otherwise, I agree with the rest of your
comments.
>Cheers,
>Nick
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@gmail.com>.
Hi Ceki,
Are you sure that this conflict is unavoidable? It would be great if
all of the methods present in the original log4j Logger could be
represented in the nlog4j implementation (down to identical method
arguments). It was my understanding that we were seeing this issue
because some of the arguments had changed in nlog4j.
I think slf4j loses quite a bit of 'adoptability' by not being able
to function alongside log4j.
On 11/10/2005, at 12:59 AM, Ceki Gülcü wrote:
>
> As you say, NLOG4J requiring NLOG4J has been previously stated. As
> for the class path requirement, it's kind of an obvious and basic
> housekeeping chore. Isn't it *always* unsafe to have distinct versions
> of a library present on the class path?
>
>
Well, yes and no. While it is healthy, for many reasons, to prevent
duplication of classes on the classpath, it has never been a problem
to have two distinct versions of log4j on the classpath. At least,
I've never found it to be a problem. Now we have introduced mandatory
housekeeping. :) I know that quite a few administrators will just ask
people to use log4j, instead of SLF4J.
>
> I see why replacing one jar with another might be impossible under
> certain circumstances. It's an additional step that needs to be
> performed which one might consider as unnecessary hassle.
>
>
Well, there is now an issue of 'accessibility of adoption', or
something like that.
The classpath conflict is not so much an unnecessary hassle as a
prohibition. Some managers won't risk the smooth running of
enterprise applications just to upgrade a logging framework,
especially if the existing one is running well.
Without that upgrade, ApacheDS won't see the light of day, in
embedded use-cases, for such applications.
Cheers,
Nick
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
Hi Nick,
At 03:37 PM 10/10/2005, Nick Faiz wrote:
>Hi Ceki,
>
>Well, this is a troubling response.
Acknowledged.
>My main issue is that, up until now, the classpath conflict between
>nlog4j and log4j has not been stated. We have discussed the fact that
>nlog4j code requires nlog4j on the classpath but not the classpath
>conflict.
Yes, in my message dated "Tue, 13 Sep 2005 09:48:55 +0200", I wrote:
As of NLOG4J 1.2.16, code compiled against log4j.jar will run fine
with nlog4j.jar. However, the inverse is not true. Code compiled with
NLOG4J will only run with NLOG4J. This means that your code, when
compiled with NLOG4J, will depend on NLOG4J, which in my humble
opinion is a rather reasonable requirement, especially if you consider
that NLOG4J has SLF4J support which log4j does not have.
As you say, NLOG4J requiring NLOG4J has been previously stated. As
for the class path requirement, it's kind of an obvious and basic
housekeeping chore. Isn't it *always* unsafe to have distinct versions
of a library present on the class path?
>It is, however, only an API incompatibility, and I think
>that we can quite easily perform a refactor to roll back to log4j, if
>we need to.
>
>Given the constraint that it is now an either/or scenario between
>log4j and nlog4j, if ApacheDS were to be embedded in an existing
>log4j application, the log4j jar would have to be removed. I see this
>as an insurmountable problem, for many applications. I can understand
>why it is present, now that you have explained it, but I wish it
>would have been stated earlier.
To summarize: one cannot leave log4j.jar and nlog4j.jar simultaneously
on the class path.
I apologize if this has not been stated this explicitly before.
>On 10/10/2005, at 6:59 PM, Ceki Gülcü wrote:
>
>
>>The test suite also reproduces a well known compatibility problem.
>>Code compiled against nlog4j.jar will not run with log4j.jar on the
>>class path.
>
>This has never been stated before, I cannot see how it has been well
>known. Indeed, our latest emails have attempted to overcome this
>problem. See your reply on the 13th of September, (in attachment). If
>we had this information before, we would have had an immediate answer
>to our questions.
It was always clear to me that one could not have both jar
on the class path at the same time. In my mind, the previous set
of emails was about preventing log4j.jar from being "exported"
by modules.
>I cannot help but think you have only just now discovered that there
>is a classpath conflict. I am glad, all the same, that you have made
>the point. We can, at least, now make an informed decision (again)
>about which logging framework to use.
Absolutely.
>Well, most of this makes sense now. In light of the classpath
>conflict mentioned above, we could not possibly expect ApacheDS to be
>embedded with existing log4j applications without causing errors.
You could mention in the document that log4j.jar would need to
be replaced with nlog4j.jar.
>I, for one, am in favour of rolling back to log4j. I know that I
>won't have the option of removing log4j from certain applications
>which I would like to experiment with, using ApacheDS.
I see why replacing one jar with another might be impossible under
certain circumstances. It's an additional step that needs to be
performed which one might consider as unnecessary hassle.
>I'll discuss this further with the ApacheDS guys.
Sure, that's the right thing to do.
>Cheers,
>Nick
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@atlassian.com>.
Hi Ceki,
Well, this is a troubling response.
My main issue is that, up until now, the classpath conflict between
nlog4j and log4j has not been stated. We have discussed the fact that
nlog4j code requires nlog4j on the classpath but not the classpath
conflict. It is, however, only an API incompatibility, and I think
that we can quite easily perform a refactor to roll back to log4j, if
we need to.
Given the constraint that it is now an either/or scenario between
log4j and nlog4j, if ApacheDS were to be embedded in an existing
log4j application, the log4j jar would have to be removed. I see this
as an insurmountable problem, for many applications. I can understand
why it is present, now that you have explained it, but I wish it
would have been stated earlier.
On 10/10/2005, at 6:59 PM, Ceki Gülcü wrote:
> The test suite also reproduces a well known compatibility problem.
> Code compiled against nlog4j.jar will not run with log4j.jar on the
> class path.
>
>
>
This has never been stated before, I cannot see how it has been well
known. Indeed, our latest emails have attempted to overcome this
problem. See your reply on the 13th of September, (in attachment). If
we had this information before, we would have had an immediate answer
to our questions.
I cannot help but think you have only just now discovered that there
is a classpath conflict. I am glad, all the same, that you have made
the point. We can, at least, now make an informed decision (again)
about which logging framework to use.
> Regarding the message "Problem embedding 0.92 ApacheDS" posted by Thom
> Park, unless I am missing something obvious, it looks like that Thom
> is using log4j.jar instead of nlog4j.jar. We have already established
> that that won't work, for the simple reason that log4j does not offer
> SLF4J support.
>
>
Well, it won't work because of what is mentioned above.
>
> As a side note, Thom mentioned that he had followed the "instructions
> in the doc for embedding ApacheDS". Which doc is that? I could not
> find it, but admittedly I did not search for long.
>
>
>
I will have to follow up on this document.
> Nick, would you concur with the above assessment?
>
>
>
Well, most of this makes sense now. In light of the classpath
conflict mentioned above, we could not possibly expect ApacheDS to be
embedded with existing log4j applications without causing errors.
I, for one, am in favour of rolling back to log4j. I know that I
won't have the option of removing log4j from certain applications
which I would like to experiment with, using ApacheDS.
I'll discuss this further with the ApacheDS guys.
Cheers,
Nick
Re: upgrading to nlog4j.1.2.17
Posted by Ceki Gülcü <li...@qos.ch>.
At 06:25 AM 10/6/2005, Nick Faiz wrote:
>Hi Ceki,
>
>Thanks for the response. Were you able to replicate the error yourself?
>
>I'll have to test on IDEA 5.0. Unfortunately, I am currently pushed for
>time and will have to follow your suggestions later on. I wanted to reply
>to let you know that I had seen your response, though.
>
>I'm a little concerned over another log4j/slf4j conflict which a user
>reported when trying to embed ApacheDS into a log4j dependent application
>(see attachment). I'm going to put together a test project of some kind
>which uses log4j and embeds ApacheDS to verify the existence of the
>problem. I'll keep you updated about what I found out on this front.
>
>What kind of testing strategies have you followed to ensure that existing
>applications, using log4j, continue to work when they use a library which
>uses slf4j?
Hello Nick,
We have a test case, called Compatibility, (please refer to [1]) which
verifies that code compiled with log4j runs when NLOG4J is on the
class path. Methods known to suffer from compatibility re exercised by
this test. In case there was any doubt, code compiled against
log4j.jar runs fine when log4j.jar is replaces with nlog4j.jar on the
class path.
The test suite also reproduces a well known compatibility problem.
Code compiled against nlog4j.jar will not run with log4j.jar on the
class path.
NLOG4J should be considered as a new version of log4j. Code compiled
with the "old" version, e.g. log4j, will run fine with both the old
and the new version. However, code compiled with the new version,
i.e. NLOG4J, requires the new version and will not run with log4j, the
"old" version.
To summarize, nlog4j.jar can replace log4j.jar but the inverse does
not hold true.
Regarding the message "Problem embedding 0.92 ApacheDS" posted by Thom
Park, unless I am missing something obvious, it looks like that Thom
is using log4j.jar instead of nlog4j.jar. We have already established
that that won't work, for the simple reason that log4j does not offer
SLF4J support.
As a side note, Thom mentioned that he had followed the "instructions
in the doc for embedding ApacheDS". Which doc is that? I could not
find it, but admittedly I did not search for long.
Nick, would you concur with the above assessment?
[1] http://svn.slf4j.org/viewcvs/nlog4j/trunk/tests/build.xml?view=markup
>Cheers,
>Nick
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Re: upgrading to nlog4j.1.2.17
Posted by Nick Faiz <ni...@atlassian.com>.
Hi Ceki,
Thanks for the response. Were you able to replicate the error yourself?
I'll have to test on IDEA 5.0. Unfortunately, I am currently pushed for
time and will have to follow your suggestions later on. I wanted to
reply to let you know that I had seen your response, though.
I'm a little concerned over another log4j/slf4j conflict which a user
reported when trying to embed ApacheDS into a log4j dependent
application (see attachment). I'm going to put together a test project
of some kind which uses log4j and embeds ApacheDS to verify the
existence of the problem. I'll keep you updated about what I found out
on this front.
What kind of testing strategies have you followed to ensure that
existing applications, using log4j, continue to work when they use a
library which uses slf4j?
Cheers,
Nick
Ceki Gülcü wrote:
>
> Hello Nick,
>
> Are you aware of IDEA's (version 5.0) ability to export jar files from
> a module (IDEA->Settings->Modules->Order/Export)? For example, if
> module X depends on jar file a.jar, it can export a.jar so that module
> Y which depends on X can also access a.jar.
>
> Thus, my first suggestion would be to remove the expanded (or
> exploded) versions of nlog4j and slf4j from ApacheDS module. When
> that's done, try exporting/not exporting nlog4j from the ApacheDS
> module.
>
> At 05:39 AM 9/14/2005, Nick Faiz wrote:
>
> > When I run a main method in module1 (which doesn't use ApacheDS) all
> > log statements in modules 1, 2 and 3 work quite well. When it finally
> > reaches a logging statement in module4, which *does* use ApacheDS, I
> > see a NoSuchMethodError:
>
> I could not find documentation about what IDEA does when multiple
> modules declare the same dependency. However, given the above, and
> given that module4 which depends on ApacheDS, assuming if ApacheDS
> exported nlog4j, module4 would no longer need to declare log4j as a
> dependency. One could then speculate that the NoSuchMethodError would
> no longer occur.
>
> Does that make sense? Even better, does it work?
>
>