Really? http://www.slf4j.org/ - SLF4J API offers an advanced abstraction of various logging systems, including ... logback. ... Logging systems can either choose to implement the the SLF4J interfaces directly, e.g. logback or ... - So what then is the relationship between logback and slf4j ? When my team has investigated the POM files for logback, we see dependency on log4j libraries. The latest POM in trunk show a dependency on slf4j 1.5.6 http://svn.qos.ch/viewvc/logback/trunk/pom.xml?revision=2114 - ... <properties> − <!-- slf4j.version property is used below and in setClasspath.cmd --> <slf4j.version>1.5.6</slf4j.version> <consolePlugin.version>1.1.0</consolePlugin.version> </properties> ... <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>${slf4j.version}</version> </dependency> ... - Are the slf4j libraries compiled into and bundled with the logback distribution? -RG Ceki Gulcu wrote:

Hi Russell,

You don't need SLF4J for logback-access. Not for jetty nor tomcat.

Russell E Glaue wrote:

...

To implement the Jetty RequestLog in Jetty,

http://logback.qos.ch/access.html#jetty

what is the minimal set lof slf4j and log libraries I need?

slf4j-? logback-core-VERSION.jar logback-access-VERSION.jar

...

From the above doc, I see the two logback-core and logback-access libraries are minimally necessary to use ch.qos.logback.access.jetty.RequestLogImpl What minimal set of slf4j libraries are necessary?

-RG

Yes, I am only interested in logback-access so that I can implement the jetty.RequestLogImpl for Geronimo-Jetty 2.1.3 And you say to do this I only need the logback-core/access libraries. I asked what the relationship was between logback and slf4j. Can I assume from what you are saying that logback-core and logback-access in no way have anything to do with slf4j in any way? So, to get to my results, Geronimo-Jetty 2.1.3 implements slf4j-api 1.4.3 (Jetty 6.1.14 implements slf4j 1.3.1). If I load the logback-access and logback-core 1.5.6 libraries into Geronimo, is there going to be any issues or conflicts with specifically the slf4j 1.4.3 support in Geronimo? In other words, will loading logback-core/access 1.5.6 into Geronimo override any part of the existing slf4j 1.4.3 library? Can any application use slf4j 1.3.1 OR slf4j 1.4.3 libraries, and then at the same time use logback-core and logback-access 0.9.14 libraries without any problems? -RG Ceki Gulcu wrote:

Hello Russell,

The logback projects consists of 3 modules: logback-core, logback-classic and logback-access. There is also the logback-audit module but which is commercial (not open-source). All modules depend on logback-core.

Logback-access module depends on logback-core. It integrates with Tomcat and Jetty. So it requires any the two to be useful.

Logback-classic module depends on logback-core and on slf4j-api. The logback distribution bundles slf4j-api.jar under logback-examples/lib. However, your can obtain slf4j from http://www.slf4j.org/download.html

The pom.xml file you mention has a *dependencyManagement* section which declares slf4j. However, the dependencyManagement is used to fix the *version* of a dependency for all modules. It does *not* declare a dependency. In logback-classic/pom.xml there is indeed a dependency declaration on log4j-over-slf4j but which is in the *test* scope. It is only used for testing purposes. In other words, you don't need log4j to use logback.

You should not confuse logback-access and logback-classic. There serve different purposes. To answer your question, logback-access does not depend on SLF4J. (You are only interested in logback-access, right?)

HTH,

Russell E Glaue wrote:

...

Really?

http://www.slf4j.org/ - SLF4J API offers an advanced abstraction of various logging systems, including ... logback. ... Logging systems can either choose to implement the the SLF4J interfaces directly, e.g. logback or ... -

So what then is the relationship between logback and slf4j ?

When my team has investigated the POM files for logback, we see dependency on log4j libraries.

