Hi Chris,

Most of the current architecture result from the quick integration of the GateIn PC to replace the eXo PC.

The Application concept, today this concept wants to be extendable to properly handle various use case which depends on the type of content of a window.

1/ The PortletApplication represents a local portlet and it does indeed have a clear portlet and application name as part of its stat

2/ The GadgetApplication represents a gadget

The main reason where you should not use PortletApplication is that the semantic of a local portlet application is not the same as a WSRP portlet (although it was the same in JBoss Portal). Indeed the portlet application state is hosted by the consumer but in a non opaque form and further more there is a notion of cascading between portlet preferences. This does not match the WSRP semantic that is related to hosting opaque state with no notion of inheritance on the consumer.

Therefore we need to work to achieve the integration of WSRP by adding a WSRPApplication extension along with a WSRP content type in the MOP. At the UI level we need to have a UI component that will represent a WSRP portlet similar to the UIPortlet and UIGadget components.

At the end we will have something like:

- application/portlet, application/gadget, application/wsrp content types at the MOP level
- PortletApplication, GadgetApplication, WSRPApplication model objects
- UIPortlet, UIGadget, UIRemotePortlet user interface components

The rest is technical details and I think we should have a brainstorming session about how to achieve this integration properly.


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.

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

_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev