Foros de discusión
ServiceBuilder based portlets dependency
Jan Tošovský, modificado hace 9 años.
ServiceBuilder based portlets dependency
Liferay Master Mensajes: 566 Fecha de incorporación: 22/07/10 Mensajes recientes
Dear All,
I have two portlets - A - which service is shared also in B.
1. In my B.pom i have
2. In liferay-plugin-package.properties for (A) I've added: required-deployment-contexts=A-portlet
3. When both portlets are deployed, B waits till A is registered.
4. When B calls a method from A, I am getting error:
WebHelpServiceImpl is located in B
WebHelpDocumentLocalServiceUtil is located in A
Both A and B uses the same package path com.liferay.portlet.webhelp
Could it be caused by using com.liferay.portlet package path? Is handled differently over custom package paths?
Could it be caused by using the same package path in both plugins? com.liferay.portlet.webhelp
Is there any other fundamental error?
Btw, when that A service.jar is placed into Tomcat's lib\ext and removed from individual portlets, everything works fine. But when B is redeployed, any code changes are ignored so tomcat has to be restarted. Development this way is very inefficient.
I need to keep both portlet separate because of specific reasons.
Also in this thread it is described the above solution is preferred over lib\ext:
https://www.liferay.com/community/forums/-/message_boards/message/7052315
Any idea why calling A method fails?
Thanks, Jan
I have two portlets - A - which service is shared also in B.
1. In my B.pom i have
<dependency>
<groupid>${project.groupId}</groupid>
<artifactid>webhelp-portlet-service</artifactid>
<version>${project.version}</version>
<scope>compile</scope>
</dependency>
2. In liferay-plugin-package.properties for (A) I've added: required-deployment-contexts=A-portlet
3. When both portlets are deployed, B waits till A is registered.
4. When B calls a method from A, I am getting error:
com.liferay.portal.kernel.bean.BeanLocatorException: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'com.liferay.portlet.webhelp.service.WebHelpDocumentLocalService' is defined
at com.liferay.portal.bean.BeanLocatorImpl.locate(BeanLocatorImpl.java:122)
at com.liferay.portal.kernel.bean.PortletBeanLocatorUtil.locate(PortletBeanLocatorUtil.java:51)
at com.liferay.portlet.webhelp.service.WebHelpDocumentLocalServiceUtil.getService(WebHelpDocumentLocalServiceUtil.java:460)
at com.liferay.portlet.webhelp.service.WebHelpDocumentLocalServiceUtil.getDocumentIdFromFriendlyUrl(WebHelpDocumentLocalServiceUtil.java:423)
at com.liferay.portlet.webhelp.service.impl.WebHelpServiceImpl.importDocumentCollection(WebHelpServiceImpl.java:247)
WebHelpServiceImpl is located in B
WebHelpDocumentLocalServiceUtil is located in A
Both A and B uses the same package path com.liferay.portlet.webhelp
Could it be caused by using com.liferay.portlet package path? Is handled differently over custom package paths?
Could it be caused by using the same package path in both plugins? com.liferay.portlet.webhelp
Is there any other fundamental error?
Btw, when that A service.jar is placed into Tomcat's lib\ext and removed from individual portlets, everything works fine. But when B is redeployed, any code changes are ignored so tomcat has to be restarted. Development this way is very inefficient.
I need to keep both portlet separate because of specific reasons.
Also in this thread it is described the above solution is preferred over lib\ext:
https://www.liferay.com/community/forums/-/message_boards/message/7052315
Any idea why calling A method fails?
Thanks, Jan
Jan Tošovský, modificado hace 9 años.
RE: ServiceBuilder based portlets dependency (Respuesta)
Liferay Master Mensajes: 566 Fecha de incorporación: 22/07/10 Mensajes recientes
I found many similar threads which suggested specifying required deployment context (what I did). But now I've found another requirement: Each service layer must use a separate distinct context path.
After changing the path and rebuilding the service everything works fine!
Hurray.
After changing the path and rebuilding the service everything works fine!
Hurray.