-
Notifications
You must be signed in to change notification settings - Fork 101
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
Conversation
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.
Conflicting PR. Removed from build OMERO-merge-develop#220. See the console output for more details. |
I don't think this was missing in your migration, but
from Indexer-0.log should likely be stripped too. |
Nice: source jars in stack traces ( |
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Summary of things that could be addressed here:
Summary of things to be ticketed:
Things needing more testing (my side):
And one question:
|
I'll fix the minor changes and ticket the others, Edit: separate tickets. Re |
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Right. That full logger |
With gretzky back up, I tested a CLI import. Only obvious issue is that |
import org.apache.log4j.xml.DOMConfigurator; | ||
import org.springframework.util.ResourceUtils; | ||
|
||
import ch.qos.logback.classic.LoggerContext; |
There was a problem hiding this comment.
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.
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:
Merging to prevent any further issues. Thanks, @ximenesuk! |
Convert logging to logback predominantly via slf4j
Convert logging to logback predominantly via slf4j
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