Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Alexey Kakunin
JPA support in Liferay 6.0.5
February 13, 2011 4:19 PM
Answer

Alexey Kakunin

Rank: Expert

Posts: 370

Join Date: July 7, 2008

Recent Posts

Hi!
One of the feature, announced in Liferay 6 was support for working with database through JPA (EclipseLink) instead of Hibernate.

Just tried to use it, following instructions in these wiki pages:
* JPA on Tomcat
* JPA on Glassfish v2

And got same problem (trying all: tomcat 6.0.26, glassfish 2.1.1 and glassfish 3.0.1 as servers):

 1
 222:37:51,593 ERROR [ContextLoader:225] Context initialization failed
 3java.lang.LinkageError: loader constraint violation: loader (instance of org/springframework/context/support/ContextTypeMatchClassLoader$ContextOverridingClassLoader) previously initiated loading for a different type with name "org/aopalliance/intercept/MethodInvocation"
 4    at java.lang.ClassLoader.defineClass1(Native Method)
 5    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
 6    at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
 7    at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
 8    at org.springframework.context.support.ContextTypeMatchClassLoader$ContextOverridingClassLoader.loadClassForOverriding(ContextTypeMatchClassLoader.java:109)
 9    at org.springframework.core.OverridingClassLoader.loadClass(OverridingClassLoader.java:61)
10    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
11    at java.lang.Class.getDeclaredMethods0(Native Method)
12    at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
13    at java.lang.Class.getDeclaredMethods(Class.java:1791)
14    at org.springframework.util.ReflectionUtils.doWithMethods(ReflectionUtils.java:448)
15    at org.springframework.util.ReflectionUtils.doWithMethods(ReflectionUtils.java:430)
16    at org.springframework.util.ReflectionUtils.getAllDeclaredMethods(ReflectionUtils.java:472)
17    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.getTypeForFactoryMethod(AbstractAutowireCapableBeanFactory.java:634)
18    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.predictBeanType(AbstractAutowireCapableBeanFactory.java:573)
19    at org.springframework.beans.factory.support.AbstractBeanFactory.isTypeMatch(AbstractBeanFactory.java:491)
20    at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:316)
21    at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:394)
22    at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:594)
23    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:407)
24    at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:276)
25    at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:197)
26    at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
27    at com.liferay.portal.spring.context.PortalContextLoaderListener.contextInitialized(PortalContextLoaderListener.java:47)
28    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
29    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
30    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
31    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
32    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)
33    at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:637)
34    at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:563)
35    at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:498)
36    at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
37    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
38    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
39    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
40    at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
41    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
42    at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
43    at org.apache.catalina.core.StandardService.start(StandardService.java:519)
44    at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
45    at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
46    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
47    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
48    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
49    at java.lang.reflect.Method.invoke(Method.java:597)
50    at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
51    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
5213.02.2011 22:37:51 org.apache.catalina.core.StandardContext start
53SEVERE: Error listenerStart


Does anybody was able to make Liferay 6.0.5 working though JPA?

==
Alexey Kakunin
EmForge: Liferay Based Project Hosting Service
Alexey Kakunin
RE: JPA support in Liferay 6.0.5
February 13, 2011 4:35 PM
Answer

Alexey Kakunin

Rank: Expert

Posts: 370

Join Date: July 7, 2008

Recent Posts

OK, it looks like it is Spring 3.0.3 (used in Liferay 6.0.5) issue
I was able to make it working with Liferay 6.0 EE Sp1 (which used Spring 3.0.5) - only thing- it is not possible to remove hibernate3.jar from classpath (as described in wiki), since some classes in Liferay still required (ClassDefNotFound exception threw) classes from Hibernate

==
Alexey Kakunin
EmForge: Liferay Based Project Hosting Service
Peter Poschenrieder
RE: JPA support in Liferay 6.0.5
May 5, 2011 10:26 AM
Answer

Peter Poschenrieder

Rank: New Member

Posts: 1

Join Date: May 5, 2011

Recent Posts

We had the same problem and tried to fix it by using Spring 3.0.5 without success. Using Liferay community edition 6.0.6 did not help either. The root cause is obviously the classloader issue described in The java.lang.LinkageError: loader constraint violation" demystified . We fixed the problem by loading the class "org.aopalliance.intercept.MethodInvocation" explicitly before the Spring method ContextLoderListener.contextInitialized() is called.
Alexey Kakunin
RE: JPA support in Liferay 6.0.5
May 5, 2011 1:30 PM
Answer

Alexey Kakunin

Rank: Expert

Posts: 370

Join Date: July 7, 2008

Recent Posts

Actua;lly my suggestion to anybody who will try to use JPA for Liferay - forgot about it! Even you will manage to fix all these problems - it still very-very-very far from production-ready state!

==
Alexey Kakunin
EmForge: Liferay Based Project Hosting Service
Hitoshi Ozawa
RE: JPA support in Liferay 6.0.5
May 5, 2011 2:44 PM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

Actua;lly my suggestion to anybody who will try to use JPA for Liferay - forgot about it! Even you will manage to fix all these problems - it still very-very-very far from production-ready state!


That's why I recommend putting all business logic in an external application server instead of Liferay. The only problem is with the workflow.
Mika Koivisto
RE: JPA support in Liferay 6.0.5
May 5, 2011 4:04 PM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1499

Join Date: August 7, 2006

Recent Posts

I don't even know why we bothered to make it possible to switch Liferay core to use JPA. Probably to accommodate Google AppEngine or some other platform. JPA is fine for for your own plugins but I would let the core use Hibernate as it's what QA tests.
ignacio garcia
RE: JPA support in Liferay 6.0.5
April 28, 2013 7:51 AM
Answer

ignacio garcia

Rank: New Member

