Re: [jira] Commented: (PLUTO-267) Implementation of the new Eventing Model

[be...@netsos.com]

> Torsten Dettborn commented on PLUTO-267:
> ----------------------------------------
>
> I want to bring this issue on top of the mailing- list for discussion.
> Christian has tests his implementation on the old implementation, before
> the patch from Tuomas has committed(all was fine). From design questions
> it is right that all functionality is in the portal, but the question is,
> how we can get the classloader from the portlet app. This we need for the
> unmarshalling, as Christian has written.

Perhaps, upon portlet initialization, the payload classes of any supported
events could be placed in a Map and stored as a servlet context attribute.
 The keys could be the qualified names of the event payload, and the
values could be a Class that was loaded using
Thread.getContextClassloader().loadClass during the PortletServlet's
init() method.  Then, instead of loading the class during the event firing
phase, use  ServletContext.getContext(String) to retrieve the required
ServletContext, look up the map of previously loaded classes, and pass the
appropriate one to the Unmarshaller.

Just my two cents,

-- Ben

Re: [jira] Commented: (PLUTO-267) Implementation of the new Eventing Model

[Tuomas Kiviaho <tu...@iki.fi>]

Hello,

I am compelled to comment since I created this mess in the first place with
my patch. I am not using the JAXB myself and the original design relied
heavily upon it. What I did was just a rough move of marshaling and
unmarshaling away from the pluto core classes to the driver side to make the
eventing JAXB agnostic.


ben-143 wrote:
> 
> Perhaps, upon portlet initialization, the payload classes of any supported
> events could be placed in a Map and stored as a servlet context attribute.
> 
Intermediate classes outside portlet.xml would becore a problem I my limited
knowledge over JAXB isn't leading me to false assumptions here. I'd be using
a JAXB context instead of map in order to play it safe
<https://jaxb.dev.java.net/faq/index.html#threadSafety><>. 

Otherwise Ben's idea was more than what I could come up with on my own but
direct references to servlet api context attributes without pluto API facade
in between generate in this case direct references to JAXB.

Applying event/listener pattern between portlet servlet init/destroy and
event provider at driver impl. is one possibility to still leave whole
responsibility of JAXB to the eventing itself. This would also clean up the
current implementation because I did pay more attention on limiting the
patch size than looks when I was butchering the provider impl. 

A test case with pre-existing JAXB payload would be highly appreciated. I'd
be happy to formalize this though as a patch, but I'm afraid of being at
square one - nothing solved without any means of proving that it actually
works.  

PS. PortletRegistryService/Listener only exist in the trunk and in the merge
branch so the patch would have to be made against merge branch instead of
the compatibility one.

--
Tuomas Kiviaho
-- 
View this message in context: http://www.nabble.com/-jira--Created%3A-%28PLUTO-267%29-Implementation-of-the-new-Eventing-Model-tf2568200.html#a13829330
Sent from the Pluto - Dev mailing list archive at Nabble.com.