Yes, if you can figure anything out, that'd be great! On 24 May 2017 at 19:38, James Carman <[email protected]> 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]> > > > -- Matt Sicker <[email protected]>
