Portal 6.1.20 on JBoss 5.1 #

+ Download the JBoss EAP in $JBOSS folder and extract it

+ Navigate to $JBOSS/server/default/lib. Add the Liferay dependencies (hsqldb.jar, portlet.jar, portal-service.jar) and mysql.jar.

+ Delete the following in $JBOSS/common/lib:

  • hibernate-validator.jar
  • hsqldb.jar
  • hsqldb-plugin.jar

+ Navigate to $JBOSS/server/default/conf and edit login-config.xml. Comment out the blocks with the name "HsqlDBRealm" and "JmsXARealm".

+ Delete the following in $JBOSS/server/default/deploy:

  • messaging
  • ejb2-container-jboss-beans.xml
  • ejb2-timer-service.xml
  • ejb3-connections-jboss-beans.xml
  • ejb3-container-jboss-beans.xml
  • ejb3-interceptors-aop.xml
  • ejb3-timerservice-jboss-beans.xml
  • hsqldb-ds.xml
  • jms-ra.rar
  • mail-ra.rar
  • mail-service.xml
  • profile-service-secured.jar
  • uuid-key-generator.sar

+ Delete the following in $JBOSS/server/default/deployers:

  • jboss-ejb3-endpoint-deployer.jar
  • messaging-definitions-jboss-beans.xml

+ Navigate to JBOSS/server/default/deploy/ROOT.war. Clear contents in folder. Extract the liferay.war.

+ Delete the following in $JBOSS.../ROOT.war/WEB-INF/lib:

  • jaxrpc.jar
  • stax.jar
  • xercesImpl.jar
  • xml-­apis.jar

Plugins #

In order to hot deploy in the correct place, configure the portal-ext.properties with the following:

auto.deploy.jboss.dest.dir=${jboss.home.dir}/server/default/deploy
#(This one can be left like this, it will usually always detect)

auto.deploy.deploy.dir=E:/home/deploy
#(This one needs to be the exact folder where you are going to be placing your .war files into.)

java.lang.ClassCastException: MySQLDialect cannot be cast to Dialect #

The following exception may occur during plugin deployment on JBoss 5.1 and Portal 6.1.20:

Caused by: org.hibernate.HibernateException: Could not instantiate dialect class
....
Caused by: java.lang.ClassCastException: org.hibernate.dialect.MySQLDialect cannot be cast to org.hibernate.dialect.Dialect
        at org.hibernate.dialect.resolver.DialectFactory.constructDialect(DialectFactory.java:156)
        ... 100 more

This happens because JBoss comes with its own hibernate jars. Therefore, we must somehow tell portal and plugins to ignore these jars. In other words, portal must use its own hibernate, and plugins must not use JBoss hibernate. This is how this can be accomplished. Btw, this procedure can be done before WAR deployment or after the deployment (when the server is down, of course).

We need to add files jboss-classloading.xml to the WEB-INF folder of portal and each plugin, with the following content:

(1) for portal:

<classloading xmlns="urn:jboss:classloading:1.0"
    parent-first="false"
    domain="LiferayDomain"
    export-all="NON_EMPTY" 
    import-all="true">
</classloading>

Here we define the portal domain, not allowing parent classes to load first, and exporting all portal classes.

(2) plugin (for example, in Chat plugin):

<classloading xmlns="urn:jboss:classloading:1.0"
    domain="chat-portlet"
    parent-domain="LiferayDomain"
    parent-first="false"
    top-level-classloader="false"
    export-all="NON_EMPTY"
    import-all="false">
</classloading>

Here we define plugin domain that has parent in portal. There are other configurations for the plugin that may work, but this one has been shown to work for all current plugins in the Liferay plugins repository.

After adding these classes, restart the JBoss and plugin will be deployed.

Portal 6 on JBoss 5.1 #

Add following to portal-ext.properties

hibernate.validator.apply_to_ddl=false
hibernate.validator.autoregister_listeners=false

Although Liferays jboss-web.xml is set correctly, JBoss 5.1 may still pick up the older hibernate-validator.jar in the commons/lib folder. The exception coming is:

