Wouldn't DynamicImport-Package on core introduce some hard-to-find deadlocks? (bundle global lock in felix?)
regards Grzegorz śr., 22 maj 2019 o 13:21 Jean-Baptiste Onofré <[email protected]> napisał(a): > Hi, > > I'm not sure a fragment is required. I think a dynamic import on core > and some extra packages in extend should work. > > Regards > JB > > On 22/05/2019 13:01, Grzegorz Grzybek wrote: > > +1 for splitting log4j2. > > > > This pax-logging-log4j2-extend would be a fragment? > > > > regards > > Grzegorz Grzybek > > > > śr., 22 maj 2019 o 12:09 Jean-Baptiste Onofré <[email protected]> > napisał(a): > > > >> My plan is basically to split into parts. > >> > >> pax-logging-log4j2-core with the minimal packages/imports to work in > >> Karaf standard and pax-logging-log4j2-extend to the packages just > >> required for other appenders. > >> > >> Regards > >> JB > >> > >> On 22/05/2019 11:55, Grzegorz Grzybek wrote: > >>> Hello > >>> > >>> pon., 20 maj 2019 o 10:55 Eric Lilja <[email protected]> > napisał(a): > >>> > >>>> Ah, that's great news! Looking forward to see the improved Pax Logging > >> 1.x > >>>> in 4.2.x then > >>>> > >>> > >>> I'm using this plugin[1] to ensure that I keep similar headers as in > >>> 1.10.1. The refactoring changes are huge (moving private classes > between > >>> pax-logging-api and the "backends" for example), but user-facing > changes > >>> are not that big so even if I was thinking about 2.0, I agree that > there > >>> could be 1.11.0 with my changes. > >>> The most problematic is pax-logging-log4j2 which collects lots of > >>> Import-Package entries from all the log4j2 artifacts. Here's the list > >> from > >>> 1.10.1 (excluding the obvious javax.* and other that are really > >> required): > >>> > >>> – com.conversantmedia.util.concurrent > >>> – com.fasterxml.jackson.annotation > >>> – com.fasterxml.jackson.core > >>> – com.fasterxml.jackson.core.type > >>> – com.fasterxml.jackson.core.util > >>> – com.fasterxml.jackson.databind > >>> – com.fasterxml.jackson.databind.annotation > >>> – com.fasterxml.jackson.databind.deser.std > >>> – com.fasterxml.jackson.databind.module > >>> – com.fasterxml.jackson.databind.node > >>> – com.fasterxml.jackson.databind.ser > >>> – com.fasterxml.jackson.databind.ser.impl > >>> – com.fasterxml.jackson.databind.ser.std > >>> – com.fasterxml.jackson.dataformat.xml > >>> – com.fasterxml.jackson.dataformat.xml.annotation > >>> – com.fasterxml.jackson.dataformat.xml.util > >>> – com.fasterxml.jackson.dataformat.yaml > >>> – com.lmax.disruptor > >>> – com.lmax.disruptor.dsl > >>> – org.apache.commons.compress.compressors > >>> – org.apache.commons.compress.utils > >>> – org.apache.commons.csv > >>> – org.apache.kafka.clients.producer > >>> – org.codehaus.stax2 > >>> – org.fusesource.jansi > >>> – org.jctools.queues > >>> – org.zeromq > >>> > >>> I have an idea - to create additional pax-logging-log4j2-extra which > >> could > >>> be a fragment adding the above exports to original pax-logging-log4j2. > >> This > >>> way, "basic" pax-logging-log4j2 would be much less affected by > refreshes > >>> related to jackson or commons-*. > >>> > >>> regards > >>> Grzegorz Grzybek > >>> === > >>> [1]: > >>> > >> > https://ops4j1.jira.com/wiki/spaces/TOOLS/pages/412549134/OSGi+Report+Maven+Plugin > >>> > >>> > >>>> > >>>> - Eric L > >>>> > >>>> On Mon, May 20, 2019 at 10:25 AM Jean-Baptiste Onofré < > [email protected]> > >>>> wrote: > >>>> > >>>>> Ah yes, those ones will be applied on both Pax Logging 2.x and 1.x. > >>>>> > >>>>> Regards > >>>>> JB > >>>>> > >>>>> On 20/05/2019 10:01, Eric Lilja wrote: > >>>>>> Sorry, I was unclear, I most thinking about the refactorings I've > >> heard > >>>>> of > >>>>>> to reduce the number of optional imports (which would reduce > >> refreshes) > >>>>> and > >>>>>> better class layout in general in the api/impl-bundles. Are these > >>>>>> improvements dependent on R7? > >>>>>> > >>>>>> - Eric L > >>>>>> > >>>>>> On Mon, May 20, 2019 at 9:58 AM Jean-Baptiste Onofré < > [email protected] > >>> > >>>>>> wrote: > >>>>>> > >>>>>>> No, Pax Logging improvements with OSGi R7 will go into 4.3.x. > >>>>>>> > >>>>>>> Regards > >>>>>>> JB > >>>>>>> > >>>>>>> On 20/05/2019 09:29, Eric Lilja wrote: > >>>>>>>> Sounds exciting! Will the improvements to pax logging make it to > >>>> 4.2.x > >>>>>>>> release train? > >>>>>>>> > >>>>>>>> - Eric L > >>>>>>>> > >>>>>>>> On Mon, May 20, 2019 at 7:47 AM Jean-Baptiste Onofré < > >>>> [email protected]> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi guys, > >>>>>>>>> > >>>>>>>>> FYI, I'm completing the preparation of Karaf 4.2.6 today. I hope > to > >>>>>>>>> submit this release to vote tomorrow or Wednesday. > >>>>>>>>> > >>>>>>>>> In the mean time, we are moving forward on third party projects > >>>>>>>>> (especially Pax*) to be OSGi R7 compliant. > >>>>>>>>> I'm also doing some preparation steps on Karaf master to prepare > >> the > >>>>>>>>> OSGi R7 upgrade. > >>>>>>>>> I think I will be able to cut a RC1 beginning of next week. > >>>>>>>>> > >>>>>>>>> Stay tuned ! > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> JB > >>>>>>>>> -- > >>>>>>>>> Jean-Baptiste Onofré > >>>>>>>>> [email protected] > >>>>>>>>> http://blog.nanthrax.net > >>>>>>>>> Talend - http://www.talend.com > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Jean-Baptiste Onofré > >>>>>>> [email protected] > >>>>>>> http://blog.nanthrax.net > >>>>>>> Talend - http://www.talend.com > >>>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> Jean-Baptiste Onofré > >>>>> [email protected] > >>>>> http://blog.nanthrax.net > >>>>> Talend - http://www.talend.com > >>>>> > >>>> > >>> > >> > >> -- > >> Jean-Baptiste Onofré > >> [email protected] > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > >> > > > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
