Custom Logging in Seam

[ucfjeff]

Can one provide a custom implementation of the interface org.jboss.seam.log.Log and have it injected via @Logger? If so how?

[gavin.king]

No, not at present (the reason for this is that we use Logging outside of Seam contexts, so I can't make Logging a Seam component).

Why do you want to do that?

[matt.drees]

I'm fairly sure you can't. Not without patching Seam.

[matt.drees]

oops, didn't see Gavin's reply. My bad.

[ucfjeff]

We have a custom log implementation that wraps log4j. It collects extra application (appID, serverName, etc) and session data (sessionID, customerID, etc) for analysis while staying as close to the log4j style as possible.

For convienence and standardization we wanted to use the @Logger annotation in our new Seam apps.

I suppose we can inject our logger as a Seam class, but we will lose the ability to use EL expressions in our log Strings.

Perhaps we can come up with a clever way to use Seam logging and collect said data.

[matt.drees]

Here's an idea.

I'm not a log4j guru, but it looks like you can specify a LoggerFactory in your log4j config file. So, maybe you can adapt/wrap your custom log impl as a log4j Logger, and make a LoggerFactory that produces those instead of the vanilla Logger objects.

So, solve the problem completely above Seam.

[matt.drees]

Here's another (probably bad) idea.

Create a Seam interceptor that looks for a @Logger field and replaces the default Log instance with yours.

Of course, your stack traces are that much bigger and maybe method calls are a tiny bit slower, and I think you might have to annotate all of your classes. But maybe there are ways around that.

[matt.drees]

At first I was thinking that you could create an observer for "org.jboss.seam.postCreate.*", but then I found out events don't handle wildcards.

Gavin, if you're still following this thread, are wildcard events a bad idea? I kinda like the thought...

[gavin.king]

"ucfjeff" wrote:
We have a custom log implementation that wraps log4j. It collects extra application (appID, serverName, etc) and session data (sessionID, customerID, etc) for analysis while staying as close to the log4j style as possible.

Why not just use the log4j NDC for this?

Here's an example from Seam CVS:

http://fisheye.jboss.com/browse/JBoss/jboss-seam/src/main/org/jboss/seam/web/LoggingFilter.java?r=1.2

[gavin.king]

"matt.drees" wrote:
At first I was thinking that you could create an observer for "org.jboss.seam.postCreate.*", but then I found out events don't handle wildcards.

Gavin, if you're still following this thread, are wildcard events a bad idea? I kinda like the thought...

Hum, I guess it could be interesting, but I want to see a truly compelling usecase first. (This is not one.)

[gavin.king]

"matt.drees" wrote:
Here's another (probably bad) idea.

Create a Seam interceptor that looks for a @Logger field and replaces the default Log instance with yours.

Of course, your stack traces are that much bigger and maybe method calls are a tiny bit slower, and I think you might have to annotate all of your classes. But maybe there are ways around that.

Yes, this is possible using an @PostConstruct interceptor.

Someday we really need to get around to allowing interceptors to be declared in components.xml, to save the need for an annotation.

[ucfjeff]

Thank you Matt and Gavin.

We have found that the log4j MDC will meet our requirements in the manner of the example provided by Gavin above.

Matt you are here in Orlando?

[matt.drees]

I am indeed. I take it you're at UCF?

[ucfjeff]

A long time ago. Local major corporation.

[matt.drees]

Cool. I may be looking for a job soon in the area, and it'd be great to be doing development in Seam. Could you email me at matt.drees at gmail dot com if there are any openings at your company? Thanks!