Reload portal #

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

ehcache.portal.cache.manager.jmx.enabled=false

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 'com.ibm.crypto.provider.DESKey' 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:

http://localhost:9080/webtest/hello
query: foo=null
query_string: null

http://localhost:9080/webtest/hello?foo=xxx
query: foo=xxx
query_string: null

http://localhost:9080/webtest/index2?foo=xxx
query: foo=xxx
query_string: null

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

http://localhost:9080/webtest/index?one=0
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: https://forum.hibernate.org/viewtopic.php?p=2405749#p2405749

Remove profile #

manageprofiles.bat -delete -profileName Test