Can't deploy custom portlet created in CE to EE

[Jorge Páez, modificado hace 9 años.]

Im having a lot of problems trying to deploy a custom portlet to my Liferay EE 6.2.. At first we realized that the portlet .war was created on a CE so we thought that was the problem, so we created the war on another EE but now im having some sort of stackoverflow due to a warn message and can't deploy the portlet. This is the message i got on my log:

08:29:52,974 WARN [localhost-startStop-1][PluginContextListener:83] Preventing the replacement of the plugin class loader

I got like a loop of those warnings and then the tomcat will not respond so i can't hot deploy the portlet using Eclipse and putting the war on the deploy file on the tomcat folder is not working either. I have been trying to import and deploy this portlet for hours but is not working for me. I know that there are ways to make an EE edition to be compatible with CE but since now the .war is created on another EE i just want to know what's wrong with the portlet or the way im importing it,

Im attaching the log here if you want to check it out, i will REALLY appreciate any help.

[Lokhande Vishnudas D., modificado hace 9 años.]

we have to change some properties from life-ray-plugin-package.properties file to make it work on EE.

What is happening when u put war in deploy folder?

Logs are showing that some plugins are deployed from deploy folder.

[Low Trux, modificado hace 9 años.]

Lokhande Vishnudas D.:

we have to change some properties from life-ray-plugin-package.properties file to make it work on EE.

What is happening when u put war in deploy folder?

Logs are showing that some plugins are deployed from deploy folder.

Yeah i have read t hat you can do that but as i said before we created the war again into another EE edition so that should not be a problem (i guess). The portlet that is giving me problems is dogc2014-portlet, the ones that are deploying from the deploy folder are the Liferay portlets by default.

[Neil Griffin, modificado hace 9 años.]

I wanted to mention that this error:

Caused by: java.lang.ClassNotFoundException: com.liferay.util.bridges.jsf.sun.LiferayConfigureListener

might be a side-effect of LPS-34945.

If my memory is correct, I think LiferayConfigureListener was something we needed to support the old Sun OpenPortal JSF Portlet Bridge. Now that we have Liferay Faces Bridge, the old Sun bridge is no longer supported.

[Low Trux, modificado hace 9 años.]

Neil Griffin:

I wanted to mention that this error:

Caused by: java.lang.ClassNotFoundException: com.liferay.util.bridges.jsf.sun.LiferayConfigureListener

might be a side-effect of LPS-34945.

If my memory is correct, I think LiferayConfigureListener was something we needed to support the old Sun OpenPortal JSF Portlet Bridge. Now that we have Liferay Faces Bridge, the old Sun bridge is no longer supported.

So i guess the problem lies on the fact that my backend team didn`t prepare the portlet to work outside their dev-env because it seems like is all about the portlet dependencies + conflicts regarding that matter...! sometimes i wish i know at least the basics about portlet development, if you can suggest any documentation besides the official one regarding that matter please let me know, since im a front end developer sometimes i lost a ton of time trying to figure out why things just don't work on my dev-env (specially when it comes to deploy portlets) to finally realize that the backend team just didn`t get it.

Many thanks for the feedback guys.

[Neil Griffin, modificado hace 9 años.]

Hi Low,

This is simply a guess, but it might be the case that the backend team is compiling/building with the Liferay Portal 6.1 API, and giving you a portlet .war that contains the Liferay 6.1 version of WEB-INF/lib/util-bridges.jar

If that is the case, then that portlet can only be safely deployed on Liferay Portal 6.1. I think you might be deploying the portlet to Liferay Portal 6.2.

Basically, all teams (backend and frontend) must be working with the same version of the Liferay Portal API. In addition, the versions used in the development environment should reflect the versions that will be used in the test/production environments.

Kind Regards,

Neil

[Low Trux, modificado hace 9 años.]

Neil Griffin:

Hi Low,

This is simply a guess, but it might be the case that the backend team is compiling/building with the Liferay Portal 6.1 API, and giving you a portlet .war that contains the Liferay 6.1 version of WEB-INF/lib/util-bridges.jar

If that is the case, then that portlet can only be safely deployed on Liferay Portal 6.1. I think you might be deploying the portlet to Liferay Portal 6.2.

Basically, all teams (backend and frontend) must be working with the same version of the Liferay Portal API. In addition, the versions used in the development environment should reflect the versions that will be used in the test/production environments.

Kind Regards,

Neil

Thanks Neil, is there any way to know (maybe looking at the util-bridges.jar) whats the Liferay version where the portlet was compiled / built ? Just want to be sure that that's the problem and if there's a way to check that on a Liferay File,so when it happen again i can discard that scenario really fast.

PS I just checked the portlet structure and it doesn't have that file on WEB-INF/lib.

Thanks again !

[Olaf Kock, modificado hace 9 años.]

It might be worth to investigate these entries in the log file:

09:58:44,109 ERROR [localhost-startStop-1][HotDeployImpl:230] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering servlet context listeners for dogc2014-portletdogc2014-portlet
com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering servlet context listeners for dogc2014-portletdogc2014-portlet
	at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.throwHotDeployException(BaseHotDeployListener.java:46)
	at com.liferay.portal.deploy.hot.ServletContextListenerHotDeployListener.invokeDeploy(ServletContextListenerHotDeployListener.java:40)
	at com.liferay.portal.deploy.hot.HotDeployImpl.doFireDeployEvent(HotDeployImpl.java:227)
...
Caused by: java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.ClassNotFoundException: com.liferay.util.bridges.jsf.sun.LiferayConfigureListener
...

(not sure if that'll help, I'm assuming that dogc2014-portlet is the problematic one?

[Low Trux, modificado hace 9 años.]

Olaf Kock:

It might be worth to investigate these entries in the log file:

09:58:44,109 ERROR [localhost-startStop-1][HotDeployImpl:230] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering servlet context listeners for dogc2014-portletdogc2014-portlet
com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering servlet context listeners for dogc2014-portletdogc2014-portlet
	at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.throwHotDeployException(BaseHotDeployListener.java:46)
	at com.liferay.portal.deploy.hot.ServletContextListenerHotDeployListener.invokeDeploy(ServletContextListenerHotDeployListener.java:40)
	at com.liferay.portal.deploy.hot.HotDeployImpl.doFireDeployEvent(HotDeployImpl.java:227)
...
Caused by: java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.ClassNotFoundException: com.liferay.util.bridges.jsf.sun.LiferayConfigureListener
...

(not sure if that'll help, I'm assuming that dogc2014-portlet is the problematic one?

Yeah dogc2014-portlet is the one im trying to deploy, i will try to investigate that ERROR but im just wondering if that servlet error is just because of the previous one (there's a previous one if you check the log regarding classes).