[gatein-dev] Application registry (& co) design and WSRP support.

[Christophe Laprun]

On Oct 8, 2009, at 5:58 PM, Christophe Laprun wrote:

> Hi,
>
> In the process of trying to integrate the WSRP consumer within GateIn,
> I found things that I find rather concerning design-wise. It might be
> a reflection of me not understanding the overall design so please
> humor me for a second.
>
> In JBoss Portal, the integration of the WSRP consumer was rather
> seamless: a FederatingPortletInvoker (implementing the Composite
> design pattern) allowed us to register additional PortletInvokers
> (which is what WSRP consumers are) and present a single, unified
> interface to the portal. In essence, from the portal point of view
> there wasn't much of a difference between a local or a remote portlet.
>
> GateIn does use the FederatingPortletInvoker concept and the WSRP
> consumers are properly registered with it. However, bridging over to
> Portal, it seems currently rather complicated to support WSRP portlets
> in a seamless fashion. The integration between the Application/
> ApplicationCategory concepts and the Portlet Container is currently
> exposing internal details of the PC (the portlet id format) in rather
> crude way: hardcoded string parsing repeated in different spots.
>
> This is bad for several reasons:
> - This tightly ties the portal to the *implementation* of the portlet
> container instead of its API.
> - This has performance impact as the bridge is done by extracting
> specific components from a String which might end up being parsed
> several times.
> - The parsing code is not encapsulated and is repeated in several
> different spots.
>
> More to the point, the whole Application concept is not adapted to
> supporting WSRP as it requires a portlet application name and portlet
> name to work. This can be emulated in WSRP (and I actually have
> working code to do just so). However, invocations do not work because
> the invocation code of the Portal hardcodes (again) specific knowledge
> of the internal PC implementation (specifically, the format of portlet
> ids). Moreover, this break of encapsulation also prevents the
> FederatingPortletInvoker to do its job properly as the portlet ids are
> improperly recreated from the formerly extracted application and
> portlet names, hardcoding the invoker id of the local invoker.
> This is embodied particularly in the ApplicationState.update method:
> producerOfferedPortletContext = PortletContext.createPortletContext
> ("local./" + applicationName + "." + portletName);
>
> So to sum up:
> - Application concept is not appropriated to supporting remote  
> portlets.
> - Information specific to the portlet container implementation is
> extracted from String versions of PortletContexts only so that said
> PortletContexts can then be recreated in a way that prevents proper
> dispatch of requests to WSRP consumers.
>
> Solutions:
> Get away from solutions that require knowledge of internal
> implementation and require multiple String operations by using the
> PortletContext everywhere application name / portlet name is used.

I've committed my changes (rev. #38393) to  
ApplicationRegistryServiceImpl.importAllPortlets(),  
UIAddApplicationForm.getApplicationByType() and  
UIPortletManagement.initWebApps() so that people can see what I have  
been doing to improve the current situation.

The issue now that the remote portlets can be displayed is the  
hardcoding of PortletContexts to use the PC internal format for a  
local invocation that I am not sure how to solve at this point.

Cordialement / Best,
Chris

==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm