Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Logging OSGi internals
In LR Server Administration there are 11 OSGi related categories in the Log Levels tab. Even all are set to the ALL level, when redeploying the module I can only see two lines STOPPED xxx and STARTED xxx in the server log.
Deploying one my module breaks functionality in other modules and I believe there could be some details why.
- aQute.bnd.osgi
- com.liferay.osgi.felix.file.install.configuration.cleaner.internal
- com.liferay.osgi.log.service.extender.internal.OSGiLogServiceExtenderBundleActivator
- com.liferay.portal.osgi.debug.declarative.service.internal.UnsatisfiedComponentScanner
- com.liferay.portal.osgi.debug.internal.osgi.commands.SystemCheckOSGiCommands
- com.liferay.portal.osgi.debug.spring.extender.internal.UnavailableComponentScanner
- com.liferay.portal.osgi.web.wab.generator.internal.WabGenerator
- com.liferay.portal.osgi.web.wab.generator.internal.processor.WabProcessor
- osgi.logging
- osgi.logging.org_apache_felix_fileinstall
- osgi.logging.org_eclipse_osgi
Deploying one my module breaks functionality in other modules and I believe there could be some details why.
There is a lot happening, sure, but none of it is logging.
Wrapping code with if (_log.isDebugEnabled()) seems like a great way to control whether a log message is generated, but even this adds overhead. In single instances, the overhead is negligible, but if you have a server doing this check frequently while trying to serve thousands of concurrent requests, the overhead is measurable and significant.
For that reason, there is little if any logging decorating the Liferay code, typically you'll only find it at key points where errors can originate outside of Liferay's control and due to customization or configuration.
So the TL;DR version, the best way to understand what is going on under the hood is by a deep code dive or live debugging.
Wrapping code with if (_log.isDebugEnabled()) seems like a great way to control whether a log message is generated, but even this adds overhead. In single instances, the overhead is negligible, but if you have a server doing this check frequently while trying to serve thousands of concurrent requests, the overhead is measurable and significant.
For that reason, there is little if any logging decorating the Liferay code, typically you'll only find it at key points where errors can originate outside of Liferay's control and due to customization or configuration.
So the TL;DR version, the best way to understand what is going on under the hood is by a deep code dive or live debugging.
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™