The latest POM in trunk show a dependency on slf4j 1.5.6 http://svn.qos.ch/viewvc/logback/trunk/pom.xml?revision=2114 - ... <properties> − <!-- slf4j.version property is used below and in setClasspath.cmd --> <slf4j.version>1.5.6</slf4j.version> <consolePlugin.version>1.1.0</consolePlugin.version> </properties> ... <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>${slf4j.version}</version> </dependency> ... -

Are the slf4j libraries compiled into and bundled with the logback distribution?

-RG

Okay then, this is great. Then despite the fact that both Geronimo and Jetty do not implement the latest slf4j, they can implement the latest logback-core/access. I have already requested that Jetty implement the latest 1.5.6 of slf4j, it is in issue: http://jira.codehaus.org/browse/JETTY-865 I will do the same for Geronimo. But since logback-core/access is not tied in dependency to slf4j, I can request the upgrade for slf4j and support for logback both at the same time. And when slf4j web site (http://www.slf4j.org/) lists, on the left side, that logback is a native implementation, it is referring to logback-classic only as the native implementation of slf4j. So I would assume logback-classic does have a dependency on slf4j since it is performing native implementation of it. Since we are on this topic, can you answer the same question in regards to logback-classic: Can any application use slf4j 1.3.1 OR slf4j 1.4.3 libraries, and then at the same time use logback-classic 0.9.14 libraries without any problems? Or will there be a dependency conflict? In other words, is logback-classic dependent on slf4j? -RG Ceki Gulcu wrote:

Russell E Glaue wrote:

...

Yes, I am only interested in logback-access so that I can implement the jetty.RequestLogImpl for Geronimo-Jetty 2.1.3 And you say to do this I only need the logback-core/access libraries.

Yes, that's what I am saying.

...

I asked what the relationship was between logback and slf4j. Can I assume from what you are saying that logback-core and logback-access in no way have anything to do with slf4j in any way?

You can assume that. Actually, I can guarantee it.

...

So, to get to my results, Geronimo-Jetty 2.1.3 implements slf4j-api 1.4.3 (Jetty 6.1.14 implements slf4j 1.3.1). If I load the logback-access and logback-core 1.5.6 libraries into Geronimo, is there going to be any issues or conflicts with specifically the slf4j 1.4.3 support in Geronimo?

If Geronimo and Jetty integrate well at present, adding logback-access to the mix will have no impact on Geronimo and Jetty integration. If you wish, it would not hurt to ask Geronimo and Jetty developers to upgrade to the latest version of SLF4J, that is 1.5.6.

...

In other words, will loading logback-core/access 1.5.6 into Geronimo override any part of the existing slf4j 1.4.3 library?

No, as logback-core and logback-access are unrelated to SLF4J.

...

Can any application use slf4j 1.3.1 OR slf4j 1.4.3 libraries, and then at the same time use logback-core and logback-access 0.9.14 libraries without any problems?

Please see above.

...

-RG

Ceki Gulcu wrote:

Russell E Glaue wrote:

...

Okay then, this is great.

Then despite the fact that both Geronimo and Jetty do not implement the latest slf4j, they can implement the latest logback-core/access.

I have already requested that Jetty implement the latest 1.5.6 of slf4j, it is in issue: http://jira.codehaus.org/browse/JETTY-865

I will do the same for Geronimo.

Thank you.

