フォーラム

ホーム » Liferay IDE » English

構造的に表示 平面上に表示 ツリー上に表示
スレッド [ 前へ | 次へ ]
toggle
Service Builder Esteban Lopez 2010/11/05 4:25
RE: Service Builder Esteban Lopez 2010/11/05 4:26
RE: Service Builder Gregory Amerson 2010/11/05 16:45
RE: Service Builder Esteban Lopez 2010/11/08 3:26
RE: Service Builder Gregory Amerson 2010/11/08 20:42
RE: Service Builder Esteban Lopez 2010/11/09 0:45
RE: Service Builder Gregory Amerson 2010/11/09 0:54
RE: Service Builder Esteban Lopez 2010/11/10 0:53
RE: Service Builder Gregory Amerson 2010/11/10 1:01
RE: Service Builder Esteban Lopez 2010/11/10 1:14
RE: Service Builder Esteban Lopez 2010/11/10 1:16
RE: Service Builder Gregory Amerson 2010/11/10 1:24
RE: Service Builder Esteban Lopez 2010/11/10 1:32
RE: Service Builder Gregory Amerson 2010/11/10 2:53
RE: Service Builder Jack Bakker 2010/11/11 6:54
RE: Service Builder Gregory Amerson 2010/11/10 18:26
RE: Service Builder Jack Bakker 2010/11/10 18:42
RE: Service Builder Gregory Amerson 2010/11/10 18:48
RE: Service Builder Jack Bakker 2010/11/10 19:32
RE: Service Builder Esteban Lopez 2010/11/11 0:31
RE: Service Builder Jack Bakker 2010/11/11 6:53
RE: Service Builder Esteban Lopez 2010/11/11 8:18
RE: Service Builder Ray Augé 2010/11/11 8:26
RE: Service Builder Esteban Lopez 2010/11/12 1:38
RE: Service Builder Jack Bakker 2010/11/12 6:45
RE: Service Builder Gregory Amerson 2010/11/12 8:12
RE: Service Builder Jack Bakker 2010/11/20 20:03
RE: Service Builder Darshan Maharana 2011/05/04 1:43
RE: Service Builder Gregory Amerson 2011/06/20 9:01
RE: Service Builder Jack Bakker 2011/06/20 9:46
RE: Service Builder Jack Bakker 2011/06/23 19:55
RE: Service Builder Jack Bakker 2011/06/23 20:19
RE: Service Builder Jack Bakker 2011/06/12 10:44
RE: Service Builder Gregory Amerson 2011/06/14 5:46
RE: Service Builder Jack Bakker 2011/06/14 6:30
RE: Service Builder Rohit Salecha 2011/05/04 5:35
Esteban Lopez
Service Builder
2010/11/05 4:25
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

Hi greg,

I'm trying to use the service builder. I have tried to build it in a portlet plugin project (i don't know if it's the most usual). I use the tool Liferay -> Build Service and the classes are generated but when i export it to my liferay, it doesn't create de table in the database. I'm using mysql for the database.

This is my schema.xml

<?xml version="1.0"?>
<!DOCTYPE service-builder PUBLIC "-//Liferay//DTD Service Builder 6.0.0//EN" "http://www.liferay.com/dtd/liferay-service-builder_6_0_0.dtd">
<service-builder package-path="com.sample.portlet.library">
<namespace>Library</namespace>
<entity name="Prueba" table="a_prueba_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" />
</entity>
</service-builder>



Sorry for my english, and thanks
Esteban Lopez
RE: Service Builder
2010/11/05 4:26
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

sorry this code is from the service.xml
Gregory Amerson
RE: Service Builder
2010/11/05 16:45
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

Hi Esteban,

So to answer your first question, it is very normal (and best practice) to put your new entities built with service builder into a plugin. Prior to 6.0 you had to use service builder in an EXT environment but now its best to put them in a plugin. This is much more portable to future Liferay releases.

