I'm more familiar with log4j myself. However, OSGi issues with Spring seem
to be a common issue thanks to Spring snubbing OSGi for a while. Chances
are that this has improved a bit in Spring 5 thanks to Java 9 modules
forcing them to embrace modularity again, though that doesn't help in this
scenar
Hi Matt,
Thanks for guiding on Same like pax-logging-service issue. we are in good
shape for that.
same like that, earlier org.springframework libraries were also downloaded
and started when we were running the package. we were defining these as
bootfeatures during prepare package.
org.apache.ka
The plugin docs for log4j2 itself [1] covers more about it. If you’re
trying to extend an existing appender, you’ll have to extend its
corresponding manager class instead (an appender in v2 is more of a
configuration mechanism while the manager handles the underlying data
sink). I’d also suggest di
Hello JB,
As you suggested and mentioned like that "If so, you should update your
appender to log4j2 style and attach to pax-logging-log4j2".
I was trying to do that but it seems creating custom appenders is very
different here. earlier I was extending fileappenders and providing
configuration pa
Hi,
Yes it looks creating a custom appender is very different with log4j2 and
not like that with log4j1 where we were using pax-logging-service as
fragment-host with our custom bundle.
we don't have AppenderSkeleton class also here.
how shall i approach it now? do we have any adapter kind of
Hi,
Yes it looks creating a custom appender is very different with log4j2 and
not like that with log4j1 where we were using pax-logging-service as
fragment-host with our custom bundle.
we don't have AppenderSkeleton class also here.
how shall i approach it now? do we have any adapter kind of thi
If you have a custom log4j 1 appender, there's limited support in
log4j-1.2-api which you can add on to the log4j2 stuff, though I'm not sure
how that would interact without some fragment hackery.
On 2 March 2018 at 03:34, Jean-Baptiste Onofré wrote:
> Thanks, please let me know if you have any
Thanks JB.
I will try and get back with results.
Regards
Munish
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
Thanks, please let me know if you have any issue.
Regards
JB
On 03/02/2018 10:33 AM, munishgupta.asr wrote:
> Thanks JB.
>
> I will try and get back with results.
>
> Regards
> Munish
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>
--
Jean-Baptiste Onof
Hi,
no need to deal with logback (that's another layer).
Correct for log4j2 attachment & style.
Regards
JB
On 03/02/2018 10:20 AM, munishgupta.asr wrote:
> Thanks for the quick response.
>
> we are extending the org.apache.log4j.FileAppender and
> org.apache.log4j.nt.NTEventLogAppender.
> for
Thanks for the quick response.
we are extending the org.apache.log4j.FileAppender and
org.apache.log4j.nt.NTEventLogAppender.
for now, my fragment pom file is using service as host bundle.
${project.artifactId}
${project.groupId}.${project.artifactId}
Hi,
As we switched to log4j2 configuration style, we now use pax-logging-log4j2.
pax-logging-log4j2 replaces the pax-logging-service (log4j1 style)
implementation of pax-logging-api.
I guess you use a fragment to use a log4j appender ?
If so, you should update your appender to log4j2 style and
Hi All,
for our project, we are using KARAF 4.0.9 for now and decided to upgrade it
to 4.1.5.
we have a customer appender which is used as a fragment with
pax-logging-service bundle.
After upgrading to KARAF 4.1.5, it is failing to find pax-logging-service
and service is not getting downloaded i
13 matches
Mail list logo
