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