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

[Christophe Laprun]

On Oct 9, 2009, at 9:57 AM, Julien Viet wrote:

> 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.

The real problem is that in the code that I modified, none of the  
concepts you mention PortletApplication or GadgetApplication are used.
However, there is code that predates the PC integration to support  
remote portlets (cf UIPortletManagement) and code that deals with  
gadgets without using GadgetApplication and still creating an  
org.exoplatform.application.registry.Application object (mind you, not  
org.exoplatform.web.application.Application) using  
org.exoplatform.web.application.Application.EXO_PORTLET_TYPE and  
org.exoplatform.web.application.Application.EXO_GAGGET_TYPE, cf  
UIAddApplicationForm.

So there seems to be a lot of confusion within the internal code as to  
how things should be handled. Again, none of the code I had to modify  
seemed to be using the MOP, I fail to see how creating new model  
objects will help in code that doesn't use it.

Maybe I'm missing something but your proposal doesn't seem to address  
the issue with the admin tools.

Also, it doesn't help with the fact that ApplicationState is creating  
PortletContexts to hardcoded local invoker which is the real issue to  
have working WSRP invocations.

> 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.

Sure. I have been asking to talk about this issue several times  
already so it's really up to you! :) have nothing else to do since  
this issue is blocking for my work.

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