Exception Handling in Web Applications

Error Handling is an important part of any implementation. An application without Error Handling is like a patient with all door closed for diagnosis. It is a perfect time killer for developers to debug the application issues without proper error handling. Hence it is an important topic to discuss. However here we are concentrating more on error handling in web applications (using JSP, Servlets).

Motive of error handling is to capture any error generated in the application, log it to any logging system and propagate it to right point so that it can be directed to the user with all useful information. So the basic flow of error handling should be
  • Apply try-catch block with right exception type in catch around the code which may generate the error
  • Log the error using any logging mechanism. One of the popular logging system is log4j using commons logging. Ensure to use right logging level i.e. debug, info, warn, error etc
  • Apply business logic whatever is required to handle the erroneous case as per application requirement
  • If error is not manageable and condition should be propagated to user, throw the appropriate error further after wrapping the original error. Make sure that new exception should carry all user centric details which can help them to understand the cause of error, and developer centric information which can help them to debug the issue. 
  • As a general mechanism, error codes can be set to exception which can describes the reason of problem at Application and UI level. These error codes can also be used to show the localized messages on UI
  • Application Framework should provide the facility to handle any exception originated from the application and redirect it to a designated UI which can show the error details to user with all the details
  • The UI can also have the mechanism which can facilitate the user to log the issue directly in Issue Tracking system or to send email to the support staff with all the details

Implementation of Login and Logout in Web Applications

Login/Logout seems like a simple operation in web application. However small information left behind can give a chance of security breach to hackers. Here is a simple and minimal workflow which we should ensure while implementing login/logout functionality in web applications.

  • Have a Security Manager on the Gateway which can authenticate and possibly authorize every new request to server. For example, it could be a ServletFilter. 
    • It should authenticate every new request to check whether user is logged in or not. 
    • If yes, does current request URL exists?
    • If yes, does user have rights on current requested URL?
  • If request is passed through Security Manager, the login  manager should do following: 
    • Clean the existing session for all application specific information.
    • Invalidate the session using session.invalidate.
    • If request is for login
      • Check if user exist for given user name and password. 
      • If not, return to right page with message
      • If yes, go ahead
      • Create a new session, for example, request.getSession (true)
      • Fill the session with all application specific information for current user like all UI structure for which current user is authorized.
      • Forward the request to home page of request application or module
    • If request is for logout
      • Forward the request to logout message page  
This is the minimal workflow to ensure the basic principles, however a lot can be added to implement the application specific security checks and to support the application structure. Like as an extension, the Security Filter which is sitting at gateway can interact with a security service to validate the current request for authentication and authorization. Similarly Login/Logout implementation can interact with Security Service to authenticate the login information and later to retrieve the user specific application settings, for example, the menu structure and UI look etc. 

This brief information may help in concept building and in basic architecture design.

How to use XDoclet and Ant to Generate Hibernate Mapping and Configuration

XDoclet is a wonderful tool to generate various kind of configuration files in declarative way, and the declaration can be done with java code. It allows Java Developers to work in Java Code files only even for all the configuration which otherwise need to be defined in XML or property files. It is very convenient way for Developers who like to have everything in Code files, and facilitate to do all configuration from same place. It makes the applications easy to maintain, and debug. XDoclet supports tags for various tools like Hibernate, EJB, JMX, JSF, and Spring etc. However here we are explaining how to use it with Hibernate. XDoclet can be used for various purposes with Hibernate, like, to generate Hibernate Mapping Files, to generate Hibernate Configuration File, and to Generate/Update the schema.

Before going into details, you should be aware that there are two active versions of XDoclet, version 1 and version 2. Difficulty is that these two versions do not seem to be in Sync. Like version 2 has many changes which are not compatible with version 1 and also has a lot of changes in API. Another problem is that it is not easy to find a good documentation for XDoclet 2, and details like the difference between version 1 and 2. We were unable to find any single document which can provide all of these information nicely, and the path to update from version 1 to 2 with all side effects and changes required. There are many changes in XDoclet tags for Hibernate in version 1 and 2. Many of old tags are not supported now. Same difference is there in ANT tasks also, which can be used to integrate the XDoclet features with ANT. Here we are taking a real life scenario for using XDoclet task in ANT for Hibernate.

Suppose, there are multiple projects dependent on one or other project for Data Objects. One project has all Global Data objects like Address, City, Country etc. Other project has some business function specific data like Employee, Supplier etc. Now Employee has a field of Address type also, which will of course be coming from Global Data Project.

