Reload portal #

In, set to false if the portal needs to be reloaded under WebSphere.


Using GMail #

WebSphere7 tip - Using GMail

Deploying plugins manually #

When WebSphere server is not set for automatic plugins deployment, additional themes/portlets has to be deployed manually, following these steps.

  1. Invoke ant in plugins folder to compile to build the plugin war file. This war is also copied to bundles/deploy folder. Please note that this file is NOT a deployable war!
  2. After few moments, portal will 'notice' a new war file, 'pick it up' and create a 'real', deployable, war.
  3. In this step, portal usually tries to auto-deploy the new war. For WebSphere it means that this war file is just copied to 'profiles/<profile>/webapps' folder. IMPORTANT: this folder is not going to be created if missing - therefore, create 'webapps' folder FIRST!
  4. Now you can deploy that war manually through Websphere administration console. Be sure that correct context path is used during deployment

Set the VM arguments #

In the topology tree, expand Servers and click Application Servers.

Click the name of the application server for which you want to set the VM parameters

On the application server page, click Configuration tab > Server Infrastructure > Java and Process Management > Process definition

On the Process Definition page, click Java Virtual Machine.

Edit Generic JVM arguments field. For example:

-Xmx1024M -Dfile.encoding=UTF8 -Duser.timezone=GMT

Save configuration.

IBM VM vs SUN VM on properties files (JCR, JackRabbit) #

If you use the JackRabbit the following exception may occur:

 javax.jcr.NamespaceException: : is not a registered namespace uri.

The problem is that IBM and SUN have different interpretations of what a properties file can contain. With SUN vm it is legal to have an empty key, but with IBM vm this is not allowed.

Possible solutions:

  • Use SUN JDK (not yet sure if this works)
  • Use IBM JDK >= 1.6 SR6
  • Use IBM JDK < 6
  • or use patched jackrabbit-core, as in the portal.

Jackrabbits claims that they fixed issue JCR-888; unfortunately, it was still not working for us. Hence we made patched version that now works.

WARNING: be aware not to mix files/folders created when JCR is on! It might happens that some folders/files are created/uploaded when server start on tomcat or when different hook is used. This will later not work when JCR hook is on.

Fixing '' exception #

