[SWS-372] Missing support for interface/implementation separated JAXB classes in Jaxb2Marshaller Created: 11/Jun/08  Updated: 04/May/12  Resolved: 13/Jul/08

Status: Closed
Project: Spring Web Services
Component/s: OXM
Affects Version/s: 1.5.2
Fix Version/s: 1.5.4

Type: Improvement Priority: Major
Reporter: Oliver Siegmar Assignee: Arjen Poutsma
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When I generate my JAXB mappings, I use the <jaxb:globalBindings generateValueClass="false"> option in my binding configuration. This results in a separation of interfaces and implementation classes of my JAXB mapping, so I have a mypackage.jaxb.MyElement interface and a mypackage.jaxb.impl.MyElementImpl implementation class.

Now about the problems:

1) The Jaxb2Marshaller's supportsInternal() method checks, if the specified type contains a XmlRootElement - which is only present in the implementation, not in the interface. So I'm forced to use the mypackage.jaxb.impl.MyElementImpl class in my Endpoint instead of using the interface mypackage.jaxb.MyElement. Bug or feature?

2) The contextPath check in the same method checks, if one of the specified contextPaths is exactly the same as the package of my JAXB element, which is not the case, because I have to specify the mypackage.jaxb package as the contextPath (because only this package contains the required ObjectFactory class) and the found type is in the mypackage.jaxb.impl package (because of problem 1).

I hope I could explain the problem - if you have any questions, let me know.



 Comments   
Comment by Arjen Poutsma [ 13/Jul/08 ]

I don't see an way to support this feature without rewriting the entire supports mechanism, and breaking backwards compatibility.

The easiest way for you to solve this would be to subclass Jaxb2Marshaller, and override the supports method to do what you want to.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sat Dec 16 14:52:26 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.