As far as the database table, when you run Build service do you see SQL scripts get created in your project? I don't exactly know how the internals of service builder work and if the database tables are created on first deploy of the portlet. So 2 questions:

1) Do you see the portlet get deployed corrected in tomcat (see the output in the console?)
2) What happens if you actually invoke the service utils to create and save a new entity in your portlet code (from a JSP in view mode, etc)? Perhaps the tables are created just-in-time to save the first entity?
Esteban Lopez
RE: Service Builder
2010/11/08 3:26
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

Hi again Greg,

In fact, I'm having a lot of problem deplying my portlets and also when I try to close my tomcat. I have a lot of exceptions lika that:

11:25:04,837 ERROR [HotDeployUtil:112] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for mi_primer_servicio-portlet
com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for mi_primer_servicio-portlet
at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.throwHotDeployException(BaseHotDeployListener.java:45)
at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.invokeDeploy(PluginPackageHotDeployListener.java:161)
at com.liferay.portal.kernel.deploy.hot.HotDeployUtil._doFireDeployEvent(HotDeployUtil.java:109)
at com.liferay.portal.kernel.deploy.hot.HotDeployUtil._fireDeployEvent(HotDeployUtil.java:182)
at com.liferay.portal.kernel.deploy.hot.HotDeployUtil.fireDeployEvent(HotDeployUtil.java:38)
at com.liferay.portal.kernel.servlet.PortletContextListener.doPortalInit(PortletContextListener.java:99)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycle.java:42)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:52)
at com.liferay.portal.kernel.util.BasePortalLifecycle.registerPortalLifecycle(BasePortalLifecycle.java:50)
at com.liferay.portal.kernel.servlet.PortletContextListener.contextInitialized(PortletContextListener.java:55)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1244)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1342)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:303)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.liferay.portal.OldServiceComponentException: Build namespace Library has build number 2 which is newer than 1
at com.liferay.portal.service.impl.ServiceComponentLocalServiceImpl.initServiceComponent(ServiceComponentLocalServiceImpl.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at com.liferay.portal.dao.jdbc.aop.DynamicDataSourceTransactionInterceptor.invoke(DynamicDataSourceTransactionInterceptor.java:44)
at com.liferay.portal.spring.aop.ChainableMethodAdvice.invoke(ChainableMethodAdvice.java:58)
at com.liferay.portal.spring.aop.ChainableMethodAdvice.invoke(ChainableMethodAdvice.java:58)
at com.liferay.portal.spring.aop.ChainableMethodAdvice.invoke(ChainableMethodAdvice.java:58)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy73.initServiceComponent(Unknown Source)
at com.liferay.portal.service.ServiceComponentLocalServiceUtil.initServiceComponent(ServiceComponentLocalServiceUtil.java:243)
at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.initServiceComponent(PluginPackageHotDeployListener.java:306)
at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.doInvokeDeploy(PluginPackageHotDeployListener.java:217)
at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.invokeDeploy(PluginPackageHotDeployListener.java:158)
... 19 more

Do you know something about that??
Gregory Amerson
RE: Service Builder
2010/11/08 20:42
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

I don't really know the problem from the stacktrace. You could try posting it over on the main forums for liferay developers that may have more insight

http://www.liferay.com/community/forums/-/message_boards/category/239390

Could you post the contents of your liferay-plugin-package.properties here?
Esteban Lopez
RE: Service Builder
2010/11/09 0:45
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

This is my liferay-plugin-package.properties

name=Mas-servicio
module-group-id=liferay
module-incremental-version=1
tags=
short-description=
change-log=
page-url=http://www.liferay.com
author=Liferay, Inc.
licenses=LGPL

I haven't modify it.

I finally build a service and it add the table to the database but I have a problem. If I try to create another service with the same namespace it fail, tomcat give me an exception like this:

com.liferay.portal.OldServiceComponentException: Build namespace Library has build number 2 which is newer than 1

You do a great work, thanks for your help greg
Gregory Amerson
RE: Service Builder
2010/11/09 0:54
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

Hi Esteban,

So here is what is happening (found out from Brian Chan) he said that in the main source folder of your portlet you should have a service.properties

1##
2## Build
3##
4
5    build.namespace=TEST
6    build.number=1
7    build.date=1289292755821
8    build.auto.upgrade=true


Notice that it has a build.number. This build.number has to be greater than the number of an existing deployed portlet. This prevents you from deploying an older copy of a plugin to tomcat where it has a newer version. This protects errors happening in the database since each new service builder build may add new columns to existing entities in the database schema.

So just either wipe out the existing deployed portlet or just modify this file in your projects to bump it to a number greater than what is deployed.
Esteban Lopez
RE: Service Builder
2010/11/10 0:53
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

Hi Greg, I have another problem this time. I finally did my service yesterday and it worked.
The problem is that I did it like a plugin portlet and its only works in this portlet. If a try to use the service from another portlet, I have a NullPointerException.

I want to build a general service, which I can use from every portlet, can you help me??
Gregory Amerson
RE: Service Builder
2010/11/10 1:01
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

So Liferay has a mechanism for this. So lets say you have multiple plugins, plugin-a-portlet and plugin-b-portlet. And then in plugin-a-portlet you create a service of some type. So in there will be a file in docroot/WEB-INF/lib/plugin-a-portlet-service.jar. This service jar has all the interfaces that you would need to use in other plugins.

So lets say in plugin-b you want to use the service from plugin-a, so in plugin-b, just copy the plugin-a-portlet-service.jar into the plugin-b-portlet/docroot/WEB-INF/lib folder. THen you can use the service UTil classes from that other plugin's jar.

The reason this works is that Liferay does classloader magic in the background to actually make that work. The technical name for this internally is called "ClassLoaderProxy" but what is nice is you don't have to worry about it at all its all handled behind the scenes.

Make sense?
Esteban Lopez
RE: Service Builder
2010/11/10 1:14
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

I have copied the service.jar to the plugin-b-portlet but the NullPointerException still appear.

This is the code from my jsp

ThemeDisplay themeDisplay = (ThemeDisplay)renderRequest.getAttribute(WebKeys.THEME_DISPLAY);
long userId = themeDisplay.getUserId();
libretoLocalServiceUtil.addBook(userId,"Prueba");

libretoLocalServiceUtil Is the class from my service. But I have the next exception:

09:09:05,817 ERROR [PortletRequestDispatcherImpl:136] org.apache.jasper.JasperException: java.lang.NullPointerException
org.apache.jasper.JasperException: java.lang.NullPointerException
at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:491)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
at com.liferay.portlet.PortletRequestDispatcherImpl.dispatch(PortletRequestDispatcherImpl.java:315)
at com.liferay.portlet.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:133)
at com.sample.jsp.portlet.JSPPortlet.include(JSPPortlet.java:109)
at com.sample.jsp.portlet.JSPPortlet.doView(JSPPortlet.java:89)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
at com.sample.jsp.portlet.JSPPortlet.doDispatch(JSPPortlet.java:62)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:101)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
at com.liferay.portlet.InvokerPortletImpl.invoke(InvokerPortletImpl.java:638)
at com.liferay.portlet.InvokerPortletImpl.invokeRender(InvokerPortletImpl.java:723)
at com.liferay.portlet.InvokerPortletImpl.render(InvokerPortletImpl.java:425)
at org.apache.jsp.html.portal.render_005fportlet_jsp._jspService(Unknown Source)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
at com.liferay.portal.util.PortalImpl.renderPortlet(PortalImpl.java:3723)
at com.liferay.portal.util.PortalImpl.renderPortlet(PortalImpl.java:3682)
at com.liferay.portal.util.PortalUtil.renderPortlet(PortalUtil.java:1168)
at com.liferay.portal.action.RenderPortletAction.execute(RenderPortletAction.java:85)
at com.liferay.portal.action.UpdateLayoutAction.addPortlet(UpdateLayoutAction.java:260)
at com.liferay.portal.action.UpdateLayoutAction.execute(UpdateLayoutAction.java:211)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at com.liferay.portal.struts.PortalRequestProcessor.process(PortalRequestProcessor.java:152)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at com.liferay.portal.servlet.MainServlet.callParentService(MainServlet.java:508)
at com.liferay.portal.servlet.MainServlet.service(MainServlet.java:485)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.servlet.filters.strip.StripFilter.processFilter(StripFilter.java:261)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:123)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.servlet.filters.gzip.GZipFilter.processFilter(GZipFilter.java:126)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:123)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.servlet.filters.secure.SecureFilter.processFilter(SecureFilter.java:182)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:123)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
at com.liferay.portal.servlet.I18nServlet.service(I18nServlet.java:101)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.servlet.filters.sso.ntlm.NtlmPostFilter.processFilter(NtlmPostFilter.java:81)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:123)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.sharepoint.SharepointFilter.processFilter(SharepointFilter.java:179)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:123)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter.processFilter(VirtualHostFilter.java:239)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:123)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:738)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:196)
at com.liferay.portal.servlet.filters.threadlocal.ThreadLocalFilter.processFilter(ThreadLocalFilter.java:35)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:123)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:465)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at com.sample.portlet.library.service.libretoLocalServiceClp.<init>(libretoLocalServiceClp.java:427)
at com.sample.portlet.library.service.libretoLocalServiceUtil.getService(libretoLocalServiceUtil.java:250)
at com.sample.portlet.library.service.libretoLocalServiceUtil.addBook(libretoLocalServiceUtil.java:233)
at org.apache.jsp.view_jsp._jspService(view_jsp.java:128)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377)
... 133 more
Esteban Lopez
RE: Service Builder
2010/11/10 1:16
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

