I have a Liferay portlet written in vaadin 6, that was using PortletRequestListener to get a handle on the request so that I could hand it to liferay, which needs it to get hold of ThemeDisplay so I can check permissions. Not my favorite design, but that’s how liferay works, no theme display object, no permissions checking (as far as I can tell)

Unfortunately it also seems to be the case that if you can’t get a PortletRequest, you can’t get the ThemeDisplay… so I need to get a reference to the portlet request. However, PortletRequestListener only seems to be valid for Application objects, and your new way seems to hide the application object.

Basically I was just doing this:

	public void onRequestStart(PortletRequest request, PortletResponse response) {
		this.request = request;

	public void onRequestEnd(PortletRequest request, PortletResponse response) { }

So that I could pass the request down to whatever Liferay code needed it. (My code never touches it of course). So what’s the new way to get a handle on the request object?

I was already overriding ApplicationPortlet2, and I can see the PortletRequest in the handleRequest() method, but it seems that in order to find the appropriate root I should call

PortletSession session = request.getPortletSession(false);
if (session != null) {
  PortletApplicationContext2 context = getApplicationContext(session);
  Application application = context.getApplicationForWindowId(request.getWindowID());

getRootForRequest requires a WrappedRequest. The constructor of WrappedPortletRequest requires the PortletRequest and a DeploymentConfiguration. Unfortunately, when I look at the uses of DeploymentConfiguration in the API, there are no sources from which to obtain it that are available for portlets, and apparently no implementations I can instantiate…



The DeploymentConfiguration is available from AbstractApplicationServlet, but not AbstractApplicationPortlet, and when I look at the code, I can’t just steal the code out of AbstractApplicationServlet because it creates an anonymous inner class with several references to AbstractApplicationservlet.this :frowning:

So this seems to be a dead end too.

The Application object is in no way hidden, though its role has been reduced to the point where it is no longer required to create your own sublcass of Application.

There is still nothing preventing you from creating your own subclass of Application and providing a reference to it in your portlet configuration in exactly the same way as with Vaadin 6 though you shouldn’t create the UI in the init method now that you also have a subclass of Root defined in your configuration.