Posts: 1

Join Date: March 3, 2011

Recent Posts

Hitoshi Ozawa:


That's why I recommend putting all business logic in an external application server instead of Liferay. The only problem is with the workflow.


Hi Hitoshi,

We have decided to develop several portlets with the following architecture in mind:

* presentation layer: vaadin framework; MVP/MVVM pattern
* business layer:
- business objects containing all business logic, backed by JPA persistence
- services as workflows of operations on business objects, responding to use cases or steps in a business process
- workflow framework (Activiti) in order to model some corporative business processes involving different roles and tasks
* persistence: JPA


After some google and forum research it seems to be not very easy to accomodate this into liferay: problems accessing same business logic (other than service builder provided) from different portlets, classloader issues, spring contexts...

Maybe we have missed something here (any enlightenment welcome) but as you recommended putting all business logic in an external application server... could you give us a brief description or tip about such a deployment??

To put it all on the table, our business objects/custom services might be used together with some liferay builtin services in the same workflow, and maybe we'll have to access our services within a velocity template called by web content display/asset publisher portlet.

We are using the tomcat bundle (6.1 GA2)... any issue with a liferay cluster deployment if we need more resources in the future?


(For the tempted reader... please, solutions in the direction of "don't do that! try service builder instead"... or the like, are not solutions to us...emoticon )

Thanks in advance!
Jack Bakker
RE: JPA support in Liferay 6.0.5
April 28, 2013 2:33 PM
Answer

Jack Bakker

Rank: Liferay Master

Posts: 513

Join Date: January 3, 2010

Recent Posts

nice post ignacio garcia : I learned from it, thanks

all business logic in one subsystem might be similar to asking for one person to do it all within a one development team

there is the JPA vs Hibernate question ; good to have a platform where you might choose on persistence layer : I used to favour OJB and still have to for other non-Liferay 'systems'

--

there is a scrabble flash game I have been playing recently ; it is lots of fun ; I have 5 tiles where I place them side by side and am asked to spell a 5 letter or less letter word ; how does each tile know what the other is thinking in order to create the view for the ultimate human player ? I bought the game so good for Hasbro.

--

I am just an outside guy ; but I certainly like Liferay for many things. Depends on what you need I guess. It is evolving tho and contributors help I am gathering. Not sure if there is another portal so open to such an opportunity from whoever to evolve this.
David H Nebinger
RE: JPA support in Liferay 6.0.5
April 28, 2013 7:13 PM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 6230

Join Date: September 1, 2006

Recent Posts

ignacio garcia:
(For the tempted reader... please, solutions in the direction of "don't do that! try service builder instead"... or the like, are not solutions to us...emoticon )


Sorry, couldn't help myself, but...

Here's the deal. When you deploy portlets in separate wars, they suffer from the same issues you have using separate servlets in separate wars. The application containers are designed to separate the separate wars from each other entirely, and for good reason. It ensures that some other servlet does not tinker with objects defined within your servlet. So they have separate class loaders, and more or less virtual walls between them.

The portal, on the other hand, does not like all of that separation. In a portal, there is a need to share beans, services, data, etc. We don't like to think of portlets as islands unto themselves, they are part of an overall system that we expect they should be able to play together.

But, at the end of the day, the portal is still running under an application container, so it comes with all of the same restrictions. The portlet specs do not really allow for the sharing of beans or data, the portlet spec really treats portlets as extensions of servlets, although the spec says that they run under a portal container and have some extra lifecycle stuff to them, so portlets will basically have the same walls between them (when deployed as separate war files) that servlets do.

So you face the same challenges that Liferay and many other portlet developers before you have faced... You have separate war artifacts containing portlets that you want to share code, functionality, and data.

At this point, I suggest you start googling for how to share spring beans in multiple servlets in separate wars. The best search I can recommend is googling for "sharing spring beans between wars" as this is, basically, what you'd like to do...

The top result is probably going to be Using a shared parent application context in a multi-war spring application. It's a pretty decent read, but unfortunately it doesn't make clear that all you're doing is sharing the bean definitions, but not the bean instances (two wars that use the parent context would each get their own instance of a particular bean as defined in the parent context, since there's still the class loader issue to deal with). Other solutions deal with using spring remoting (so you're basically sharing your beans/code/data via a remote invocation and suffering the marshalling/unmarshalling penalties in doing so), etc.

So, after doing all of this research, what is the end result? Can we share spring beans/code/data across separate wars? No. It's just not possible, and the app container is going to keep it that way.

So the only way to really share beans/code/data across wars is to have one war host it's stuff and provide services of some kind so other wars could invoke those services, thus giving you the beans/code/data access you're looking for...

Now you could spend some time building some sort of framework for doing this, maybe leveraging web services, maybe leveraging SOAP or JSON so you can pass objects around. You could address issues of running your framework within a cluster, and how you deal with caching of data in your cluster, etc.

Or you could go back and take another look at Service Builder (which takes care of all of these issues w/ the class loader yet does not have the marshalling/unmarshalling overhead of some remote call).

Or you can continue to snub your nose at SB and complain...

Your call...
Jack Bakker
RE: JPA support in Liferay 6.0.5
April 29, 2013 7:21 AM
Answer

Jack Bakker

Rank: Liferay Master

Posts: 513

Join Date: January 3, 2010

Recent Posts

And here I have been telling my 7 year old to not be so silly... perhaps I am to blame given computer thinking is only one necessary part of my life...

Service Builder is fantastic. I drive it more than I drive my car. wrt classloading trickery, I wish I had time to learn more OSGi and how JRebel works for furthering explorations to the better, but in the meantime, yeah Service Builder offers SEO much to get projects up and running faster while offering local, soap, and rest interfaces even, plus transaction control.