Risk Storming

Risk Storming - Collaborative and Visual Technique for identifying technical risk

My notes

1) Draw you app design on board - high level to show each like component, class, container etc
2) Identify risk individually - each and every member of team has different view of looking at risk!
3) Highlight risk at component/flow/integration level
4) Discuss and Priorities

Excellent write up by Simon here @ Risk Storming.


Java EE - the next inception!

Read this article on WebSphere and found this interesting about basics of how IBM WebSphere Application Server Liberty profile works, and how its architecture differs significantly from that of older Java EE application servers

Please read here complete article at Java EE, the next inception: A primer to WebSphere Liberty for Java EE developers

Portlet Preferences Usage - Best Practices

PortletPreferences should be used very carefully and in situations only when there is a valid use case for it.
So ideally, one should have good knowledge of portlet preference and most imortantly, where to apply it.

The PortletPreferences object provides the ability to store information persistently about how a client wants to use a particular portlet. 

For example, with the stock portlet, a user can provide stock code information to the portlet, and the portlet will store that information persistently using the PortletPreferences object. The next time the user visits the view mode of the portlet, the stock details for that user's choice will be displayed. 
Persistently storing this information, is all done behind the scenes for you by the portal framework.

So when you use portlet preference, did you ever think about where does portlet preference gets stored? In hard drive, some KB's data in DB or as CLOB or something that is not efficient. 
So how to store portlet preference is completely upto portal vendors and hence we as a developer or DB administrator don't have much control over the data which is stored in portlet preference.

Let's talk about application efficiency, where in if you want to store just a Boolean flag and if you choose to store it in portlet preference, you don't know how it will be stored and what size it would use for storage compared to if we chose to use our own DB to store the flag which would just take few tiny bit of space.

Furthermore, mining information from data stored in portlet prefernce is almost very difficult.

So, If you don't know how the portal stores your PortletPreferences data, and you don't know how the portal ties a particular preference to a particular user, you're going to have a pretty hard time mining your own data.

The best use of portlet preference could fall in below situations where a user wants 

1) To have red background.
2) configurable pagination numbers
3) configurable TimeZone
4) configurable portotol ( http or https etc )
5) Configurable fonts etc.

Conclusion -

  • Use portlet preference for simple configurable parameters
  • Don't ever use preference to store information where it would become impossible to do data mining from preference storage because you don't have control over preference storage.

Dynamic Registration of Servlets and Filters at application startup

Recently I read about one of the nice feature of JAVA EE 6 - Dynamic Registration of Servlets and Filters at application startup.

I then thought of use cases around this feature. 
I think, this is mostly desinged for framework creators but developers could also get benefits from this.

You can use this fefature by using new methods introduced in the ServletContext class which are able to programmatically add servlets and servlet filters to a web application during startup. 

The methods are addServlet() method to add a servlet to the web application, and the corresponding addFilter() method to add a servlet filter.

Here's an example, which dynamically registers a Servlet as soon as the ServletContextListener is triggered:

//Register Servlet
public class MyServletContextListener implements ServletContextListener {
    public void contextInitialized(ServletContextEvent sce) {
        ServletContext sc = sce.getServletContext();
        // Register Servlet here
        ServletRegistration sr = sc.addServlet("DynamicServlet",
        sr.setInitParameter("servletInitParamName", "servletInitParamValue");

The same steps can be used to register a Filter named MyDynamicFilter bound to the class com.sample.TestFilter:

// Register Filter
FilterRegistration fr = sc.addFilter("DynamicFilter","com.sample.TestFilter");
fr.setInitParameter("filterInitName", "filterInitValue");
                                     true, "DynamicServlet");

Would be great if readers of this post, could suggest creative use cases which could add useful functionality to an applications.

How to programatically refresh data from LDAP

Came across to this article which very well details out, how one can Programatically refresh date from LDAP.

The articles also have a Sample Code to programatically refresh data from the LDAP.

I am sure, this would be helpful for those who encounter this use case.

Handling users with multiple roles while Login to portal

Problem Statement-
When you have got scenario where in, a user is belonging to multiple roles and you want him/her to select his choice of role while login to portal.

This situation can be solved by developing a custom login portlet and make use of Authentication Filters.

Here is how this would work,
User login using your custom login portlet with his userid & password.

Once user submit,  control goes to authentication filter and there you connect to your user repository to fetch user roles and preset a screen ( next screen of login portlet ) to select his roles.

When user selects his roles and click Login,  control again goes to authentication filter and there you authentication user and redirect user to portal landing page.

I hope that helps.Feel free to post your queries here.

How to change the WPS URL

There might be situations when you want to change portal entry url.
After portal installation you will see portal url as 

http://hostname:10039/wps/portal     ( for Anonymous users) and  
http://hostname:10039/wps/myportal  ( for Authenticated users).

In the above url, 

wps is the WPSContextRoot
portal is the WpsDefaultHome
myportal is the WpsPersonalizedHome

Now, if you want to change the url and want to look like

 ( for Anonymous users)

( for Authenticated users).

You would require to make changes in the 
wkplc.properties and wkplc_comp.properties files, located in the wp_profile_root/ConfigEngine/properties

For complete details, please go through the following documentation


Above changes are for wps 6.1.5. If you want to make change in some other wps version, please refer to respective WPS version info center.