[jira] Reopened: (PLUTO-509) JAXB portlet descriptor model handling broken with respect to the different namespace handling for portlet API 1.0 and 2.0

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PLUTO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma reopened PLUTO-509:
-----------------------------


Reopening as the pluto container implementation actually *requires* that at runtime the descriptor model is portlet 2.0 based... even when a portlet 1.0 descriptor was loaded.

So, going to a third rewrite here, now providing a even more clean om interface api with now only 1 single implementation for the portlet 2.0.
For the portlet 1.0 descriptors, still a separate JAXB "struct" classes are used, but only for loading now.
If a portlet 1.0 model was loaded, it will be automatically "upgraded" to a full blown 2.0 model which implements the api interfaces.
And, for writing out, this can be done in reverse *if* the application version is still 1.0  

> JAXB portlet descriptor model handling broken with respect to the different namespace handling for portlet API 1.0 and 2.0
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: PLUTO-509
>                 URL: https://issues.apache.org/jira/browse/PLUTO-509
>             Project: Pluto
>          Issue Type: Bug
>          Components: descriptor
>    Affects Versions: 2.0-refactoring, 2.0.0
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>            Priority: Critical
>             Fix For: 2.0-refactoring, 2.0.0
>
>
> The current Portlet 1.0 and Portlet 2.0 JAXB descriptor api is an ackward merge of both namespaces in one object model.
> While this did seem to "work" more or less correct, when testing it more thoroughly it complete blew to pieces ...
> JAXB really cannot properly handle two namespaces blended on top of a single object model, it uses java packaging to map namespaces.
> And while you can have multiple fields mapped to multiple namespaces in one bean, one cannot do the same with one class: you really need to duplicate the classes to support multiple namespaces.
> This really becomes clear as soon as you try to actually write out an JAXB managed object tree.
> Using the current Pluto descriptor mapping this simply isn't possible to do without a corrupting the output or just exceptions thrown all over the place.
> So, as we do need to have this managed properly, I have started out *rewriting* the whole JAXB mapping mostly from scratch again, now properly using two implementation packages for the two namespaces (portlet10 and portlet20).
> As we already had extracted the descriptor api interfaces, the two new implementation packages both implement the *most* common denominator (e.g. portlet20) interface, where the portlet10 implementations throw an UnsupportedOperationException when trying to use portlet20 specific features (write *and* read methods).
> As the JAXB jxc compiler generates classes based on the xsd type definitions, all *DD classes ended up to be called *Type now. I've kept it that way as the *DD classes are no longer directly used anyway (or at least shouldn't).
> Finally, to be able to modify an JAXB loaded portlet10 or portlet20 descriptor model, while only dealing with the interfaces, a solution is needed for creating new instances of objects managed through lists, e.g. portletApp.getPortlets().add(Portlet).
> For this purpose, I've created a new ElementFactoryList<E> extending ArrayList<E> which provides a factory method for creating new elements for itself: E ElementFactoryList<E>.newElement().
> So, like for a org.apache.pluto.om.portlet.Portlet interface, you have to use: portletApp.getPortlets().add(portletApp.getPortlets().newElement()).
>  
>     

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.