Service.xml

[Scott Donn Umphrey, módosítva 9 év-val korábban]

Following the example on p. 75 of Liferay in Action, I have added the service.xml and used ant build-service and ant to build and deploy the portal. The following error occurs in the log:

18:43:23,084 ERROR [localhost-startStop-11][HotDeployImpl:211] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for product-registration100-portletproduct-registration100-portletcom.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for product-registration100-portletproduct-registration100-portlet

any ideas? Thanks in advance for your help. S-

[David H Nebinger, módosítva 9 év-val korábban]

LiA was written against Liferay 6.1. If you're using 6.2, there's an errata page here somewhere w/ the differences.

The error posted doesn't really tell us anything except it couldn't register. Were there any other errors in the log

[Scott Donn Umphrey, módosítva 9 év-val korábban]

Thanks for your help David.

Here is the error when I use service.xml. It seems to be doubling the name:

14:19:26,255 ERROR [localhost-startStop-28][HotDeployImpl:211] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for product-registration300-portletproduct-registration300-portlet
com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for product-registration300-portletproduct-registration300-portlet

Thanks! S-

[Scott Donn Umphrey, módosítva 9 év-val korábban]

I have completed the entire example from Chapters 3 and 4 of Liferay in Action. I have worked througjh a lot of errors. I only have one left:

