WebSphere 7 tips
Table of Contents [-]
- Reload portal
- Using GMail
- Deploying plugins manually
- Set the VM arguments
- IBM VM vs SUN VM on properties files (JCR, JackRabbit)
- Fixing 'com.ibm.crypto.provider.DESKey' exception
- Fixing 'Application already exists in the configuration repository'
- Changing the default port
- Windows WebDav can't connect to portal
- getQueryString() issue
- c3po issues
- Remove profile
- Filter initialization issue
- Set user.timezone !
- Deployment order
- Start Script
- Java 2 security with WebSphere Portal
- Enable MIME Type for SWF
- Request params without EQUALS
- Enabling AutoDeploy when security it's enabled
Reload portal #
In portal-ext.properties, set to false if the portal needs to be reloaded under WebSphere.
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.
- 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!
- After few moments, portal will 'notice' a new war file, 'pick it up' and create a 'real', deployable, war.
- 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!
- 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
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.
- 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.
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:
- Remember the companyId and accountId of the companies in the table.
- Delete the rows in the table.
- 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)
- Shutdown the portal
- 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
Filter initialization issue #
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/startServer.sh server1 -script
in your profile folder. This command , for example, creates batch file start_server1.sh 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 java.security.AllPermissions.
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:
PM35450: WEBCONTAINER RETURNS NULL VALUE FOR PARAMETER WITH no "=" in URI QUERY STRING
It is fixed in 184.108.40.206+, 220.127.116.11+
To get this new behavior please add this new WebContainer custom property to the server (Application servers > server1 > Web container > Custom properties):
com.ibm.ws.webcontainer.AllowQueryParamWithNoEqual =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 wsadmin.properties if it’s configured to use SOAP or RMI as default protocol (default com.ibm.ws.scripting.connectionType=SOAP)
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):
com.ibm.SOAP.securityEnabled=true com.ibm.SOAP.loginUserid=admin-user-name com.ibm.SOAP.loginPassword=admin-password com.ibm.SOAP.loginSource=none (by default it’s prompt)
2) If you want, password can be obfuscated using PropFilePasswordEncoder.sh 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.