cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Serialize Custom Class with CXF via Reflection (or similar)
Date Thu, 10 Feb 2011 18:13:35 GMT
No problems :-), great you've realized your idea...

Cheers, Sergey

On Thu, Feb 10, 2011 at 3:49 PM, Tim Clotworthy
<> wrote:
> Thanks for your patient help Sergey. I think I gave too much info. Your responses were
appreciated and I have an ok solution ro now, and will hopefully get a better one later. Tim
> -----Original Message-----
> From: Sergey Beryozkin []
> Sent: Tuesday, February 08, 2011 5:19 PM
> To:
> Subject: Re: Serialize Custom Class with CXF via Reflection (or similar)
> Hi Tim
> sorry for a delay...please see comments below
> On Tue, Feb 8, 2011 at 3:57 PM, Tim Clotworthy <
>> wrote:
>> Sorry for sending again, I thought the pseudo code was a little garbled in
>> the last message...
>> -----Original Message-----
>> From: Tim Clotworthy
>> Sent: Tuesday, February 08, 2011 10:50 AM
>> To: ''
>> Subject: RE: Serialize Custom Class with CXF via Reflection (or similar)
>> Thanks so much for the response. Maybe I should describe it from the
>> perspective of a library user. Currently, the user is given a library that,
>> given a particular consumer request, is returned a fixed-formatted response
>> (in the form of some flavor of streamed XML-based structure). It is a fixed
>> format in that the WS is only using the output format(s) (from the finite
>> number of java output classes in the library) it knows how to serialize as
>> part of a response.
>> This is too limited. I want to give the user the opportunity to do the
>> following:
>> Class MyCustomProcessor implements CustomProcessor , where the interface
>> contains 2 method definitions:
>> public void processInputMessage(String msg); /* the msg is provided to the
>> user in a structure they are inherently familiar with, and therefore know
>> how to "process". When they are through processing it, they have created
>> some sort of structure, presumably as java objects (captured in
>> MyCustomOutputObject after processing) */
>> public CustomOutputObject getProcessedMessage();/* the returned object
>> (probably nested classes, but whatever) gets embedded in the response
>> returned by the JAXRS method/subresource. Here though, the structure of the
>> CustomOutputObject is unknown to the library at runtime. */
>> So, then user's custom processor might look like:
>> Class MyCustomProcessor implements CustomerProcessor {
>> private MyCustomOutputObject so; /* the returned custom output objects */
>> public void processInputMessage(String msg){
>> //TODO process message
>> }
>> public CustomOutputObject getProcessedMessage() {
>> //TODO return custom object
>> }
>> }
>> My ideas were:
>> 1) have CustomOutputObject be an abstract class (part of the library) that
>> the user must extend (MyCustomOutputObject extends CustomOutputObject ) for
>> their custom output classes. I was hoping to figure out a way via
>> reflection/introspection or anything convenient,  to have the library
>> assemble those custom output classes at runtime in way that JAXRS/JAXB
>> (whatever) can figure out how to serialize as part of the response. I made
>> progress on the above except that the WS apparently didn't know what to do
>> with the MyCustomOutputObject (it was missing in the response).
>> 2) rather than:
>> public CustomOutputObject getProcessedMessage();
>> , have a simpler
>> public String getProcessedMessage();
>> Here, the library just has to embed the String blindly in the response. I
>> must say, I don't know how to do this in JAXRS, and would need to (i.e. how
>> do you take a java container that the JAXRS/JAXB knows how to serialize a
>> priori as XML and embed the XML string in it? -> if this was a conventional
>> servlet, I would know what to do!).
>> So, I would like to be able to do 1) ( because some day would like to do
>> all this outside a web environment with EJBs, etc.), but doing 2) would be
>> FINE for now..
>> Too much information? Thanks for any response!
>> Sorry, I'm not yet following :-)
> But it sounds like what you'd like to do is to write some opening XML
> fragment and then delegate to some handler to write the 'dynamic' XML bit,
> with an object not known in advance, and then close the tag, right ? And
> then read in a similar way.
> If yes then the JAX-RS way is to register a custom MessageBodyWriter, write
> some opening part to the OutputStream (possibly via XMLStreamWriter which
> wraps OutputStream) and then use a JAX-RS Providers context to find a more
> specific writer capable of serializing the unknown object. Reading is
> similar.  Simpler approaches could be possible.
> What would really help if you could provide some sample code and/or XML
> showing the process...Say, this is CustomBean, and it's expected to be
> serialized as follows, etc...
> Cheers, Sergey

View raw message