Community
Participate
Working Groups
Build Identifier: See: https://issues.apache.org/jira/browse/KARAF-1117 Reproducible: Always Steps to Reproduce: 1. Install karaf 2.2.5-SNAPSHOT 2. start karaf 3. feature:install http
Christian, The logging in jetty did change, however those startup lines have always been generated to stderr (if an slf4j logger was not found on the runtime classpath). How is karaf's logging configured? Also, where is it you would like jetty's logging to go to?? thanks Jan
We use slf4j by default in Karaf. So if logging uses slf4j we should be all right. Can you give me a pointer where I can debug into to see the start of jetty and check what happens with the logging? Btw. The logging system in Karaf is pax logging which supports slf4j, jdk logging, and log4.
Christian, In org.eclipse.jetty.util.Log.java, around line 153 is where we detect whether slf4j is on the classpath or not. If you're deploying into osgi, then I guess this test might not work (although I don't believe this particular bit of code changed between versions 7.4.x and 7.5.x). How do you use jetty with karaf in osgi? Are you using the jetty-osgi-boot bundle, or are you importing the jetty jars and doing your own setup? Jan (In reply to comment #2) > We use slf4j by default in Karaf. So if logging uses slf4j we should be all > right. Can you give me a pointer where I can debug into to see the start of > jetty and check what happens with the logging? > > Btw. The logging system in Karaf is pax logging which supports slf4j, jdk > logging, and log4.
Hi Jan, I looked into the jetty Log class. Pretty complicated setup. Why do you implement your own logging facade and allow people to set the backend? I think the easiest way to have a solid logging that also works in OSGi is to just use slf4j and let it decide which logging backend to use. So people still have the freedom to choose a logging backend and you have a simpler and more solid logging in jetty. I know though that it would be a lot of work to convert jetty to just use slf4j. I think I have found the problem with initializing slf4j. Class.forname in Slf4jLog does not work in OSGi. The easiest fix would be to remove that and live with the fact that slf4j does not log if it is not initialized. Christian
Hi Christian, I hear what you're saying, but we're not likely to change the way we do logging in jetty, as having our own logging facade and default impl has saved us an enormous amount of pain. That said, in our osgi impl (jetty-boot-osgi) we do have optional import statements for slf4j, so presumably if you deployed that, then it would find the slf4j packages in your osgi environment. I think the solution mentioned in https://issues.apache.org/jira/browse/KARAF-1117 of setting the system property sounds like the way to go (if you can't use the jetty-boot-osgi module). cheers Jan (In reply to comment #4) > Hi Jan, > > I looked into the jetty Log class. Pretty complicated setup. Why do you > implement your own logging facade and allow people to set the backend? > > I think the easiest way to have a solid logging that also works in OSGi is to > just use slf4j and let it decide which logging backend to use. So people still > have the freedom to choose a logging backend and you have a simpler and more > solid logging in jetty. I know though that it would be a lot of work to convert > jetty to just use slf4j. > > I think I have found the problem with initializing slf4j. Class.forname in > Slf4jLog does not work in OSGi. The easiest fix would be to remove that and > live with the fact that slf4j does not log if it is not initialized. > > Christian
I understand that you can not change the logging api. So how about two possible solutions: - short term: remove Class.forName in Slf4jLog. Testing for an implementation class is not a good idea anyway as it may change. The downside is that you have no logging output in case slf4j impl is not present. I think with good documentation that is acceptable - long term: You could simplify your logging facade by hard wiring it to the slf4j api. So you do not need special class loading and setup code and no special adapters to the other backends. Slf4j also provides those adapters. Compared to completely switching to slf4j this solution has the advantage that your internal facade keeps the same so no changes are needed. Christian
Christian, I've discovered the reason the Class.forName was added into the SLF4JLog class. It was to ensure that the jetty stderr logger was used if no slf4j impl jar was on the classpath (ie only the slf4j-api jar). I don't think its worthwhile jetty trying to second-guess slf4j like this, so I've removed the Class.forName. This means that jetty in karaf should work with slf4j as before. This change will be in jetty-7.6.3/8.1.3 Jan
*** Bug 365817 has been marked as a duplicate of this bug. ***
Thanks for fixing this. We will be updating as soon as the release comes out: https://issues.apache.org/jira/browse/KARAF-1363
This change introduced bug 379501. Not sure how to proceed here and avoid the warning message.
Thomas, This is caused by someone having the slf4j-api jar deployed, but no slf4j impl jar. In general, if someone is not going to use an sfl4j logger, then they shouldn't deploy the slf4j-api. IMHO the warning message is actually useful ... Jan
