Portal on Weblogic 10.3.2 #

Starting from recently (> v6.1), portal war can not be deployed on Weblogic 10.3.2. due to usage of some new xml elements (prefer-application-packages) in weblogic.xml. It is recommended to migrate to Weblogic >= 10.3.5. If you still need to deploy on Weblogic 10.3.2. do the following:

1) build portal war

2) edit weblogic.xml and use old definition header:

<weblogic-web-app
	xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
>

3) remove prefer-application-packages tags.

4) add rhino.jar to PRECLASSPATH (see below).

5) upgrade Sun Java JDK that is shipped with Weblogic 10.3.2 (see below).

WebDav on Portal 5.2 #

When WebDav Basic Auth is used (as in portal 5.2), Weblogic authenticate users by itself and does not let the portal do the auth. Add the following line in Oracle/Middleware/user_projects/domains/<domain_name>/config/config.xml, inside of <security-configuration> section.

<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials>

This prevents Weblogic to authenticate users and pass the authentication to the portal.

Portal with prefer-web-inf-classes #

Note: consider using prefer-application-packages in weblogic.xml instead!

The weblogic.xml Web application deployment descriptor contains a <prefer-web-inf-classes> element (a sub-element of the <container-descriptor> element). By default, this element is set to false. Setting this element to true subverts the classloader delegation model so that class definitions from the Web application are loaded in preference to class definitions in higher-level classloaders. This allows a Web application to use its own version of a third-party class, which might also be part of WebLogic Server.

When this setting is enabled in weblogic.xml, the following jars has to be removed from portal WEB-INF/lib (jars with javax.xml package):

• jaxrpc.jar
• stax.jar
• wstx.jar
• xml-apis.jar

Note that the author was not able to start the portal (> 6.1) this way recently.

Read more about WebLogic Server Application Classloading.

Plugins #

The prefer-web-inf-classes element may be set to true for portal plugins, too. As for portal, sometimes it is required to remove included plugin jars (usually xml-related ones, for example: xml-apis-xxx.jar).

Using newer commons-lang.jar #

Some portal modules uses features from newer version of commons-lang, that is bundled with the portal. However, this new version of commons-lang is not getting loaded since Weblogic loads its old version first (located here: Oracle/Middleware/modules/com.bea.core.apache.commons.lang_2.1.0.jar).

We have to tell Weblogic to load classes from WEB-INF and not by its original class loader. In weblogic.xml set prefer-web-inf-classes flag to true. This tells weblogic to load classes from web-inf folder first.

    <container-descriptor>
	<prefer-web-inf-classes>true</prefer-web-inf-classes>
	...
    </container-descriptor>

Note: container-descriptor nested tags must follow the order defined by xsd! Validate weblogic.xml before starting the server.

Warning #

For some web applications above change will not help. In that case, commons-lang jar needs to be added to the PRE_CLASSPATH in domain's setDomainEnv.cmd.

set PRE_CLASSPATH=...path...\commons-lang-2.x.jar;

Another option is to take the commons-lang.jar from Liferay WEB-INF/lib and put into the lib/endorsed directory of the JVM being used

Deploying plugins manually #

When WebLogic 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' the 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 WebLogic it means that this war file is copied to '/Oracle/Middleware/user_projects/domains/<domain>/autodeploy' folder. From here WebLogic should take control and continue with the plugin installation. However, if WebLogic app server is not started in development mode (or for whatever other reason), auto-deployment may not be active.
4. If autodeploy is not active, you can proceed manually and deploy that war through WebLogic administration console. Be sure that correct context path is used during deployment.

JSF library #

Portal might require Weblogic JSF library to be installed. It is located here:

/Oracle/Middleware/wlserver_10.3/common/deployable-libraries/jsf-1.2.war

and can be installed from Admin Console (as a library).

Setting VM parameters #

If, for some reason, the following doesn't work: Environment > Servers > AdminServer > Configuration tab > Server Start tab > Arguments

you can set the parameters in domains/DOMAIN_NAME/bin/setDomainEnv.cmd. Example:

line #244:
set JAVA_PROPERTIES=-Dfile.encoding=UTF8 -Duser.timezone=GMT %JAVA_PROPERTIES% %EXTRA_JAVA_PROPERTIES%

Memory settings #

Memory settings should be set differently, prior to above line. Around line #160 and dozens of line later, there are definitions for WLS_MEM_ARGS_xxBIT, MEM_ARGS_xxIT, MEM_PERM_SIZE_xxBIT, MEM_MAX_PERM_SIZE_xxBIT. There you should set memory settings, depending on your VM (sun/32bit/64bit).

Delete weblogic domain #

There is no tool for removing weblogic domain. You can delete the domain under $DOMAIN_HOME (i.e. user_projects) manually. Also check for the domain-registry.xml and for $DOMAIN_HOME/apps/<domain_name>. The config wizard will not create a new domain with the same name if $DOMAIN_HOME/apps/<domain_name> is still there.

EXT plugins and web.xml changes #

Once deployed, WebLogic will NOT pick up any web.xml changes (made directly on deployed location). Instead, a new war needs to be recreated and redeployed.

Weblogic offers alternative solution for changing web.xml: using 'deployment plan'. It is another XML file (e.g. plan.xml) that defines dynamic changes to be applied on various descriptors (without undeploying the application). To start with deployment plans, you can generate empty one using plan generator.