java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(...

Another way to fix this is to try to upgrade/remove hibernate-validation.jar in commons/lib. Source.

Installing Liferay 5.2 SP3 on JBoss 6 (M1) #

Read full article here.

Deployment order in JBoss 5 #

Sometimes the order of deployed units matters. Typical scenario is when portal is deployed under certain context (e.g. /liferay) and there are other plugins installed (e.g. themes). On startup it may happens that JBoss 5 tries to deploy plugins first (for example: /jedi-theme before /liferay); obviously this will not work.

One solution is to define the deployment order in JBoss 5 so portal (/liferay) loads first, before any other war application. For this, open: jboss-5.1.0/server/default/conf/bootstrap/deployers.xml and add the following:

   <bean name="topContextComparator">
      <constructor factoryClass="org.jboss.system.deployers.LegacyDeploymentContextComparator" factoryMethod="getInstance"/>
      <property name="suffixOrder" class="java.util.Map">
            <map keyClass="java.lang.String" valueClass="java.lang.Integer">
               <entry>
                  <key>liferay.war</key>
                  <value>690</value>
               </entry>
               <entry>
                  <key>.war</key>
                  <value>700</value>
               </entry>
            </map>
         </property>
      </bean>

We set here the ordering value (690) for liferay.war to be less then any other war file (700); JBoss will now load portal before any other plugin (or war application).

Web console #

In order to have the JBoss Web console on the web profile, one needs to copy the "management" folder from the JBoss default configuration into web.

But, this will result in an error. If you read carefully, the error message says:

NOT FOUND Depends on 'jboss.jmx:name=Invoker,protocol=jrmp,service=proxyFactory,type=adaptor'

That message actually means that the JBoss proxy factory invoker adaptor, based on the JRMP protocol, cannot be found. Differently from the default profile, the web profile deploys that component using the HTTP protocol. That declaration is actually defined in jmx-invoker-service.xml.

Now, to make the JBoss web console use the HTTP JMX invoker:

  • Open the file management/console-mgr.sar/META-INF/jboss-service.xml
  • Find the declaration: <depends>jboss.jmx:type=adaptor,name=Invoker,protocol=jrmp,service=proxyFactory</depends>
  • In that line, change jrmp into http
  • Restart JBoss (that change is not taken into account in real time sometimes)

HSQLDB and "length must be specified in type definition: VARBINARY" #

If you experience the following exception:

java.sql.SQLException: length must be specified in type definition: VARBINARY
        at org.hsqldb.jdbc.Util.sqlException(Util.java:232)
        at org.hsqldb.jdbc.JDBCStatement.fetchResult(JDBCStatement.java:1838)
        at org.hsqldb.jdbc.JDBCStatement.executeUpdate(JDBCStatement.java:207)
        at org.jboss.resource.adapter.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:249)

do the following:

  • Open the JBOSS_HOME/server/< servername>/conf/standardjbosscmp-jdbc.xml
  • Search for the "Hypersonic SQL" type-mappping in the file.
  • Change
<type-mapping>
         <name>Hypersonic SQL</name>
         <row-locking-template/>
         ...
         <mapping>
            <java-type>java.lang.Object</java-type>
            <!-- hsqldb only supports directly serializable objects for sql type OBJECT -->
            <jdbc-type>VARBINARY</jdbc-type>
            <sql-type>VARBINARY</sql-type>
         </mapping>
         ...
      </type-mapping>

to

<type-mapping>
         <name>Hypersonic SQL</name>
         <row-locking-template/>
         ...
         <mapping>
            <java-type>java.lang.Object</java-type>
            <!-- hsqldb only supports directly serializable objects for sql type OBJECT -->
            <jdbc-type>VARBINARY</jdbc-type>
            <sql-type>VARBINARY(1024)</sql-type>
         </mapping>
          ...
      </type-mapping>

Note the change in the sql-type value. It is set to random value 1024, so you might need to change it. After this change, restart the server.

