Meaningless Drivel is fun!*
The moose likes Java in General and the fly likes Overriding JULI Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Overriding JULI" Watch "Overriding JULI" New topic
Author

Overriding JULI

Graeme Woodhouse
Greenhorn

Joined: Jan 19, 2011
Posts: 12
Hello,

I've got a partially blackbox system which is using java.util.logging to log everything. I've had a major problem with this from the start as it seems completely incomprehensible (but thats an entirely different story).

But I've lately had an excuse to try and switch over to log4j so, since I can't change some of the classes I have instead done something very bad and overridden java.util.logging.Logger with my own class, keeping the same methods but plugging it into a log4j logger system to act as a facade.

But my application is ignoring my overridden class and is still loading the origional (even though the package/class is in the right place).

Is there something i don't know about java.util.* packages ?

Thanks for any help,

Graeme
Graeme Woodhouse
Greenhorn

Joined: Jan 19, 2011
Posts: 12
I should add, the Logger object is instanciated like so:



Which uses Logger's static method to create an instance of itself.
Graeme Woodhouse
Greenhorn

Joined: Jan 19, 2011
Posts: 12
Drat!

http://download.oracle.com/javase/tutorial/ext/basics/load.html

rt.jar is loaded as part of the bootstrap which contains the JULI logging implementation meaning my overriden class is waaaaaaaaay lower on the class loader heirarchy.

Don't suppose anyone can see a way around this? Otherwise i'll mark this question as resolved.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

What do you mean exactly by having "overridden" the java.util.logging.Logger class? Have you created your own subclass of that class? The system will not automatically pick up your own subclass when you do that.

And java.util.logging is a package which is indeed part of the standard Java class library, so you cannot replace it by your own version.

There is no easy way to replace classes in the standard library. If you really want to do this, you could do this with aspect oriented programming, for example with AspectJ. That will allow you to replace calls to the logging methods by your own code by replacing bytecode at runtime. But I'd only do that as a last resort - it's really a kind of ugly hack.

What is exactly the reason that you want to replace the java.util.logging in this blackbox system by Log4J? The features of java.util.logging are not that much different from Log4J, so I doubt that it will be really worth it to do this.

A good logging API is SLF4J. It's not a logger itself, but a facade that you use in your application and that you can plug in different loggers at the back end, such as Log4J and java.util.logging. The nice thing about SLF4J is that you can later decide to use a different logger without needing to replace anything in the program itself.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Hussein Baghdadi
clojure forum advocate
Bartender

Joined: Nov 08, 2003
Posts: 3476

And by the way, JULI acronym isn't popular and recognized among developers. I checked this post just because I don't know what JULI is.
Graeme Woodhouse
Greenhorn

Joined: Jan 19, 2011
Posts: 12
Some of the reasons i want to replace it is because even after reading the documentation and asking for help across the internet, I have yet to find someone who can explain how the handlers defined in the logging. Properties are used and why. (I don't want to get into that here).

BUT the real reason is that we have servers that need to be up 24/7 and therefore lock the logs files they're writing (Therefore i can't use a scheduler to wrap the file up afaik). A requirement has come through that we need logs split daily - but java.util.logging doesn't have functionality to do this. Searching the internet suggests that writing your own handler is going to be a fairy difficult/useless thing to do and most suggest switching to log4j.

But since i can't touch the source code, only the environment, i can't write new logging into the system. I was planning to override the entire class of Logger (By override i mean have the class / package load before the original meaning that my version is used by the source code). Obviously this is a terrible hack and to get it to work I’d have to modify rt.jar. (Do you ever get a feeling a little hack leads you to a bigger hack until you end up replacing core libraries with timebomb code?)

If anyone has any knowledge of how i can implement this that would be awesome but I’m a bit stuck atm.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

Graeme Woodhouse wrote:... to get it to work I’d have to modify rt.jar.

Don't do that; you'd be running your software on a non-standard, modified JVM. I'd never take such a risk on a production system. And I don't know the details, but I think that modifying the standard classes might not be allowed according to Oracle's license agreement for the JRE / JDK.
Graeme Woodhouse
Greenhorn

Joined: Jan 19, 2011
Posts: 12
So... What are my options?

Compiled classes using java.util.logging.Logger - Constantly running proccess which doesn't let the lock off of the log file, and need to implement daily rolling log files. I can't think of a way to do it with the above limitations.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

If you're looking for something to override, then here's what the Java™ Logging Overview says:

The API Documentation wrote:There is a single LogManager object that can be retrieved using the static LogManager.getLogManager method. This is created during LogManager initialization, based on a system property. This property allows container applications (such as EJB containers) to substitute their own subclass of LogManager in place of the default class.


For more such information follow the link from the bottom of the API documentation page for the java.util.logging package.
Graeme Woodhouse
Greenhorn

Joined: Jan 19, 2011
Posts: 12
The code I'm unable to change retreived the Logger object through this method:


public static Logger LOG = Logger.getLogger(LayoutController.class.getName());


Reading the source of java.util.logging i can confirm LogManager isn't included in the instantiation or main use of the Logger object. According to the documentation it is simply a vehical by which information is shared across Logger instances. Java.Util.Logging is simply not designed to be used as the core of a production system it seems.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Overriding JULI
 
Similar Threads
log4j working, but writing log file to wrong directory
Websphere 6.1 - Apache commons logging with log4j does not work
struts & Log4J
how to stop printing log in console?
log4j.properties not found