addbook is a class that I have implemented in my service and its works in the plugin-a-portlet. The same exception is throw when i use libretoServiceUtil.create(long idlibreto)
Gregory Amerson
RE: Service Builder
2010/11/10 1:24
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

Could you send me a zip of all of your projects that you are trying to get working so that I could inspect them for potential issues?
Esteban Lopez
RE: Service Builder
2010/11/10 1:32
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

The service-portlet.zip is the project which has the service and plugin-portlet is the external porject. Both have the same view.jsp but service-portlet.zip works correctly and plugin-portlet.zip don't.
添付ファイル: plugin-portlet.zip (41.5k), service-portlet.zip (120.6k)
Gregory Amerson
RE: Service Builder
2010/11/10 2:53
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

Esteban,

Thanks for helping by sending those projects. I am going to investigate it tomorrow and get to the bottom of this. It may be that you must get the latest trunk for this to work properly. It may have been broken in 6.0.5. I'll have more info tomorrow.
Jack Bakker
RE: Service Builder
2010/11/11 6:54
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

Another way to make services available to multiple portlets is as Rick Sezov suggests in his book Liferay in Action:

Service Builder makes your services available in a convenient .jar file which is generated and placed
in the WEB-INF/lib folder of your project. You can very easily take this .jar file and put it inside
another .war file or on the global classpath of your application server. This has the effect of making the
services in that .jar file available to other plugins that might need to access those services.


I guess there are advantages and tradeoffs with both ways. Putting the service jar in global classpath like tomcat*/lib/ext requires a tomcat restart, and putting service jar in each portlet also requires effort. But both ways seem to work.

What I've been doing is create a seperate Portlet project which has all the services for multiple portlets. I then deploy it and then move the service jar to tomcat*/lib/ext. I am getting a little tired of restarting tomcat all the time though, so perhaps copying service jar to each portlet WEB-INF/lib might be faster.
Gregory Amerson
RE: Service Builder
2010/11/10 18:26
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

Hi Esteban,

Jack is correct, for 6.0.5, the only way to get inter-plugin services work is to put the service.jar from the plugin whose services you want to consume in the global classpath for tomcat (/lib/ext).

For 6.1.0 this is going to be fixed by the ClassLoaderProxy transparently just by having a copy of the service jar you want to consume from the producer plugin. But that trunk will need to stabilize a bit before you can grab a nightly and build from there (service builder optimizations going on right now in trunk).

So if you just take your producer service.jar, copy it in to tomcat/lib/ext and make sure to delete all jars from your 2 portlet plugins and it should work for 6.0.5
Jack Bakker
RE: Service Builder
2010/11/10 18:42
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

Hey Greg,

Cool, the ClassLoaderProxy of 6.1.0 looks promising for speed of development ; and for such it also sounds like there might be some advantageous IDE features also to choose 'other' portlets to distribute service jar(s) to
Gregory Amerson
RE: Service Builder
2010/11/10 18:48
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

