2:57 a.m.
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