The actual problem happens when you switch from one JVM to another (IBM to Sun/Oracle). Liferay stores the encryption key algorithm in the company table of the database. Each JVM generally has its own algo implementation and thus when you move from one JVM to another, you will need to do the following to repair:

  1. Remember the companyId and accountId of the companies in the table.
  2. Delete the rows in the table.
  3. Restart the portal (it will automatically create a new company when it cannot find the desired one, creating a key that's valid for your new JVM)
  4. Shutdown the portal
  5. Go into the database and set the companyId and accountId fields to the previous values.

Fixing 'Application already exists in the configuration repository' #

If you (un)deploy a lot, you may starting getting this error, that means that you have broken Websphere Application Server application to a very good extend that now you cannot deploy or un-deploy that particular application.

In order to fix this issue we need to do a manual process of deleting the application. Steps:

  • Stop the WAS
  • Do a search for your ear file in the file system and delete all the occurrences of the XXX.ear folder
  • Once we deleted these entire XXX.ear folders, delete all the contents of temp and wstemp folder.
  • Go to WAS_INSTALL_DIR\profiles\<profileName>\default\config\cells\<cellName>\nodes\<nodeName>\
  • Edit the file serverindex.xml for an entry for our application within the tag <deployedApplications>xxx.ear</deployedApplications>
  • Restart WAS
  • Redeploy the application to the WAS....== Enabling Security ==

By default, security is disabled in WAS 7. To enable it, do the following: In the Admin Console, go to: Security > Global Security and make sure the "Enable application security" checkbox is checked. You may need to restart the server after saving changes.

Even beter, you may take the "Security Configuration Wizard". It will enable security and also set the master admin user. By default you may use simle federated repositories. Note: wizard will clean previous setting.

Changing the default port #

 Click on Servers > Application servers. Select server, go to "Configuration" tab. Under "Communication" section, click on "Ports".

Click on the port name you want to change. For default http transport port click on WC_defaulthost.

Change the value from 9080 to 8080 (or whatever). Apply and save the changes (ignore the warning)

 Now click on Environment > Virtual Hosts. This page would display all the virtual hosts present in the system. Click on default_host. Click on Host Aliases. Click on the port you want to change (9080).

Apply and Save the changes to Master Repository.

Restart the server and now the server will start binding to the new port.

Windows WebDav can't connect to portal #

One of the reasons may be not setting the user.timezone to GMT. When timezone is not set, WebSphere detects the timezone from locale. When locale is not GMT, portal returns WebDav xml that containts dates in other timezones (like CET) and that does not work for some Micorosoft WebDav clients (like Windows 7).

Setting the proper timezone setting based on GMT should fix this issue.

getQueryString() issue #

Websphere has a bug with getQueryString(). Check out:

query: foo=null
query_string: null

query: foo=xxx
query_string: null

query: foo=xxx
query_string: null

fwd to /hello
query: null                     <----- BUG!
query_string: foo=xxx

query: one=0
query_string: null

fwd to /index2?one=1
query: one=1
query_string: one=0

fwd to /hello
query: null             <----- BUG! should be "one=1"
query_string: one=1     <----- BUG! should be "one=0"

c3po issues #

When c3po.jar is used (by default), portal can not be restarted inside Websphere. The exception looks like this:

BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext

but the core issue is in c3po.jar. There is no way to solve this issue. I've moved c3po.jar into various locations (AppServer/lib, AppServer/lib/ext, AppServer/java/jre/lib, AppServer/java/jre/lib/ext ..). I've tried creating a shared library, too, but that didn't work. So now the only workarounds are:

  • if you need to use c3po.jar, you can't restart portal; just restart the whole Websphere server.
  • otherwise, use WAS datasource.

This is not the portals issue:

Remove profile #

manageprofiles.bat -delete -profileName Test

Filter initialization issue #

For WAS <, see:

Set user.timezone ! #

Don't forget to set JVM argument: -Duser.timezone=GMT as many things can go wrong with Websphere and IBMs JDK (i.e. date conversion). This can be set in: Application servers > server1 > Process Definition > Java Virtual Machine > Generic JVM arguments.

Deployment order #

Set numerical value in: Business-level applications > liferay-portal > liferay-portal > Startup behavior Lower number starts first.

Start Script #

You can build the startup script fom WebSphere by invoking:

bin/ server1 -script

in your profile folder. This command , for example, creates batch file on linux. By editing this script you can adjust all JVM options manually, enable debugging etc.

Java 2 security with WebSphere Portal #

Java2 (J2SE) security provides a policy-based, fine-grain access control mechanism that increases overall system integrity by checking for permissions before allowing access to certain protected system resources. J2SE security allows you to set up individual policy files that control the privileges assigned to individual code sources. If the code does not have the required permissions and still tries to execute a protected operation, the Java Access Controller will throw a corresponding security exception.

Policy files assign individual permissions to individual code sources. WAS uses a specific set of policy files to set up Java 2 Security. The following table contains information on the policy files and their protection scope:

AppServer_rootjava/jre/lib/security/java.policy - This is the root policy file that contains permissions for all the processes launched by WAS

wp_profile_root/properties/server.policy - This policy file grants default permissions to all product servers.

wp_profile_root/properties/client.policy - This policy file grants default permissions for all of the product client containers and applets on a node.

wp_profile_root/config/cells/cell_name/nodes/node_name/spi.policy - This template is for the Service Provider Interface (SPI) or the third party resources that are embedded in the product. The default permission is

wp_profile_root/config/cells/cell_name/nodes/node_name/library.policy - This policy grants default permissions (empty) to code contained in the shared library (Java library classes) to use in multiple product applications.

wp_profile_root/config/cells/cell_name/nodes/node_name/app.policy - This policy grants default permissions to all enterprise applications running on this node in this cell.

wp_profile_root/config/cells/cell_name/applications/ear_file_name/deployments/application_name/META-INF/was.policy - This policy assigns permissions to a specific enterprise application, imbedded within EAR:/META-INF/was.policy.

rar_filename/META-INF/was.policy.RAR - This file can have a permission specification that is defined in the ra.xml file. The ra.xml file is embedded in the RAR file.

Note: The application server searches for was.policy files in the enterprise application archive rather than the Web application archive comprising a portlet. Therefore, the portal server copies was.policy from the appname.war/META-INF directory to the generated appname.ear/META-INF directory during deployment of a portlet WAR file.

Enable MIME Type for SWF #

By default, SWF extension and MIME type is not defined in WAS. This causes IE to behave bad, as returned mime type is "plain/text" but should be 


Go to: Virtual Hosts > default host > MIME types and add mime type for SWF and swf extensions.

Request params without EQUALS #

WAS does not like request parameters without '='. They are simply ignored.

This is WAS issue:


It is fixed in,

To get this new behavior please add this new WebContainer custom property to the server (Application servers > server1 > Web container > Custom properties): =true(default =false).

Restart the server for the custom property to take effect.

Enabling AutoDeploy when security it's enabled #

(this tip is provided by Denis Signoretto)

0) Check default protocol used by wsadmin: look at if it’s configured to use SOAP or RMI as default protocol (default

In the former case we will need to be modified soap.client.props in the latter sas.client.props

1) Edit soap.client.props: modifying  the following properties (see this): (by default it’s prompt)