Hi Jack,

Your exactly correct. I was just talking with one of Liferay's core engineers and the guy responsible for the classloaderproxy optimizations and we were discussing how the IDE could help make the jar copying automatic. So if you have plugin-a that produces services and then plugin-b that you want to consume, we could create a simple declarative UI in the IDE that will let developers say "plugin-b wants to consume plugin-a's services" and in the background the compile time dependencies and the deployment dependencies would be handled automatically.

We should be able to get to that well before 6.1 is final.
Jack Bakker
RE: Service Builder
2010/11/10 19:32
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

Good ; I guess trick for you is to provide such in one project with multiple portlets or available across multiple projects where projects need to know about each other ; well you are the Eclipse guy so good luck !
Esteban Lopez
RE: Service Builder
2010/11/11 0:31
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

Hi again,

I have tried to copy the .jar file in my tomcat /lib/ext but it doesn't work.
I can't use the service in the portlet-b. The IDE doesn't give me any problem but when I put the portlet in my liferay page and it throws me a NullPointerException in the ClassLoader:

08:22:55,787 ERROR [jsp:154] java.lang.NullPointerException
at com.sample.portlet.library.service.libretoLocalServiceClp.<init>(libretoLocalServiceClp.java:427)
Jack Bakker
RE: Service Builder
2010/11/11 6:53
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

try moving the jar, not copying it
Esteban Lopez
RE: Service Builder
2010/11/11 8:18
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

Hi, I've tried to move it and it doesn't still working. I'm getting crazy.
I'm going to write all the steps I have done,

1.- Create plugin-portlet with Liferay IDE
2.- Create service.xml and write it with the new entity.
3.- Build the service.xml with the liferay IDE.
4.- Write the code of the view.jsp in which I use the persistence methods of the service.
5.- Build the build.xml of the portlet with ant.
6.- Copy the service.jar to the /lib/ext
7.- Create a new plugin-portlet
8.- Use in the view.jsp of this new portlet the persistence methods of the service.

Finally the first portlet works correctly but the second one doesn't.

Am I doing something wrong??

thanks for your help
Ray Augé
RE: Service Builder
2010/11/11 8:26
答え

Ray Augé

LIFERAY STAFF

ランク: Liferay Legend

投稿: 1171

参加年月日: 2005/02/07

最近の投稿

The service jar must ONLY exists in the global classpath once you place it there.

It must NOT exist in the original plugin anymore after you placed it in the global classpath.

The reason is that in service jar there are singletons which get wired up with the implementation classes found in the originating plugin.

If the deployment process finds the singleton classes in the plugin's webapp classpath only it will ever be wired, which is why the originating plugin works, and the one referring does not.

When the service jar only exists in the global classpath, then it will be found and wired by the deployment process and so both the plugin service owner and referrer will work.
Esteban Lopez
RE: Service Builder
2010/11/12 1:38
答え

Esteban Lopez

ランク: Junior Member

投稿: 26

参加年月日: 2010/11/03

最近の投稿

Ok. But the implementation classes must be in the plugin-potlet, aren't they?
So I move the jar to the lib/ext and then I remove the service folder of the plugin and execute with ant the build.xml of the plugin-porlet??
Jack Bakker
RE: Service Builder
2010/11/12 6:45
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

