Reading Properties file using ResourceBundle - native2ascii ANT task

Introduction
Most of the portlets or any web application that we usually create, will make use of the properties file to read and display the localized contents/value present in it. The .properties file created will be of encoding type ASCII. And as we know, for displaying the japenese and other language it should be of UTF-8 characters. Even if the properties files are stored as UTF-8 encoding type, still the content displayed for some of the languages would be junk. The reason being when the properties file is read using resource bundle object it doesn't know whether the characters are of UTF-8 format. There should be mechanism to make this properties file available for the web application.

We spent almost two to figure out this, hope this solves some time for you :)

Below are the steps that should be followed to make your web application to display the locale specific text:

Reading Properties file using Resource Bundle
a) Creating a proper properties file
First step would be to create a properties file with the encoding type UTF-8 format for all the locales. Inside the properties file have the locale specific text. eg. for japenese properties file,

portal.message=ポータル

Eventhough locale specific text is available for the web application to use it, the JVM treats all the contents as similar format. So option is to change the JVM settings to allow the UTF-8 characters. The other option would be to convert the existing UTF-8 characters into UNICODE characters so that it can be displayed normally.

But the problem is to have the unicode value in the properties file. It is hard to maintain and also not human readable. eg. the UNICODE value would be:

portal.message=ポータル

So there needs a mechanism to convert the UTF-8 characters to UNICODE at runtime or at compile time. And mostly we use ANT as the tool to build our projects to create the war file. So the idea should be implemented at the build level so that even the properties file can be human readable and also understood by underlying JVM.

b) Using native2ascii ANT task
Fortunately ANT provides option to use the native2ascii utility.

native2ascii: Converts files from native encodings to ASCII with escaped Unicode. A common usage is to convert source files maintained in a native operating systenm encoding to ASCII prior to compilation.

The option would be is to convert the properties file using the native2ascii utility so that the properties file entries will be converted to Unicode format. The Unicode format can be easliy be understood by any Operating system.

Sample ANT code for this is given below:

<!-- converting the properties file values to unicoce character values-->

<native2ascii encoding="UTF-8" src="${portletmodulename}/src" dest="${warfiledir}/WEB-INF/classes" includes="**/*.properties"/>

This convert all the UTF-8 characters into Unicode format at the build, so that even the web apps can use it. And also properties stored in the filesystem will be UTF-8 characters which is easily maintainable.

Reference:

http://ant.apache.org/manual/OptionalTasks/native2ascii.html

Regards,
Elango

Removing Unwanted spaces between the portlets

Introduction
One common problem which the portal developer come accross is the spacing issue that is formed between the portlets. Even though we develop themes and skins properly, the space between the portlets will still be exisiting. And in most of the scenario we want that to be controlled.

Here are few steps that needs to be followed to avoid the spaces between the portlets.

Removing Unwanted Spaces between the Portlets
a) Changing the default Skin for the themes
The custom theme or the exisiting portal theme which is applied to the portal page will have the default skin. To remove the unwanted spaces which is occuring between the portlets, first the default skin needs to be changed to "IBM No Skin" which does not contain any drag and drop feature code.

b) Modifying the applied Skin
The Skin which is applied to the page has to be modified to remove the unwanted spaces. All the javascript code related to drag and drop should be removed from skin. If "IBM No Skin" is used for the portlet then this step is not needed, as it is by default will not contain any drag and drop related code.

The above changes will remove all the extra spaces between the portlets.

Drawbacks:
Even using the above changes we get rid of the extra spaces, we are also losing the drag and drop feature. The places where drag and drop needs to be implemented, the above approach can't be used. Till WPS6.1 i believe this is the only way where you can remove the spaces between the portlets.

Regards,
Elango

Using TCP monitor in WPS

TCP Monitor:

You can use the TCP monitor which does exist in portal server itself. if you have installed portal server then you can use it using the following ways:

a) Open the cmd prompt, and navigate to AppServer\bin folder

> cd C:\IBM\WebSphere\AppServer\bin\

b) Execute the following command to open the tcp monitor:

C:\IBM\WebSphere\AppServer\bin> java -Djava.ext.dirs=C:\IBM\WebSphere\AppServer\runtimes\ com.ibm.ws.webservices.engine.utils.tcpmon

{give the runtimes path accordingly}

The tcp monitor should have opened by now. For more details: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/twbs_tracewbs.html

Regards,

Elango

Back door entry for Portal

Introduction
Did you ever faced a situation where you have deleted the login portlet by chance :) Are your custom theme hides the login portlet itself. But still IBM Web Sphere Portal allows us to login without using the login portlet i.e. back door entry for the admins.

Back Door URL

The URL to login:

https://:/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=&password=

Example: https://localhost:10035/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=wpsadmin&password=wpspwd

Regards,

Elango

Enabling Automatic JSP reloading

Introduction
Eventhough in IBM Web Sphere Portal 6.1(refered as Portal going forward) you can deploy deploy the custom theme as a separate war file, only the changes made in the defaul.jsp file will be reflected relatime. Other supporting file like head.jspf files etc.. even if you change the files, it practically it needs a application restart (In Portal 6.0 it required server restart. some what a improvement in that sense:) )

Particulary while developing the themes it would be cool if the JSP reloading is enabled. Make sure that the JSP reloading is disabled in Production and Stagging environment. Otherwise you will run into performance issues :)

Enabling Automatic JSP reloading

Steps followed:

a) Open the file<>/config/cells/cell_name/applications/ wps.ear/deployments/wps/wps.war/WEB-INF/ibm-web-ext.xmi

ie. Say the portal sever is installed in C:\ibm drive, then the path would be : C:\ibm\WebSphere\profiles\wp_profile\config\cells\citizen\applications\wps.ear\deployments\wps\wps.war\WEB-INF\ibm-web-ext.xmi

b) Change the value in the tag , reloadingEnabled to true

c) restart the portal server from WAS console

After making the above changes, changes are reflected immediatley when the files like head.jspf etc.. are changed in themes/skins

Things to Remember:

a) Performance issue will be there. use only for the testing purpose i.e. development environment. Dont use in PRODUCTION or STAGGING environment.

b) To view changes to a JSP that is included by another (parent) JSP, you must also change the parent JSP to indicate that it must be reloaded by the server.

Regards,

Elango