> -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > > You can extend JaxbElementProvider and override > AbstractJAXBProvider.convertToJaxbElemenIfNeeded() and implement it the > way > it's done on the trunk [1].
The "jaxbElementClassMap" map is referenced in more than just the "AbstractJAXBProvider.convertToJaxbElementIfNeeded()" method. It's also referenced in "AbstractJAXBProvider.isSupported()" and "JAXBElementProvider.readFrom()". It appears that I'll need to create my new subclass in the same package as JAXBElementProvider, at least for the reason that "org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.CollectionWrapper" is defined as a protected class in "AbstractJAXBProvider". I'm not sure whether it will be easier to just define my subclass identical to JAXBElementProvider and then try to remove pieces, or start from the minimal side and add pieces. > > let me know please how it goes > > cheers, SErgey > > [1] > http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/ja > va/org/apache/cxf/jaxrs/provider/AbstractJAXBProvider.java > > > KARR, DAVID (ATTCINW) wrote: > > > > I noticed in the following thread > > <http://www.mail-archive.com/[email protected]/msg09175.html> that > > there are some changes in the trunk to allow JAXBElementProvider to > have > > a "jaxbElementClassMap" property, which will allow me to bind my REST > > services to classes I don't control (or are generated), so I can't > add > > "@XmlRootElement" to them. Sergey mentioned in that thread that it > > would be straightforward to build that JAXBElementProvider before the > > next release it's available in. Would that be possible? > > > > > > -- > View this message in context: http://www.nabble.com/Need-help-writing- > JAXBElementProvider-that-uses-%22jaxbElementClassMap%22- > tp25303787p25312013.html > Sent from the cxf-user mailing list archive at Nabble.com.
