:-) The good old days actually we're different...
Apache Avalon was the breeding ground for Separation of Concern, Inversion of Control and Separation of Interface and Implementation. We had a Logging API, that was quite popular, and allowed a pluggable implementations. When java.util.logging showed up, I tried to convince Ceki Gulcu that separation of interface and implementation was powerful, and spinning some ideas around that... can't remember exactly what was discussed, but it was cool, I am sure. We also discussed a lot around classloading issues that commons-logging exacerbated for Tomcat and other classloading-heavy systems, and he wrote a good piece on that at some point. And a year or two later, Avalon had died and slf4j showed up (I think he did one before that), but since Log4j community was deadlocked in what should be done, he went on and created LogBack outside of Apache. History is fun! On Tue, Apr 23, 2019, 14:21 Grzegorz Grzybek <[email protected]> wrote: > Hello > > After I entered my 40s, I became history nerd, so thanks for some insight. > I was there when there was only log4j and here's what I wrote in > readme.adoc about this: > > – Log4j: the grandfather of all configurable Logging frameworks. Created > when there was no logging bridges/facades around. Actually first facades > (Commons Logging) was created to bridge common logging API to one of > different logging frameworks (back then, it was only Log4j1 and Java Util > Logging (JUL) from JDK1.4). > – Logback: Logback was created after the logging-bridge (r)evolution and > even if it may be used without any logging facade/bridge, it is very > uncommon to do so. > – Log4j2: After huge (in my humble, subjective opinion) success of > Logback, Log4j2 was created as modernized version of original Log4j project > with full awareness of logging bridges/facades and weird properties file > syntax. > > One of the things I always did when forking/shading/changing external > sources (like zookeeper in fabric8) was to create git commit with _exact_ > original version and then to use separate commits for better _diffability_ > (preserving formatting even if I didn't like the original one). It's the > best (IMO) way to track what really has changed comparing to original and > to make it easier (or even possible) to backport future changes to original > library. > > Log4j doesn't change much, but I see the classes are from around 2006 > (matching roughly 1.2.13 version) - but even first commit is already > reformatted and doesn't have the way to diff consecutive changes. > > I'm currently reviewing itests (there are not many of them) and API/Impl > separation (both for Log4j and Log4j2). > > regards > Grzegorz Grzybek > > > pon., 22 kwi 2019 o 01:41 Niclas Hedhman <[email protected]> napisał(a): > >> >> I can answer the "Why?" question, and for the "When?" the original work >> is from 2005. >> >> At that time there was a plethora of logging frameworks, and we had more >> and more "facades" that tried to "solve" the problem of "too many" by >> adding one more. >> >> At that time the two most popular ones were Log4j and commons-logging, >> and both of these are not OSGi friendly at all. In fact, Ceki wrote a piece >> about the commons-logging classloading problem and reloading of classes. >> >> Pax Logging started as an internal need with the project I was working on >> at the time. In a world with an Apache Avalon application to be ported to >> Knopflerfish OSGi framework, with many legacy parts pre-dating Avalon. And >> the only way to make all that work properly in OSGi (something that most >> people don't care about nowadays) was to re-write some of those logging >> frameworks, and in the initial version, all features that we didn't need >> were simply left out, such as MDC/NDC, and other people have added that >> over time. >> >> Pax Logging were able (not sure if that is still true) to upgrade or >> replace the service without stopping any other bundle and cleanly remove >> all classes from memory. At that time, that was an important aspect of all >> bundles in that project. >> >> Hope that brings some additional background to why things are the way >> they are. >> >> >> Niclas >> >> On Sat, Apr 20, 2019, 01:44 Grzegorz Grzybek <[email protected]> >> wrote: >> >>> Hello >>> >>> Thanks for response. By no means I want to "take over" pax logging. I >>> just recently released several aligned versions of pax-web, pax-cdi, >>> pax-tools, pax-jdbc, pax-jms, pax-transx and pax-tipi and I found >>> pax-logging a bit behind. Parent org.ops4j:master pom version could be an >>> indication ;) >>> >>> For pax logging it was hard for me to find out when (and why) so many >>> source files from external projects were simply copied without a hint of >>> the version/tag of source files/library. It's hard to maintain and keep in >>> sync such libraries. >>> >>> I'll definitely present a PR with comments and ask for review. >>> >>> kind regards >>> Grzegorz Grzybek >>> >>> pt., 19 kwi 2019 o 16:12 Niclas Hedhman <[email protected]> napisał(a): >>> >>>> >>>> I let go of being the daddy of Pax Logging more than 10 years ago, and >>>> overall trust the community to do the right thing... That said, every >>>> now and then I feel like I want a bigger part of it again, so my previous >>>> comment was more about my desire to contribute than to tell people what >>>> should be done. >>>> >>>> Still alive and dying. Carry on as you were. >>>> >>>> Niclas >>>> >>>> On Fri, Apr 19, 2019, 12:50 Grzegorz Grzybek <[email protected]> >>>> wrote: >>>> >>>>> Hello >>>>> >>>>> pt., 19 kwi 2019 o 04:19 Niclas Hedhman <[email protected]> >>>>> napisał(a): >>>>> >>>>>> For your last point; OSGIPaxLoggingManager becoming a singleton... >>>>>> The amount of memory or other overhead you save with that is minimal, >>>>>> and I >>>>>> recommend against the proposed change. In general, we don't try to >>>>>> maximize >>>>>> the utilization of trackers in OSGi, but let each client handle its own >>>>>> tracker to keep responsibilities near the usages. IF you decide to do it >>>>>> anyway, you will still need to keep the public constructor as it is part >>>>>> of >>>>>> the official API and don't want to break compatibility over such a minor >>>>>> thing. >>>>>> >>>>> >>>>> Thanks for technical suggestions. I already started checking the >>>>> "singleton" version of OSGIPaxLoggingManager. I wasn't that much concerned >>>>> about number of trackers created, but with general code organization. >>>>> There are six _clients_ but OSGIPaxLoggingManager was not created once >>>>> for every client - for example with SLF4J, the manager was created both >>>>> inside Slf4jLoggerFactory and in Slf4jMDCAdapter. That's one thing. >>>>> Another >>>>> was that most (not all) of these "manager keepers" were holding >>>>> Map<String, >>>>> ClientSpecificLogger> m_loggers - only to ensure that loggers created >>>>> between static client/factory was created and OSGIPaxLoggingManager was >>>>> set. >>>>> For now, I extracted "setPaxLoggingManager" method to >>>>> PaxLoggingManagerAwareLogger interface and I can keep single Map<String, >>>>> PaxLoggingManagerAwareLogger> m_loggers map in the Activator itself (I can >>>>> think of moving it somewhere else) - so far, all _clients_ contains the >>>>> same code related to m_loggers. >>>>> >>>>> So less optimization (because it's not a problem here), but code >>>>> cleanup, comments and consistency. >>>>> >>>>> In addition, I was able (so far) to: >>>>> - keep only those sources from slf4j/commons-logging/... that are >>>>> needed, other classes from original _clients_ are simply private-packaged >>>>> (and exported) >>>>> - enforce a convention that _client_ specific overrides are in their >>>>> original package and supporting classes (like >>>>> org.ops4j.pax.logging.slf4j.Slf4jLoggerFactory) are kept in >>>>> org.ops4j.pax.logging._clientid_. IMO these packages should not be >>>>> exported >>>>> (I have to be delicate here) - org.ops4j.pax.logging.slf4j is exported but >>>>> org.ops4j.pax.logging.log4jv2 not. >>>>> - additionally, I added pax-logging-api-test project which has >>>>> maven-invoker based tests to show different API usages and ensure that >>>>> pax-logging-api adheres to these idioms. For example (no pax-logging-api >>>>> usage, just awareness of the implementation): >>>>> >>>>> package org.ops4j.pax.logging.test.slf4j; >>>>> >>>>> import org.junit.Test; >>>>> import org.slf4j.Logger; >>>>> import org.slf4j.LoggerFactory; >>>>> import org.slf4j.MDC; >>>>> >>>>> import static org.junit.Assert.assertTrue; >>>>> >>>>> public class FactoryTest { >>>>> >>>>> @Test >>>>> public void paxLoggingSpecificSlf4jFactory() { >>>>> Logger log = LoggerFactory.getLogger(this.getClass()); >>>>> log.info("Factory: {}", LoggerFactory.getILoggerFactory()); >>>>> >>>>> >>>>> assertTrue(LoggerFactory.getILoggerFactory().getClass().getName().startsWith(" >>>>> *org.ops4j.pax.logging.slf4j*")); >>>>> } >>>>> >>>>> @Test >>>>> public void paxLoggingSpecificMDC() { >>>>> >>>>> assertTrue(MDC.getMDCAdapter().getClass().getName().startsWith(" >>>>> *org.ops4j.pax.logging.slf4j*")); >>>>> } >>>>> >>>>> } >>>>> >>>>> pax-logging didn't have maven-bundle-plugin:baseline verification >>>>> (like pax-web) and I'm not (yet) sure if adding new interface (and not >>>>> touching previous exported packages) requires bumping version to 2.0 (I >>>>> don't think so). There's no pax-logging 1.11.0 yet, so minor version >>>>> upgrade allows _some_ API changes. >>>>> I'll keep you informed. >>>>> >>>>> Also there's this PAXLOGGING-240 ("ClassCastException with log4j2 on >>>>> org.apache.logging.log4j.core.LoggerContext") issue which _may_ require >>>>> some API reorganization. >>>>> >>>>> I just have some time now and want to do some maintenance work for pax >>>>> project (I'm working on https://ops4j1.jira.com/browse/PAXWEB-1190 as >>>>> well). >>>>> >>>>> regards >>>>> Grzegorz Grzybek >>>>> >>>>> >>>>>> >>>>>> Cheers >>>>>> Niclas >>>>>> >>>>>> On Thu, Apr 18, 2019 at 1:54 PM Grzegorz Grzybek < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hello >>>>>>> >>>>>>> I have few issues backlogged for PAXLOGGING Jira: >>>>>>> – PAXLOGGING-243: Incorrect bundle names in the logs in case of the >>>>>>> logs come from embeded lib >>>>>>> – PAXLOGGING-247: pax-logging-api/Slf4jMDCAdapter uses stale MDC >>>>>>> after refreshing service bundle >>>>>>> – PAXLOGGING-249: JUL loggers are not properly configured if used >>>>>>> before calling PaxLoggingServiceImpl#setJULLevel >>>>>>> – PAXLOGGING-250: Log4j2 - JNDI based JDBC appender should be more >>>>>>> lazy >>>>>>> >>>>>>> So I started to review the code (licenses, deps, upgrading from old >>>>>>> org.ops4j:master:3.3.0, ...). >>>>>>> >>>>>>> I see some code could be refreshed and improved. Here are my >>>>>>> concerns which I'll try to handle if I won't get any feedback): >>>>>>> – should we switch compiler settings to Java8? Not necessary >>>>>>> – I want to upgrade log4j2, slf4j, logback and jboss logging deps >>>>>>> – I want to get rid of those source files from external libs which >>>>>>> can be simply private packaged >>>>>>> – I want to switch org.ops4j.pax.logging.OSGIPaxLoggingManager >>>>>>> usage to singleton - now, each logging facade uses own copy of this >>>>>>> manager, which is effectively a tracker for given PaxLoggingService. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> regards >>>>>>> Grzegorz Grzybek >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> ------------------ >>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>> >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "OPS4J" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Niclas Hedhman, Software Developer >>>>>> http://polygene.apache.org - New Energy for Java >>>>>> >>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "OPS4J" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>>> -- >>>>> ------------------ >>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OPS4J" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> -- >>>> ------------------ >>>> OPS4J - http://www.ops4j.org - [email protected] >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OPS4J" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> -- >>> ------------------ >>> OPS4J - http://www.ops4j.org - [email protected] >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OPS4J" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
