It's possible there's an issue with the shading going on. Ideally, log4j2
should be split into at least log4j-api and log4j-core, but pax-logging
shades them together for some reason.

On 25 May 2017 at 00:55, Jean-Baptiste Onofré <[email protected]> wrote:

> 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
>



-- 
Matt Sicker <[email protected]>

Reply via email to