Well, as it turns out, there is no interest in adding library support for Logback into Jetty, at this time. Jetty is moving to a "Jetty @ Eclipse" core distribution - I refer to it as "jetty-core". http://www.nabble.com/Jetty-%40-Eclipse---td20851567.html#a20867927 I had a discussion on the jetty-dev mail list: http://www.nabble.com/-DISCUSS--Jetty-6.2-or-7.0-for-new-features--td2162753... The JSP 2.0 implementation in Jetty-6 actually required a commons logging type of support. This is the reason for including slf4j in Jetty6. The reason for downgrading slf4j support is due to the fact that they did not know about it, and it was an accident - as slf4j is never used in Jetty-7. Additionally, Jetty 6 and 7 have support for log4j to implement application logging. There does not seem to be any interest in replacing log4j with Logback. One of the main reason appears to be that Logback is LGPL and not either APL or EPL. I think this is a little weird, because all three licenses are GPL compatible. So I am not understanding the reasoning why Logback could not legally be used. However I do understand that in the move to Eclipse, the Jetty community is steering clear of anything that might potentially give reason to slow down the process of getting Jetty moved to Eclipse. I think that after Jetty @ Eclipse has been established, there might be more openness to adding additional third party library support to Jetty-core. In the mean time, it is my belief that additional enterprise-worthy library support (like Logback) can be requested to be added to Geronimo or other upstream software implementations of Jetty-core. My team here at the center is working on a GBean implementation of Logback's RequestLogImpl class. After its completion, we are planning to contribute it to Geronimo. Is the Logback community interested in receiving the Geronimo GBean contribution? Perhaps it is better to give the GBean implemention to Logback's distribution, then implement it in Geronimo from there? Comments/Discussion? -RG

While this is true in general when the desire is to embed a LGPL work into an APL work, it is not true in this case. In regards to LGPL 2.1, which Logback is licensed, review section 5. In using logback in Geronimo: 1. Logback is distributed with Geronimo, but Geronimo is not derived from Logback. 2. Geronimo can run without Logback. I am intending that the Logback library be distributed with Geronimo to provide an additional option for logging at the user's prerogative. However, by default the Logback library would not be configured, thus making the Logback library a dormant unused library by default. The only license problem Apache (APL) has with LGPL is the restriction LGPL puts on larger works, as defined in LGPL section 5. However, as I have noted, in this case Geronimo would not be consider a "larger work". So, yes, as you said, Logback has to be an optional component. However, thank you for making this clear to me. I now am considering that to include a LGPL software in an APL software as I have said may not initially cause any issues, but as time proceeds, the doors will be inviting issues while the LGPL is part of the distribution, lending to the future possibility of violating section 5 of the LGPL. How does the logback community feel about this restriction upon the Logback library? -RG Ralph Goers wrote:

On Jan 26, 2009, at 1:09 PM, Russell E Glaue wrote:

...

Additionally, Jetty 6 and 7 have support for log4j to implement application logging. There does not seem to be any interest in replacing log4j with Logback. One of the main reason appears to be that Logback is LGPL and not either APL or EPL. I think this is a little weird, because all three licenses are GPL compatible. So I am not understanding the reasoning why Logback could not legally be used.

Although components using these various licenses can all be packaged and distributed together, they are not completely "compatible". See http://apache.org/legal/resolved.html.

...

However I do understand that in the move to Eclipse, the Jetty community is steering clear of anything that might potentially give reason to slow down the process of getting Jetty moved to Eclipse.

I think that after Jetty @ Eclipse has been established, there might be more openness to adding additional third party library support to Jetty-core.

In the mean time, it is my belief that additional enterprise-worthy library support (like Logback) can be requested to be added to Geronimo or other upstream software implementations of Jetty-core.

My team here at the center is working on a GBean implementation of Logback's RequestLogImpl class. After its completion, we are planning to contribute it to Geronimo.

While Geronimo can use the SLF4J api, due to its licensing Logback can only be an optional component for any Apache project. So you can expect that the default implementation used would be log4j.

Ralph

------------------------------------------------------------------------

_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user

Ralph Goers wrote:

While Geronimo can use the SLF4J api, due to its licensing Logback can only be an optional component for any Apache project. So you can expect that the default implementation used would be log4j.

Hello Ralph, You are right. At present time the ASF considers LGPL to be in category C (excluded licenses). However, I think one could argue that as long as some Apache software, say Geronimo, uses logback-classic via SLF4J, without ever linking against logback-classic, LGPL restrictions on distribution do not apply. I hope to eventually present this argument to legal@apache. A similar argument may apply to Tomcat embedding logback-access. Logback-access is deployed in Tomcat as a Valve (a Tomcat structure). Tomcat does not link with logback-access. In a similar vein, logback-access implements the Jetty RequestLog interface. Jetty does not link with logback-access. Cheers,

