Friday, 25 November 2011

Install JFreeChart 1.0.14 with Maven

After 2.5 years, JFreeChart came out with a new release of the toolkit on Nov 21,2011.Version 1.0.14 promises bug fixes, improvements in the TimeSeries graphing and much more. Over the last few years, JFreeChart has been a popular open source choice for charts and graphs in Java.  The previous version has been download close to 430,000 times and while there are not many examples available describing the usage of the toolkit, installing it and implementing it in a Java application is relatively pain free.
Currently, the Maven repositories have not been updated with this release and you will need to manually install it into your local repository. To do so:

  • Download the latest release from the source-forge download page. Unzip the jar onto your local file system to any directory, say C:\jFreeChart\jfreechart-1.0.14
  • Open a command prompt in the directory where you have your Maven POM located and invoke the following command from the command line:
  • mvn install:install-file -Dfile=C:\jFreeChart\jfreechart-1.0.14\lib\jfreechart-1.0.14.jar -DgroupId=jfree -DartifactId=jfreechart -Dversion=1.0.14 -Dpackaging=jar
This should install jFreeChart into your local Maven repository. Now you can add a dependency to the Maven POM as follows:

     jfree 
     jfreechart
     1.0.14 
     compile 
    

Saturday, 19 November 2011

Tomcat 7.0, JSF (Mojarra) 2.3.1 and PrimeFaces 3.0M4


Spent the last few nights experimenting with the bleeding edge of Java Server Faces (JSF), Prime Faces and Tomcat and expectedly came away bloody and a lot more wiser.

