Java in 2009


Today the last day of 2009, people say time to look back on the year passed by and prepare to  welcome a new year.For me a New Year day is just like any other day.. I feel and live the day of New Year just like all other days.

For Java Community, the year 2009 was major acquisitions like,
Oracle buying Sun,
Terracotta took over the Quartz and ehCache open source frameworks,
SpringSource acquire G2One and Hyperic, 
VMWare acquire SpringSource.

Other interesting development is happening in JVM languages. Groovy, Scala, Clojure, and JRuby gained more popularity this year. JVM is getting remodelled as a platform for other languages.

The fight of dominance in the world RIA is continiuing with Java FX, Flex. Microsoft Silverlight is alos in the race. I feel Adobe has the upper hand in the RIA world.

Cloud Computing continued be discussed in 2009 . Cloud got prominence as IT world start thinking of ways to reduce cost. Google is the most prominent player in this area.Sun, Microsoft recent joined this arena. Microsoft with Azure Platform. Google currently not supporting Java , but urges developer to go with Python.

2010 we may see the languages other Java getting more acceptance.But Java will continue to be strong and will be the most powerful of all. OSGI world seems to busy with projects like Gemini.

Have a great year ahead !!!.


REST - Building Better Systems

REpresentational State Transfer (REST) in short is a simple solution for invoking Web Services through URL's

REST defines a set of architectural principles to design Web services. The RESTful Web Services focus on the system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages.

REST is now a predominant Web service design model. REST is much simpler that the SOAP- and WSDL-based interface design.

REST style of Web Service invokes HTTP methods explicitly. The basic CRUD (create, read, update, and delete) operations are mapped with HTTP methods POST,GET,PUT,DELETE respectively.

In bad designs there is a chance of using these HTTP methods for unintended purposes, For example;

GET /addemployee?name=Chris HTTP/1.1

addemployee is a state changing operation over HTTP method ,GET. If the above request is successful, it will an employee to the database.

HTTP Servers are designed to respond to GET method to retrieve information for the data store. So from the view of HTTP servers the above usage is wrong.

Similar to Create or operations like update ,delete can be invoked in a similar way, which will cause a state change in the server.

The other side of the problem is , this will cause sever side changes if the link is crawled even un intentionally.

To overcome this, the parameter name and values can be represented as XML tags and sent as a body of the HHTP POST request.











The receiver of this request will process this and add the resource in the body as a child of the resource identified in the request URI. In the above example the employee is the resource in the request URI, and Chris will be added under employee.

This is an example for RESTful service.

To update the name of an employee, the RESTful way of doing is to send a PUT request.













The key concept behind defining Restful interface is reusing the “verbs” defined the protocol. For example, employee, parts, machine all are nouns, think of what we can do with theses nouns, it could be get employee, get parts etc. “GET” is the common verb for all the nouns. GET is already defined in the protocol. The service should not define new verbs or remote procedures.

To be more clear, instead of defining services like getemployee, getpart use the universal verb , “GET” to define these services. POST for the services like addemployee, addpart etc. For Update use the PUT request.

The URL will define the resource on which the action needs to be taken ex, employee in the case of the URL, POST /employee HTTP/1.1

The other important design concept in REST is that the body part of HTTP request should carry only the state of the resource and not to carry any name of the remote method or remote procedure.
REST design reduces dependency with the application server than the SOAP- and WSDL-based kind.

Domain Driven Design (DDD)

Domain-Driven Design (DDD) is a collection of principles and patterns that help developers to create software abstractions called domain models. These models highly expressive and encapsulate business logic.These models will  bridge the gap between business and code . These models that is understandable by all the stake holders involved in the project and not just software developers.

For non technical people, the models can be represented in different ways. Typically, a model of a domain can be depicted as a UML diagram, as code, and in the language of the domain.

As an example of using language,
A user wants to order a book online. He searches for the book based on Author, Title. This book is available, user can purchase the book. An order number is issued which the user can use to track the order status.
The language used has to do more with the concepts. It has to explain what the intention is. How the it is implemented is not significance. This helps in better interaction with the developers and the domain experts.

As an example,
A user wants to order a book online. He searches for the book based on Author, Title. If this book is available, user can purchase the book. The user Credit Card is validated by calling a Web Service offered by a third party vendor. Once validated, an order number is issued which the user can use to track the order status.

