Liferay and WSRP portlets: wrong URLs on WSRP consumer - liferay

Currently I'm checking out Liferay and its portlet feature, especially remote portlets via WSRP.
I've got two liferay instances running on different machines in the same network. Now I want to share a portlet from one of the liferay instances to the other, so I've installed the WSRP app on both installations and configured one of the nodes as WSRP Producer and the other as WSRP Consumer.
My WSRP Producer publishes the portlet for currency calculations (Währungsrechner in German) which is included in Liferay.
At first glance, this WSRP portlet seems to work on the WSRP consumer side - I can add it to a page of the WSRP consumer and its content (some input boxes) is displayed correctly.
But there is one problem:
The HTML form rendered by the portlet always submits to the WSRP produder's domain, not to the WSRP consumer's domain as I would expect. The action attribute of the tag contains the wrong domain name.
I've also written a small portlet for debugging purposes using the Liferay UI which simply prints the output of the JSP-Tag , installed it on the WSRP producer and embedded it in a page of the WSRP consumer. The URLs printed by this simple debugging portlet are always absolute URLs and point to the WSRP producer, even when the portlet is displayed on the WSRP consumer. I would expect that the URLs are either relative or that they point to the correct domain, e.g. to the WSRP consumer domain when the portlet is displayed via a page on the WSRP consumer liferay instance.
The reason for my evaluation of Liferay is, that we want to check if it is a suitable solution for developing portlets and providing these portlets via WSRP for remote usage.
To further investigate the problem I've built a small debug portlet with the Liferay SDK and Eclipe Plugin. The portlet mainly consists of a simple JSP page which prints out the result of :
<%# taglib uri="http://liferay.com/tld/portlet" prefix="liferay-portlet" %>
<span class="important"%>portlet:actionURL: </span><portlet:actionURL/%>
When I install this portlet on lifery.mycompany.net and publish it via the WSRP producer to liferay-2.mycompany.net, the output URL is:
http://liferay.mycompany.net:8080/de_DE/widget/web/wsrp-achimstestproducer/portlets?p_auth=0iLgJP7e&p_p_id=sbdebug_WAR_sbliferaydemopluginportlet_INSTANCE_qs2S&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view
Please note that the domain is liferay.mycompany.net instead of the expected liferay-2.mycompany.net.
How can I fix this?
Do I need to adjust Liferay's configuration so that the WSRP Consumer replaces URLs from WSRP portlets with its own URL?
Are there other factors that affect WSRP portlets and actionURLs?
Any help on this issue would be greatly apreciated!
My setup is:
- Liferay 6.2 CE with Tomcat 7
- Database is MySQL 5.5
- Oracle Java 7
- Liferay was configured with the inbuilt installation wizard
Thanks in advance!
2014-05-23: Here's some more info
I've also posted this question with some additional info in liferay's forums:
--> setting requires-namespaced-parameters to false in liferay-portlet.xml seems to fix the domain problem, but still the portlet's processAction method is not executed when the portlet is used via WSRP :(
Am I doing something wrong here? Any ideas and hints are welcome!

After using liferay's forum, several other WSRP resources on the web an search engines a lot it now works.
The following three things seemed to be the major causes for my problems with WSRP problems:
requires-namespaced-parameters must explicitly be set to false
CSRF token must be deactivated, I've did this in portlet-xml via init-param:
<init-param>
<name>check-auth-token</name>
<value>false</value>
</init-param>
Render parameters don't seem to be available in the view JSP when the render parameter was created in an event processing method, therefore I switched to portlet session attributes to transport data from the portlet class to the JSP view

Related

Liferay : How to see which portlets are composing a page?

I'm new to liferay.
I imported a big lar into my liferay instance but, for the moment, have none of the required portlets : there are a lot of portlets in the project I'm joining.
Currently, I have the site structure, but the pages display the message that the portlet is not here (logical).
For comprehension purposes, I wanted to build my portlets one after the other, on the need, to see them appear by the grace of liferay ;-)
But for that I wanted to know which portlet is missing.
This thread : How can i find - which portlets are deployed on which pages in Liferay 6.1? explain how to achieve this through the DB.
Is there really no built-in solution to do it through the liferay interface? Have we really to hack in the DB to get the info or install plugin?
Thanks!
In your browser console, Liferay.Portlet.list contains all portlets in the page.
This value is generated by themeDisplay.getLayoutTypePortlet().getAllPortlets() on the server.
As an alternative you can also look at the HTML code of the page and look for elements with the class portlet-boundary. For example this belongs to an instance of the Journal Content Portlet (Portlet name 56):
<div class="portlet-boundary portlet-boundary_56_ portlet-static portlet-static-end portlet-borderless portlet-journal-content full-screen" id="p_p_id_56_INSTANCE_WdRdMGe86kDa_">

