Portlets deployed with EAR file are not available in portal server

We usually deploying portlets on portal server and we know portal server always takes WAR file. Now we are working on business applications where we do not have only portlets. We have EJBs, JSP components, WCM plugins, custom workflows along with portlets.

So keeping WAR file separate with other components is not a better idea. It is better to keep EAR file on WAS which will help us to deploy everything at one go.

Now we have some observations that deployment with EAR file is not reflecting portlets on portal environment. We got one thing that deployment of WAR file with portlets are reflecting portlets on portal environment but EAR with portlets and other components are not reflecting portlets on portal environment.

This is happening since WAR deployment store portlets entry in portal DB but EAR deployment is not storing that entry.

So applying this entry, we need to apply XML file on portal server. This will make available portlets on portal server.

You will find reference links with following links,
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wps/adprdplt.html

http://wpcertification.blogspot.in/2009/03/installing-portlet.html

There is one more thing which I would like to share,
when we apply XML on portal server, immediately WAR file [part of EAR] is available in portal server environment.
In case, you want to update any specific portlet, you can delete WAR file in portal environment and apply XML file again otherwise use 'update' [instead of 'create'] in XML file and apply on portal server.

IBM portal 8 impersonation feature

IBM portal 8 has come up with latest feature which saves lot of time for developers. I had worked one of JEEE project in which I have used impersonation feature. For achieving this feature, J2EE developers are using too much code and testing efforts.

I would like to describe in brief about impersonation feature for those who do not know about this. This feature is used to replicate the end user screen to understand the issue of end user.
Suppose user X has some issue in his web-site (using X's credentials). He raised request for web-site administrator and explained about his issue. For understanding the issue of user X, administrator will impersonate the screen of User X and will try to replicate the issue without informing user X.
This feature is useful to understand the end user functionality or support.

IBM portal 8 provides this feature by default in portal server.

Keep tracking of this blog... I will add more post on portal new features which beats the market of other portal servers.

Portlet namespace

First, I would like to highlight some point for those who are new in portal and they are not aware of namespaces.

Basically 'namespace' term is used in portal terminology and this term comes from portal itself. Let me clear this point in easy way. Suppose, we have a large amount of data in database and we want to fetch a particular data from database. So what we will do? We would need a unique id for identifying the data which you want to fetch.

In a same way, portal manages all portlets with a unique id that called 'namespace'. I think, I am able to describe this think in simpler way.

Now the question is, if namespace is unique for each portlet so what happen if we use different instance of same portlet on a same page. The answer is, portal creates different namespaces for different instances.

Ok, this is with a single user. What happens if we use the same instances (2 instances on same page) with other user. This is a tricky question if you do not know. Here the answer is, namespaces are similar for other user.

Conclusion

In portal server, namespaces are managed according to portlet instances. Namespaces are changed according to instances of portlet, these are not changed with change user (i.e. other users).