Ralph

-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

Russell E Glaue wrote:

But I am not seeing how including LGPL libraries in a distribution, which only provides additional options, can be a problem. Especially as Ceki says Logback code is actually implementing an interface with an APL license.

The only thing to be careful of is that if there are any derived works from the LGPL libraries, that the code is probably contributed to the LGPL licensed work instead of the APL licensed work.

The LGPL 2.1 license has a rather ambiguous definition of "derivative work". See conditions 5 and 6 of the LGPL 2.1. The ASF folks have a conservative interpretation of the LGPL terms, preferring to forbid Apache projects from referencing software licensed under the LGPL. The poor communication channel between the ASF and the FSF has not helped to clarify matters. If I remember correctly, some years ago the ASF has asked to clarify the terms of LGPL. FSF's answer was rather unsatisfactory. That's my understanding of the matter.

So if I want to contribute some code to Geronimo which the code actually is a derived work of Logback libraries, I should contribute it to Logback and then put in a request to upgrade the Logback libraries in Geronimo so that support exists there.

And this answer a previous question of where to commit the GBean implementation of the Logback Jetty RequestLogImpl for Geronimo. We should contribute it to Logback for inclusion in release X, then lobby Geronimo to support release X of Logback.

I would not hold my breath until the licensing issues are resolved. In order to move forward quickly, you could simply create your own oss project and develop your GBean there, licensed under LGPL. By the way, if you don't intend to distribute the GBean, you could use any license. Those wishing to use your GBean would install it manually into their Geronimo installation after downloading it from your project's site. I am just mentioning this as an alternative. Depending on what your GBean does, it could be part of the logback project. (We have an incubator.) Could you please remind us of what you GBean does? Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

On Jan 27, 2009, at 12:09 PM, Ceki Gulcu wrote:

Russell E Glaue wrote:

...

But I am not seeing how including LGPL libraries in a distribution, which only provides additional options, can be a problem. Especially as Ceki says Logback code is actually implementing an interface with an APL license. The only thing to be careful of is that if there are any derived works from the LGPL libraries, that the code is probably contributed to the LGPL licensed work instead of the APL licensed work.

The LGPL 2.1 license has a rather ambiguous definition of "derivative work". See conditions 5 and 6 of the LGPL 2.1. The ASF folks have a conservative interpretation of the LGPL terms, preferring to forbid Apache projects from referencing software licensed under the LGPL. The poor communication channel between the ASF and the FSF has not helped to clarify matters. If I remember correctly, some years ago the ASF has asked to clarify the terms of LGPL. FSF's answer was rather unsatisfactory. That's my understanding of the matter.

That has all been cleared up. As I said, LGPL'd works can be used for optional components. For example, a project may use Hibernate but only if it is not required for the project to work.

...

So if I want to contribute some code to Geronimo which the code actually is a derived work of Logback libraries, I should contribute it to Logback and then put in a request to upgrade the Logback libraries in Geronimo so that support exists there.

...

And this answer a previous question of where to commit the GBean implementation of the Logback Jetty RequestLogImpl for Geronimo. We should contribute it to Logback for inclusion in release X, then lobby Geronimo to support release X of Logback.

I would not hold my breath until the licensing issues are resolved.

In order to move forward quickly, you could simply create your own oss project and develop your GBean there, licensed under LGPL. By the way, if you don't intend to distribute the GBean, you could use any license.

The GBean may not be a derivative work, in which case it can be licensed under the Apache license. The whole point of the LGPL is that while the library itself is under the LGPL, applications using the library can choose any license they like. Ralph

...

And this answer a previous question of where to commit the GBean implementation of the Logback Jetty RequestLogImpl for Geronimo. We should contribute it to Logback for inclusion in release X, then lobby Geronimo to support release X of Logback.