Two portlets with same database

I am developing Liferay portal and I have one portlet which handles the administrator side of the portal and one the client side. The thing is that the clients cannot see the administrator page (including the portlet). Also I have created custom DataBase for the portal (I included my own tables in the Liferay database using Service Builder). Now I want to use the same database so I can take info from it using the client portlet.
Any ideas?
I am using Liferay 6.1 with Tomcat and Liferay SDK plugin for Eclipse.
You can copy the [portlet name]-service.jar from Web-Inf/lib, and paste it to any other portlet's lib folder. Even better if you can do this with maven and add this jar as a dependency. This way you can have access to the Util Classes that your service provides, to any other Portlet
All portlets in a plugin project share the service builder service made by that plugin (because they end up in one war file and thus share runtime context). So you could just put both your portlets in the same plugin and they can both access that plugin's service builder services/tables. I think you will find this is a commonly used approach. The permission and visibility issues you mention are not impacted by this organization.
Doing it this way keeps the deployment simple -- just deploy the plugin's war, done.
If there are reasons beyond your control that require the portlets to be in separate plugins, then it becomes harder -- yannicuLar's approach is one way.
If you have two portlets sharing same tables/entities , you can copy the service.jar to
tomcat-7.0.27\lib\ext a common location where these two portlets can access this .jar at runtime.

Portlet content is not shown in Liferay

I've recently started working with portlets, and trying to have experience with several portal engines. I have a basic hello world portlet (extending GenericPortlet and basically doing the same as in all tutorials) that works perfectly with Pluto 2.
I deployed the same portlet to Liferay 6.0, and added it to a page in the portal. Strangely, the portlet frame appears without any content. According to the logs, the portlet init() is called, but doView() is not, thus there's no portlet content in the resulted HTML page.
My question is: should the same portlet work out of the box with Liferay, too? If not, what non-standard descriptors are mandatory for deploying a portlet to Liferay? If yes, what may be the problem? I've seen portlet content height issues mentioned in some forums, but this may not be the problem: the content is not hidden, it's not generated at all.
While checking the relevant file contents to paste here as asked, I realized that my web.xml is empty (as it should be according to Liferay tutorials), but a maven plugin generates pluto-specific invoker definitions into it as defined in my pom.xml. As a result, the generated pluto-specific PlutoInvoker mappings screwed it all up. So it was solved easily, thanks for reading the question though.

Development questions related to Liferay 6

I am using Liferay version 6.06. I have developed a Login Portlet using Liferay plugins SDK under which the View JSP consists of a login screen. Upon submitting credentials from this view JSP it will be received by the processAction Method of my Custom Portlet class. All this works good.
I have two questions:
Currently the Login Portlet is being part of Sample Category under Liferay screen (I want to have my own screen, where initially upon entering http://localhost:8080/mycontext, I want to show that Login screen).
And once the credentials are received inside the processAction method of my Custom Portlet class, I want to display my own two portlets.
Could anybody tell me how to achieve this?
Beside you don't need a customized login for your Usecase, in case you still need to customize the login process you should:
build a hook which is a kind of plugin able to interact with Liferay's core functionalities.
In case you don't know take a look [here] http://www.liferay.com/it/documentation/liferay-portal/6.0/development/-/ai/hooks
or just use the property login.events.post=my.custom.PortletAction
and put your business logic after successfull user login

Liferay - theme across all portlets?

If I create multiple portlets with liferay, how can I have 1 theme control the look of all of them?
Thanks
The Liferay's templating system consists of Velocity/Freemarker templates that renders particular html segments of portlets on a page. It is essentially one theme that styles everything.
If you choose to use JSPs on server side and Alloy UI framework on client side, even your portlet would have the same look and feel as the rest of the portal because Liferay JSP taglibs and Alloy UI both use the same CSS classes that the classic/default Liferay theme is expecting and made for.

Resources