Liferay is a Gartner Magic Quadrant Leader for the Sixth Year! Find out why

WebSphere 6.1

WebSphere 6.1.0.9 and Above#

Deploying Portlets #

  1. If you don't have one already, create a portal-ext.properties file in the WEB-INF/classes folder of your Liferay installation. Add the following directive to it:
auto.deploy.dest.dir=${resource.repositories.root}/websphere-deploy
  1. Create a folder called websphere-deploy inside your $LIFERAY_HOME folder. This is the folder where the Lucene index, Jackrabbit config, and deploy folders are.
  1. Make sure the web.xml file inside the plugin you want to install has the following context parameter in it:
<context-param>
     <param-name>com.ibm.websphere.portletcontainer.PortletDeploymentEnabled</param-name>
     <param-value>false</param-value>
</context-param>
  1. The WebSphere deploy occurs in two steps. You will first use Liferay's tools to "pre-deploy" the file, and then use WebSphere's tools to do the actual deployment. This is because Liferay makes deployment-time modifications to the plugins right before they are actually deployed to the application server. For other application servers, this can usually be done in one step, because Liferay can make the modifications and then copy the resulting .war file into an autodeploy folder to have it actually deployed. Because WebSphere does not have an autodeploy feature, we need to separate these two steps.
  1. Deploy your .war file using Liferay's Plugin Installer or by copying it into $LIFERAY_HOME/deploy. Liferay will make its modifications and because we changed the auto.deploy.dest.dir in the first step, it will copy the resulting .war file into $LIFERAY_HOME/websphere-deploy. You will see a "copied successfully" message.
  1. Use WebSphere's tools to deploy the .war file. Make the context root for the .war file equal to the file name (i.e., /my-first-portlet). Once the .war file is deployed, save it to the master configuration.
  1. Go back to the Applications -> Enterprise Applications screen. You will see that your portlet is deployed, but not yet started. Start it.
  1. Liferay will immediately recognize that the portlet has been deployed and register it. The portlet will be automatically started and registered upon subsequent restarts of WebSphere.

You may see the following exception in the log, which can be ignored as it does not affect the functioning of the portlet (i.e., the portlet can access the database normally without issues).  

[1/23/09 13:01:29:646 EST] 0000001d Helpers       W   NMSV0610I: A NamingException is being thrown from a javax.naming.Context implementation. Details follow:
Context implementation: com.ibm.ws.naming.jndicos.CNContextImpl
Context method: bind
Context name: enterpriseNode01Cell/nodes/enterpriseNode01/servers/server1
Target name: java_liferay:jdbc/LiferayPool
Other data: Object to bind: org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy@5dfe5dfe
Exception stack trace: com.ibm.ws.naming.util.CannotBindObjectException: Object is not of any type which can be bound.
        at com.ibm.ws.naming.util.Helpers.processJavaObjectForBinding(Helpers.java:628)
        at com.ibm.ws.naming.jndicos.CNContextImpl.doBind(CNContextImpl.java:2237)
        at com.ibm.ws.naming.jndicos.CNContextImpl.bind(CNContextImpl.java:534)
        at com.ibm.ws.naming.util.WsnInitCtx.bind(WsnInitCtx.java:210)
        at javax.naming.InitialContext.bind(InitialContext.java:371)
        at com.liferay.portal.kernel.servlet.PortletContextListener.portalInit(PortletContextListener.java:116)
        at com.liferay.portal.kernel.util.PortalInitableUtil.flushInitables(PortalInitableUtil.java:39)
        at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:435)

Unpatched WebSphere 6.1.0.x with Liferay 4.x #

Note: This information is obsolete on newer versions of Liferay and WebSphere. See above for the proper procedure. There is one root problem and that is that Websphere AS 6.1 has a custom portlet container which (at this time) cannot be turned off until they release a patch. This is interfering with Liferay as a portlet container. Another issue is that you are on Liferay 4.1.2 where JAAS cannot be toggled on/off so easily. Here are the steps using WAS 6.1 and Liferay 4.1.2: 1) Modify Liferay to point to an alternate portlet.xml This is a workaround to the WAS custom portlet container issue. IBM has fixed this issue as of WebSphere 6.1.0.9. Please see above for instructions for the procedure for that and above versions. You need to do the following - Edit MainServlet.java to pick up a different portlet.xml file. You'll want to change try { String[] xmls = new String[] { Http.URLtoString(ctx.getResource("/WEB-INF/portlet.xml")), Http.URLtoString(ctx.getResource( "/WEB-INF/portlet-ext.xml")), Http.URLtoString(ctx.getResource( "/WEB-INF/liferay-portlet.xml")), Http.URLtoString(ctx.getResource( "/WEB-INF/liferay-portlet-ext.xml")), Http.URLtoString(ctx.getResource("/WEB-INF/web.xml")) }; try { String[] xmls = new String[] { Http.URLtoString(ctx.getResource("/WEB-INF/_portlet.xml")), Http.URLtoString(ctx.getResource( "/WEB-INF/portlet-ext.xml")), Http.URLtoString(ctx.getResource( "/WEB-INF/liferay-portlet.xml")), Http.URLtoString(ctx.getResource( "/WEB-INF/liferay-portlet-ext.xml")), Http.URLtoString(ctx.getResource("/WEB-INF/web.xml")) }; All you need to do is rename it as above. You'll then want to change the name of the file under \portal\portal-web\docroot\WEB-INF and \portal\web-sites\liferay.com-web\docroot\WEB-INF . You'll then need to redeploy the war. 2) Modify Liferay to turn JAAS off In recent Liferay releases this can be turned off through the properties file. If you choose to stay on 4.1.2 you will have to do this yourself in the source code. Take a look at this LEP ticket: http://support.liferay.com/browse/LEP-2247 It has all the patch files and code diff's to be able to change the code yourself. Look at the attachments in that ticket as a to-do list, as well as reading the last comment about adding entries to PropsUtil.java. Make sure it all compiles and try doing a regular build just to make sure the portal starts without JAAS. After a recompile of course, a new war will need to be generated. After these steps, you can deploy the resulting WAR file onto WAS. (I had mentioned in my previous note to modify WAS to turn off the WAS custom portlet container, but since that cannot be done yet until a new WAS patch, step 1 above is the workaround.)

0 Attachments
32101 Views
Average (0 Votes)
The average rating is 0.0 stars out of 5.
Comments