Here the validating credit card is important. But the Web Service is the implementation, which is insignificant.
So the language used to model the concept must be in line with those of the domain experts.
To have a better understanding the concepts can be explained as "Stories" or "Scenarios". This is the key in Behavior-Driven Development (BDD). What is in story , http://dannorth.net/whats-in-a-story is an interesting article.

Story usually tells about a user wants to do an action, so that he will be benefited. So the above model can be rephrased as,

Story about Buying a Book.
I want to search for a book on Java. I want to buy that. This will help to improve my Java Knowledge.
As the story develops, it will have turning points or scenarios.
Scenarios for the story will be like, 'When' the book is out of print, 'Then' add this book to my wish list and send me a mail when book is available. 'When' describes and event, and 'Then' explains what is the outcome of that event.
Lot of discussion happens around DDD. Some good resources
http://msdn.microsoft.com/en-us/magazine/dd419654.aspx
http://dddstepbystep.com/

Trap with System Properties

Recently I had developed a file upload module in a Portlet application. The module was tested and working perfectly in Windows.When the application was delpoyed in an AIX server, this fuctionality stopped working.
The fix was simple , though it took hours to debug.

To get the header of the multipart content I had code like this,
final int headerIndex= requestContent.indexOf(System. getProperty("line.separator") +System.getProperty("line.separator"));

Using this index I was trying to get the conetent and do the manipulation.

The server where the application was deployed "line.separator" was not set and System. getProperty("line.separator") was returning EMPTY STRING !!!.

This caused my logic to break in the server. So finally I had to put a empty string check (IF condition) for for the property ,line.separator and hard code as '\r\n' as i have no cotrol over the server setting.

This article is a good one for such traps while porting from Windows to AIX, http://www.ibm.com/developerworks/aix/library/au-aix-javatraps/index.html

Facelet - Flushing component

When deploying a new EAR created from a machine with time settings different from that of the server where application is deployed, flushing of the JSF components can happen.

Logs will show the following error.

INFO: Facelet[/pages/menu.jspx] was modified @ 11:45:04 AM, flushing component applied @ 11:41:30 AM

The reason being, when ever a new request is made, server sees the page as modifed in future time stamp and starts compiling again. This causes the component tree to be created again, causing to lose all the state stored by the component.

To fix this add facelets.REFRESH_PERIOD to the web.xml.

REFRESH_PERIOD indicates, When a page is requested, what interval in seconds should the compiler check for changes. If you don't want the compiler to check for changes once the page is compiled, then use a value of -1. Setting a low refresh period helps during development to be able to edit pages in a running application.

web.xml, should look like this,




-1 indicates not to check for changes, since production servers it is safe to set this value.

For more,
https://facelets.dev.java.net/nonav/docs/dev/docbook.html#config-webapp-init

Migrating to WebSphere Portal 6.1, PUMA API

There are some minor chages related to PUMA. To get the user and group information make these changes,

Usage of class com.ibm.portal.puma.User should be rpelaced with com.ibm.portal.um.User
and

com.ibm.portal.puma.Group should be rpelaced with com.ibm.portal.um.Group

List attributes = new ArrayList();
attributes.add("cn");
//Get User Name

PumaProfile userProfile = pumaHomeSvc.getProfile(PortletRequest);
PumaLocator locator = pumaHomeSvc.getLocator(PortletRequest);
com.ibm.portal.um.User wpUser = (com.ibm.portal.um.User) userProfile.getCurrentUser();

List attribUser = userProfile.getDefinedGroupAttributeDefinitions();
Map userAttributes = userProfile.getAttributes(wpUser,attributes);
String userName = (String) userAttributes.get("cn");

//Get Group
com.ibm.portal.um.Group wpGroup;
List groups = locator.findGroupsByPrincipal(wpUser, false);

for (Iterator i = groups.iterator(); i.hasNext();) {
wpGroup = (com.ibm.portal.um.Group) i.next();
Map groupAttributes = userProfile.getAttributes(wpGroup, attributes);
String groupName = (String) groupAttributes.get("cn");
}


Migrating to Websphere Portal 6.1,ServletContext

Prior to 6.1 ServletContext could be retived like

PortletContext context = (PortletContext)FacesContext.getCurrentInstance().getExternalContext().getContext();
PortletUtils.getInternalContext(context ).getServletContext();

But this won't work any more.Instead

PortletContextWrapper contextWrapper = new PortletContextWrapper(config.getPortletContext());
//config is PortletConfig
ServletContext servletContext=contextWrapper;

PortletContextWrapper implements ServletContext , so this will work with out any issues.

Migrating to Websphere Portal 6.1,PortletSession

