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.
