When I deploy two portlets one after another in liferay the second deployed portlet is undeploying the first deployed portlet in liferay

When I am deploying two portlets in liferay 6.0.6 on tomcat server one after another portlet, the second deploying portlet is undeploying the first deployed portlet and vice versa happening when changing its order:


 2ERROR [HotDeployUtil:112] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for abc-portlet
 3com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for abc-portlet
 4    at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.throwHotDeployException(BaseHotDeployListener.java:45)
 5    at com.liferay.portal.deploy.hot.PluginPackageHotDeployListener.invokeDeploy(PluginPackageHotDeployListener.java:161)
 6    at com.liferay.portal.kernel.deploy.hot.HotDeployUtil._doFireDeployEvent(HotDeployUtil.java:109)
 7    at com.liferay.portal.kernel.deploy.hot.HotDeployUtil._fireDeployEvent(HotDeployUtil.java:182)
 8    at com.liferay.portal.kernel.deploy.hot.HotDeployUtil.fireDeployEvent(HotDeployUtil.java:38)
 9    at com.liferay.portal.kernel.servlet.PortletContextListener.doPortalInit(PortletContextListener.java:99)
10    at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycle.java:42)
11    at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:52)
12    at com.liferay.portal.kernel.util.BasePortalLifecycle.registerPortalLifecycle(BasePortalLifecycle.java:50)
13    at com.liferay.portal.kernel.servlet.PortletContextListener.contextInitialized(PortletContextListener.java:55)
14    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4135)
15    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4630)
16    at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1244)
17    at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1342)
18    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:303)
19    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
20    at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
21    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
22    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
23    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
24    at java.lang.Thread.run(Thread.java:744)
25Caused by: com.liferay.portal.OldServiceComponentException: Build namespace abc has build number 20 which is newer than 4
26    at com.liferay.portal.service.impl.ServiceComponentLocalServiceImpl.initServiceComponent(ServiceComponentLocalServiceImpl.java:128)
27    at sun.reflect.GeneratedMethodAccessor689.invoke(Unknown Source)
28    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
29    at java.lang.reflect.Method.invoke(Method.java:606)
30    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
31    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 com.sun.proxy.$Proxy74.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
09:02:30,390 INFO  [HookHotDeployListener:394] Registering hook for abc-portlet
09:02:34,913 INFO  [HookHotDeployListener:649] Hook for abc-portlet is available for use

Any Solution?

Looking at stack trace

Caused by: com.liferay.portal.OldServiceComponentException: Build namespace abc has build number 20 which is newer than 4

it seems you need to update build number.

Either change in service.properties or update build number inrelease_ table for particular portlet

you can refer to below Link


When i am deploying two portlets the earlier portlet is undeployed , When i am deploying two portlets the earlier portlet is undeployed automati. When I am deploying two portlets one after another, the previously deployed portlet changes are revert back when second portlet is deployed. Same this is happening if i am ERROR [HotDeployUtil:112] com.liferay.portal.kernel.deploy.​hot. The sandboxing feature has two limitations. First, only portlet and web plugins can be deployed on an SPI. Second, the portal ignores SPI portlet implementation classes that are not remote-safe. Implementation classes (such as asset renderers and pollers) that register with the portal fall into this category and are ignored by the portal.

I have found the solution after lots of digging and fixed the issue, you can fix this via following steps:

  1. before deployment of any portlet need to delete entry of pre-deployed portlets in lportal database from servicecomponent table via following command : eg: DELETE FROM servicecomponent WHERE buildNamespace = 'abc';

  2. Now re-deploy your portlet will not throw exception: Caused by: com.liferay.portal.OldServiceComponentException: Build namespace abc has build number 20 which is newer than 4

Problems to hot deploy portlets - Forums, I already looked at the configuration tab of the plugin portlet an I'm realy sure Can you please try to delete the deployed portlet, restart the portal and redeploy I can just copy my war file to my deploy folder and after this I see my portlet in But at first I want to deploy my portlets with the plugin installer on my linux server. A portlet has multiple instances on each page with preferences and permissions. Portlet was undeployed, but the portlets information still on pages. Observation: An undeloyed portlet from Liferay portal server only removes the portlet of visibility in the "Add Application" so that permission users can't add that portlet to a page. But portlet

Caused by: com.liferay.portal.OldServiceComponentException: Build namespace yourProject has build number x which is newer than y

Solution: go to service.properties change the build.number=x

[PDF] Liferay Developer's Guide, UNDERSTANDING THE TWO PHASES OF PORTLET EXECUTION: ACTION Local Gadget: consists in deploying the gadget in the Liferay server in the can also use AlloyUI for their custom portlets or choose any other JavaScript library specially if you are an Eclipse user, you may start by reading that chapter first and​. In versions of Liferay prior to 4.3.5, there is a property called auto.deploy.dest.dir that defines the folder where plugins are deployed after the hot deploy utilities have finished preparing them. This folder maps to a folder the container defines as an auto-deploy or a hot deploy folder.

Deploying Plugins to a Local Portal Instance – Liferay Help Center, Liferay IDE provides multiple options for deploying plugins: you can drag and drop It's almost as easy using an Ant target directly from the Plugins SDK. to your project's directory (e.g., portlets/[portlet name] ) in your Plugins SDK and enter Here are the two main components for WSRP: Producer: A web service that exposes one or more portlets and is described using a Web Services Description Language (WSDL) document. Consumer: A web service client that receives the data from the Producer and presents it to the user in a portlet window.

Portal Properties - Index of, JBoss now knows to load this portlet after the other WARs have loaded. These classes are used to process the deployment and undeployment of that the first grouping denotes utility scripts that are used by the second and third groups. Multiple portal instances might be deployed on one application server, but not all​  After writing the view code and business logic, it has to be deployed on to the Liferay server. The deployment is in the form of packaged WAR file. There is again one ANT task named “deploy” which compiles all the Java code and generates the WAR file which is then copied to Liferay server’s deployment folder (the folder named “deploy

Deploying New Liferay Projects to Liferay Server – Liferay Help Center, Click Finish. You should see the project get deployed to Liferay Tomcat server; in the console is a message indicating your new portlet is available for use. On the second screen of the wizard, enter Guestbook for the component class name, and com.liferay.docs.guestbook.portlet for the package name. Click Finish . Note that it may take a while for Developer Studio to create your project, because Gradle downloads your project’s dependencies for you during project creation.

  • After following the instructions the problem wasn't solved. Only the error from console is removed still it is undeploying the previous deployed portlet.
  • can you please check whether they are sharing same namespace or not