21:14:20,382 ERROR [localhost-startStop-2][HotDeployImpl:211] com.liferay.portal
.kernel.deploy.hot.HotDeployException: Error registering plugins for product-reg
istration600-portletproduct-registration600-portlet
com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugi
ns for product-registration600-portletproduct-registration600-portlet
at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.throwHotDe
ployException(BaseHotDeployListener.java:46)
at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.invokeDe
ploy(PluginPackageHotDeployListener.java:64)
at com.liferay.portal.deploy.hot.HotDeployImpl.doFireDeployEvent(HotDepl
oyImpl.java:208)
at com.liferay.portal.deploy.hot.HotDeployImpl.fireDeployEvent(HotDeploy
Impl.java:95)
at com.liferay.portal.kernel.deploy.hot.HotDeployUtil.fireDeployEvent(Ho
tDeployUtil.java:27)
at com.liferay.portal.kernel.servlet.PluginContextListener.fireDeployEve
nt(PluginContextListener.java:164)
at com.liferay.portal.kernel.servlet.PluginContextListener.doPortalInit(
PluginContextListener.java:154)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePor
talLifecycle.java:44)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLif
ecycleUtil.java:64)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLif
ecycleUtil.java:56)
at com.liferay.portal.kernel.util.BasePortalLifecycle.registerPortalLife
cycle(BasePortalLifecycle.java:54)
at com.liferay.portal.kernel.servlet.PluginContextListener.contextInitia
lized(PluginContextListener.java:116)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContex
t.java:4939)
at org.apache.catalina.core.StandardContext.startInternal(StandardContex
t.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:87
7)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.jav
a:1113)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig
.java:1671)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:47
1)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: com.liferay.portal.OldServiceComponentException: Build namespace PR h
as build number 36 which is newer than 14
at com.liferay.portal.service.impl.ServiceComponentLocalServiceImpl.init
ServiceComponent(ServiceComponentLocalServiceImpl.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(Ser
viceBeanMethodInvocation.java:115)
at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.exec
ute(DefaultTransactionExecutor.java:62)
at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(T
ransactionInterceptor.java:51)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(Ser
viceBeanMethodInvocation.java:111)
at com.liferay.portal.spring.aop.ServiceBeanAopProxy.invoke(ServiceBeanA
opProxy.java:175)
at com.sun.proxy.$Proxy94.initServiceComponent(Unknown Source)
at com.liferay.portal.service.ServiceComponentLocalServiceUtil.initServi
ceComponent(ServiceComponentLocalServiceUtil.java:288)
at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.initServ
iceComponent(PluginPackageHotDeployListener.java:247)
at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.doInvoke
Deploy(PluginPackageHotDeployListener.java:132)
at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.invokeDe
ploy(PluginPackageHotDeployListener.java:61)
... 23 more
Mar 30, 2015 9:14:20 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
Loading file:/C:/liferay/bundles/tomcat-7.0.42/temp/17-product-registration600-p
ortlet/WEB-INF/classes/service.properties
Loading file:/C:/liferay/bundles/tomcat-7.0.42/temp/17-product-registration600-p
ortlet/WEB-INF/classes/service.properties
21:14:20,787 INFO [localhost-startStop-2][PortletHotDeployListener:343] Registe
ring portlets for product-registration600-portlet
Loading file:/C:/liferay/bundles/tomcat-7.0.42/temp/17-product-registration600-p
ortlet/WEB-INF/classes/portlet.properties
21:14:21,008 WARN [localhost-startStop-2][ResourceActionsImpl:905] The communit
y-defaults element is deprecated. Use the site-member-defaults element instead.
21:14:21,009 WARN [localhost-startStop-2][ResourceActionsImpl:905] The communit
y-defaults element is deprecated. Use the site-member-defaults element instead.
21:14:21,009 WARN [localhost-startStop-2][ResourceActionsImpl:905] The communit
y-defaults element is deprecated. Use the site-member-defaults element instead.
21:14:21,010 WARN [localhost-startStop-2][ResourceActionsImpl:905] The communit
y-defaults element is deprecated. Use the site-member-defaults element instead.
21:14:21,111 INFO [localhost-startStop-2][PortletHotDeployListener:495] 2 portl
ets for product-registration600-portlet are available for use
21:14:37,150 INFO [HelloYouPortlet:82] HelloYouPortlet - doView(...) - Beginnin
g of doView(...)
21:14:37,170 INFO [HelloYouPortlet:87] HelloYouPortlet - doView(...) - username
: |Batman|
21:14:37,171 INFO [HelloYouPortlet:93] HelloYouPortlet - doView(...) - Inside f
alse of if (username.equalsIgnoreCase("no"))
21:14:37,174 INFO [HelloYouPortlet:98] HelloYouPortlet - doView(...) - End of d
oView(...)

Thanks. S-

[Scott Donn Umphrey, módosítva 9 év-val korábban]

The portlet displays as a choice in the Content Categoty named "Product Administration". But a red banner appears to the right reading:

Product Administration is temporarily unavailable.

The log shows this error:

21:18:05,347 ERROR [http-bio-8080-exec-17][render_portlet_jsp:132] null
org.apache.jasper.JasperException: /admin/view.jsp (line: 25, column: 0) The abs
olute uri: http://java.sun.com/jstl/core_rt cannot be resolved in either web.xml
or the jar files deployed with this application

[David H Nebinger, módosítva 9 év-val korábban]

Scott Donn Umphrey:

21:18:05,347 ERROR [http-bio-8080-exec-17][render_portlet_jsp:132] null
org.apache.jasper.JasperException: /admin/view.jsp (line: 25, column: 0) The abs
olute uri: http://java.sun.com/jstl/core_rt cannot be resolved in either web.xml
or the jar files deployed with this application

This is usually a result of an incorrect URI reference to a tag lib. The URI for core_rt is looked up in web.xml or in the jar files (as part of an auto-registration mechanism).

My guess - you don't have the jstl jars listed in your liferay-plugin-package.properties file as a portal dependency jar and it's therefore missing from your deployed war.

[Scott Donn Umphrey, módosítva 9 év-val korábban]

The portlet displays as a choice in the Content Categoty named "Product Administration". But a red banner appears to the right reading:

Product Administration is temporarily unavailable.

The log shows this error:

21:18:05,347 ERROR [http-bio-8080-exec-17][render_portlet_jsp:132] null
org.apache.jasper.JasperException: /admin/view.jsp (line: 25, column: 0) The abs
olute uri: http://java.sun.com/jstl/core_rt cannot be resolved in either web.xml
or the jar files deployed with this application

[David H Nebinger, módosítva 9 év-val korábban]

Scott Donn Umphrey:

Caused by: com.liferay.portal.OldServiceComponentException: Build namespace PR has build number 36 which is newer than 14

This has nothing to do with 6.1 vs 6.2.

When you build services, you get a new build number. This number is tied to both the service provider plugin and the service jar. At runtime Liferay will check the version from the service jar against the service providing plugin to ensure they match.

This is really a check to ensure that you aren't using a newer jar than the service plugin or vice versa, basically to guarantee the contract is the same on both sides.

In your case it looks like your service jar has a newer version than the deployed PR service provider.

Basic rule of thumb, when you build services you must deploy the plugin providing the service as well as every plugin that has the service jar (so they get the current copy).

[Scott Donn Umphrey, módosítva 9 év-val korábban]

Wow! This was great help. I understood the jist of your last statement, but I did not know what the specific steps should be.

From other posts I gleaned the following.

I changed src/service.properties to: build.number=36

I then ant suild-service and then ant

I noticed that it was overwritten with "build.number=37"

Now no errors in the log. the log says:

14:09:59,424 INFO [localhost-startStop-5][ServiceComponentLocalServiceImpl:322] Upgrading PR database to build number 37

I am sure that I do not fully undestand this, but I will contiue to learn. Thanks! S-

[David H Nebinger, módosítva 9 év-val korábban]

Right, so the build number is meant to keep the service jars (deployed to service consuming portlets) in sync with the service providing plugin (the one that has the service.xml file).

You should never have to set the build number manually. This kind of scenario may happen if you're working on a team where everyone is free to change the service tier, often the members will end up with different build numbers. Personally I've always found it to be advantageous to have a "service owner" who is responsible for the service code and building services, that way you can avoid these kinds of sync issues.

When you get this message, it means they are out of sync - either you built services and deployed an updated service providing plugin but didn't deploy all of the plugins using the service jar (this is the "newer than" message, service jar is reporting the service providing plugin has a newer version of service than what the service jar supports) or you build services but don't deploy, just deploy the updated service jar with a different plugin (in this case the service jar is newer than the deployed version of the service providing plugin).

So this is an important point - when you build services, you get a new build number and a new service jar tied to that number. If you deploy one, you must deploy the other. If you push the service providing plugin, then all service jars must be updated. If you deploy the new service jar, you must deploy the service providing plugin.

It's also important to note that you should not build services every time you make a code change (that just tends to get you out of sync sooner).

The only times you need to build services are a) if you change service.xml in any way or b) if you change a method signature in any of your XxxImpl classes (i.e. XxxLocalServiceImpl and the like). As long as the API, the contract, doesn't change, you don't have to build services. If you define a method in XxxLocalServiceImpl to, say, create an Xxx entity by passing in two arguments, say an int and a String. After you first define the method, you then have to build services so it is defined in the service jar, this will cause the whole redeployment thing. After this method is defined and in the service tier, though, you are free to change the body of the method and you do not have to build services. So you can bugfix the method, change the implementation, add validation/verification logic, whatever; as long as the method signature doesn't change, you don't have to rebuild services and you don't have to worry about deployments of new service jars.