Should Project Manager Apologize if Project Failure is Due to Resources Being Managed by Anyone Else

Answer is with statement "Project Managers should be proactive and not reactive!". Project manager has the ultimate responsibility for the failure or success of project. To answer the original question, certainly project manager should apologize for the failure to meet the target. There is nothing wrong in accepting the failure and inherent responsibility. However important thing is to analyze the reason of failure and make everyone aware about the facts including the other managers, who were influencing the resources responsible for failure. It is not about directing the blame to those managers, but to make everyone aware that what was the reason of failure; so that these can be avoided further. Stakeholders should be aware about the reasons so that they can direct the team members to take corrective action. Other managers may not be having all knowledge to understand the effect of his management, so sharing the facts is always important.

Important thing is that main responsibility lies with Project Manager role is to make the project a successful venture. So one should always ask himself, that, "What is Good for Project". This is like a Panacea in any situation. It will give him right answer for every difficult situation, will keep him away from politics and will enable him to be proactive.

Further, being proactive is important for management. If project manager is aware that some part of the project is not going well, she should inform all concerned stakeholder about the situation, possible effects and various solutions. Project Manager should be very clear that she is responsible for success or failure of project. So she should have absolute control over the resources, their schedule and their performance. She should be proactive to ask for the control, if it is required for the project success. If this kind of control is not there due to a specific management style in Organization, then the control flow and hence the responsibilities should be defined clearly accordingly; and Project Manager should communicate every deviation from desired path to the concerned stakeholders with possible solutions

Redmine Java Connector 0.7 Released

We are happy to announce the first release of Redmine Java Connector (RedmineJConnector) at http://code.google.com/p/redmine-jconnector/. It is a Java based client side API for Redmine.

The product is born out of necessity. We were desperate for a Java based Redmine Client library which can help us to interact with Redmine from our projects. The use case was to help the users to create an issue in Redmine System in case there is any bug or feature request. However we were not able to find any library matching to such requirements. So this product is the result of this requirement, and now we are using it with our projects also.