If GBean's are a Geronimo construct (I am unfamiliar with Geronimo) and the GBean in question just allows Logback's configuration to be dynamically updated I see no reason why this can't reside with Geronimo, unless it needs to modify existing Logback classes.

The GBean is a Geronimo construct, however if Geronimo does not bundle the Logback library in with it, then it seems ridiculous to include the GBean in Geronimo which depends on an external library not available in the Geronimo distro. Instead it makes more since to put it in the Logback distro. Logback implements the Jetty RequestLog, as RequestLogImpl. This implementation is in the Logback distro, not Jetty. Jetty does not incorporate Logback, so it would seem funny to give the implementation to Jetty unless they also agree to accept the Logback libraries into the distribution. On the other hand, if we implement a log4j version of RequestLog, that should go into the Jetty namespace, and not the Log4j namespace, as Log4j is distributed with Jetty. Overall, I agree with you. It would seem logical that the RequestLogImpl (of Logack) be distributed as part of Jetty, and the GBean wrapper for it distributed with Geronimo, but if Jetty and Geronimo do not bundle the Logback library, I do not see that as making sense. -RG

Ceki Gulcu wrote:

Russell E Glaue wrote:

...

The GBean is a Geronimo construct, however if Geronimo does not bundle the Logback library in with it, then it seems ridiculous to include the GBean in Geronimo which depends on an external library not available in the Geronimo distro.

Instead it makes more since to put it in the Logback distro.

Logback implements the Jetty RequestLog, as RequestLogImpl. This implementation is in the Logback distro, not Jetty. Jetty does not incorporate Logback, so it would seem funny to give the implementation to Jetty unless they also agree to accept the Logback libraries into the distribution.

On the other hand, if we implement a log4j version of RequestLog, that should go into the Jetty namespace, and not the Log4j namespace, as Log4j is distributed with Jetty.

Overall, I agree with you. It would seem logical that the RequestLogImpl (of Logack) be distributed as part of Jetty, and the GBean wrapper for it distributed with Geronimo, but if Jetty and Geronimo do not bundle the Logback library, I do not see that as making sense.

I thought that you were interested in providing access-log functionality for a widely-deployed application in the enterprise/institution where you work. Why is it so important in which project your GBean extension lives? Put differently, why do wish to redistribute the GBean extension?

Why would I not contribute it back? I have a commitment to see Geronimo prosper. I think it needs an enterprise capable logging mechanism. Plus at least one other person has responded that they are also interested in it. Once it is in the code, the community supports it, and it is a part of the default installations which our developers will all be using. Makes it easier for us manage. Our environment is a 40-server Geronimo farm. With over 30 web sites, and over 50 web applications. The less I have to manage, the better.

...

-RG

Oh, I forgot to mention that if you wanted to have your project hosted within logback at qos.ch, that is also possible. Ceki Gulcu wrote:

Hello Russell,

Obviously, it would be nice if your contribution became part of the default installation. However, your contribution can be helpful even if it is not part of the default Geronimo distribution.

Implementing accessing-logging with log4j would not be easy. I think you would end up rewriting log4j which is presumably not your intention.

Notwithstanding the license issue, I still think you can have sweet deal. Here is how I see it.

- Write a GBean with the jetty/logback-access extension. - Create a project in sourceforge to host it. - Add one page documentation on installing your GBean in Geronimo. - Locally, you would distribute your own version of Geronimo (with your extension already installed). You would then install that version in your farm.

(The above is just an indication.)

Many log4j extensions are not hosted in log4j. The same is true for logback. It's nice if an extension becomes part of the main distribution but it does not have to.

HTH,

-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

In that case, you could just post the code with instructions on this list. We could then add it on a page on logback project web-site. (You have to start somewhere.) Russell E Glaue wrote:

Thanks, but since what would be contributed is just a straight-forward single file, we just assume it be contribute back. -RG

-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch