Hi guys,
I will take a look on this one. It sounds like a missing activator/fragment host
in pax-logging-log4jv2.
Regards
JB
On 05/25/2017 02:38 AM, James Carman wrote:
I can try to help if you guys want. Want me to tinker? I think we will
want to update the docs too, since folks will need to generate those dat
files.
On Wed, May 24, 2017 at 8:31 PM Matt Sicker <[email protected]> wrote:
Oh, well that certainly sounds like a problem! There's an activator in both
log4j-api and log4j-core from what I recall, so pax-logging might need
something custom as well.
On 24 May 2017 at 17:41, James Carman <[email protected]> wrote:
So, I've done a bit of digging. Log4j2 ships with an Activator that sets
up a BundleListener which scans (looks for Log4j2Plugins.dat files)
bundles
for any plugins to be registered. Since log4j itself is not loaded as a
bundle (it appears to be shaded into pax-logging-log4j2), that Activator
doesn't run. Perhaps we should delegate to Log4j's internal Activator
during the start() method of the Pax Logging Activator
(org.ops4j.pax.logging.log4j2.internal.Activator)? Do we cover this
behavior in some other way?
On Wed, May 24, 2017 at 3:32 PM James Carman <[email protected]
wrote:
So, am I way off base with my approach or anything? Should Karaf be
installing pax-logging-service? Or, is pax-logging-log4j2 taking its
place
for Karaf? Is there anything special we have to do to implement a
custom
Layout using pax-logging? Is there a working example I can use to
install
into karaf to see if it works for me?
On Wed, May 24, 2017 at 3:20 PM Matt Sicker <[email protected]> wrote:
I mostly work on Log4j2, though I try to answer questions about it on
ops4j
and karaf due to pax-logging.
On 24 May 2017 at 14:17, James Carman <[email protected]>
wrote:
I know. ;) And I meant no slight to you. I didn't know you were
one
of
the contributors these days. I have checked out the code and I'm
going
to
poke around a bit.
On Wed, May 24, 2017 at 3:15 PM Matt Sicker <[email protected]>
wrote:
That would be on the ops4j lists, though that's mostly the same
people as
here.
On 24 May 2017 at 13:31, James Carman <[email protected]
wrote:
I think I must be doing something wrong. Hopefully one of the
PAX
folks
can help here. I wonder if I should just reach out to them
directly or
if
this is a karaf-specific issue with PAX?
On Wed, May 24, 2017 at 2:29 PM Matt Sicker <[email protected]>
wrote:
At compile time, an annotation processor in log4j-core
generates a
.dat
file containing some metadata about scanned plugins. These JAR
resource
files are loaded at plugin scan time where reflection is used
to
investigate the classes and instantiate plugins based on
config
files.
Alternatively, there's an option you can set to scan a
particular
list
of
packages for additional plugins, though I think that uses the
context
ClassLoader which might not work properly in your scenario.
On 24 May 2017 at 11:22, James Carman <
[email protected]
wrote:
Any advice on how I might be able to fight my way through
it?
How
does
Log4j2 "discover" those @Plugin-annotated classes? Does it
use
some
form
of classpath scanning? Is it scoped to certain packages
only?
I'm
thinking I might have to attach to the pax-logging-log4j2
bundle
as a
host
in order to augment its classpath so that it can see my
stuff.
On Wed, May 24, 2017 at 12:20 PM Matt Sicker <
[email protected]>
wrote:
It could be a bug in log4j2 itself rather than
pax-logging.
I
worked
on
some OSGi support in log4j2 a while back, and I'm not sure
if
this
is a
new
issue or an existing one.
On 24 May 2017 at 05:43, James Carman <
[email protected]>
wrote:
I tried adding pax-logging-service to startup.properties
(after
putting
it
into the system repo) and I still have the issue. So,
the
ultimate
issue
isn't the fragment host necessarily. My issue is that it
can't
fine
my
custom layout class. I've tried using the name from the
@Plugin
annotation.
I've tried using the fully-qualified class name. Nothing
seems
to
work.
Here's the declaration of my layout:
@Plugin(name = "MyJsonLayout", category = Node.CATEGORY,
elementType
=
Layout.ELEMENT_TYPE, printObject = true)
public class MyJsonLayout extends AbstractStringLayout {
...
}
and here's what I've changed in the logging config file:
log4j2.rootLogger.appenderRef.RollingFile.ref =
RollingFile
# Rolling file appender
log4j2.appender.rolling.type = RollingRandomAccessFile
log4j2.appender.rolling.name = RollingFile
log4j2.appender.rolling.fileName =
${karaf.home}/log/aetos.log
log4j2.appender.rolling.filePattern =
${karaf.home}/log/aetos.log.%i
# uncomment to not force a disk flush
log4j2.appender.rolling.immediateFlush = false
log4j2.appender.rolling.append = true
log4j2.appender.rolling.layout.type =
com.myco.log4j.json.MyJsonLayout
log4j2.appender.rolling.policies.type = Policies
log4j2.appender.rolling.policies.size.type =
SizeBasedTriggeringPolicy
log4j2.appender.rolling.policies.size.size = 200MB
As I said, I tried just using layout.type =
MyJsonLayout,
but
that
doesn't
work either. Do we have an example where something like
this
works
that
I
can reverse engineer?
Thanks,
James
On Tue, May 23, 2017 at 7:03 PM James Carman <
[email protected]
wrote:
I am trying to use a custom layout and I'm following
the
examples
(I
think). We had one that worked in Karaf 3.0.x.
Anyway, I
set
up
the
fragment host like this:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.3.0</version>
<extensions>true</extensions>
<inherited>true</inherited>
<configuration>
<instructions>
<Fragment-Host>org.ops4j.pax.logging.pax-logging-service</
Fragment-Host>
</instructions>
</configuration>
</plugin>
However, my bundle will not resolve this way. I don't
see
that
bundle
being loaded in Karaf 4.1.1:
karaf@root()> list -t 0 -s | grep -i log 19:01:18
5 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-
logging-api
6 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-
logging-log4j2
36 │ Active │ 30 │ 4.1.1 │ org.apache.karaf.log.core
I tried binding to
"org.ops4j.pax.logging.pax-logging-api",
but
that
didn't work either. Did this process change for
4.1.x?
--
Matt Sicker <[email protected]>
--
Matt Sicker <[email protected]>
--
Matt Sicker <[email protected]>
--
Matt Sicker <[email protected]>
--
Matt Sicker <[email protected]>
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
