We ran into the same thing with CXF a long time ago. It's also a bit more complex than just referencing the NamespaceMapper class. The "key" that is used to set it into the context is also different with the built in version of JAXB as even the "key" gets the ".internal" into it.
For CXF, we actually have the user set the namespaces into the settings as a straight Map<String, String>. We then use a bit of ASM magic in some cases to create a NamespaceMapper from that map and set that on the context. If you really want to look, see: http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java the setNamespaceWrapper call. By using a Map like that, we CAN possible update that setNamespaceWrapper call to support other JAXB impls as well (potentially Moxy is one) if there is enough demand. Dan On Friday, May 11, 2012 08:36:13 AM Christian Müller wrote: > Good morning Claus! > > I had the same thoughts, but because this class comes from > jaxb-impl-2.1.13, I assume it will not be a problem with an IBM JDK. I use > the Apple JDK (Java version: 1.6.0_31, vendor: Apple Inc.) and it works > well. > > NamespacePrefixMapper is an abstract class which doesn't implement any > interface. > Another possibility is to use the java.lang.Object as type for the > instance variable and the getter/setter and not > com.sun.xml.bind.marshaller.NamespacePrefixMapper. This is possible, > because this instance is passed thru the marshaller.setProperty(String, > Object) method. Than we don't have any imports on > com.sun.xml.bind.marshaller.NamespacePrefixMapper but may a runtime > exception if users set Objects from a wrong type (I didn't test whether > JAXB RI ignore it or throw an exception). > > Thoughts? > > Best, > Christian > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
