Hello Sure about separation and refresh-friendliness. No worries I won't make it worse ;)
regards Grzegorz Grzybek pt., 26 kwi 2019 o 08:49 Niclas Hedhman <[email protected]> napisał(a): > > The reason for Log4j original classes not used was very simple; Didn't > work. > > So, the underlying requirement that makes everything "trickier than > normal" is that you need to allow for the pax-logging-service to be > reloaded/replaced without stopping pax-logging-api, as that would in turn > stop everything else. AND that classes+classloader are correctly removed > from the JVM memory. > > So the "actually correct" might mean different to you, than it did to us... > > Niclas > > On Thu, Apr 25, 2019 at 11:26 PM Grzegorz Grzybek <[email protected]> > wrote: > >> Ah - fireplace stories ;) >> >> I'm continuing my work. It's a bit painful with log4j1. There's one jar >> (apache-log4j-extras duplicates the packages from log4j and adds some >> classes to some packages) and currently pax-logging-api exports these >> packages: >> - org.apache.log4j >> - org.apache.log4j.spi >> - org.apache.log4j.xml >> >> However, original log4j:log4j:1.2.17 jar is also proper OSGi bundle and >> exports more packages. >> And: >> - some classes from log4j included and exported by pax-logging-api use >> (in "uses" sens of Export-Package) classes from packages that are not >> exported >> - some shaded classes have simply removed methods (instead of for >> example changed to throw UnsupportedOperationException). >> - some classes, like org.apache.log4j.Category is included both in >> pax-logging-api *and* in pax-logging-service - completely different >> - LogManager doesn't work (similarly to a problem we have with >> PAXLOGGING-240) >> - some logging methods from org.apache.log4j.Category are reimplemented >> (to call super version) in org.apache.log4j.Logger to properly handle >> org.apache.log4j.spi.LocationInfo when detecting class/method/source file - >> but not all. If you call generic log() method, wrong LocationInfo is >> calculated. >> >> What I'm now doing is to properly split log4j (and apache-log4j-extras) >> classes between pax-logging-api and pax-logging-service, trying to make it >> both backward compatible *and* actually correct. >> Also I'm waiting for Imperator: Rome from Paradox - it'll be released in >> ~1 hour! >> >> regards >> Grzegorz Grzybek >> >> >> czw., 25 kwi 2019 o 17:04 Niclas Hedhman <[email protected]> napisał(a): >> >>> >>> :-) >>> >>> 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. >>> >> -- >> -- >> ------------------ >> 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.
