It does not mean much me saying so, but the SLF4J and logback projects are gaining traction. The project mailing lists are showing real signs of life and community interest, whereas the download statistics are showing significant upward trend.
We are not at the same levels of popularity as commons-logging or log4j. Nevertheless, it is very encouraging to see users responding favorably to our work. It feels like the early days of log4j, and that's pretty damn exciting.
3 comments:
Hi Ceki:
First, it is great to write to someone which contributions to the development and IT industries are so proficient. I am a Software Architect and right now I am in the process of create an architectural baseline (evolutionary prototype) with the latest technologies (JEE5, Struts2, and so on...), updating previously constructed prototypes.
I have happily used Log4j for years, and I think that it is an awesome piece of software. I was just about to start logging with log4j (JDK14 logging wasn't an option) when I decided to read about the project current status. There I found that its last release was on September 2006, and there doesn't appear to be any plan to keep working on it. Then I found the LogBack project and start reading about it and about SLF4J, which looks like a great idea.
I am almost decided to integrate LogBack classic through SLF4J in my prototype (although in SLF4J documentation states that it should be used only for libraries, an evolutionary prototipe should have the benefit of choosing a logging framework), but I have a last question, and I think this is the only place where I can find an answer:
Since you are the creator of Log4j, and you are behind LogBack, Is there any reason to stop developing Log4j and start another different project with all that it implies? Has it anything to do with a separation from the Apache Software Foundation? What does it implies to me as a framework user? Should I be afraid of being in the middle of a political or ideological war or something like that, jeopardizing my humble prototype? In short:
Should I use SLF4J and LogBack in an evolutionary prototipe with confidence??
Thank you very much for your time and patience, and thanks in advance for any answer about the topic.
Best Regards,
(pls send me any thoughts to pedro.solorzano@sun.com)
Hi Ceki
Any reason that logback-access can't be used directly as a OGGi bundle? Logback-core can be loaded directly in OSGi and it seems that the MMANIFEST.FM of the logcack-access.jar contain OSGi info but I keep getting: The bundle "ch.qos.logback.access_1.1.2 [23]" could not be resolved. Reason: Missing Constraint: Import-Package: org.apache.coyote; version="0.0.0"
We use jetty imbedded in OSGi.
Now for the question:
Could You please add support for OSGi in logback-access.jar.
We would like to migrate to logback, but since we are using webservices extensivily, and need to log all requests, We have kind of run into a dead end.
Could You at least point us in the right direction.
We have tried to use org.eclipse.jetty.osgi.boot.logback-8.0.0.M0.jar but this fails with absolutely no information on why the bundle could not load.
Best regards,
TUC
I have added the following line to the section in the logback-access pom.xml:
org.apache.coyote.*;resolution:=optional,
I have then build the jar with:
mvn install
We are now able to do something like:
org.osgi.framework.Bundle bundle = frameworkContext.installBundle("file:" + systemBundleDir + logback-access-1.1.2.jar);
bundle.start();
No runtime exceptions BUT when I do a ss in a OSGi console the logback-access bundle is not listed (only logback.classic, logback.core and logback.slf4j):
osgi> ss
"Framework is launched."
id State Bundle
0 ACTIVE org.eclipse.osgi_3.9.1.v20130814-1242
1 ACTIVE org.eclipse.equinox.simpleconfigurator_1.0.400.v20130327-2119
2 RESOLVED ch.qos.logback.classic_1.0.7.v20121108-1250
Fragments=236
3 RESOLVED ch.qos.logback.core_1.0.7.v20121108-1250
4 RESOLVED ch.qos.logback.slf4j_1.0.7.v20121108-1250
Master=445
.
.
.
etc. (but not logback.access)
Question: Why does it look like (in the logback-access.jar MANIFEST.MF) the jar is build as a OSGi bundle if it does not work as a OSGi bundle!
It looks like a half hearted attempt (or half finished job) to make logback-access OSGi compatible! Any thoughts or comments on that Ceki?
IT WOULD BE GREAT TO BE ABLE TO START LOGBACK-ACCESS DIRECTLY AS A BUNDLE JUST LIKE LOGBACK-CORE AND LOGBACK-CLASSIC
(Comment: Either I have completely misunderstood something or I am the only one on the planet using logback-access with OSGi)
Please help Ceki.
Best regarts
TUC
Post a Comment