Another issue I faced is while to get the PortletSession. This I couldn't solve . But I got another solution and i was happy as long as it worked. (..But still trying)I was trying to get PortletSession like,

PortletSession)FacesContext.getCurrentInstance().getExternalContext().getSession(false);

Here I got java.lang.ClassCastException: com.ibm.ws.session.HttpSessionFacade incompatible with javax.portlet.PortletSession

PortletSession i need to store some user attributes.Tried different options,but noting worked. So decided to go like,

FacesContext.getCurrentInstance().getExternalContext().getSessionMap()

Now I'm putting my user related attribted in this SessionMap.

Migrating to WebSphere Portal 6.1,FacesContext Locator

Continutaion to my post Migrating to WebSphere Portal 6.1 ...


I had FacesContext Locator in the Project which I was migrating. The getFacesContext method gave me ClassCastException.

thrown : java.lang.ClassCastException: com.ibm.wps.pe.pc.legacy.impl.PortletConfigImpl incompatible with javax.servlet.ServletContext at com.ibm.faces.context.MultipartFacesContextFactoryImpl.getFacesContext(Mult­ipartFacesContextFactoryImpl.java:60

With changes as highlighted I was able to over come this.

public class RIFacesContextLocator implements FacesContextLocator{ ...

public FacesContext getFacesContext(PortletRequest request,PortletResponse response) throws EPSConfigurationException {
FacesContextFactory contextFactory = null;
if (request != null) {
contextFactory = (FacesContextFactory) request.getAttribute(PortletConstants.CONTEXT_FACTORY);
}
if (contextFactory == null) {
try {
contextFactory = (FacesContextFactory) FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
} catch (FacesException e) {
e.printStackTrace();
}
}
if (contextFactory != null) {
try {
PortletContextWrapper contextWrapper = null;
if (null != contextFactory) {
contextWrapper = new PortletContextWrapper(this.config.getPortletContext());
contextWrapper.setPorletConfig(this.config);

/*
*Commented Out
*return contextFactory.getFacesContext(this.config,request, response, this.lifecycleLocator.getLifecycle(request,response));
*/
return contextFactory.getFacesContext(contextWrapper,request, response, this.lifecycleLocator.getLifecycle(request,
response));
}
}
catch (FacesException e) {
e.printStackTrace();
}
}
return FacesContext.getCurrentInstance();
}

Migrating to WebSphere Portal 6.1

Recently (late though..) we migrated our portal application from Websphere Portal 5.1 to Websphere Portal 6.1 using RAD 7. Initially we had some issues in getting the environment ready. Even sample projects was not getting published. Server was just showing "Starting..." and never finished. Due to this the projects never got published.
After googling found this was issue with RAD and upgrading RAD from 7.0.0 to 7.0.5 solved this issue.

Migration Steps I followed

1. Created a dummy FacesPortlet Project in RAD 7.x and take the follwing jar files.
jsf-api.jar, jsf-ibm.jar , jsf-impl.jar , jsf-impl-messages.jar , jsf-portletbridge.jar
Update your jar files with the above files. jsf-portletbridge.jar will not be there in the old project.


2. Extend the portlet with FacesPortlet
public class MyPortlet extends FacesPortlet
previously I had
public class MyPortlet extends FacesGenericPortlet

3. Remove com.ibm.faces.context.PortletFacesContextFactoryImpl from faces-config.xml
This is the faces-config I created newly.



This will be the minimal chages to get your Portlet initialized. But to get the User and Group info there are some minor changes in PUMA API. Also to locate the faces context need some changes. Steps I followed are published as different posts.

OOP...getting the basics right

Even after extensive coding experience in Java , when ever I get time I try to read about the basic concepts of OOP like Encapsulation, Abstraction etc. I search in google and try to read the definitions given by different authors on these topics. Each definition "may" sometimes give a different dimension which I might not have thought before.

I ask the question to explain Abastraction or Encapsulation during candidate interviews. Even many seniors fail to explain these concepts in simple words.

Getting the basics right is something which the software developers like us should keep in mind.


Effective Java

By Joshua Bloch is one book which from my personal experience i recommend all Java developers to read.

First Post

Being the in the IT industry for more than 8 years, many times came across complex issues which I could solve just because somone had faced the same issue before me and most importantly they published how they solved.

Experience now gave me the confidence to guide others and with this confidence I thought to share those tips with which i could solve some issues which I came across in my career, mainly with Java/J2EE technologies.

I do plan to share my thoughts that may not be purely technical.