EXT plugin deployment #

This WebLogic feature makes EXT deployment... harder. The procedure would be like this:

1. copy somewhere existing web.xml
2. deploy EXT plugin
3. make plan.xml based on differences between the new web.xml and old one
4. use plan.xml in administration console

However, creating plan.xml may not be an easy task. Therefore, another idea, or a workaround, might be:

1. deploy portal to Tomcat
2. deploy EXT plugin on Tomcat
3. build war
4. deploy war to WebLogic

Since war is built from Tomcats deployment, it will contains all EXT stuff, including the new web.xml.

ClassNotFoundException: com.liferay.portal.util.PropsUtil #

See next section.

Deployment order #

Standalone portal is running fine on Weblogic. However, when some portlet is deployed too, the following exception may appears during portal startup:

SEVERE: java.lang.ClassNotFoundException: com.liferay.portal.util.PropsUtil
java.lang.ClassNotFoundException: com.liferay.portal.util.PropsUtil
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        at com.liferay.portal.kernel.util.MethodCache._get(MethodCache.java:110)
        at com.liferay.portal.kernel.util.MethodCache.get(MethodCache.java:62)
        at com.liferay.portal.kernel.util.MethodHandler.invoke(MethodHandler.java:79)
        at com.liferay.portal.kernel.util.MethodHandler.invoke(MethodHandler.java:75)
        at com.liferay.portal.kernel.util.PortalClassInvoker.invoke(PortalClassInvoker.java:40)
        at com.liferay.portal.kernel.util.PropsUtil.get(PropsUtil.java:32)
...

Problem is simply with deployment order: portlet gets started before the portal.

To fix this, change "Deployment Order" value for portlet (Deployments > portlet > Overview tab). Default value is 100. To make it start after the portal, use any number greater then 100, e.g. 900. Units with lower values are deployed before those with higher values.

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, WebLogic 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 client (like Windows 7).

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

IndexOutOfBoundsException #

Java 1.6-r14 that comes with Weblogic 10.3.2, has a bug with StringCharBuffer, that results with following exception during execution of StripFilter class:

java.lang.IndexOutOfBoundsException
	at java.nio.StringCharBuffer.subSequence(StringCharBuffer.java:92)

Upgrading Sun JDK #

To upgrade Sun JDK, you can simply install it over existing one (as described in the official documentation). However, it might be ugly to put new version of Java (lets say 1.6.0_22) in the folder named jdk160_14.. Therefore, you can change the java reference in the following files:

.../domains/<DOMAIN_NAME>/bin/setDomainEnv.

You need to setup this for each domain. This should work.

Printing null values in JSP #

Weblogic by default should print null values as 'null' in JSP, so the following example:

Hello: <%= name %>

would render as:

Hello: null

if 'name' is null. There is an option in Weblogic that can control this behavior: it is set in weblogic.xml, like this:

<jsp-descriptor>
<print-nulls>true</print-nulls>
</jsp-descriptor>

Read more here

Since this is a common behavior among other application servers (Tomcat, Websphere...), be sure that Weblogic is set this way!

Bug with print-nulls #

However, it seems that weblogic has a bug with this: when null value is rendered inside the tag, it is rendered as empty string, although outside of tags is rendered as 'null', as we can see in the following example:

[<%= foo %>]
<aui:script use="liferay-open-social-gadget">
	alert("[<%= foo %>]");

The first line will be rendered as 'null' but inside the tag the same null value will be rendered as an empty string.

Enable the output of system.out.println in the log file #

In the weblogic administraton console: Servers > AdminServer > Logging -> General (open advanced) and check the box "Redirect stdout logging enabled".

Performance issues #

If portal runs very slowly (e.g. login takes several minutes) try running Weblogic server in production mode. We have reports that Weblogic v10.3.3 runs very slowly in development mode. This is not case with Weblogic v10.3.2.

Development and Production mode #

To change from production mode to development mode in Weblogic 10.3 do the following change in setDomainEnv.cmd:

set PRODUCTION_MODE=false
set DOMAIN_PRODUCTION_MODE=false

Or follow the official steps to configure all servers in a domain to run in production mode:

• click Lock & Edit (see Use the Change Center).
• under Domain Structure, select the domain name.
• Select Configuration > General and select the Production Mode check box.
• Click Save, and then click Activate Changes.
• Shut down any servers that are currently running.
• Invoke the domain's startWebLogic script.

Difference between DEV and PROD #

Development mode:

• The default JDK for development domain is Sun Hotspot
• You can use the demo certificates for SSL
• Auto deployment is enabled
• Server instances rotate their log files on startup
• Admin Server uses an automatically created boot.properties during startup
• The default maximum capacity for JDBC Datasource is 15
• The debugFlag which is used to start the WebLogic Workshop Debugger is enabled

Production mode:

• The default JDK for production domain is JRockit
• If you use the demo certificates for SSL a warning is displayed
• Auto deployment is disabled
• Server instances rotate their log files when it reaches 5MB
• Admin Server prompts for username and password during startup
• The default maximum capacity for JDBC Datasource is 25
• The debugFlag which is used to start the WebLogic Workshop Debugger is disabled.

weblogic-application.xml note #

"weblogic-application.xml" file's settings will work ONLY IF you place your jar files inside "<EAR_APP>\APP-INF\lib"; i.e. in ear deployment.