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 logging.properties 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 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)
(the people behind jetty and cometd)
On Tue, Oct 11, 2011 at 12:23 AM, Alan Williamson (aw2.0 cloud experts) <alan@xxxxxxxxxx>
@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