work in Eclipse like usual ; ant deploy as usual (which puts *-services.jar into portlet WEB-INF/lib) ; then MOVE _only_ the *-services.jar to tomcat*/lib/ext ; then restart tomcat

it is like a regular deploy of a portlet, then just moving the *-services.jar and restarting container

as an aside, I also go to project properties, 'Java Build Path', and reference the *-services.jar in tomcat*/lib/ext so workspace knows about the likes of MyServiceLocalServiceUtil
Gregory Amerson
RE: Service Builder
2010/11/12 8:12
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

Quick note: regarding modifying the build path, the Liferay Tomcat container in the IDE will add all jars that are in tomcat/lib/ext automatically. however, in this case when you copy the new services.jar out the lib/ext you will have to either restart eclipse or close the project and reopen the project for the Liferay Tomcat classpath container to be recomputed by eclipse so it will pick up the new jar entry in /lib/ext.
Jack Bakker
RE: Service Builder
2010/11/20 20:03
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

Thanks Greg, good to know
Darshan Maharana
RE: Service Builder
2011/05/04 1:43
答え

Darshan Maharana

ランク: Junior Member

投稿: 59

参加年月日: 2007/05/29

最近の投稿

I know this is a quite late in this thread. but since I went through this experience recently, I am sharing the test results.

Thread link: http://www.liferay.com/community/forums/-/message_boards/message/8521793

-darshan
Rohit Salecha
RE: Service Builder
2011/05/04 5:35
答え

Rohit Salecha

ランク: Junior Member

投稿: 50

参加年月日: 2011/02/20

最近の投稿

Liferay Service Builder Step-By-Step.

Check this out

http://liferaydemystified.blogspot.com/
Jack Bakker
RE: Service Builder
2011/06/12 10:44
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

Hi Greg

Was good to see you at ECS. Hope you got home ok with or without your public transit to handle the 'all spread out' problem.

--

I'm wondering about v6.1 status of ClassLoaderProxy you wrote about last November.

Currently I am still taking the approach of having one portlet with all my services in it and then copying the service jar to global classpath ; my only complaint is slowdown of dev because of required container restart

If I have 10+ portlets looking to a common set of services, with new approach of copy of service jar to all portlets looking to consume common set, I wonder about path of least resistence: dll hell vs. tomcat restart ; I dream about a dependency injection way forward via a seperate xml upload to handle, where such would also allow test scenarios, but then my dreams are hazy at best and wouldn't necessarily avoid the container restart need
Gregory Amerson
RE: Service Builder
2011/06/14 5:46
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

Hey Jack,

So for 6.1 we have a nice solution for this in the IDE and portal. It uses the Required Deployment Context property in liferay-plugin-package.properties. In this scenario, you can put all your common services into one plugin, say a hook or a portlet plugin. (common-hook). These services will produce a common-hook-service.jar. Then lets say you have 10 portlets that all use services from common hook. With the new method you can just declare in each of those 10 portlets projects in the liferay-plugin-package.properties file by adding common-hook to the required-deployment-context property
1required-deployment-context=common-hook


Now with 6.1 and the latest nightly build of Liferay IDE this will do 2 things, 1) Cause Liferay IDE to automatically add a compile time dependency resolution in your 10 portlet projects to have access the common-hook-service.jar virtually without having to physically copy the jar file to either the tomcat global classpath or copying it to the WEB-INF/lib of each project. 2) During hot-deployment to Liferay, this service jar will be automatically copied to each of the 10 portlet project deployments automatically without requiring manual steps by developer.

What is nice is that you do not have to restart tomcat to have this feature, it should all be hot deployable. I plan on making a blog post about this in my new features in Liferay IDE 1.3 series.
Jack Bakker
RE: Service Builder
2011/06/14 6:30
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

Thanks Greg

That sounds great and should increase dev throughput considerably because of avoiding the tomcat restart.

