Liferay 5.2.3, oracle 9i, glassfish 2.1

[Roger F, geändert vor 14 Jahren.]

Am trying to evalutate liferay for a project, but cannot get it to run in (Liferay 5.2.3, oracle 9i, glassfish 2.1) setup. Persistent error involves the Counter, vis:

ERROR [IncludeTag:165] com.liferay.portal.SystemException: com.liferay.portal.kernel.dao.orm.ORMException: could not load an entity: [com.liferay.counter.model.Counter#com.liferay.counter.model.Counter]

Have tried deploying on a working gf install with war file using the portal-ext.properties file as directed in the guides, both with connection settings explicit to use liferay pooling and/or with the jndi (jndi/Liferay) setup to use glassfish connection pooling.

Have tried taking the glassfish/hsql bundle (which works out of the box), and fitting it with an oracle connection (as per portal-ext.properties). Works great on hsql, will not start up with oracle.

The oracle tables are created, the data is populated, so the database connection is working ok. The thing just will not start up with oracle on the backend - have tried various dialects of oracle (including Oracle9i, Oracle9, Oracle10g) in the portal-ext.properties . Consistently, there are problems with the counter or counterpersistence as noted above. Have also tried various permutations of ojdbc14.jar and classes12.jar with the dialects. Nothing seems to work.

Also tried to set the autocommit to true in the CounterPersistence in the portal source as suggested by some - this doesn't work either; but also sounds like a bad idea even if it did work (autocommit true in a production env ???).

I had high hopes for this as a foundation, particularly for the permissions/access hierarchy as that is crucial and integral to the new project, but am at my wits end to get this to work.

Please, suggestions like "use tomcat" or "use access " are not useful - the target environment is fixed. Anything else that helps me to get this working greatly increases the chance that liferay will be employed in another serious project !!

[Shepherd Ching, geändert vor 14 Jahren.]

I am using liferay-portal-glassfish-linux-5.2.3.jar with Oracle 10 XE, so far so good.

Here is my Oracle jdbc and portal-ext.properties:

$HOME/glassfish/domains/domain1/lib/ojdbc14.jar


$HOME/glassfish/domains/domain1/applications/j2ee-modules/liferay-portal/WEB-INF/classes/portal-ext.properties
jdbc.default.driverClassName=oracle.jdbc.driver.OracleDriver
jdbc.default.url=jdbc:oracle:thin:scott/tiger@localhost:1521:xe
jdbc.default.username=scott
jdbc.default.password=tiger

[Roger F, geändert vor 14 Jahren.]

Shepherd Ching:

I am using liferay-portal-glassfish-linux-5.2.3.jar with Oracle 10 XE, so far so good.

Here is my Oracle jdbc and portal-ext.properties:

$HOME/glassfish/domains/domain1/lib/ojdbc14.jar


$HOME/glassfish/domains/domain1/applications/j2ee-modules/liferay-portal/WEB-INF/classes/portal-ext.properties
jdbc.default.driverClassName=oracle.jdbc.driver.OracleDriver
jdbc.default.url=jdbc:oracle:thin:scott/tiger@localhost:1521:xe
jdbc.default.username=scott
jdbc.default.password=tiger

Shepherd,
Thanks for the attempt, but unless your portal-ext.properties contains an OracleDialect of some type there is general failure at startup like:
ERROR [DialectDetector:114] java.sql.SQLException: Unsupported feature java.sql.SQLException: Unsupported feature
followed by:
ERROR [PortalHibernateConfiguration:93] java.lang.RuntimeException: No dialect found java.lang.RuntimeException: No dialect found

Nonetheless, if I do exactly what you suggest - which I had tried before, the only difference being that I had put the portal-ext.properties file into the root(-1) directory as directed in the admin guide - with the addition of a dialect as in:

hibernate.dialect=org.hibernate.dialect.OracleDialect
or
hibernate.dialect=org.hibernate.dialect.Oracle9iDialect
or
hibernate.dialect=org.hibernate.dialect.Oracle10gDialect

Liferay or it's parts spew messages like crazy, vis:
[#|2009-12-08T11:09:24.976-0700|INFO|sunappserver2.1|javax.enterprise.system.stream.out|_ThreadID=17_ThreadName=httpSSLWorkerThread-8080-0;|11:09:24,976
ERROR [IncludeTag:79] Current URL /web/guest generates exception: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'wrapPortlet' in class com.liferay.taglib.util.VelocityTaglib threw exception com.liferay.portal.SystemException: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'iconOptions' in class com.liferay.taglib.util.VelocityTaglib threw exception javax.servlet.ServletException: com.liferay.portal.SystemException:
com.liferay.portal.kernel.dao.orm.ORMException: could not load an entity: [com.liferay.counter.model.Counter#com.liferay.counter.model.Counter] at _SERVLET_CONTEXT_/html/themes/classic/template/portlet.vm[line 18, column 40] at _SERVLET_CONTEXT_/html/themes/classic/templates/portal_normal.vm[line 47, column 24]

i.e. various permutations of ORMException: could not load an entity: [com.liferay.counter.model.Counter# ...


or
Caused by: com.liferay.portal.kernel.dao.orm.ORMException: could not load an entity: [com.liferay.counter.model.Counter#com.liferay.
portal.model.Resource]
at com.liferay.portal.dao.orm.hibernate.ExceptionTranslator.translate(ExceptionTranslator.java:41)
at com.liferay.portal.dao.orm.hibernate.SessionImpl.get(SessionImpl.java:143)
at com.liferay.counter.service.persistence.CounterPersistence.createCounterRegister(CounterPersistence.java:308)
... 176 more
|#]

[#|2009-12-08T11:30:30.812-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;|11:30:30,812 ERROR [JDBCExceptionReporter:101] ORA-01002: fetch out of sequence
|#]

[#|2009-12-08T11:30:30.812-0700|SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=18;_ThreadName=httpSSLWorker
Thread-8080-1;_RequestID=c51c337f-ae07-48d2-be87-0feab573eb7b;|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet jsp threw exception
com.liferay.portal.SystemException: com.liferay.portal.kernel.dao.orm.ORMException: could not load an entity: [com.liferay.counter.model.Counter#com.liferay.counter.model.Counter]



at any attempt to access the portal (i.e. redirect of http://localhost:8080).

Based on the number of page views I'm wondering ... has ANYONE run this successfully in the described environment ... note also one other difference is that I'm using windows (xp) for the development ...

[Shepherd Ching, geändert vor 14 Jahren.]

The main difference between you and me is that I am using JDK 1.6.0_12 +Liferay 5.2.3 +Glassfish 2.1 +Oracle 10XE at Debian 5.03.

My virtual machine is dedicated to run Liferay +Glassfish +Oracle only.

By using bottom up debugging, you may check your windows XP environment (CLASSPATH, PATH & task list etc.,) to see if there is any conflicts of other applications.

[Roger F, geändert vor 14 Jahren.]

Shepherd Ching:

The main difference between you and me is that I am using JDK 1.6.0_12 +Liferay 5.2.3 +Glassfish 2.1 +Oracle 10XE at Debian 5.03.

My virtual machine is dedicated to run Liferay +Glassfish +Oracle only.

By using bottom up debugging, you may check your windows XP environment (CLASSPATH, PATH & task list etc.,) to see if there is any conflicts of other applications.

Thanks again for your comments, but environment has nothing to do with it. I reproduced the problem running on a sun sparc:

-bash-3.00$ uname -a
SunOS dev2 5.10 Generic_141414-02 sun4u sparc SUNW,Sun-Fire-V490

As before, database is created and populated fine, then the first related error:

Hibernate:
    select
        counter0_.name as name0_0_,
        counter0_.currentId as currentId0_0_
    from
        Counter counter0_
    where
        counter0_.name=? for update
            |#]

[#|2009-12-10T10:13:15.835-0600|INFO|sun-appserver2.1|javax.enterprise.system.st
ream.out|_ThreadID=16;_ThreadName=Timer-7;|10:13:15,833 ERROR [JDBCExceptionReporter:101] ORA-01002: fetch out of sequence

Then the fun really begins since the Counter entity can't be loaded (see previous error messages in this thread).

It will NOT start up using oracle9i, Oracle9Dialect, ojdbc14.jar (I also could not find any permutation of dialects or other jdbc drivers that will allow it to work properly here either); whether trying to use glassfish pooling or explicitly specifying database connection parameters in the portal-ext.properties file. Comes up fine with the embedded database.

We have written many, many hibernate/spring/glassfish applications using the ojdbc14.jar and Oracle 9i that work fine - I doubt this is a driver bug.

These are regression bugs that were 'fixed' in earlier versions,
vis:
http://www.liferay.com/web/guest/community/forums/-/message_boards/message/682804

and then:
http://issues.liferay.com/browse/LPS-1831

and others involving counter/persistence. It might be a bit naive, but are there any of the target (modern) databases that don't support use of sequences for cardinality?

Supposedly as per that issue hibernate is 'no longer used' for counter persistence, but that's a hibernate query being issued; looks to me like somebody is issuing a commit after the cursor has been opened (vis 'for update'). There is something seriously wrong with the transaction semantics in liferay5.2.3 ... anytime folks start talking about autocommit in a production app, particularly when you have spring at your disposal, makes me wonder.

Given that this is a pretty generic environment, I am coming to the conclusion that liferay5.2.3 is not robust or stable enough for a real deployment - I'm done trial and erroring (emphasis on the 'erroring'!) trying to get this working.

Come on, liferay programmers/experts! Prove me wrong! (or fix the bug!!) Sorry, I just don't have the time at this point to ramp up for nuts and bolts work on the portal server itself.

[Michael C. Han, geändert vor 14 Jahren.]

Roger,

This issue you mentioned (LPS-1831) was addressed in 5.1 EE (5.1.6) and 5.2 EE (5.2.5). This is also resolved in the next major release of CE early next year.

Cheers

-m

[Roger F, geändert vor 14 Jahren.]

Michael C. Han:

Roger,

This issue you mentioned (LPS-1831) was addressed in 5.1 EE (5.1.6) and 5.2 EE (5.2.5). This is also resolved in the next major release of CE early next year.

Cheers

-m

Michael,
Thank you finally putting this to rest. I have to tell you though that I am pretty disappointed with respect to the following perspectives:

Issue 1831 doesn't appear to be listed in the 'known issues' for CE - might have saved at least one person from days of hair pulling (and proposals that have to be rethought after submission).

And I quote from the FAQ:

Liferay Portal CE is community supported and includes the latest in features.

While it is questionable that the particular issue is a 'feature', it is certainly a showstopper that prevents a subset from even getting to the features at all. How could this issue have been fixed in such early predecessors (5.1?) and not have been merged into 5.2.3 ?? I think it would be more accurate to say that you have two different codelines, one of which might (the real open source one) or might not work.

Sure, folks need to make a living, but putting out such an obviously flawed release, even as a CE, doesn't seem like the best way to do it.

Thanks again for clarifying this issue for me.

[Michael C. Han, geändert vor 14 Jahren.]

Roger F:

Michael,
Thank you finally putting this to rest. I have to tell you though that I am pretty disappointed with respect to the following perspectives:

Issue 1831 doesn't appear to be listed in the 'known issues' for CE - might have saved at least one person from days of hair pulling (and proposals that have to be rethought after submission).

And I quote from the FAQ:

Liferay Portal CE is community supported and includes the latest in features.

While it is questionable that the particular issue is a 'feature', it is certainly a showstopper that prevents a subset from even getting to the features at all. How could this issue have been fixed in such early predecessors (5.1?) and not have been merged into 5.2.3 ?? I think it would be more accurate to say that you have two different codelines, one of which might (the real open source one) or might not work.

Sure, folks need to make a living, but putting out such an obviously flawed release, even as a CE, doesn't seem like the best way to do it.

Thanks again for clarifying this issue for me.

LPS-1831 was opened in May 2009. This was well after the final releases of 5.1 CE and 5.2 CE. This was not a factor of something fixed in 5.1 and then regressed in 5.2. Unfortunately, the final resolution was in July 2009 and by then we were in the depths of 6.0 and both 5.1 and 5.2 have moved into the EE life cycles. Thus, the final resolution for the CE product line would appear in 6.0 CE.

Regarding branches, both EE and CE product lines originate from trunk. Upon release candidates, we branch trunk into say 6.0.x. Upon release of CE, a private branch is taken from the CE branch for our EE portal line. While we are developing in the portal trunk, we also have EE plugins developing in a private EE plugins trunk. Similarly, we have CE plugins developing in the public plugins trunk and plugins incubation.