Wednesday, 8 December 2010

JBoss - separating application logs without using monolithic jboss-log4j.xml

A minor irritant we've discovered in implementing applications for Jboss AS is that that the logging configuration for applications has to go through their monolithic jboss-log4j.xml file.

So we've managed to find a work-around (after some investigation of the Jboss class loaders and some trial and error).  This technique has been confirmed for jboss-eap-4.3 and jboss-4.2.3.GA but will likely work for other versions.

If you want to have split application logs and have that log4j.xml based configuration separated out (e.g. Not have it all in the jboss-log4j.xml file) then you can do the following.

1.) Your WAR/EAR must contain log4j-1.2.16.jar. It must be 1.2.16 or later as earlier versions don't work.

2.) The class loading for that WAR or EAR must have its java2ParentDelegation=false. So for example the jboss-app.xml file will look something like this:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-app PUBLIC
      "-//JBoss//DTD J2EE Application 1.4//EN"
      "http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd">
<jboss-app>
  <loader-repository>${your domain}:archive=${your app name}.ear
    <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
  </loader-repository>
</jboss-app>

Now this means that the WAR/EAR will use the log4j-1.2.16.jar for logging within its own classloader, i.e. It will not use Jboss's log4j.jar library (and therefore the jboss-log4j.xml won't be used).

3.) In the MANIFEST.MF file in your WAR/EAR archive you need to set a Class-Path: entry that shows the location (directory) where the log4j.xml file that you want to use will reside. For example if your EAR file is deployed in the deploy directory, your Class-Path reference might be something like this:

Class-Path: ../conf/log/${application name}/

4.) Your log4j.xml file should just be an ordinary one, with no references to any special jboss classes. However, it will have an appender with the specifc name for the log file for the application you want to log for, e.g.


  <appender name="${module.name}" class="org.apache.log4j.RollingFileAppender">
    <param name="File" value="${jboss.server.home.dir}/log/${module.name}.log"/>
    <param name="Threshold" value="INFO"/>
    <param name="Append" value="true"/>
    <param name="MaxFileSize" value="2MB"/>
    <param name="MaxBackupIndex" value="20"/>
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern" value="%d{yyyyMMdd HH:mm:ss.SSS} %-5p [%t] %C{1}.%M(): %x %m%n"/>
    </layout>
  </appender>

5.) OPTIONAL: You can still have all of your logging also go to the shared central $JBOSS_HOME/${instance}/log/server.log file by adding the following to your log4j.xml file:


  <appender name="all" class="org.apache.log4j.RollingFileAppender">
    <param name="File" value="${jboss.server.home.dir}/log/server.log"/>
    <param name="Threshold" value="INFO"/>
    <param name="Append" value="true"/>
    <param name="MaxFileSize" value="2MB"/>
    <param name="MaxBackupIndex" value="20"/>
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern" value="%d{yyyyMMdd HH:mm:ss.SSS} %-5p [%t] %C{1}.%M(): %x %m%n"/>
    </layout>
  </appender>

I've updated the Jboss community wiki with this information (thanks for pointing out the location Jaikiran!).

Tuesday, 16 November 2010

Java is dead, long live the Java developer! - Part II


Hi all,
This is an updated post based on the recent announcements and events in November, enjoy!

Well, what a few months it has been in the Java space!  It started with Oracle announcing that the best plan to move the Java language forward was to split the existing openJDK work into Java 7 (for summer 2011), followed by a Java 8 (for summer 2012?).  You can see the current feature list for JDK7 at http://openjdk.java.net/projects/jdk7/features/.  Now that a decision has been made I think we'll see some good progress on this front.

This of course threw our plans for the book into a bit of a spin and so Ben Evans and I are now writing "The Well-Grounded Java Developer (covers Java 7)", a subtle yet important shift in the emphasis for the book.  This has caused some material to be thrown out (bye bye Date and Time, Closures and more) and other bits to be re-written.  If you're interested in the book or what is going on with Java 7, then head on over to http://www.java7developer.com for more details!

But that of course was not all!

The Oracle vs Google lawsuit continues to gather pace with Google counter suing Oracle.  It's watch this space for everyone at the moment, but it seems that at this stage the lawyers are going to be kept rather (happily one suspects) busy.  Another recent paper filed by Google appears to be a multi-layered defence, no quick resolution here then.  You can keep an eye on this over at groklaw

Oracle also announced a partnership with IBM in terms of developing the openJDK, a bit of a coup for Oracle, but understandably there was some backlash as the Java community as a whole realised that the formerly IBM backed Apache Harmony and all it stood for (a truly open Java) was effectively doomed.  This has been well covered in the blogosphere, so I'll leave it at that (repeat after me "pragmatic").

Then came some JCP nomination and election hooha!  Some prominent people have sadly left (Doug Lea foremost amongst them) and there are also accusations flying about the JCP election process being gamed somewhat.

Apple stated that they would no longer be providing their own version of Java for Mac OS 10.7 and beyond.  However, much to the relief of the Java community they then announced that they were gifting a vast majority of their work to the OpenJDK and would help Oracle integrate that.  So although the steward has changed, it's still likely we'll get a first class Java on the Mac.  I guess I'll buy a Macbook pro after all.

Last but not least we have the Apache foundation vs Oracle battle.  Remember the bit about Apache Harmony above?  Apache wrote a public letter thanking IBM for their efforts, it was all very professional and seemed as amicable as possible. However, they then went on to bluntly tell Oracle that they would vote against the JSR for Java 7 SE unless Harmony was granted access to the TCK without restrictions.  Yo can follow the conversation roughly via the links below

Apache's opening salvo --> Oracle's response --> Apache's response

So we have IBM, Apple and Oracle all pretty much playing in the openJDK/Java 7 sandpit, with Google and Apache firmly on the outer, still some interesting times ahead.

Are we there yet?
All in all this has of course led to many pundits claiming that Java is dying if not dead already.  I disagree with that assessment, but with a bit of a twist.

On the enterprise side of things I think that Java will continue to have a strong presence, especially now that the JVM ecosystem has matured and allowed languages such as Clojure, Scala and Groovy to flourish.  This is one of the cruxes that "The Well-Grounded Java 7 Developer" falls on.

On the desktop I think that JavaFX 2.0 may have come too late to the party and certainly Swing is looking very aged as a relevant desktop client library.

Mobile?  This is probably the big one for the future, we'll have to wait and see what the Google and Oracle lawsuit brings out. Android is 'Java based' and has moved well ahead in terms of mind share (if not devices) over J2ME. If it at least remains 'Java based', then the Java language will continue to do well in this space, especially when all the new young developers continue to build software for the Android.  If not, we may see a move towards Java (& JVM langauges) being seen purely as a specialised server side language.

Java's not dead - it's just got new plumage and there's _plenty_ of excitement for the 'Java' developer :)