Trust me, I tried to make it work with the deliverables from Log4j v1 and
all of the APIs, and it was simply not possible, IF you maintain the goal
that reloading/replacing the logging service implementation should be
possible without stopping the entire application and without having memory
leaks
But you can still star them early, I don't see a reason why this should
not work...
Am 24.05.19 um 11:25 schrieb Grzegorz Grzybek:
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 start
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.,
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 in
pt., 24 maj 2019 o 08:48 Niclas Hedhman napisał(a):
>
> I have seen that you have done a lot of good work, and the only thing I
> can contribute nowadays is history/background and initial conditions/goals.
>
And I highly appreciate - those who don't know history are doomed to repeat
it ;)
regar
I have seen that you have done a lot of good work, and the only thing I can
contribute nowadays is history/background and initial conditions/goals.
Cheers
Niclas
On Fri, May 24, 2019 at 12:52 PM Grzegorz Grzybek
wrote:
> Hello
>
> Yes - in ideal world, every jar in Maven Central should be OSGi
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.
org.apache.logging.log4j:log4j-api and log4j-core (log4
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 bette
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
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 act
10 matches
Mail list logo
