using Vaadin 7.1 and Liferay 6.1 I try to open a new UI (in the same session) in a new browser window using com.vaadin.server.BrowserWindowOpener:
Button button = new Button("button");
BrowserWindowOpener windowOpener = new BrowserWindowOpener(OverviewWindow.class);
windowOpener.extend(button);
Where
OverviewWindow extends UI
is a trivial custom UI.
In standalone use (i.e. without Liferay) this works fine, but in Liferay the popup opens and displays “Request was not handled by any registered handler.” (HTTP-Response-Code: 404).
I tried many things - among others to generate the url via
com.liferay.portlet.PortletURLFactoryUtil.create(PortletRequest, String, long, String)
- but nothing works.
Fascinating, I tried it and it really doesn’t work. I’m not immediately sure what the problem could be, but apparently the BrowserWindowOpenerUIProvider doesn’t work properly in portal for some reason.
I suggest
creating a ticket about the problem. I didn’t notice an existing ticket.
My first guess is that the pathInfo of the portal request is different from servlet, so it doesn’t match when getUIClass() in the provider is called. It’s expected to be “popup/ClassName”.
If you want to look for a workaround, you could extend the BrowserWindowOpener class, define a custom UIProvider class in it, and add some debug logging in the getUIClass() method.
I tried to debug it a bit and it indeed probably is a path problem. The path in the popup looks like a portal URL, but there’s probably something wrong with it. The message comes from VaadinService, so the portlet is called, but the UIProvider is not called at all. So, I’d think that the request is not properly associated with the session or something.
But even if that is fixed with a more correct URL, it could be that the BrowserWindowOpenerUIProvider handles the request parameters wrong. So the pathInfo could also be wrong, unless Vaadin somehow translates it from the portlet request parameters, I’m not sure about that.
I found the same confusing: any custom UIProvider is not at all called - but a custom RequestHandler is called…
Some things I’m not sure what correct values would be - especially for
p_p_resource_id (maybe “v-browserDetails”?)
Setting the url to a portal url - e.g.
routing?p_p_id=OliaCCSRoutingPortlet_WAR_OliaCCSRoutingPortlet_INSTANCE_bO4yqyT6JUmu&p_p_lifecycle=0&p_p_mode=view&p_p_resource_id=v-browserDetails
does not help, as this results in the following url:
http://localhost:17777/web/ccs_002/routing?p_p_id=OliaCCSRoutingPortlet_WAR_OliaCCSRoutingPortlet_INSTANCE_bO4yqyT6JUmu&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_resource_id=APP&p_p_cacheability=cacheLevelPage&p_p_col_id=column-2&p_p_col_count=1&p_p_id=OliaCCSRoutingPortlet_WAR_OliaCCSRoutingPortlet_INSTANCE_bO4yqyT6JUmu&p_p_lifecycle=0&p_p_mode=view&p_p_resource_id=v-browserDetails&_OliaCCSRoutingPortlet_WAR_OliaCCSRoutingPortlet_INSTANCE_bO4yqyT6JUmu_v-resourcePath=%2Frouting
So it is difficult to play around…
Notice that the constructor takes path, such as “popup/MyUI”, not URL. Looking at the portal URL in the popup window, its parameters look like they should work, although there could be something wrong. If a RequestHandler is called with the popup URL, it indicates that the session is associated properly, but the UIProviders are not called for some odd reason.
What are you trying to open in the popup - another portlet a servlet? I’m not sure if opening a portlet in a context not really managed by the portal would work correctly.
If a servlet, define the servlet in your web.xml or with Servlet 3.0 annotations and construct its URL manually (proxies that transform URLs might cause problems with this approach). Then use an ExternalResource with the URL, which should prevent it getting transformed.
In the portlet case, you could in theory get a VaadinPortletResponse with CurrentInstance.get(VaadinPortletResponse.class), get the portlet request from it, check that it is a MimeRequest, create a render URL with it and set its parameters. This could then be given as an ExternalResource to BrowserWindowOpener. However, it probably wouldn’t be what you want - if working at all.
Generally you are right: it does not really make sense do open browser windows in the portal context, but this is an explicit customer request…
As to the question wehter it should be a portlet or servlet: I don’t mind. But we really need to access the original UI (i.e. share the portlet session) - what is the best way to archive this?
An HttpSession (which is normally per WAR file and browser) can contain multiple UI instances (with VaadinSession as an intermediate layer). However, how the portlet session is linked to the HttpSession is to a large extent a portal specific implementation detail. Therefore, it might not be easy to find and access the portlet session from a servlet in the WAR, but it should be possible to access the HttpSession from both and add a reference to the UI there in the portlet if that is sufficient for your purposes - just keep in mind that you need to identify the UI somehow as there can be multiple of them.