Redmine Java Connector is capable to interact with Redmine(http://www.redmine.org/) Server using its Rest API. Redmine provides API for various CRUD operations on Projects, Issues, and Users etc. This connector helps to interact with this API using Java based Connector API, without going into details of Redmine Rest API.

System picks its various configuration like Server Address, and Security Key etc from configuration file. Its build is based on ANT.

Sample Code: You can find the sample code with Test Case
Documentation: Run the build with 'javadoc' target, and you will get the documentation in 'javadocs' folder

Various dependencies are:
  • Redmine - Version 1.1.0 or above
  • ANT - For building the application
  • JIBX - For Java to XML and XML to Java conversion
  • Restlet - For accessing Rest API of Redmine
  • Commons Logging and Log4J - For Logging purpose
  • Junit - For test cases
System is developed on Java, hence should be able to run on all platforms. However it is tested on Windows environment with Java 6.

The system is under active development, and more features will be added soon.

General Workflow of Issue in Project Management (Tool)

Here we are giving a general workflow for a support/maintenance/development project. It is quite elaborative process considering the scenario, when a product is in production and team is working on support/maintenance and for new development also. Of course it does not suit to everybody requirement, however it can be amended to suit the requirements.

  • New Issue as a Feature or Enhancement
    • Users will initiate the new requirements or defects for existing functionality in the system
      • Alternatively Business Analysis team can log this on behalf of users, till user get familiar with the system.
    • Business Analysis Team will also generate new requirements based on various requests from the users and log these in the system with the details. 
    • BA team will discuss the requirements, put all of their views in the system
    • Once requirements are freeze, the status will be changed to Finalized and the issue will be assigned to Development Team manager
  • New Issue as Defect
    • End user or UAT team can log any defect they found in the system with all the details, set it status to Finalized and can assign it to Development Team Manager.
  • Development Manager will review the new assignment.
    • She may come back to end user or Business Team for more clarifications
    • She will set the status as Analysis Scheduled if it is a requirement or to Implementation Scheduled if it is a bug and schedule it for the team as per the discussed priorities in roadmap
    • The issue will be assigned to any team member
  • Developer will pick the issue as per the schedule and update the status as In Analysis
    • She may assign this issue to Business team or users for more details
    • She will put all her understanding for the requirement in system to avoid any gap
    • Once she is done, she will update the status as Analyzed and assign it to concerned Business Analyst for Confirmation
  • Business Analyst will review the understanding and will update its status as Confirmed, and assigned it to Development Manager
  • Development Manager will schedule the activity with developer as per priorities and update the status as Implementation Scheduled
  • Developer picks the issues as per the schedule and updates their status with their progress as in Progress. Once the issue is fixed, the status will be marked as Resolved.
  • Development Quality team (developers currently) will test the solution and update the status as QA Approved.
  • UAT team will pick the issues in QA Approved state and perform their testing on these.
    • If there is any issue, defect can be logged and issues can be rejected with the status as Reopened
    • If everything is fine, issue can be approved as QA Approved
  • Now with the next release to production, this issue will be deployed to live server and the status will be updated by the concerned authority (Project Coordinator/Owner) as Deployed.
  • Later if end user or UAT team found any issue, the process can be started again from first point.
This is just a sample process flow, however can be modified to fit to any requirement.

Use of Project Management Tool and Redmine

Welcome to the Project Management Tool. Project management tools help us in managing the projects for various important activities. Although these activities can be managed without tools, like on paper or in mind, however that is not a convenient and optimum way. Keeping things on paper are outdated, where no report is available and we need to manage the papers. Keeping everything in mind is not good for mind, as then it won’t get time to process other more important data. Hence to manage any project, we need to have a Project Management Tool in place which can contribute to overall development and output, like

  • Facilitate to define the requirements as features and enhancements with all the details
  • Help in finalizing the requirements around these features by facilitating the discussions online, involving as much users as required and capture every point of discussion for reference
  • Roll out the final requirement specification to development team for their action with the required User Acceptance Test cases, so that functionality can be tested with same scenarios by Development team also.
  • Help development team to discuss the requirements and design internally, and involve business experts/analysts also for any doubt or improvement
  • Development team can finalize the design and estimate the efforts required for complete development
  • Define a Roadmap for the development team considering the priorities of Users/Product Owners and efforts required for the activities.
  • Help development managers to assign and track the work activities progress up to completion and to have a live status for the progress anytime. 
  • Enable Project Manager to implement the good management methodology like SCRUM, which is an agile product development process and is good for such developments. Refer to following links for SCRUM
    • http://en.wikipedia.org/wiki/Scrum_(development)
    • http://www.vedantatree.com/2010/01/practical-scrum.html
  • Help QA team to test the solution and ask to proceed for the release.
  • Release the features to UAT team for UAT
  • Help UAT team to log any defect in the system for existing feature or for any missing functionality and track their status
  • Finalize the UAT and approve the solution for production release.
  • Help the end users to log any defect or missing functionality they want in the system, and give them a live updated for their request.
  • Help the key stakeholders to track the status of development anytime, anywhere.


Key Principles for Software Architecture and Design

Defining the Architecture is a challenging job. However by focusing on few Key Design Principles, we can make it easy and even interesting. Here are few Key Principles for Architecture and Design:
  • Separation of concerns: Each component in the system should be assigned a specific responsibility. It means that features should not be overlapped among the components and the users should be very clear about where to go for a certain feature. It avoids interdependency of system components, and make the system easy to maintain. Suppose in future, you find scope of improvement for this feature, then you need not to make the changes at multiple places. But you will make the changes in the specific component, owner of the feature, and all other components will get the benefits as they must already be using this for that specific feature. This approach also makes the application easier to understand for a user.
  • Principle of Single Responsibility: Every component should own one specific and distinguished feature. It helps in defining the responsibilities clearly, helps the user to understand the system easily and also help in integration of component with other components. 
  • Don't Repeat Yourself: This principle states that one functionality and hence the piece of code should be implemented in one component only. It should not be repeated across the components. Uses are that the code will be very maintainable. If you find any error, or you want to optimize the code, there is always one place where you can do it. Otherwise there will be a search in whole code to find out the places where similar code has been done for a feature.

Application Architecture and Design

Application Architecture is the structure of the whole system which describes the important component/objects of a system, various interfaces and that how these interact with each other. It also defines how system will be accessible to external world and how it will integrate with other third party services. So it is a high level structuring of the system, which might not have the detailing at object level; but will describes various layers, what kind of components/objects these layers will have and how these different layers will interact with each other.

Now if we need detailing at next level i.e. objects and their relations then we should proceed for designing of the system. To understand the difference between architecture and design, consider the Architecture may define a layer where all request processor/handlers should resides. Further design can describes various kind of actual request processors based on system and business need.

New Version of ExpressionOasis-3-0-1 Released

This is a micro release with few but important bugs fixes. The new 3.0.1 version should be used to have bug free solution. Fixed issues are:

GoogleCode: #1, #2, #3, #4