Foren

Custom Servlets Configuration in Liferay

thumbnail
Sunil Rai, geändert vor 9 Jahren.

Custom Servlets Configuration in Liferay

Junior Member Beiträge: 57 Beitrittsdatum: 31.01.12 Neueste Beiträge
I have some legacy applications built with JSP and Servlets on tomcat . This application has form action which call Servlets for processing. It has to be deployed under Liferay application.

JSP can be easily deployed under ROOT directory but facing issue with "Servlets" configuration.

Approach:

1) Copy class files under \webapps\ROOT\WEB-INF\classes 2) Configure Servlets mapping under \webapps\ROOT\WEB-INF\web.xml

After changing these setting unable to start Liferay. I want some quick fix for this issue.
thumbnail
David H Nebinger, geändert vor 9 Jahren.

RE: Custom Servlets Configuration in Liferay

Liferay Legend Beiträge: 14919 Beitrittsdatum: 02.09.06 Neueste Beiträge
Whoa, this is doomed to failure.

Liferay employs a slew of servlet filters, preprocessors, has a very big spring/hibernate initialization, ...

And honestly, your core belief, "it has to be deployed under Liferay application" is simply wrong. It does not need to be installed under the Liferay application.

If you believe it has to be there because, perhaps, it does not support any sort of context prefix, i.e. it won't work as http://myhost/mylegacyservlets/..., well all that means is that you don't understand how a fronting httpd daemon can route traffic to different locations based upon cookies, headers, url patterns (i.e. *.jsp or *.do or something), ...

It means that you don't know how to set up two separate app servers and route traffic separately, that's all.

Or you might believe it has to be there because it is dependent upon some bit of Liferay data or something, well that also means that you don't understand that all of that information is also available to portlets and servlets running in different contexts on the same server.

Now perhaps you have some other basis for your belief but I assure you that it is just plain wrong. And once you discard this belief and start asking how you solve whatever problem you actually have, well that's when we can help by providing some clarity and answers that you can actually use.
thumbnail
Sunil Rai, geändert vor 9 Jahren.

RE: Custom Servlets Configuration in Liferay

Junior Member Beiträge: 57 Beitrittsdatum: 31.01.12 Neueste Beiträge
Hi David,

Thanks for your feedback. Please recommend the correct way to convert existing application to liferay compatible. As per my understanding creating a portlet for this requirement should work.

Need your comments so that I can understand correct way to approach my problem.
thumbnail
David H Nebinger, geändert vor 9 Jahren.

RE: Custom Servlets Configuration in Liferay

Liferay Legend Beiträge: 14919 Beitrittsdatum: 02.09.06 Neueste Beiträge
You need to understand what they mean when they ask for you to convert it.

If it does need to be like a portlet in a frame on the portal, well your options are to a) do the actual conversion or b) use the iframe or proxy portlets to front the legacy application. Which way you go depends upon what level of integration they want out of the conversion. I.e. if you want to leverage the Liferay users, the theme, the security/permissioning, etc., then an actual conversion is the only path. If all they want is the portlet frame, well the iframe or proxy portlets will give you that without having to touch the legacy app at all.

Maybe they don't want any integration or conversion, they just want http://mysite.com/web/guest to land on a portal page but http://mysite.com/catalog.do uses your legacy app. In this kind of thing there is no integration, it is just handling a redirect correctly within your httpd daemon in front of two tomcats, one Liferay and one legacy.

Maybe it's even less integration, where the legacy app is http://mysite.com/legacy/... in which case the redirect is easier, but they want some sort of SSO to simplify the sign on process. That just takes CAS or some other SSO implementation.

So as you can see, there's many different paths. The correct path is the one that satisfies your requirements and their expectations, neither of which have been shared in the forum.