History of using PortalClassInvoker for Liferay...

So Liferay 6.2 is doing away with many of the PortalClassInvoker methods that V7 uses to get portal info (I have opened a bug on it, http://dev.vaadin.com/ticket/11751).

I’m wondering what drove the decision to use PortalClassInvoker to invoke public static methods on available classes was…

Basically V7’s VaadinPortlet has a VaadinLiferayRequest instance that has a getOriginalRequest() method that uses PortalClassInvoker to actually call Liferay’s PortalUtil.getHttpServletRequest() method (which is a public, static method that is part of the service layer that all portlets have access to).

I could see that the original code must have used the method directly, as it’s in there but commented out.

I figure there must be some reason why the decision was made to switch from invoking the method directly to using PortalClassInvoker to get to it indirectly… I believe that there must have been a reason (some sort of compile time issue? Perhaps something else?), and I guess I’m fishing for what that reasoning was…

Anyway, the methods used by V7 are gone in the milestone releases of 6.2. I created my own extension class of VaadinPortlet and fed my own instance of an extension of VaadinLiferayRequest that uses PortalUtil.getHttpServletRequest() directly, and it all seems to work.

I’m worried that because I’m missing the history of the decision to use PortalClassInvoker that my local test might have some sort of hidden bug that I’m not entirely aware of (and may not be aware of until it’s too late).

Any of the developers/architects that know the history of the decision care to share your thoughts?

Okay, I’ve tracked the original addition of the code in SVN to
Revision 12380
.

This was added by Henri Sara 3 years ago, there was no before/after, the extra lines appeared in 12380 directly in response to a bug
4160
dealing with restartApplication not working for portlet 2.0 spec.

So I’m starting to think maybe this wasn’t done on purpose, maybe it was just an implementation that worked at the time.

Henri, you out there?

I have the vague recollection there was a problem with using com.liferay.portal.util.PortalUtil directly back when this code was developed. If I remember correctly, loading the class (even if it wasn’t really used after class loading) triggered loading of problematic other classes that broke some other portals that do aggressive checking of loaded classes. The class PortalClassInvoker had no static dependencies on any other Liferay class.

Most likely, reflection could be used directly to eliminate also the dependency on PortalClassInvoker. The use of class loaders would differ from the current implementation, but most likely that would not be a problem in this case as the classes should already be loaded when coming to this branch.

I figured it was something along the lines of classloaders, but didn’t consider the effect of deploying to other portals…

Using reflection directly, then you still have the class loader boundary to worry about…

There is still one remaining method in PortalClassInvoker that could be leveraged, invoke(boolean newInstance, MethodKey method, Object… arguments) to stick w/ the PCI, but it does have a dependency on the MethodKey class (which uses other Liferay classes, …). It is one option for staying w/ the PCI, but I don’t know what impact it would have on the other portals…

In the meantime, Vaadin does not work on the 6.2 line of Liferay. V6 fails because of the PCI methods not being there, and so does V7. There is a bug opened in Liferay’s jira, http://issues.liferay.com/browse/LPS-34135 and I’ve commented there indicating why Vaadin fails on 6.2.

I don’t know what kind of relationship you guys have with Liferay. It would seem to me the easiest path is to get the methods restored in 6.2. They could mark them as ‘do not use’ or something for the general public, but getting them back in would make Vaadin work again under Liferay…

At this point, if Liferay 6.2 ships as-is, it will be a total blocker for Vaadin users…

If you guys end up making code changes to support Liferay 6.2, then the release has to get over to Liferay before they move 6.2 to RC status, I’d think…

Plus I don’t know what the plan for PortalClassInvoker is for the upcoming 6.1 GA3; if they are going to remove the methods for GA3, Vaadin won’t work under that version either…

https://vaadin.com/forum#!/thread/3902907