Can I let my own HttpServlet run with LiferayDXP?

[3年前 に Yoshikazu Kobayashi によって更新されました。]

With Liferay 6.2, we were able to deploy and execute our own HttpServlet in the portlet project which is a WAR file.
With Liferay DXP, it was not possible to run your own HttpServlet within the portlet bundle.
Please tell me how to run your own HttpServlet with DXP.

[7年前 に David H Nebinger によって更新されました。]

This is not true. There's just a different mechanism to make this happen.

Check out com.liferay.wsrp.internal.servlet.ProxyServlet for an example.

[3年前 に Yoshikazu Kobayashi によって更新されました。]

Hi David,
Thank you for your answer.

I will explain why I used servlets.
We have implemented URL link collection with custom portlet as a requirement of a customer.
The URL is a unique system developed by customers. Depending on the system, it is essential to switch the browser to FireFox, IE, Safari, etc., and the browser switching plugin developed by the external vendor was set in the browser.
In order to correspond to specifications for switching browsers, I will not mention detailed specifications, but since I call HttpServlet and link to each system, I implemented HttpServlet in the custom portlet and included it.

Placing the HttpServlet in the portlet is not conscious of tricky but it was feasible with Liferay 6.2.
Please teach whether it can be realized also with Liferay DXP.

[7年前 に Olaf Kock によって更新されました。]

Yoshikazu Kobayashi:

Placing the HttpServlet in the portlet is not conscious of tricky but it was feasible with Liferay 6.2.
Please teach whether it can be realized also with Liferay DXP.

I'm not sure what exactly you're doing and why, but you definitely can deploy an independent webapplication to your appserver. It'll be hard to call any Liferay APIs - especially the "*LocalService" services, but you can always go through the remote services (in case you need any integration with Liferay code).

Alternatively, David gave a pointer to an implementation of servlets that are deployed within the Liferay context. However, as servlets don't get a lot of benefits from the portal infrastructure anyways, you might be happy with just deploying them to the appserver.

[3年前 に Yoshikazu Kobayashi によって更新されました。]

Dear David and Olaf
Thanks to your advice, In Liferay DXP,I ​​found that instead of using HttpServlet, I realized it in a different way.
The method is to create a module of REST service using javax.ws.rs.core.Application.
Within the module, we were able to use the Liferay API such as * LocalServiceUtil.
Thank you very much.

[7年前 に Olaf Kock によって更新されました。]

Yoshikazu Kobayashi:

Within the module, we were able to use the Liferay API such as * LocalServiceUtil.

Thanks for reporting back. Note that in DXP (and OSGi) you shouldn't call *LocalServiceUtil any more, rather inject dependencies through @Reference annotations - this will properly wire all the dependencies and make them explicit. Otherwise you might risk to have hidden dependencies and your modules might be started before the APIs you depend on are available.

[3年前 に Yoshikazu Kobayashi によって更新されました。]

Olaf Kock:

Otherwise you might risk to have hidden dependencies and your modules might be started before the APIs you depend on are available.

Thanks for the advice.
I do not understand the top risks. Consider DLFileEntryLocalService as an example of Liferay's API.
Even if I do not plan to override the DLFileEntryLocalService, should I not use DLFileEntryLocalServiceUtil?

(As it is a habit to access User, DLFolder, DLFileEntry, Expand using * LocalServiceUtil in Liferay 6.2 development)

[7年前 に David H Nebinger によって更新されました。]

No, the issue w/ using the Util classes is that it removes the direct dependency on the service itself so your code can start even if the actual service you're using isn't ready.

So, for example, take DLFileEntryLocalService (the service interface) and DLFileEntryLocalServiceUtil (the legacy static class). If you use the util class, you have no direct dependency on the service itself so OSGi will start your bundle whether or not the service is actually available.

When you use @Reference and the service interface to inject into your module, OSGi is aware of this and will only start your module once all dependent services are started. This will block your module until all dependencies are ready.

Granted you might think that a core service doesn't have these problems, but they do still exist especially during startup (your module might start before the Liferay service has finished).

So no, you never want to use the util classes ever again if you're doing OSGi development. The only reason the util classes are there is to support legacy code that used all of those static classes from previous Liferay versions.

But any new development should only go through the service references and never the util classes.

[3年前 に Yoshikazu Kobayashi によって更新されました。]

I understand that there is a possibility that service reference can not be made depending on timing.
From now on, I will not use util class.
Thanks for the advice.