Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Logging Custom Handlers JUL

The ./lib/ext folder is also too late in the process to include the custom java.util.logging handlers.

You have a choice at this point.

1) Do not use LogManager.readConfiguration() but rather use the Logger.addHandler() technique instead.
     This means you cannot use the default facilities.
     This is due to the fact that by the time java.util.logging is initialized (one of the first thing the JVM does on startup) you don't have jetty yet started to even manage the classpath/classloaders.
      That means the ClassLoader that initialized the LogManager has no access to your custom handlers.

      I created an example project showing how to set this up, see
      (I need to blog about this)

2) Do not rely on default jetty's start.jar and write your own jetty bootstrapping that includes the custom logging handler in the startup classpath and then use the jetty-xml.jar to configure your jetty instance.

     There might be a configuration option around the --exec startup command (but I haven't researched that angle yet)

Joakim Erdfelt
joakim@xxxxxxxxxxx |
(the people behind jetty and cometd)

On Tue, Oct 11, 2011 at 12:23 AM, Alan Williamson (aw2.0 cloud experts) <alan@xxxxxxxxxx> wrote:
@Jan did you get a chance to have a look at this?

Very frustrating that Jetty is refusing to play with the j.u.l custom handlers.

Alan Williamson (aw2.0 cloud experts) wrote:
Sure Jan, here is the full trace:

I have put the necessary classes in the ./lib/ext/ folder

Jan Bartel wrote:

I wonder if j.u.l is expecting those classes to be on the system classpath, rather than a child classpath?

It would be helpful if you could post the rest of that stack trace too.

jetty-users mailing list

Back to the top