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.
