Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert logging to logback predominantly via slf4j #1006

Merged
merged 33 commits into from
Apr 11, 2013

Conversation

ximenesuk
Copy link
Contributor

This PR converts the underlying logging to logback throughout much of the codebase using the slf4j facade. use of jcl and jul by third-party libraries is handled by bridges. The import/insight stacks still use log4j but that will be dealt with in a separate branch. Thee are still small traces of log4j that need tidying up but again that can be done separately once this base work is merged in.

There is no easy way to test this other than the build being successful, the server running and functioning normally. All java logs should be present. slf4j configuration information should appear in master.out (this can be turned down once the work is complete).


--no-rebase FS only

ximenesuk added 28 commits April 9, 2013 12:16
This can probably be done in a more sophisticated way but to get the
build working this is a reasonable fix.
No build section as that does not currently support logback.
No perf4j section yet.
There are various log4j features in use here that need to be replaced by their
slf4j/logback equivalents. In this commit have had logging configuration specific
to log4j commented out so that they build.

The importer-specific files will be overhauled in the per-fileset logging work. Any
remaining files will be fixed once the current branch is tested and merged in.
@snoopycrimecop
Copy link
Member

Conflicting PR. Removed from build OMERO-merge-develop#220. See the console output for more details.

mtbc added a commit to mtbc/openmicroscopy that referenced this pull request Apr 10, 2013
@joshmoore
Copy link
Member

I don't think this was missing in your migration, but

2013-04-11 08:33:23,799 INFO  [    ome.security.basic.BasicEventContext] (3-thread-2)  cctx:    group=-1

from Indexer-0.log should likely be stripped too.

@joshmoore
Copy link
Member

Nice: source jars in stack traces ([org.springframework.aop.jar:3.0.1.RELEASE-A], ~[server.jar:na], ...)

@ximenesuk
Copy link
Contributor Author

Stripped as in we don't want ome.security INFO in that log? Can we review the config for that afterwards? Also, at the moment Pixeldata uses the base config logback.xml Does that need its own config?

Logger.getLogger("ome.formats").setLevel(level);
Logger.getLogger("loci").setLevel(level);
}
// public void configureDebug(Level level) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will certainly affect the results of what we get from import logging until it's been fixed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there I tried a fix but it looks like it will need to be fixed in the context of moving Insight/Importer away from log4j

@joshmoore
Copy link
Member

Summary of things that could be addressed here:

  • s/Logger/Log/ in comments
  • debug=false
  • EOL changes: ShutdownSafeEhcacheManagerFactoryBean, PdfParser and LoggingCacheListener

Summary of things to be ticketed:

  • -Dlog4j.configuration=log4j-cli.properties
  • ImportConfig cgb marker
  • CommandLineImporter cgb marker
  • Entry.java's description, etc. (incl. BlitzEntryTest)
  • TempFileManager cgb marker
  • Review IniFileLoaderTest (or delete it. This should no longer be used) Similar changes in MetadataValidatorTest
  • Split indexer and pixeldata logging files (RFE)

Things needing more testing (my side):

  • ehcache
  • apacheds issues

And one question:

  • is there any explanation of the missing FATAL level from the slf4j folks?

@ximenesuk
Copy link
Contributor Author

I'll fix the minor changes and ticket the others, Edit: separate tickets.

Re FATAL http://www.slf4j.org/faq.html#fatal So we can re-implement it using markers.

@joshmoore
Copy link
Member

For the RFE of splitting the indexer, etc., perhaps we can merge them all back together instead via http://logback.qos.ch/manual/configuration.html#conditional and possibly http://logback.qos.ch/manual/configuration.html#fileInclusion

@@ -29,7 +29,7 @@

public class ObjectsVmTest extends TestCase {

private static Log log = LogFactory.getLog(ObjectsVmTest.class);
private static Log log = LogFactory.getLog(ExampleUsageTest.class);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like an error here too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Funny. I saw that, and read it backwards. I thought you had fixed an old error of mine. That's optimism for you.

@joshmoore
Copy link
Member

Stripped as in we don't want ome.security INFO in that log? Can we review the config for that afterwards? Also, at the moment Pixeldata uses the base config logback.xml Does that need its own config?

Right. That full logger o.s.b.BasicEventContext can be stripped from indexer and pixeldata. pixeldata previously used the indexers config, so that would be a good change for this PR. Afterwards, we can look at re-organizing the three setups.

@joshmoore
Copy link
Member

With gretzky back up, I tested a CLI import. Only obvious issue is that ...import -- --debug=DEBUG 1006.fake doesn't do debug, which will just require the client migration to slf4j. Other than that and the minor points above, I'd say this is good to go.

import org.apache.log4j.xml.DOMConfigurator;
import org.springframework.util.ResourceUtils;

import ch.qos.logback.classic.LoggerContext;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These logback imports are unnecessary and were a left-over from trying to use manual configuration before working out that it could all be done in the xml file. I'll remove them.

@mtbc mtbc mentioned this pull request Apr 11, 2013
@joshmoore
Copy link
Member

Tested this locally, all still looks fine. The latest few commits certainly look visually ok. An import worked fine. Colorizing the server logs (!) worked too:

$ diff ../etc/logback.xml etc/logback.xml
19c19
<       <pattern>%date %-5level [%40.40logger{40}] \(%10.10thread\) %msg%n</pattern>
---
>       <pattern>%date %highlight(%-5level) [%40.40logger{40}] \(%10.10thread\) %msg%n</pattern>

Merging to prevent any further issues. Thanks, @ximenesuk!

joshmoore added a commit that referenced this pull request Apr 11, 2013
Convert logging to logback predominantly via slf4j
@joshmoore joshmoore merged commit 82b43a0 into ome:develop Apr 11, 2013
@ximenesuk ximenesuk deleted the slf4j branch April 11, 2013 17:03
rgozim pushed a commit to rgozim/openmicroscopy that referenced this pull request Oct 8, 2018
Convert logging to logback predominantly via slf4j
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants