Re: [Simple-support] stating the deserialization strategy on a class using annotation
Brought to you by:
niallg
|
From: Niall G. <gal...@ya...> - 2011-03-01 11:31:27
|
Why not create this annotation yourself. It seems specific to what your doing so just created it in your own package. It will works just as well. Just wrap the Persister in a Serliaizer implementation that uses this annotation.
--- On Mon, 28/2/11, hatchetman82 <hat...@gm...> wrote:
> From: hatchetman82 <hat...@gm...>
> Subject: Re: [Simple-support] stating the deserialization strategy on a class using annotation
> To: "Niall Gallagher" <gal...@ya...>
> Cc: sim...@li...
> Received: Monday, 28 February, 2011, 4:02 AM
> we have an enterprise system with a
> REST api. basically we're sending
> and receiving XML over HTTP.
> all of our methods send or receive Simple-xml-annotated
> classes that
> represent either requests or responses. RESTeasy (the
> framework we use
> to drive this API) provides a mechanism to derialize and
> deserialize
> Objects into their string representation (XML in our case)
> via its
> MessageBodyReader and MessageBodyWriter interfaces.
> our use case revolves around the reader component. this is
> the
> component that gets an input stream and a class type and
> is
> responsible for deserializing an instance of this class
> type from the
> input stream.
>
> some of our simple-annotated classes require a strategy to
> deserialize
> (this strategy needs to be provided as an argument to the
> Persister
> constructor). since we know what type we intend to
> deserialize, we can
> provide the appropriate strategy, but the resulting code is
> a giant
> switchboard of if-elses and it not very pretty, fast or
> maintainable
> as a result (this message body reader is a single point of
> entry to
> the entire application).
>
> since Persister receives the type to be serialized as the
> 1st argument
> to its read() method, i was thinking it would have been
> nice to be
> able to state the deserialization strategy on the
> simple-annotated
> class somehow.
>
> so, for instance, instead of doing this:
>
> Strategy s = getStrategy(type); //ugly code hidden here
> Persister p = new Persister(s);
> Object result = s.read(type,inputStream);
>
> i could have something like this on my class:
>
> @DeserializationStrategy(MyStrategy.class)
> @Root(name="myClass")
> public class MyClass {
> //code here
> }
>
> and then i could create a Persister using the no-arg
> constructor, and
> upon calling read() the persister could inspect the type
> (its getting
> it as the 1st arg anyway) for @DeserializationStrategy, and
> if found
> use that strategy to read the object from the input
> stream.
> that would save us the need to find the strategy ourselves,
> and would
> make the resulting code more elegant
>
> On Mon, Feb 28, 2011 at 13:09, Niall Gallagher
> <gal...@ya...>
> wrote:
> > Hi,
> >
> > If you could provide more details that would be great!
> Not sure what your trying to achieve here. Have you tried
> the @Convert annotation or even a visitor?
> >
> > Niall
> >
> >
> > --- On Sun, 27/2/11, hatchetman82 <hat...@gm...>
> wrote:
> >
> >> From: hatchetman82 <hat...@gm...>
> >> Subject: [Simple-support] stating the
> deserialization strategy on a class using annotation
> >> To: sim...@li...
> >> Received: Sunday, 27 February, 2011, 10:47 PM
> >> Hi.
> >>
> >> we use simple-xml to (de)serialize entity classes
> for out
> >> application's REST api (using resteasy).
> >> as part of the RESTeay api, there's an interface
> called
> >> MessageBodyReader responsible for deserializing
> XML into a
> >> java class
> >> with the following signature:
> >> public Object readFrom(Class type, /* stuff
> omitted */,
> >> InputStream
> >> inputStream);
> >> deserializing some of our classes requires custom
> Strategy
> >> implementations, which turns the implementation of
> the
> >> above method
> >> int a giant switchboard of if-elses according to
> the type
> >> variable. it
> >> would be very nice to be able to have some sort
> of
> >> @DeserializationStrategy(value=[some strategy
> class])
> >> annotation on
> >> simple-xml-annotated classes to prevent this
> scenario.
> >> is this possible?
> >> if so, is it on the roadmap anywhere?
> >>
> >> thanks in advance for any assistance,
> >> radai.
> >>
> >>
> ------------------------------------------------------------------------------
> >> Free Software Download: Index, Search &
> Analyze Logs
> >> and other IT data in
> >> Real-Time with Splunk. Collect, index and harness
> all the
> >> fast moving IT data
> >> generated by your applications, servers and
> devices whether
> >> physical, virtual
> >> or in the cloud. Deliver compliance at lower cost
> and gain
> >> new business
> >> insights. http://p.sf.net/sfu/splunk-dev2dev
> >> _______________________________________________
> >> Simple-support mailing list
> >> Sim...@li...
> >> https://lists.sourceforge.net/lists/listinfo/simple-support
> >>
> >
> >
> >
> >
>
|