2) If you want, password can be obfuscated using utility:

Write your password in plain text, save your property file, save and exit. At command prompt, type  this command:         


It will replace cleartext password in  your original soap.client.props  file and creates soap.client.props.bck as a backup

3) Restart WAS

See this too.

0 Attachments
Average (0 Votes)
The average rating is 0.0 stars out of 5.
Threaded Replies Author Date
@Deploying plugins manually 4.Now you can... Gerhard Karl August 10, 2011 7:35 AM
should be "/wsrp-portlet" Igor Spasić February 1, 2012 7:58 AM
Could someone explain in detail the manual... Jerry Hegeduis March 7, 2012 10:48 AM
Hi, Could you please give me more detailed... Cristian Roldan December 15, 2012 3:42 AM
I have defined WAS Datasource and updated... Denis Signoretto February 19, 2013 6:57 AM
Sure, since you are not using it:) Igor Spasić February 19, 2013 7:44 AM
Hi Igor, even though I removed c3p0.jar from... Denis Signoretto March 14, 2013 8:41 AM

@Deploying plugins manually
4.Now you can deploy that war manually through Websphere administration console. Be sure that correct context path is used during deployment.

What is the CORRECT Context path for WSRP Portlet,
if the context path of liferay portal is "/portal"?
Posted on 8/10/11 7:35 AM.
should be "/wsrp-portlet"
Posted on 2/1/12 7:58 AM in reply to Gerhard Karl.
Could someone explain in detail the manual plugin installation? Not having much luck following what is posted here. For example I downloaded the web-form- plugin but don't see where to invoke an ant build.

Posted on 3/7/12 10:48 AM.
Hi, Could you please give me more detailed information about step 1:

Deploying plugins manually #

When WebSphere server is not set for automatic plugins deployment, additional themes/portlets has to be deployed manually, following these steps.

1) Invoke ant in plugins folder to compile to build the plugin war file. This war is also copied to bundles/deploy folder. Please note that this file is NOT a deployable war!
Posted on 12/15/12 3:42 AM.
I have defined WAS Datasource and updated To solve the issue with c3p0 can I safely remove c3p0.jar from Liferay webapp?
Posted on 2/19/13 6:57 AM.
Sure, since you are not using itemoticon
Posted on 2/19/13 7:44 AM in reply to Denis Signoretto.
Hi Igor,

even though I removed c3p0.jar from liferay webapp I still can stop and restart Liferay (WAS I get this error:

ERROR [WebContainer : 6][BasePortalLifecycle:45] com.liferay.portal.kernel.bean.BeanLocatorException: java.lang.IllegalStateException: BeanFacto
ry not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
com.liferay.portal.kernel.bean.BeanLocatorException: java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before a
ccessing beans via the ApplicationContext
at com.liferay.portal.bean.BeanLocatorImpl.locate(
at com.liferay.portal.kernel.bean.PortalBeanLocatorUtil.locate(PortalBeanLocatorUti­
at com.liferay.portal.dao.orm.hibernate.region.MBeanRegisteringPortalLifecycle.doPo­rtalInit(
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycl­
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.­java:64)
at com.liferay.portal.kernel.util.BasePortalLifecycle.registerPortalLifecycle(BaseP­
at com.liferay.portal.dao.orm.hibernate.region.LiferayEhcacheRegionFactory.start(Li­
at com.liferay.portal.dao.orm.hibernate.region.SingletonLiferayEhcacheRegionFactory­.start(
at org.hibernate.impl.SessionFactoryImpl.<init>(
at org.hibernate.cfg.Configuration.buildSessionFactory(

Any suggestion?
Posted on 3/14/13 8:41 AM in reply to Igor Spasić.