|
From: Ryan J. M. <ry...@da...> - 2008-08-11 21:57:24
|
On Aug 11, 2008, at 12:41 PM, Bill Burke wrote:
> I'm fine with that.
>
> The JSON JAXBContexts existed as I thought users might want to use
> it outside of Readers/Writers.
True, I think we can keep the contexts, but we can consolidate the two
into one.
> FYI, I have a huge serious refactoring coming. I don't think it
> will effect providers, but most of the codebase is affected.
>
> Reason? Well, 0.10 changes a lot. Specifically:
>
> * how encoding works
> * No more Path.limited
> * Regular expression in @Paths
> * other minor API changes
>
> I've been working on it for a week now (mostly), still not done :(
Since you'll be making some changes to the core framework, it may make
more sense for me to way and fix any regression after your commit. I'm
going to hold off on any commits until those changes make their way in
unless you feel differently.
Ryan-
> Ryan J. McDonough wrote:
>> I'm finishing up the changes to the JAXB providers and had some
>> thoughts on the JSON Providers:
>> Current, the providers utilize a customized JAXBContext by
>> extending JAXBContext. There is a separate Context class for each
>> of Jettisons JSON conventions. Additionally, there's a custom
>> marshaller and unmarshaller for each convention type. What i'd like
>> to do is either get rid of the custom context and supporting
>> completely or consolidating the 2 context classes into one. We
>> could easily handle the Jettison mapping conventions via property
>> configuration rather than multiple classes. As far as configuration
>> goes, I've also been tinkering with the idea of an additional
>> annotation that can used on resource classes and methods. For
>> example:
>> @JSONConfig(value = JSONConvention.MAPPED,
>> ignoredElements = "foo")
>> public class OrderResource { ...
>> This would instruct the JSONProviders to use the mapped convention
>> and ignore <foo> elements. Additionally, we can also pass a array
>> of JSONToXml annotations that provides some fine grained control
>> over mapping process. On a related note, I also have an additional
>> JAXBConfig annotation which provides the following:
>> @JAXBConfig(packages = "org.jboss.resteasy.test.providers.jaxb.data",
>> useNameSpacePrefix = true,
>> validate = true,
>> namespaces = @XmlNs(
>> namespaceURI = "http://jboss.org/resteasy/test/providers/jaxb/generated/order
>> ", prefix = "o"))
>> @JSONConfig(value = JSONConvention.MAPPED,
>> ignoredElements = "foo")
>> public class OrderResource { ...
>> The useNameSpacePrefix attribute instructs RESTEasy to output the
>> XML using a namespace prefix. If the package is annotated with an
>> @XmlSchema annotation containing an @XmlNs annotation, the
>> namespace prefix will be lifted from there. However, the namespaces
>> array will take precedence over the package annotation. The
>> packages attribute allows you specify multiple package names. The
>> validate attribute will validate the XML against a provided XML
>> schema (attribute TBD).
>> I have most of this working at the moment but still need some more
>> time to wrap it up, but I wanted to get some feeler about the
>> aproaches here before continuing.
>> Ryan-
>> ------------------------------------------------------------------------
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
|