I'd like to propose that we consider adding a simplistic juli log filter class to log4j 1.2. Since it needs to compile with jdk 1.4, we'd probably have to create a separate jar for this, perhaps a new log4j-juli sandbox module. We could update all *Configurator classes to detect if this bridge is available, and expose a new property on the configurators such as public void setUseJDK14LoggingBridge(boolean true) (or better name). This could throw an IllegalStateException if the underlying OS is not JDK 1.4 or above, and the juli-bridge classes are not available. That way a simple bridge could be provided to our user community by them doing: * Downloading and adding a single additional jar to log4j * Using the latest log4j 1.2.15 (say) * Adding a single method call to their Configurator usage Perhaps as an added bonus, adding support to the XML/Properties configuration to allow that <log4j:configuration debug="false" threshold="debug" useJDK14LoggingBridge="true"....>
Revisions 531719 and 531720 committed to the log4j sandbox area a working version of a bridge with simple test cases. Only the LocationInfo to do, I think. URL: http://svn.apache.org/repos/asf/logging/sandbox/juli-to-log4j-bridge/ I created a Maven pom.xml, but I'm still new to Maven, so tread carefully.. :) Comments and code review most welcome.
That may be wise to provide a Handler as well as a Filter if someone doesn't want to route exclusively the messages to log4j.
(In reply to comment #2) > That may be wise to provide a Handler as well as a Filter if someone doesn't > want to route exclusively the messages to log4j. Yes, a good point. I'll add some flexibility there.
Another thought, the level conversion should support custom levels. Currently if I define a FATAL level above the SEVERE level, it'll turn into a DEBUG log4j level. The best would be to compare the value of the level.
This is why I created the LevelConverter interface. You can simply create your own mapping. Having said that, I should take a look at the numeric values of the Level object and use that as a basis, that probably does make more sense than simply defaulting to DEBUG if the standard mapping doesn't work. thanks.
I've done some more updates, and added an 'assimilate' mechanism that completely takes over juli. On the issue of the Filter, I've decided that the 'bridge' mechanism (alternative to 'assimilate'), delegates to an existing Filter if already configured on the logger, or returns 'true' which effectively acts like a null-Filter. This eliminates (I think) the impact on existing juli configuration. I think having both bridge and assimilate mechanisms works for the use cases I can think of. Be keen to get feedback on that though.
A minor detail, from the standpoint of a java.util.logging user, I think the handler would be better named Log4JHandler since it's a handler that delegates the work to Log4J.
Yes, that's probably better. I'm going to review the naming. I started calling things JULI, which I believed to be the generic term for java.util.logging, but it turns out that that's a library already developed by the Tomcat team. So quite a bit of renaming to do... On a related note, we'll be moving the contents of this project inside the log4j-receivers module, because it is effectively just that, a Receiver that imports LoggingEvents into log4j. I'll be adding a log4j plugin that does the assimilation as part of the log4j configuration.
Firstly, 'reassigning' this bug back to log4j-dev@logging.apache.org so that comments are seen on the list. That was my bad. I have renamed the module to be 'jul-to-log4j-bridge', and renamed the classes to match 'JUL' instead of 'juli' to avoid confusion. We have not merged this module into the log4j-receivers module because the bridge requires JDK 1.4, but the rest of the receivers do not. I've added a log4j Receiver, so that one can configure the bridge using XML configuration (requires log4j 1.2.15 though, not yet released). http://svn.apache.org/repos/asf/logging/sandbox/jul-to-log4j-bridge/README.txt There is still a maven weirdness whereby the unit tests do not pass, because somehow maven is putting log4j 1.2.14 on the classpath instead of 1.2.15. The 'ant test' does pass though. That is still under investigation.
Incidentally for the watchers of this bug, latest viewable snapshot available here: http://people.apache.org/~psmith/logging.apache.org/repo/org/apache/logging/apache-jul-log4j-bridge/1.0.0-SNAPSHOT/ Website docs here: http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/
What's the status on this issue ? I see that log4j 1.2.15 has been released but the bug is still open. Do we have the java.util.Logging bridge in the latest release of log4j ?
We have had one 'customer' report successful usage of this module, and working towards a release (other log4j sub-modules considered a priority). If you were able to try out the latest snapshot and confirm it works for your use cases it would encourage us that this module is stable enough as a release worthy. That would help a lot.
I don't think it is a good idea to replicate the work that has been done with slf4j regarding gluing logging frameworks together. I believe they have functional log4j and j.u.l bridges, and that log4j should only concentrate on log4j stuff.
(In reply to comment #13) > I don't think it is a good idea to replicate the work that has been done with > slf4j regarding gluing logging frameworks together. I believe they have > functional log4j and j.u.l bridges, and that log4j should only concentrate on > log4j stuff. > That's a pretty fair point actually!
As you want, that's a small and useful feature though, but as long as an alternative exists that's fine. Paul's implementation has an interesting advantage, the redirection can be simply declared in an external configuration file. the SL4J bridge requires to change the code to call SLF4JHandler.install(). The declarative approach is better IMHO, it's less intrusive and doesn't require to recompile its code to enable the redirection. (btw I'm not a SL4J expert, I may have missed a similar feature).
(In reply to comment #15) > As you want, that's a small and useful feature though, but as long as an > alternative exists that's fine. > > Paul's implementation has an interesting advantage, the redirection can be > simply declared in an external configuration file. the SL4J bridge requires to > change the code to call SLF4JHandler.install(). The declarative approach is > better IMHO, it's less intrusive and doesn't require to recompile its code to > enable the redirection. (btw I'm not a SL4J expert, I may have missed a similar > feature). There can never be enough free software :) As other code in log4j-core needs Java 1.4+ to compile I see no reason why this could not go in the core distribution. Can we still support Java 1.1 even when compiling with a Java 1.5 compiler?
> As other code in log4j-core needs Java 1.4+ to compile I see no reason why this > could not go in the core distribution. Can we still support Java 1.1 even when > compiling with a Java 1.5 compiler? eh? If there is log4j-core code that needs Java 1.4 to compile, then we've made a mistake somewhere. I believe log4j 1.2.x series is designed to be Java 1.2 source compatible? (perhaps no-one cares anymore and no-ones noticed).
Clearing NEEDINFO since it isn't appropriate for this bug. It should only be used when it is impossible to understand the bug due to missing info. It should not be used to try to grab the attention of developers since it would have exactly the opposite effect. NEEDINFO bugs go to the bottom of the list until the reporter (or someone else who has or understands the problem) provide the missing INFO. Release preparations require JDK 1.4 since Maven requires JDK 1.4, however the bytecode generated in JRE 1.1 compatible. However, log4j.jar can alternatively be built using Ant on JDK 1.3 (again targeting JRE 1.1 bytecode). Last I checked, unit tests could be run on JRE 1.2, it just couldn't be built there due to known compiler problems with JDK 1.2 (and would require an older version of Ant). If I remember correctly, JDK 1.5's javac had problems producing JDK 1.1 compatible bytecode. Anyway, anything "cutting edge", "experimental" or controversial, should not be in log4j.jar. The release cycles are too slow for anything rapidly evolving. If we can't get people to test this as its own log4j companion, we definitely shouldn't push it into log4j and force people to consume it and also freeze our ability to change it.
Is there any updates on this topic? Is help needed? I have been using this component for quite some time now, most notably as a mean to nicely format the JUL messages in my test cases without touching the code. An official release in the central Maven repository, either as an independent component or as part of the core distribution, would be very welcome. For the record here is how I use the bridge to format the log messages in my tests, in the Maven POM I put this: <dependencies> <dependency> <groupId>org.apache.logging</groupId> <artifactId>apache-jul-log4j-bridge</artifactId> <version>1.0.0-SNAPSHOT</version> <scope>test</scope> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.16</version> <scope>test</scope> </dependency> </dependencies> <plugin> <artifactId>maven-surefire-plugin</artifactId> <configuration> <systemProperties> <property> <name>java.util.logging.manager</name> <value>org.apache.logging.julbridge.JULBridgeLogManager</value> </property> <property> <name>log4j.configuration</name> <value>log4j.properties</value> </property> </systemProperties> </configuration> </plugin> <plugin> <artifactId>maven-antrun-plugin</artifactId> <executions> <execution> <phase>generate-test-sources</phase> <goals><goal>run</goal></goals> <configuration> <tasks> <mkdir dir="target/test-classes"/> <echo file="target/test-classes/log4j.properties"> # log4j configuration for test cases log4j.rootLogger=INFO, console log4j.logger.com.arianesoftware=INFO log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern=[%d{HH:mm:ss}] [%p] %x %m%n </echo> </tasks> </configuration> </execution> </executions> </plugin>