Hello
One of the reasons was that these pax-logging bundles usually start very
early. In Karaf they're in "startup" stage (== etc/startup.properties),
thus starting before even Features Service start.
That's how it worked since always and I didn't mean to change it.
regards
Grzegorz Grzybek
pt., 24 maj 2019 o 10:36 'Christoph Läubrich' via OPS4J
<[email protected] <mailto:[email protected]>> napisał(a):
But there is no need for starting these bundles. If you don't start
them
the activator won't be executed but pax-logging can still use the
classes from them.
And if there are still issues, why not fix them in log4j instead of
providing an own repacked version?
I just wan't to point out that instead of embedding required classes
for
pax-logging just importing the packages with proper version range would
be better. pax-logging can still provide the required service/spi on
top
of it.
Am 24.05.19 um 06:51 schrieb Grzegorz Grzybek:
> Hello
>
> Yes - in ideal world, every jar in Maven Central should be OSGi
bundle
> and every closure of dependencies should be consistent.
> Also, everyone forced to use OSGi hates it and switches to beautiful
> one-line µservices written in go-lang.
> </sarcasm>
>
> org.apache.logging.log4j:log4j-api and log4j-core (log4j2) are
indeed
> OSGi bundles, but with own activators that do something not
related to
> pax-logging.
> Also nothing in Log4J2 implements org.osgi.service.log.LogService.
>
> log4j-core does for example this:
>
> private static void scanInstalledBundlesForPlugins(final
BundleContext
> context) {
> final Bundle[] bundles = context.getBundles();
> for (final Bundle bundle : bundles) {
> * // TODO: bundle state can change during this*
> scanBundleForPlugins(bundle);
> }
> }
>
> As for pax-logging, Niclas - since last email I wrote >60
integration
> tests that check various assumptions you probably made when starting
> this project. There are tests for example that check how a piece
of code
> using loggers from different frameworks/facades (JCL, JUL, Slf4J,
JULI,
> Avalon, Log4j1 "api", ...) behaves when pax-logging-api or
> pax-logging-<backend> (or both) bundles are restarted/refreshed.
> There are tests for extending log4j1/logback (log4j2 tests coming
soon)
> via org.ops4j.pax.logging.spi interfaces or via fragments that just
> contain e.g., classes inheriting the Appender interface(s) (or
filters,
> or error handlers, or layouts).
>
> I'm getting more confident about pax-logging architecture and
approach.
>
> Soon we'll (Jean Baptiste Onofre is working on it) get R7 support
> (org.osgi.service.log 1.4).
>
> Whether or not this goal has been maintained is unknown to me, I
> don't know if it stills hold true for the original
implementation,
> and no idea if the log4j2 and logback impls have tried.
>
>
> It holds. Both for log4j1 and logback and I'm just finishing to
ensure
> that it's working for log4j2 too.
> Private-Packaging without exporting of classes from "impl" jars
(indeed
> it wasn't easy with log4j1) was and still is (IMO) good idea.
>
> The fact that something is OSGi bundle, doesn't mean that original
> author took care of everything. For example log4j2 has "log4j-osgi"
> subproject, but it's simply:
> - org.apache.logging.log4j.osgi.tests.felix.FelixLoadApiBundleTest
> -
org.apache.logging.log4j.osgi.tests.equinox.EquinoxLoadApiBundleTest
>
> both these "tests" just install log4j-api, log4j-core,
log4j-samples and
> log4j-1.2-api.
>
> best regards
> Grzegorz Grzybek
>
> pt., 24 maj 2019 o 04:13 Niclas Hedhman <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> napisał(a):
>
>
> Just because someone added a BND descriptor to Maven/Gradle,
doesn't
> mean that the library is OSGi-capable, let alone OSGi-friendly.
> Please see https://articles.qos.ch/classloader.html for the
starting
> point, and although the article discusses Java EE
classloading, the
> OSGi scenario isn't any better for many libraries out there. Pax
> Logging made an attempt at overcoming the issues for all logging
> frameworks when running in OSGi, and it was a particularly
> meticulous beginning, when I ensured that nothing was left
behind in
> the class space and that one should even be able to replace the
> pax-logging-service without stopping all the bundles, i.e.
the whole
> app. Whether or not this goal has been maintained is unknown
to me,
> I don't know if it stills hold true for the original
implementation,
> and no idea if the log4j2 and logback impls have tried.
>
> Almost all the 'embedding', and more importantly the
replacements,
> have origins in the above.
>
> Niclas
>
> On Thu, May 23, 2019 at 2:50 PM 'Christoph Läubrich' via OPS4J
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> WHat is teh reason for merging the META-INF at all?
> Beside that why embeeed log4j at all if it is already an OSGi
> Bundle?
>
> I think that people do embeed a way to much stuff in the OSGi
> world that
> does not make sense. Embedding should only be used if the
lib is
> not an
> OSGi-Jar (where I prefere to open a PR on the project ot
add the
> required headers).
> In all other cases a proper version import does the job
much better
> beside the fact that embedding might cuase problems with
> licensing and
> maintaining stuff (e.g. security updates).
>
> Am 22.05.19 um 17:21 schrieb Grzegorz Grzybek:
> > Hello
> >
> > (sorry for writing to two mailing lists, but I think it's
> important).
> >
> > I've just found nasty problem.
> >
> > After having lots of fun with pax-logging-service and
> > pax-logging-logback I wanted to clean up
pax-logging-log4j2.
> But I found
> > that original, already available pax-logging-log4j2 bundle
> actually has
> > Export-Package header (pax-logging-service and
> pax-logging-logback don't
> > export anything).
> >
> > The strange thing was that all bundles have:
> >
> > Export-Package: \
> > !*
> >
> > The difference is that pax-logging-log4j2 additionally has
> >
>
<https://github.com/ops4j/org.ops4j.pax.logging/blob/b8c9137/pax-logging-log4j2/osgi.bnd#L5>:
> >
> > Private-Package: \
> > ...
> > META-INF; -split-package:=merge-first, \
> > ...
> >
> > So it ... took the META-INF/MANIFEST.MF from
> > org.apache.logging.log4j:log4j-core. It wouldn't be a
problem if
> > pax-logging-log4j2 exported something - even single
package.
> >
> > Here's why
> >
>
<https://github.com/bndtools/bnd/blob/4.2.0.REL/biz.aQute.bndlib/src/aQute/bnd/osgi/Analyzer.java#L1063-L1065>
>
> > (aQute.lib.osgi.Analyzer#calcManifest()):
> >
> > // Copy old values into new manifest, when they
> > // exist in the old one, but not in the new one
> > merge(manifest, dot.getManifest());
> >
> > pax-logging-log4j2 bundle didn't have any
Export-Package (as
> intended),
> > so it just inherited it from
org.apache.logging.log4j:log4j-core
> > (definitely *not* as intended...).
> >
> > This is related to
> https://ops4j1.jira.com/browse/PAXLOGGING-240 and the
> > discussion here[1].
> >
> > To be honest, the only thing I think is sensible here
is to stop
> > exporting anything from pax-logging-log4j2... Extensions
> should be done
> > via fragments or pax-logging-api's
org.ops4j.pax.logging.spi
> interfaces
> > (like PaxAppender).
> >
> > WDYT?
> >
> > regards
> > Grzegorz Grzybek
> > ===
> > [1]:
> https://groups.google.com/forum/#!msg/ops4j/yjqOzvrKRkc/t5BXmfyoBgAJ
> >
> > --
> > --
> > ------------------
> > OPS4J - http://www.ops4j.org - [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[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]
<mailto:ops4j%[email protected]>
> <mailto:ops4j%[email protected]
<mailto:ops4j%[email protected]>>
> > <mailto:[email protected]
<mailto:ops4j%[email protected]>
> <mailto:ops4j%[email protected]
<mailto:ops4j%[email protected]>>>.
> > To view this discussion on the web visit
> >
>
https://groups.google.com/d/msgid/ops4j/CAAdXmhr1W2_3y56mpUUiErHFgKs13jFb2bd4CoC0rvcfaE9M8A%40mail.gmail.com
>
> >
>
<https://groups.google.com/d/msgid/ops4j/CAAdXmhr1W2_3y56mpUUiErHFgKs13jFb2bd4CoC0rvcfaE9M8A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> > For more options, visit
https://groups.google.com/d/optout.
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org - [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[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]
<mailto:ops4j%[email protected]>
> <mailto:ops4j%[email protected]
<mailto:ops4j%[email protected]>>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/ops4j/39649881-6014-cf4b-323c-dfcf045f35a5%40googlemail.com.
> 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]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[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]
<mailto:ops4j%[email protected]>
> <mailto:[email protected]
<mailto:ops4j%[email protected]>>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/ops4j/CADmm%2BKf1FMysGrKFMM4DqTTKbsxx9skXDf8yZUPnF_tCMdYfUg%40mail.gmail.com
>
<https://groups.google.com/d/msgid/ops4j/CADmm%2BKf1FMysGrKFMM4DqTTKbsxx9skXDf8yZUPnF_tCMdYfUg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org - [email protected]
<mailto:[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]
<mailto:ops4j%[email protected]>
> <mailto:[email protected]
<mailto:ops4j%[email protected]>>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/ops4j/CAAdXmhop9sFb8FP8L2cy_S8GeT5x72v51ouNAaOD5Wxbgk21Kw%40mail.gmail.com
>
<https://groups.google.com/d/msgid/ops4j/CAAdXmhop9sFb8FP8L2cy_S8GeT5x72v51ouNAaOD5Wxbgk21Kw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
--
--
------------------
OPS4J - http://www.ops4j.org - [email protected]
<mailto:[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]
<mailto:ops4j%[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ops4j/0b5bffa8-4254-f955-2529-9211e37276be%40googlemail.com.
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]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ops4j/CAAdXmhpA%2B2TW4zKZ_TWb_5S3GPM-cf%2BNu04sG5a8FxCdG4EY%3DQ%40mail.gmail.com
<https://groups.google.com/d/msgid/ops4j/CAAdXmhpA%2B2TW4zKZ_TWb_5S3GPM-cf%2BNu04sG5a8FxCdG4EY%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