Java Server Faces has come a long way in the last 5 years or so but a steep learning curve and relatively poor documentation makes it even harder to adapt. The latest specification release of JSF is 2.1, compatible with JavaEE 6 application servers, or any server implementing Servlet 3.0.JSF has two main implementation flavours- Apache MyFaces and Sun (now Oracle 's) Mojarra.

Now herein lies the problem.There are some subtle differences between JSF 2.0 and 2.1 specifications as pointed out by BaluC. JSF 2.1 is aimed at marrying the Servlet 3.0 API and so targets Servlet Containers supporting the 3.0 specification, such as Tomcat 7.0, Glassfish v3. while JSF 2.0 was aimed at the Servlet specification 2.5 and so works well with earlier releases of the servers.

If you are intending to use the latest release of Tomcat which is 7.0.22 and JSF MyFaces, you should be fine but if you try and bring in a component library such as Tomahawk, you'll find that support for the > JSF 2.0 version of a JSF implementation is not all there.I decided to use PrimeFaces and went with 3.0M4, a milestone release from last week and while the setup and integration of the stack (Tomcat 7.0.22, MyFaces 2.3.1 (and later I removed MyFaces and bought in Mojarra) was smooth(Thanks to Maven), getting the FileUpload component of PrimeFaces to work was impossible. The fileUpload bean would just not get called and there were no errors in the server log. Baffling!!Questions to the user forum did not show much light until I came upon Bug 49711 related to annotation scanning in the Tomcat archives. The problem was not with PrimeFaces of a JSF implementation but with a regression of Tomcat's handling of a multi-part request. This problem was reported since version 7.0.6 and while there is an indication that setting allowCasualMultipartParsing = true in the Context definition will by-pass this issue, I can tell you otherwise. Anyway, I got it all to work with Tomcat 7.0.2 (i.e I had to go back 20 releases).

Tomcat version 7.0 onwards implements the Servlet 3.0 specification and brings in some new and very much needed features such as out-of-the box authentication support(via the HttpRequest) and FileUpload. This major leap forward could have possibly led to these regression defects that need to be addressed before Tomcat can be regarded as a stable candidate for implementing a JSF based stack. JSF (MyFaces & Mojarra) doesn't really help Tomcat in the sense that itself is in a state of evolution and the component libraries are struggling to keep up.

To end on a positive note, I was very impressed by the PrimeFaces showcase and the extensive set of features offered which currently makes it one of the best JSF component libraries going around.However, again a word of caution.The last stable release of version PrimeFaces is 2.2.1 which has Flash based components while the latest 'milestone' version 3.0M4 is based on HTML5.This again is a major revamp of the architecture and currently the forum is littered with support questions and reports of 'not working', so wait for a few more releases before choosing PrimeFaces version 3+ or like me, prepare for battle!!

Thursday, 10 November 2011

Deploying your web application to TomCat 7.0 using Maven

Deploying your web-application using the tomcat-maven-plugin can be done by as follows:
1. Create a user in Tomcat with the manager-script role. Before Tomcat 7.0, this was accomplished using the manager role. The user details can be sepecifed in the conf/tomcat-users.xml file as follows:
2. Now you need to tell maven that it can deploy applications to Tomcat using this role.
To set this connection, open your settings.xml file which should be present .m2 directory. Search for 'server' and put in the following credentials:

          localhost
          tom
          cat

Obviously, the server name is :localhost in this case.
3. In your maven pom.xml configure the tomcat-maven-plugin as follows:

             org.codehaus.mojo
             tomcat-maven-plugin
             
                http://localhost:8080/manager/text
                      localhost
                      /test
             
         

Take note of the
http://localhost:8080/manager/text
This is important otherwise you will keep getting 403:Access Forbidded errors when you attempt to deploy.
  • To build you war and deploy on Tomcat, use : mvn tomcat:deploy
  • To redploy your war, use : mvn tomcat:redeploy
  • To undeploy your war, use : mvn tomcat:undeploy
Troubleshooting : If you are getting connection refused : 401 errors while deploying, it means that most probably you have not setup your Maven settings.xml file correctly or that you have added the configuration parameters to the wrong file.

Wednesday, 2 November 2011

log4j - power logging at your fingertips

log4j has been a popular logging framework in Java applications for several years. It is simple to implement, thread safe and light weight. While there are no current major releases planned, it is still a popular download among the Apache Logging Services toolset.
To add log4j to your project using Maven, add the following dependency snippet to your code


  log4j
  log4j
  1.2.16
 
Maven will download and add the log4j jar to your respository. Next, you need to specify a configuration file, which could be either a .properties file or a .xml file.The configuration file is usually named as log4j.properties or log4j.xml and need to be placed within the classpath for the application to find it.
If you are building an application that ships as an executable JAR, place this file within your src/main/resources or your src/test/resources directory depending upon whether you need your logging framework in the production code or not
The log4j manual describes a sample properties file.If you don't have access to a .properties file, you can use the entries shown in the example to create a .properties file for yourself.Now that you have a log4j properties file, you need to make sure that you have a Appender defined within it.
For logging messages to the console, use a ConsoleAppender. For logging to a file, use a FileAppender.
To control what should be logged with the log statement, set up a Layout and initialise it to a particular Pattern. A popular Layout is the PatternLayout that formats the output line with meta data using a pre-defined pattern.

For example, here is a snippet from the manual.

# Set root logger level to DEBUG and its only appender to A1.
log4j.rootLogger=DEBUG, A1

# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

The ConversionPattern can be used to specify meta-data about the logged statement, such as the Class from were the log originated, the date and time in different formats, the severity level etc.An exhaustive list is available in the API docs. It is worth noting the several warnings posted in the API docs regarding speed and efficiency before choosing a ConversionPattern character.
Another aspect of log4j logging performance that one needs to be aware of is the cost of creating a log statement that may not be used.To get around the parameter construction code, wrap the logging statements within a check:
if(logger.isDebugEnabled() {
    logger.debug("Log : " +  " String 1 " + "String 2"));
}
If the check is not place, the log statement will create 4 Strings (yes , we could have used a StringBuffer), but a simple check prevents this overhead. Ofcourse, there is now the cost of checking the LEVEL at which the logger is set, but this is a miniscule overhead.
Finally, now that the log4j is setup and has been configured, instantiate it 

static final Logger logger = Logger.getLogger(MyClass.class);
and start logging:
logger.info("Starting the APP");
Exceptions can be sent to the log file as an argument to the logger.error method.
catch (Exception exception) {
logger.error("Error in loading application! ", exception);
To conclude, if you need an easy and fast logging framework, log4j will fit your bill.However, if you are in the market for the next generation of logging, then have a look at Logback