[
https://issues.apache.org/jira/browse/PLUTO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639728#action_12639728
]
David Jencks commented on PLUTO-509:
------------------------------------
If the object models are consistent enough so that they can implement the same
interfaces used by pluto itself I'd expect that you could use the 2.0 jaxb tree
and simply use a sax filter to change the namespace for portlet 1.0 to that for
portlet 2.0 as its being read in. Openejb does this a lot to read in any ejb
deployment descriptor into the same jaxb model. If you're interested in
pursuing this please point me to the xsds and code that reads a descriptor into
jaxb.
> 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.0, 2.0-refactoring
> Reporter: Ate Douma
> Assignee: Ate Douma
> Priority: Critical
> Fix For: 2.0.0, 2.0-refactoring
>
>
> 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.
