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]> 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]> 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]
>> >
>> > ---
>> > 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/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]
>>
>> ---
>> 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].
>> 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]
>
> ---
> 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].
> 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]
---
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ops4j/CAAdXmhop9sFb8FP8L2cy_S8GeT5x72v51ouNAaOD5Wxbgk21Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