Down the road...

1) should it be 'required-deployment-contexts' ? (plural) where multiple commonA-hook-service.jar,commonB-hook-service.jar can be referenced? that could get confusing though on multiple fronts

2) a 'build' then becomes a concept that involves all 10 plugins ; be interesting if LR was to support upload to staging or production of more than one plugin at a time (a + sign with additional 'browse' that appears)

--

and if there are 50 plugins consuming a common set of services, well does then tomcat restart become attractive again ?

anyways, I am going off topic for an IDE thread

fun stuff though, and thanks as always Greg
Gregory Amerson
RE: Service Builder
2011/06/20 9:01
答え

Gregory Amerson

LIFERAY STAFF

ランク: Liferay Master

投稿: 921

参加年月日: 2010/02/16

最近の投稿

What version of Liferay are you using? I know that this feature has some problems with 6.0.5 and requires a later version than that.
Jack Bakker
RE: Service Builder
2011/06/20 9:46
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

I hear you. I am currently recommending LR 6.1 EE to my clients for many reasons including this new feature we wonder about here and also other features I heard at ECS coming with 6.1 including SAML 2 identity provision, content being associated with a particular 'page' (likely also improving searching/load), better monitoring, and so on. Very good what is going on. Thanks.

I am reasonably new to Liferay (hence looking to CE to support first), coming from ColdFusion, so-called upcoming Neo where then I switched quickly to just good Java using OpenCms, but always looking for better ; shifting Enterprise decision makers takes time ... integrating Vaadin for example which I think is cutting and not bleeding at this point.

No need to respond to this brain dump. But yes v6.1 EE looks VERY good.

Thanks
Jack Bakker
RE: Service Builder
2011/06/23 19:55
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

I noted your early IDE Service Builder GUI demo at ECS ; perhaps I was dreaming it really is there just like I dream the Vaadin GUI is something I will use for wiring things up (both remind me of a former Allaire/ColdFusion guy who's name I can't remember now)

with current service builder generation, there is the *persistance that get auto-generated but still there is need for manual coding needed to reference such in either *LocalServiceImpl or *ServiceImpl ; a good approach as I have found for more control over one to many or ... etc.

some services are best local to portlets (where with your new IDE allowance for setting/sharing dependent on service(s) feature: specified portlets can share common sets of services ; cool), others might be more generally consumed by multiple portlets where for many enterprise use-cases on Liferay, such seems like it should be centralized not distributed (my current favoured approach)

GUI to wire all that up makes my head hurt

--

aside from above, I do think a wizard to create connections to biz databases would be really useful (META-INF/ext-spring.xml)
Jack Bakker
RE: Service Builder
2011/06/23 20:19
答え

Jack Bakker

ランク: Liferay Master

投稿: 606

参加年月日: 2010/01/03

最近の投稿

a per table in db definition lookup/autogenerate of service.xml entity tool would be useful also (without associations to other tables) ; generate to view for cut and paste perhaps into this or that service.xml

yes, I should be putting such into JIRA ; sorry
Angelos Varvitsiotis
RE: Service Builder
2012/12/12 21:40
答え

Angelos Varvitsiotis

ランク: New Member

投稿: 6

参加年月日: 2011/07/26

最近の投稿

Angelos Varvitsiotis:
One question, if I might: doesn't this mean that 10 different instances of the service-related beans (singleton classes) will live in the server, one for each .war?

If the answer is "yes", then is there a solution that would allow a single instance and still not require a tomcat restart? I was thinking of something like a commont parent application context for all 10 portlet plugins and the hook.


More than a year since my original question, and just in case someone else wonders about this, the answer is here: there will be one instance of the service-related implemantation classes. And 10 instances of the interface class files and the classloader proxies. The latter (interfaces and Clp's) are distributed to each dependent plugin with the service JAR. The former (implementation classes) stay with the original portlet. Spring takes care of "linking" the two, of course with the aid of the Liferay portal's core.

Angelos