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

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