Generating JavaDoc with Eclipse or Maven

Generating JavaDocs is an integral part of every Java project and there are various options of generating the required documentation.

Option 1 :  Using Eclipse and JDK's JavaDoc tool.

This is the simplest option. If you are using Eclipse and have the path to the JDK (not JRE) set in the Eclipse > Windows Preferences > Installed JRE option set correctly (as shown in the screenshot below), Eclipse should be able to find the JavaDoc tool.

Set the path to your installed JDK

JavaDoc Tool in Eclipse

That's it. Clicking on the Javadoc option will bring up a wizard that will prompt you for the Destination folder for the generated JavaDocs. Apart from generating the JavaDocs, the tool will also create a stylesheet.css for the JavaDocs that can be edited if required.

Option 2 :  Using Maven and the JavaDoc plugin.

Add the plugin definition to your pom.xml

               
                
                     ...........
                  
                  org.apache.maven.plugins
                  maven-javadoc-plugin
                  2.9
                  
                    C:/javadoc/stylesheet.css
                     public
                  
                  
                
                  

In the snippet above, I have added the plugin definition and configuration to the build section. It can also be repeated in the section. This will allow me to run the Javadoc generation goal during the build cycle. I have also specified a path to a stylesheet file that will define the look and feel of the JavaDoc generated.

To generate the JavaDoc using Maven, use mvn javadoc:javadoc

More details on this option is available here.

Setting up a database based authentication realm in Tomcat 7.0.0

Setting up an authentication module is one of the primary tasks that come across a web-developer's canvas when coding a web-application.In this post, I'll detail the basic steps needed to set up a database backed authentication realm and outline the configuration files that need to be updated when using a Tomcat 7.0.0 servlet container. This post is NOT about security or securing the web-app context so please if you do implement these steps, please do some more research on what is required to secure your web-application.It is also important to note that this post pertains to Tomcat version 7.0.0 and some steps may not be required in more recent versions.

Tomcat 7.0.0 implements the Servlet 3.0 specification (JSR 315) which provide login / logout methods to be invoked on the HttpServletRequest. 

Step 1: Create the user and user-roles table in your database using the sql scripts described here. Insert a couple of records in each table.
Step 2: Set up Tomcat to connect to the database realm
(a) In the context.xml(located in server/conf directory), set up the datasource  

(b) In server.xml (located in server/conf directory) add the following snippets in the correct location within the xml file. This will set up the connection between the datasource and the authentication mechanism :

.......

..........

Step 3: Download the jdbc driver based on your database & the tomcat-jdbc jar to set up the JDBC Connection Pool (You do not need to download the tomcat-jdbc jar if you are using Tomcat version 7.0.19 and above).


Step 4: Write the logic for passing the login & password from the user form to the backing bean.

 public String login() {  
          FacesContext context = FacesContext.getCurrentInstance();  
          HttpServletRequest request = (HttpServletRequest) context  
                                             .getExternalContext().getRequest();  
             
          try 
          {  
               request.login(username, password);  

          } catch (ServletException e) {  
            e.printStackTrace();
               context.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_WARN, "Login   failed!", null));  
               return "failed-login";  
          }  
             
 //You can fetch user from database for authenticated principal and do some action  
          Principal principal = request.getUserPrincipal();  
          log.info("Authenticated user: " + principal.getName());  
             
             
          if(request.isUserInRole("administrator")) {  
            setLoginSectionVisible(false);
            setUploadSectionVisible(true);
            context.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO, "Login successful!", null));  
               return "admin-login";  
          } else {  
               return "user-login";  
          }  
     }  

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!!

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

Mock or Stub.. Test it inside out!!

If you have been living in the Test Driven Development (TDD) world, then Mocks and Stubs will be second nature to you. The very philosophy of writing a test case before writing any code sounds like putting the cart before the horse but when you start implementing the practice, it all begins to make sense. Your tests before 'smaller'. They don't have dependencies between them and your code is  much more readable and easier to maintain.

Mocking and Stubbing are two essential components of TDD. While they may appear to perform the same function, they are different sides of the coin. To understand the similarities and the differences between these two forms, consider for example, the class, Compute defined as follows:

public class Compute {

private Integer a;

private Integer b;

public Integer getA() {

if (a instanceof Integer)

{

return a;

}

return null;

}

public Integer getB() {

if (b instanceof Integer)

{

return b;

}

return null;

}

public Compute(Database db) {

this.a = db.getA();

this.b = db.getB();

}

public Integer addNumbers()

{

if  ((getA() != null) && (getB() !=null ))

{

return getA() + getB();

}

return null;

}

public static void main(String[] args) 

{

Compute comp;

Database db = new Database();

comp = new Compute(db);

comp.addNumbers();

}

}

In this example, Compute is getting its input from another class, Database. In the real world, Database would be actually be an RDBMS such as Oracle or MySQL. Since running test cases against a LIVE database can bring in additional complexity such as the setting up of a connection, running an SQL statement against the tables and retrieving the data, Mocking and Stubbing allows the role of the Database to be mimicked.

While there are several subtle differences, the major difference between the frameworks is that Mocks enable the testing of the behaviour of the code while Stubs allow the final result  to be tested.

To test the add Compute with the EasyMock framework, I would 'mock' the behaviour of the Database class using the EasyMock framework as follows:

 Compute compute;

Database mockDB;

@Before

public void setUp() throws Exception {

mockDB = EasyMock.createMock(Database.class);

EasyMock.expect(mockDB.getA()).andReturn(100);

EasyMock.expect(mockDB.getB()).andReturn(200);

EasyMock.replay(mockDB);

}

@After

public void tearDown() throws Exception {

mockDB = null;

compute = null;

}

@Test

public void testAddNumbers() {

compute = new Compute(mockDB);

assertEquals(300,compute.addNumbers(), 0);

}

In the  EasyMock, approach outlined above, we set up the expectations related to how the method calls related to retrieving and adding two numbers would play out and then Assert the actual result against the expected. To understand the code, check out this excellent summarisation of EasyMock. The main rule of thumb while writing a Mock is to specify exactly what should happen and no more

Using Stub frameworks, such as StubOuts to test the above scenario would require creating a Class that implements the addNumber and subtractNumber methods of the Compute class and returns hard coded values, to suit the test. For example, the testAddNumbers  method would look like this:

        

public Integer addNumbers()

{

if ((getA() == 100)  && (getB() ==200 ))

{

return 300;

}

  else

  {

return null;

  }

}

Mocks and Stubs are both powerful ways of testing code and catching regression.However both frameworks are applied differently and are suitable in different scenarios. To ensure a robust testing framework, both approaches should be used in conjunction.

One JAR for all your JARs

Sometimes it is more convenient to package your Java application into a single JAR which includes all dependencies and works just like an executable. This seemingly simple objective becomes complicated when the dependencies include other JAR files as one can run into JAR Hell with the Java Class Loader. One possibility of achieving the goal of having a single executable jar is using One Jar.

The unique aspect of OneJar is that dependencies can be bundled into the executable Jar in their native form without unpacking the classes and the custom class loader resolves and loads required classes from within the dependent jars. The default Java class loader can only load classes from the file system, it cannot look inside other jars for the required classes. To achieve loading of classes from within other jars, a custom class loader is required which is provided by One Jar.One Jar also provides an Ant and a Maven2 task and can be easily integrated into your build cycle.

Integrating Spring Security with Active Directory on JBOSS 4.0.5

Spring Security (formely ACEGI) is a fairly robust and flexible framework that fits in well with a J2EE solution stack. Some of the main features that made us choose Spring was its flow transition authorization policy and its database backed 'remember me' implementation.
Based on this, we decided to use Spring Security 2.0.4 on a JBOSS 4.0.5 server. The Spring component authenticates and authorizes a user against a Active Directory through its LDAP authenticator component (org.springframework.security.providers.ldap.authenticator.BindAuthenticator) and authorize the user using its LDAP authorities search classes (org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopulator & org.springframework.security.providers.ldap.LdapAuthenticationProvider).

The important thing to remember is that Spring security matches a group name with the prefix "ROLE_" so if you have a user belonging to a group called "PG_JAVA_DEV), it would get mapped as ROLE_PG_JAVA_DEV within the security context. You can get more information on how the Spring security LDAP component works in Chapter 10 of the Spring Security guide.A detailed example of how to set up Spring Security to talk to the Active Directory is given here.

To set up Spring Security, you will need Spring Security 2.0.4 and Spring LDAP 1.3 (which has some additional dependencies mapped in them).Just map these to your Maven POM and you'll be good to go.

In-Container testing with JUnit

Given the usefulness and success of a Test Driven Development(TDD) approach for developing (Java based) web applications, it is imperative that a developer chooses a good testing framework for writing unit tests. One such popular open-source test case framework is JUnit.

With JUnit 4.x, developer's can annotations to develop unit test cases. Annotations simplify the construction of test cases to a great extent leaving the developer to focus on writing the essential pieces of the testing logic. In an earlier post that included some test cases, I used the annotation @Test that took care of marking the method as a JUnit test case to be executed by the Test Runner. Thus, all that I needed to write was the assertion for testing the method. A short tutorial on learning the essential JUnit annotations is given here while a more detailed learner guide is available here and an excellent cheat sheat can be downloaded here.

While JUnit is basically a unit testing framework for stand alone Java applications, testing web applications is an entirely different cup of tea. Web applications run within an application server (such as JBOSS), while JUnit executes its test cases in a local JVM. Then how do you test thosein-containerMock Object based approach and the second is to use another testing framework that directly performs in-container testing.

For a Struts based web application, the MockObject approach can be implemented using StrutsTestCase class. Apart from the StrutsTestCase, there are several other available frameworks such as EasyMock that allow you to easily mock up objects. It should be noted that the Mock Object approach is not the same as in-container testing of components.

In-container testing can be carried out using one of the testing frameworks that extend JUnit and enable end-2-end testing of the web application. Cactus, HttpUnit and HtmlUnit are three such testing frameworks. It should be noted that Cactus and Http/HtmlUnit provide different facets to testing the server components. While Cactus focuses on testing server objects in the J2EE spec such as Servlets, EJBs and JSPs, Http/HtmlUnit frameworks emulate the browser behaviour. In other words these frameworks help you test the rendered view after an Http Request. The good news is that these frameworks can be integrated and working together can provide excellent test coverage.

For more reading on unit testing Struts based applications with these testing frameworks, check out this excellent book chapter.

Software caused connection abort: recv failed with MySQL and Hibernate

If you get "Software caused connection abort: recv failed" after attempting to login to your JBOSS server after a long period of idle time then you need to take a cup of coffee and sit down as this is going to take a while to fix.

In a web application that we developed,  we were using a JBOSS server version 4.04, connecting to MYSQL 5.0.24 with Hibernate 3.1 and we started getting these messages after the server had been sitting idle for some time and a login was attempted. The initial diagnosis was that the MySQL /JDBC connection was getting stale and it could be resolved by updating your MySQL driver to the latest version and adding a few properties to your data-source connection file. We updated the driver to mysql-connector-java-5.0.8 and as explained in this excellent post we added the following lines :

       
 (exception-sorter-class-name)
com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
(/exception-sorter-class-name)
(valid-connection-checker-class-name)
com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker
(/valid-connection-checker-class-name)        

The basic idea was that the JNDI would ping the DB periodically and keep the data source alive. Well, it didn't work for us but atleast we had the latest driver.

The next approach was to write a custom class that would operate on the database every hour or so and keep the connection fresh. (According to the docs, MySQL marked the connection stale after 8 hours but I was not in a trusting mood). I wrote a Java Timer class that was called by a servlet every 30 minutes. The objective of the class was to check the table which housed our support requests and if found a new request, it would shoot me an email. The Timer class and the Servlet hookup worked fine and I stated getting emails if there was a support request waiting to be serviced but the original problem still remained. The server would still spit out a long stream of exceptions, starting with Software caused connection abort: recv failed if a login was attempted after a few hours of idle time.This was getting annoying!

I then approached the problem in a different way and went over my Hibernate connection pooling setup. We were using C3PO but maybe something was missing? I reset the Hibernate connection pooling parameters to the following :
(property name="connection.provider_class")org.hibernate.connection.C3P0ConnectionProvider(/property)
(property name="c3p0.acquire_increment")1(/property)
(property name="c3p0.idle_test_period")100(/property) (!-- seconds --)
(property name="c3p0.max_size")100(/property)
(property name="c3p0.max_statements")0(/property)
(property name="c3p0.min_size")10(/property)
(property name="c3p0.timeout")100(/property) (!-- seconds --)

and Voila, the exceptions disappeared. We finally had a clean console when attempting login ever after several hours. So while, the Hibernate connection pooling params appear to be the main culprit, I feel that its equally important to update your MySQL driver and make sure that there are no loose ends in the JNDI data-source params.

www.samaaj.com.au - a platform for students !!

One night while half asleep, I had a dream and in my dreams I saw a website. WoW!! People have such cool dreams and I just saw a website. But in my dream, the website was not just a website, it was a cool thing, a platform for students to get together and help each other, a helpline for students. It was something that I had to act upon.

Having been an International student myself, I understood the problems that some students faced and this was the main motivation behind www.samaaj.com.au. I got up from my sleep and shot of an email to a few friends who I hoped would share my enthusiasm of giving up their free time and instead spend time building a web-site. Well, my faith wasn't misplaced. My pals responded and we slogged through the weeks and months. Yes, there were periods of inactivity and procrastination but finally on the 13th of October, 2008 we made a BETA version of our website LIVE and available to the general public. 

While the initial version was BETA and I expected several refinements and fixes over the coming months but overall, it was a fine effort and when I look back at the year that we spent in refining and developing the application, I am happy that we acted on our impulse. Even though at times it appeared as if we were hardly moving, we persisted and today that dream is a reality. The web-app has been built in what I know best - Java. Over the next few years, we refined our user interface, added several bug fixes and changed our hosting from a home run server to Amazon Web Services's cloud infrastructure and released a brand new look of the Student Helpline version 2.1.1 in September 2012.

Portlets, Servlets, Application Servers and Portal Servers

Portlets have been around for a few years now and after JSR 168 have matured as a technology.Easy plugability, interoperability (of Portlets) with various Portal Servers (post JSR 168) and the rich user interfaces possible in Portlets have made them a popular choice in the J2EE development world. The main purpose of this post is to briefly explain the difference between a Portlet and a Servlet (technically and functionally).

Portlet as a technology borrows heavily from the traditional Servlet model. While both, Portlets and Servlets are Java components that have to be hosted within a Java container (JVM), there are some essential differences.

Portlets as compared to Serlvets are relatively specialised components. They give the developer a chance to focus on capturing some essential function without worrying about the 'other' things that go with making the function available to the real world. Further, unlike Servlets, Portlets cannot be invoked via a URL. This is hardly a limitation as they aren't meant to be invoked in such a manner. Portlets are realized and invoked via Portals. Thus browsers (web-clients) communicate with Portlets via Portals.

A Portal defined in layman terms is a 'web-site' but in essence it is a collection of Portlets. It includes a theme other user interface features that define the look and feel of the Portal. Cameron McKenzie explains it well when he says that Portals build upon existing J2EE functionality and simply management of several diverse applications. Content management is a good example of simplified Portal functionality that is considerably simplified. I experienced this first hand when I installed and ran JBOSS Portal Server 2.6.5.