install opensso.war on jboss 5 #

  • Create file opensso.war/WEB-INF/jboss-web.xml (inside the war)
  • Add this content to the file:
    <!DOCTYPE jboss-web PUBLIC "-JBossDTD Web Application 5.0EN" "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd"><jboss-web> <class-loading java2ClassLoadingCompliance='true'> <loader-repository> jbia.loader:loader=opensso <loader-repository-config> java2ParentDelegaton=true </loader-repository-config> </loader-repository> </class-loading></jboss-web>
  • start Jboss 5.1 and deploy opensso.war. Deployment will succeed without errors.

Tested with oracle_opensso_80U2.zip.See:

Portal 6.1.30, plugins and logging framework #

Some depends on SLF4J logging framework. This framework detects a binder in JBoss5 (or any other app server). When this binder is of a newer version of the logging lib, everything works. However, as in this case, app server binder is of an old version, and we can not use due to differences between logging framework versions (differences in signatures of the methods).

First step is to add util-slf4j.jar to the portal-dependency-jars property. By this addition we are telling portal to copy it from portals lib to plugins lib on deployment. Settings may look like:

portal-dependency-jars=\
   commons-codec.jar,\
   commons-httpclient.jar,\
   slf4j-api.jar,\
   util-slf4j.jar

With this we have added our own binder to the classpath and logging library will detect that, saying:

ERROR  SLF4J: Class path contains multiple SLF4J bindings.
10:37:37,729 ERROR SLF4J: Found binding in [vfszip:/D:/java/jboss-5.1.0.GA/server/default/deploy/solr-web.war/WEB-INF/lib/util-slf4j.jar/org/slf4j/impl/StaticLoggerBinder.class]
10:37:37,729 ERROR SLF4J: Found binding in [vfszip:/D:/java/jboss-5.1.0.GA/common/lib/slf4j-jboss-logging.jar/org/slf4j/impl/StaticLoggerBinder.class]
10:37:37,730 ERROR SLF4J: See [[http://www.slf4j.org/codes.html#multiple_bindings|http://www.slf4j.org/codes.html#multiple_bindings]] for an explanation.
10:37:37,734 ERROR SLF4J: Actual binding is of type [com.liferay.util.sl4fj.LiferayLoggerFactory]

Logging framework detected 2 bindings - one from JBoss and one from our jar. In this case, logging framework chooses one of these, but there is no rule which one will be chosen. TWe must 'remove' the original, JBoss logging binding.

To do so, edit file: jboss-5.1.0.GA\server\default\deployers\jbossweb.deployer\META-INF\war-deployers-jboss-beans.xml and modify bean WarClassLoaderDeployer by adding another filter package: org.slf4j. This code snippet looks like this:

   <!-- Allow for war local class loaders: in testing -->
  <bean name="WarClassLoaderDeployer" class="org.jboss.web.tomcat.service.deployers.WarClassLoaderDeployer">
     <property name="relativeOrder">-1</property>
     <property name="filteredPackages">javax.servlet,org.apache.commons.logging,org.slf4j</property>
  </bean>

When you restart JBoss5, plugin should not complain about logging framework - at least my JBoss was happy with it.

Jboss EAP 5.1 AttachmentStore exception #

The workaround is described in the JIRA issue (https://jira.jboss.org/jira/browse/JBAS-6981), and also here. You need to change the content of conf/bootstrap/profile.xml. Look for the definition of the AttachmentStore, and change the constructor line so that it starts:

<constructor><parameter class="java.io.File">

The original version doesn't have the class="java.io.File" attribute.

0 Allegati
28364 Visualizzazioni
Media (0 Voti)
La media del punteggio è 0.0 stelle su 5.
Commenti
Commenti Autore Data
Are the changes required when you download the... J B 18 ottobre 2011 13.34
Bundles should be already set up, so you don't... Igor Spasić 13 settembre 2013 2.50

Are the changes required when you download the bundle for Jboss 5.1 / Liferay 6?
Inviato il 18/10/11 13.34.
Bundles should be already set up, so you don't have to do anything - or, at least, add some minimal changes.
Inviato il 13/09/13 2.50 in risposta a Jakub B.