No problems :-), great you've realized your idea... Cheers, Sergey
On Thu, Feb 10, 2011 at 3:49 PM, Tim Clotworthy <[email protected]> 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 [mailto:[email protected]] > Sent: Tuesday, February 08, 2011 5:19 PM > To: [email protected] > 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 < > [email protected]> 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: '[email protected]' >> 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 >
