Great thxs works now ;)
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Freitag, 26. Juni 2009 11:37
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Jaxb cdata
On Jun 26, 2009, at 11:22 AM, saturon wrote:
>
> Sorry my persistence but the problem I have is that I do not see a way
> on how to define this at the converter level. Yes U can modify the
> converters...
>
public interface CDATAProvider {
String[] getCDATA();
}
public class MyConvertor implements CDATAProvider {
...
}
public class My CDATAProviderWriter implements
MessageBodyWriter<CDATAProvider> {
public boolean isWritable(Class<?> c, ....) {
return CDATAProvider.isAssignableFrom(c);
}
...
}
Or define an annotation:
@CDATA({"x", "y"})
public class MyConvertor {
}
public class My CDATAProviderWriter implements MessageBodyWriter {
public boolean isWritable(Class<?> c, ....) {
return c.isAnnotationPresent(CDATA.class);
}
...
}
Paul.
> -----Original Message-----
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Freitag, 26. Juni 2009 11:02
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] Jaxb cdata
>
>
>
> On Jun 26, 2009, at 10:27 AM, saturon wrote:
>
>>
>> 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:
>
> That is a bad design. If you need to do that i would recommend using a
> Map<Class<Convertor>, String[]>, you could wrap the map around a
> registry class.
>
>>
>>
>> Optimal would be of course to annotate / define what to print as
>> cdata
>
>> at the converter level.
>
> Yes, that is the better design, if you can modify your convertor
> classes.
>
> Paul.
>
>>
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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