No Hibernate Session bound to thread when trying to acces Modelclass

[Arthur Grohe, modificado hace 11 años.]

Hi guys,

I have the following setup:
+ Plugin Portlet Project with JSF 2.x and Liferay Faces Alloy
+ Liferay SDK 6.1.1, Liferay Portal 6.1 CE (Tomcat 7)

I get this exception when trying to access a model class created by the service builder from within a javaBean.

My question is: What is the recommended way to access instances of Model-Classes built by the service builder with an jsf architecture?

view.xhtml

<f:view xmlns="http://www.w3.org/1999/xhtml" xmlns:aui="http://liferay.com/faces/aui" xmlns:c="http://java.sun.com/jsp/jstl/core" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:ui="http://java.sun.com/jsf/facelets">
	<h:head />
	
	<h:body>
		<h:outputtext value="#{i18n['my-greeting-hello-world']}" />
		Book name: <h:outputlabel value="#{bookBean.book.userName}" /><!-- this causes the error! -->
	</h:body>
</f:view>

BookBean.java

import com.liferay.portal.kernel.exception.SystemException;
import com.sample.portlet.library.NoSuchBookException;
import com.sample.portlet.library.model.Book;
import com.sample.portlet.library.service.persistence.BookPersistence;
import com.sample.portlet.library.service.persistence.BookUtil;


@ManagedBean
public class BookBean {

	public Book getBook() throws SystemException{
		Book b = null;
		BookPersistence bu = BookUtil.getPersistence();
		try {
			b = bu.findByPrimaryKey(1234);
		} catch (NoSuchBookException e) {
			e.printStackTrace();
		}
	
		if(b == null){
			b = bu.create(1234);
			bu.updateImpl(b, true);
		}
		
		return b;
	}
}

service.xml

<service-builder package-path="com.sample.portlet.library">
	<namespace>Library</namespace>
	
	<entity name="Book" local-service="true" remote-service="true">  
	<!-- PK fields -->
		<column name="bookId" type="long" primary="true" />  
	
	<!-- Group instance -->
		<column name="groupId" type="long" />  
	
	<!-- Audit fields -->
		<column name="companyId" type="long" />
		<column name="userId" type="long" />
		<column name="userName" type="String" />
		<column name="createDate" type="Date" />
		<column name="modifiedDate" type="Date" />  
	
	<!-- Other fields -->
		<column name="title" type="String" />
        <column name="authorId" type="long"></column>
	</entity>
    <entity name="Author">
        <column name="authorId" type="double" primary="true"></column>
        <column name="name" type="String" primary="false"></column>
    </entity>
	
</service-builder>

[David H Nebinger, modificado hace 11 años.]

You should never access BookPersistence directly.

Instead you should be using BookLocalServiceUtil methods to access entities.

[Arthur Grohe, modificado hace 11 años.]

Thanks for the superfast answer David, and it works perfectly!

I find it very confusing that the service builder creates about 30 java classes for 1 Model
And the other even more confusing thing is, I didnt find a good documentation that told me
what classes I should use, and what the several classes do.

And the last confusing thingy is that the magically correct class MyClassLocalServiceUtil is NOT SHOWN
in the Eclipse source packages.

I only shows some of the generated service-builder classes, like *LocalServiceImpl.java, *ServiceImpl.java, *PersistenceImpl.java .....
so I have to scroll down in the Eclipse-package-explorer and look into docroot/WEB-INF/service/my/package/name/service/
And in this folder there is *LocalServiceUtil and *ServiceUtil.

Thanks again David, you saved the day!


For the ones who are interested, here is my modified bean:

BookBean.java - getBook()

	public Book getBook() throws SystemException{
		Book b = null;
		try {
			b = BookLocalServiceUtil.fetchBook(1234);
		}catch(SystemException e){
			e.printStackTrace();
		}
	
		if(b == null){
			b = BookLocalServiceUtil.createBook(1234);
			BookLocalServiceUtil.updateBook(b, true);
		}
		b.setUserName("Peter Klause");
		
		return b;
	}

[Oliver Bayer, modificado hace 11 años.]

Hi Arthur,

the MyClassLocalServiceUtil isn't shown in the eclipse source path because you should never edit this file. If you need new methods change MyClassLocalServiceImpl and then re-run the service builder so the method gets added to MyClassLocalServiceUtil. After that the MyClassLocalServiceUtil class is put into the jar file of your service. The book "Liferay in Action" can be of great help in learning the programming internals.

HTH Oli

[Arthur Grohe, modificado hace 11 años.]

Hello Oliver,

thank you for the explanation.
I find it a good idea to only show the classes in source path that the developer may modify.

But unfortunately I found some classes which are shown under the source path, generated by the service-builder, which should not be modified,
that are (assuming my Models name is "Book"):

com.sample.portlet.library.service.persistence

• BookPersistenceImpl

com.sample.portlet.library.service.base

• BookServiceBaseImpl
• BookLocalServiceBaseImpl
• BookLocalServiceClpInvoker (?)
• BookServiceClpInvoker (?)

com.sample.portlet.library.model.impl

• BookModelImpl
• BookCacheModel (?)
• BookBaseImpl

So what the service-builder builds is kind of inconsistent IMHO. It should either put all classes in the source path or really just the ones that may be modified by the developer.

[David H Nebinger, modificado hace 11 años.]

It's not structured that way, and is just a learning curve you'll need to get over...

SB creates two jars - a service jar containing methods/interfaces your class should use and the internal implementation jar your plugins never use.

In the implementation, the classes are all cleanly separated by function into their own package paths. The model package contains the model information, the service package is broken down into base (for base class info), and other sub packages to separate their functionality.

Each class generated includes a comment about what you should not modify (i.e. the base classes) and indicate where your changes should go. Basically for service changes you'll always be in the XxxLocalServiceImpl or XxxServiceImpl classes (for remote APIs).

The first SB implementation you do will be the hardest because you need to get your head around some basic yet important SB concepts. Once you get through that first implementation, it will be easier for future implementations...

[Arthur Grohe, modificado hace 11 años.]

Thanks again David,

maybe we talked about different things, maybe not...

I hope this screenshot makes everything clear: (As you can see the LocalServiceUtil is not shown in the source path)

[David H Nebinger, modificado hace 11 años.]

Right. You can make changes to the XxxLocalServiceImpl classes. The classes in the docroot/WEB-INF/service folder are generated and maintained by ServiceBuilder and you should never, ever, be editing these files (they are regenerated when you build services).