While Servlets are hosted by an Application Server (such as JBOSS application server, Bea's Weblogic), Portlets require Portal servers. Examples of popular Portal servers are JBOSS Portal Server 2.6.5 and IBM's Portal Server 6.1. Portal servers are super sets of Application servers in the sense that they extend their capabilities and provide specialised functions which make single-sign on, customisable security, one-look applications and rich user interfaces possible in Portlets.

To summarise Portlets are specialised Java components.They can be persisted, configured, manipulated via the addition of buttons and while they aren't allowed to generate general HTML code, the iFrame tag can be used with caution. Nifty??? eh??

Survey of J2EE open source tools and libraries

I came across this excellent collection of open source tools and tag libraries with a focus on Java / J2EE tools. There are links and reviews of open source AJAX frameworks, content management systems, J2EE Frameworks, JSP tag libraries and a lot of other goodies.
Most of the topic reference links are active and the content is relatively current. Worth bookmarking if you are working in the Java domain and want to see some of the various open-source offerings on a particular subject.

While on the subject of surveying J2EE tools, an interesting book on the market is Java Power Tools. While the book is basically a compendium of 30 tools ranging from version control systems to QA analysis tools, it tends to gravitate a lot towards the use of Unit testing, Continuous Integration and Stress and Volume testing tools. A look at the TOC doesn't reveal much for the experienced developer but for the newbie J2EE guy, this might be a good starting point. I would have liked it a lot more, if it had a chapter on application servers and 'compared' different frameworks (albeit briefly) such as Struts and Tapestry or Struts and Cocoon. I also missed Hibernate in the TOC. :-( But overall, it looks to be a good read for a newbie.

Securing your Web-App:The WEB-INF story, FORMS, JBOSS and JAAS

Securing your web application is a multi-step process and requires careful planning.If you are not careful, you can end up leaving the application vulnerable to hacker attacks or lock yourself in and throw away the key which is what happened to me recently.

I was securing a web application that was to be deployed on JBOSS. Taking the first step in security, I placed all my web-resources in my WEB-INF. Good move.No. Bad move.Yes.
It was a good move in the sense that by placing every resource under WEB-INF, I was securing them from being accessed externally, i.e no one could get to them unless they pretended to be a servlet call. I had locked myself in and thrown away the key. Hang-on what if I got to a resource as an Authenticated subject. Yeah, you could. I redeployed the application and pointed it to my login.jsp that was sitting in the WEB-INF under a pages directory. It worked fine except for one thing. My login.jsp requested a style-sheet and try as much as I could, I could not get it to load. That was when the lightening struck.

The call to load the stylesheet was a new request being made before the authentication process had completed and of course the WEB-INF would bar the request. I moved my jsp pages, stylesheets, images and scripts out of WEB-INF and secured them using security tags defined in the web descriptors.

Securing web-resources placed outside the WEB-INF folder is carried out using the web.xml and your server specific descriptor. Access to web-resources is granted based on user-authentication and authorization policies. These policies are user role base.

To secure your web-resource folders in JBOSS, follow this tutorial or follow this link in the Sun Forum. Both tutorials are very succinctly written and bring out the salient features required to configure and set up security in JBOSS. If you are after WebLogic, then this guide will be useful. It also describes FORM based authentication in sufficient detail which is what most web-applications are based on.

Well, there you go! Enjoy locking yourself in but don't throw away the key...yet!!

Subversion : The next generation of version control systems

Subversion has been gaining popularity as a robust and easy-to-manage version system over the last few years but are there specific advantages for a project to use Subversion as a source code control system? This post briefly examines some of the benefits of using Subversion and brings together a collection of resources that can be used to understand, set-up and start using Subversion as a version control system.

What is Subversion?

Subversion is a version control system which maintains different versions of your documents and files, allowing you to get the latest versions or previous versions easily.

Some of the major advantages for using Subversion are:

1. It is open-source and thus is free.
   
2. Setting up Subversion and managing users is a simple affair.
3. Subversion is rated to handle binary files comparatively better to the widely used Concurrent Versions System. Thus, image files can be handled better.
4. Subversion can be integrated with Eclipse using a plug-in named Subclipse, which is useful for developers who like working from within an IDE.
5. An open-source client (TortoiseSVN) makes accessing and using Subversion from Windows systems easy. Tortoise operates as a windows-shell client and is integrated into the windows explorer.

Some strong testimonials and user experiences are given on this page. On a personal note, I have used Subversion in about 5 projects over the last two years have found it to be a very robust and easy to use source control system.

Using Subversion

Subversion is based on a client-server model, which means that a server process actually monitors and manages access to your files.

( Note: you can also run Subversion as a standalone program to store your personal files but if you choose to do so, you will not be able to access your files from other systems. This article is describing a scenario where you would want to access your files from multiple systems.)

To set up a subversion server, follow the steps outlined in this excellent post.

If you have installed the Subversion server successfully (with Apache), then install a client that will be used to access and modify the files managed by Subversion. To keep things simple, we will focus on setting up Tortoise SVN ( a Subversion client) and use it

To set up the subversion client (TortoiseSVN), follow the steps outlined in this post.

Once you have a server and client system setup, you can access Subversion, check out and check in files, as many times as you like.

Subversion / TortoiseSVN resources

1. Subversion Homepage
2. TortoiseSVN Homepage
3. Subclipse download page
   

John's essential links..for the saavy J2EE developer

We often come across useful information in our development phase and store it away as a book mark but we don't really index or summarise the information for later use and end up Googling for the same information when we need it again.

I intend to maintain this page as a collection of links related to various J2EE tools and technologies, that can be used for as a one stop shop for finding my favorite J2EE links regarding a particular technology or the solution to an issue I faced and sharing them with the J2EE community.

Feel free to send me your favorite links with a short summary of what is there on the page and I'll add it to the list.

----------------------

• Build Tools

A. Maven

1. This article gives a good conceptual overview of the maven build tool and a handy startup command reference.
2. From the Maven home page, a starter's guide. This page has a handy faq but tries to focus on too many things and so might not answer all your doubts but it does give you something to go on.
3.Another good explanation of Maven concepts and a starter guide.

B. Ant

• Java XML Serialization Technology

JAXB

1. A beginner's guide to JAXB.

• Wikis and Blogging Tools

A. Versionate

B. MediaWiki

C. BaseCamp

• Logging Tools

A. Log4J

• Testing Tools

A. JUnit

B. Cactus

C. JMeter

D. SoapUI

• Web Application Servers

A. Tomcat

B. JBOSS

C. WebLogic

• Presentation / Web Tier

A. Struts

B. JSF

C. AJAX

D. CSS

• Code Standardizing / Bug Finding Tools

A. PMD

B. findBugs

C. lint4J

• Source Control Software
  

A. SubVersion

B. TortoiseSVN

Refer to this post for information, directions and tips on understanding, setting up and using Subversion and TortoiseSVN.

• Useful Tools

Source Generation Tools

A. MiddleGen
B. XDoclet

Tailing Log Files : Cygwin

• Frameworks

A. Spring

B. JEMS

• Interesting APIs

A. Google Maps

1. This article has an excellent collection of Google Maps API usability examples.
2. This post summarises some of the other Google APIs, mainly the Google ToolBar API, Google Gadgets API, the Google Calendar API among others.

• Setting Up / Configuring Tools / HowTos