Zoo of logging frameworks

[eparovyshnaya]

During the work on 553877 spend some time investigating logging frameworks used in Eclipse Passage. Results are interesting and worth to be discussed.

We use

• JUL directly,
• OSGi logging in some equinox-based bundles,
• SLF4J in a sporadic way,
• Jetty logging for JettyServer

How we do this

1. JUL directly
   • all the *Messages.java
   • org.eclipse.passage.lbc.internal.equinox.conditions.ServerConditionArbiter
   • org.eclipse.passage.lic.internal.equinox.requirements.BundleCapabilityResolver
   • org.eclipse.passage.lic.internal.hc.HcConditionMiner
   • org.eclipse.passage.loc.internal.licenses.core.LicenseMailSupport
   • org.eclipse.passage.loc.workbench.dialogs
2. OSGi logging
   • org.eclipse.passage.lbc.internal.equinox.ServerRunnerImpl
   • org.eclipse.passage.lic.internal.equinox.requirements.ComponentConfigurationResolver
3. SLF4J
   • org.eclipse.passage.lbc.internal.equinox.conditions.AcquireConditionActionExecutor
   • org.eclipse.passage.lic.hc.HttpRequests
   • org.eclipse.passage.loc.internal.workbench.LocDomainRegistryAccess

Findings

1. One physical package exploits several logging frameworks
2. Each particular framework does not seem to have a peculiar reason to be used here or there.

Question

Should we put things here in some order?

Suggestion

I think, that, for understandable causes (like, say, logging configuration),
there should be

• either a static choice (like, JUL)
• or some reasonable strategy for choosing a framework.
  Like:
  • OSGi logging for OSGi/Equinox dependent packages
  • SLF4J+JUL for the rest of the bundles

What do you think, colleagues?

[eparovyshnaya]

572145 Jetty integration logs through log4j2

[eparovyshnaya]

1. JUL
   • *Messages
   • org.eclipse.passage.loc.workbench.dialogs
2. OSGi logging eliminated
3. SLF4J eliminted
4. Jetty-logging eliminated