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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev