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).

Fix Basic Authentication issue on WebLogic #

HTTP Basic Authentication on WebLogic starting from version 9.2 (previous versions were not tested) does not work correctly. The problem is that if there is some request to your application with "Authorization" header the request will be intercepted by WebLogic itself and will not be passed to your application. WebLogic will try to make authentication itself.

Such problem can occur in your application if you are using HTTP Basic Authentication with portals SecureFilter

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>

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. 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).

prefer-application-packages #

Starting from Weblogic 10.3.5, a new descriptor tag has been added to weblogic.xml definition: prefer-application-packages. This element specifies a list of packages for classes that must always be loaded from the application. See more: Oracle doc and weblogic.xml descriptors.

From recently portal supports Weblogic >= 10.3.5 and this is the PREFERRED way how to load NEW classes.

Using newer commons-lang.jar #

(this heading is for existing references, please see the next paragraph for description)

Using newer JARs #

Portal and plugins comes with newer version of JARs than those bundled with Weblogic. However, Weblogic loads first it's own, older, JARs and not the new versions. This many be a problem when some new features of JARs are used.

Here is the list of problematic jars:

  • commons-lang.jar
  • antlr.jar
  • mozilla jars

We have to tell Weblogic to load portal/plugin JARs 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>

On weblogic 10.3.5 and later, there is even a better way for doing this, using prefer-application-packages, like this:

	<container-descriptor>
		<prefer-application-packages>
			<package-name>antlr.*</package-name>
			<package-name>org.mozilla.*</package-name>
		</prefer-application-packages>
	</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, prefer-web-inf-classes 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.

Set portal to start early #

It is a good practice to change default Deployment Order for the portal from 100 to e.g. 10. This is because all plugins will be deployed with order of 100. It happens that autodeployed plugins starts before portal and do not get registered.

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 to PRODUCTION mode, 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.
  • Restart

Once the mode set to PRODUCTION you cannot change it from Weblogic Console !!!

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

  • Stop the servers running in a domain.
  • Open the config.xml file location under MIDDLEWARE_HOME/domains/domain_name/config
  • Change the production-mode-enabled entry to false and save the file and exit
  • change the setDomainEnv.cmd:
set PRODUCTION_MODE=false

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.

*.getAttribute() and Serialization #

Objects that need to be retrieved through the ServletContext.getAttribute() method need to implement the Serializable interface. If they are not serializable, the exception java.io.NotSerializableException will be thrown.

Some of the code that ships current Apache AXIS fails because this is not the case.

Serialization also occurs on getAttribute() method invoked on servlet request and session. You can control this behavior with optimistic-serialization option that can be set on Domain (through admin console: Domains>Configuration>Web Application) or in weblogic.xml file of web application. Read more about this option here.

Basically, when optimistic-serialization is set to true (not a default value) Weblogic will NOT serialize objects on getAttribute(). When sharing Session data across WebApps of a same EAR file; Weblogic primary mechanism is to rely on serialization/deserialization to avoid ClassCastException. However, this can cause some serious performance issues which is why they have an optimistic-serialization flag that can be turned ON to avoid Weblogic triggering serialization/deserialization.

However, the debug mode is causing Weblogic to “test” your Session data, triggering serialization/deserialization. By having the Weblogic session-descriptor debug setup to true; causing Weblogic to trigger serialization/deserialization of our Session data objects.

Reference Material #

OptimisticSerialization

When OptimisticSerialization is turned on, WebLogic server does not serialize-deserialize context and request attributes upon getAttribute(name) when a request gets dispatched across servlet contexts. This means you will need to make sure that the attributes common to Web applications are scoped to a common parent classloader (they are application-scoped) or placed in the system classpath if the two Web applications do not belong to the same application. When OptimisticSerialization is turned off (which is the default) WebLogic Server does serialize-deserialize context and request attributes upon getAttribute(name) to avoid the possibility of ClassCastExceptions. The value of OptimisticSerialization can also be overridden for specific Web applications by setting the optimistic-serialization value in weblogic.xml.

Weblogic starts slow #

Weblogic 10.3g may start slow under linux (Centos 5.2) - between 5 - 20 minutes.

Turns out Weblogic uses random number generator during start up. Because of the bug in java it reads ‘randomness’ from /dev/random. /dev/random is very good random numbers generators, but it is extremely slow. It takes sometimes 10 minutes or more to generate one number. /dev/urandom is not that good, but it is instant.

Java somehow maps /dev/urandom file to /dev/random. That’s why default settings in $JAVA_HOME/jre/lib/security/java.security are useless.

Possible solution is to add “-Djava.security.egd=file:/dev/./urandom”(/dev/urandom does not work) to java parameters or change $JAVA_HOME/jre/lib/security/java.security and replace securerandom.source with

securerandom.source=file:/dev/./urandom

Weblogic uses OutputStream in JSPs #

Warning: You cannot use the response.getWriter() method from within a JSP page; if you do, a run-time exception is thrown. Use the out keyword to send the JSP response back to the browser from within your scriptlet code whenever possible. The WebLogic Server implementation of javax.servlet.jsp.JspWriter uses javax.servlet.ServletOutputStream, which implies that you can use response.getServletOutputStream(). Keep in mind, however, that this implementation is specific to WebLogic Server. To keep your code maintainable and portable, use the out keyword.

Reference: http://docs.oracle.com/cd/E15051_01/wls/docs103/webapp/reference.html

Enabling Auto Login by Using the Boot Identity File #

Browse to Oracle\Middleware11\user_projects\domains\<DOMAIN_NAME>\servers\AdminServer\security\boot.properties and edit (or add) the boot.properties file. Modify the file with the following values and save it.

username=admin
password=welcome1

Next time weblogic will not ask for the user/pass and will encrypt these in the file.

Patches #

Placing patch jar into WEB-INF/lib folder of portal deployed on Weblogic will not work, as Weblogic is not using alphabetical ordering like Tomcat does.

One solution is to put the patch under DOMAIN_HOME/lib.

Using shared library feature didn't work.

Mime Types #

Some mime types are not set and there might be a problem when vieweing content in some browsers. For example, PNG images are not shown in IE10. To set MIME types, just add them in web.xml:

<mime-mapping>
    <extension>png</extension>
    <mime-type>image/png</mime-type>
</mime-mapping>

Done.

Redeploying #

Put file named 'REDEPLOY' in WEB-INF folder.

0 Anhänge
109137 Angesehen
Durchschnitt (2 Stimmen)
Die durchschnittliche Bewertung ist 5.0 von max. 5 Sternen.
Kommentare
Antworten im Thread Autor Datum
When this setting is enabled in weblogic.xml,... liferay learner 24. August 2013 02:27

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.

>> Did the author try to bring up Liferay 6.1.1 CE release with Weblogic 10.3.6 using this method. If he did, then could he update this document.
Gepostet am 24.08.13 02:27.