Thanks Paul, that's a good start.
So now I am in my MessageBodyWriter and should list all the different
methods from the different converters..
Since all converters are in the same namespace I actually have no way of
distinguishing method names. So I would need to do a big if-else branch
checking the actual types and set the respective cdata elements... Hmm:
Optimal would be of course to annotate / define what to print as cdata
at the converter level.
Otherwise is there no way to say print all String types as CDATA ?
public void writeTo(CDATASupport data,
Class<?> type, Type genericType, Annotation[] annotations,
MediaType mediaType, MultivaluedMap<String, Object> headers,
OutputStream out) throws IOException {
try {
JAXBContext jc = JAXBContext.newInstance(data.getClass());
Marshaller marshaller = jc.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT,Boolean.FALSE);
// get an Apache XMLSerializer configured to generate CDATA
XMLSerializer serializer = getXMLSerializer(out,data);
private XMLSerializer getXMLSerializer(OutputStream out,CDATASupport
data) {
// configure an OutputFormat to handle CDATA
OutputFormat of = new OutputFormat();
// how to distinguish what to write as cdata ?
if ( data instanceof MyConverter ) {
of.setCDataElements(new String[]{"^name"});
}
....
@Tatu: Yes if the reader does this. However I am dealing with some
legacy J2ME clients that do not do this..
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Donnerstag, 25. Juni 2009 18:52
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Jaxb cdata
On Jun 25, 2009, at 6:49 PM, Paul Sandoz wrote:
> Hi,
>
> It is not currently possible to support this with the existing JAXB
> providers i.e. it is not possible to define a content handler that
> the JAXB beans are serialized to, or to declare the CDATA with the
> JAXB bean.
>
> But it looks like you are defining your own JAXB supported
> providers. So... why don't you define that each convertor implement
> a common interface or is annotated with a common annotation. Then
> write one MessageBodyWriter supporting that interface or annotation.
> The CDATA mapping can be defined by the common interface or the
> annotation.
>
Alternatively, if you cannot modify those convert classes support a
wrapping type e.g.
public class ConvertorWrapper<T> {
// Store CDATA + Convertor
}
and implement a message body writer for ConvertorWrapper.
Paul.
> Paul.
>
> On Jun 25, 2009, at 6:36 PM, saturon wrote:
>
>> Hi there,
>>
>> I now come to a problem i already had 1.5 years back and then
>> solved with a workaround. Now after 1.5 years I wonder if there are
>> any better solutions.
>>
>> My stack:
>> Jersey 1.01/Glassfish 2.1
>>
>> To develop: NB 6.1 with jersey plugin
>>
>> REST services serve xml, which partly contains xml-illegal
>> characters. Therefore I need to produce xml elemements with cdata
>> tags.
>>
>> I have jaxb annotated converters that wrap my entity beans.
>>
>> So how do you do that best?
>>
>> My solution 1.5 years back was to write MessageBodyWriter for every
>> Converter involved. In the MessageBodyWriter I configured the
>> serializer with the specifc cdata OutputFormat, actually using the
>> depreciated org.apache.xml.serialize.XMLSerializer and
>> org.apache.xml.serialize.OutputFormat.
>>
>> Something like:
>>
>> @Produces("application/xml")
>> @Provider
>> public class MyConverterWriter implements
>> MessageBodyWriter<MyConverter> {
>> ..
>> private XMLSerializer getXMLSerializer(OutputStream out) {
>> // configure an OutputFormat to handle CDATA
>> OutputFormat of = new OutputFormat();
>>
>> of.setCDataElements(new String[]{"^desc", "^log"});
>>
>> XMLSerializer serializer = new XMLSerializer(of);
>> serializer.setOutputByteStream(out);
>>
>> return serializer;
>> }
>> ..
>>
>>
>> As you see not very elegant, verbose ( I have now something like 35
>> Converters which I would need to write MessageBodyWriter for .,),
>> and also error prone to forget things.
>>
>> Is there any better solution for this problem?
>> Can't be that I am the only one and that JAXB did not foresee such
>> a thing?
>>
>>
>> Thanks, Ben
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net