On Mon, Sep 7, 2009 at 1:20 PM, Sergey Beryozkin
wrote:
>
> Hi
>
> [1] +1 to b. yes it does, I haven't tried but users can wrap whatever
> providers they want into their custom JAXRS providers. I'd rather do a
> system test showing users they can do if they want.
>
I did the systest. If you think
Hi
[1] +1 to b. yes it does, I haven't tried but users can wrap whatever
providers they want into their custom JAXRS providers. I'd rather do a
system test showing users they can do if they want.
possible pros : jackson will do natural JSON easily
possible cons : it's convention-based, that is
I agree. I was focussed on the reader. Given that in the writer, it's
clear that you are correct.
On Mon, Sep 7, 2009 at 8:33 AM, Sergey Beryozkin wrote:
> Hi Benson
>
> In MessageBodyWriter.writeTo() it's actually Class which is in the
> signature. And there's no return value.
>
> We could've
Hi Benson
In MessageBodyWriter.writeTo() it's actually Class which is in the
signature. And there's no return value.
We could've implemented just MessageBodyWriter as opposed to MessageBodyWriter but it would stiill cause warning in the user
test code
I can agree that implementing Messag
I am hoping to attract some comments from other members of the community by
gathering a few threads of debate between Sergey and myself in one place. If
I misrepresent his side of these arguments I'm sure he'll let me know. I
also plan to ask some questions on the user list.
[1] The default JSON p
I'm going to start an omnibus thread.
On Mon, Sep 7, 2009 at 5:20 AM, Sergey Beryozkin wrote:
>
>
> http://wiki.fasterxml.com/JacksonInFiveMinutes
>>
>> It looks to me as if a Jackson 'provider' would be a pretty
>> straightforward
>> construction. To be clear, there's be no CXF DataBinding in t
Sergey,
With Java generics, there's a pattern:
public T gloop(Class type, whatever)
That pattern requires that you pass in the class of what you expect to get
out.
If XXXProvider implements MessageBodyReader, then it must have a
implement the read API against the same T. You can't, legitima
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/ext/MessageBodyWriter.html#writeTo(T,%20java.lang.Class,%20java.lang.reflect.Type,%20java.lang.annotation.Annotation[],%20javax.ws.rs.core.MediaType,%20javax.ws.rs.core.MultivaluedMap,%20java.io.OutputStream)
type - the class of object that is
How about dropping the namespaces from the produced JSON ? A simple wrapper
around XMLStreamWriter woud do it. And Jettison can produce natural JSONs
too (some configuration is needed for that)
As I said in the other email, some users may've invested in Aegis already.
So suppose they have a metho
http://wiki.fasterxml.com/JacksonInFiveMinutes
It looks to me as if a Jackson 'provider' would be a pretty straightforward
construction. To be clear, there's be no CXF DataBinding in the process at
all. Jackson maps pojos to JSON and vica versa.
The plus side of this is that it would yield, i
Hi,
As I said in the other email, JSON has no idea of what namespaces are so some
mapping between namespaces and prefixes has to exist.
We can also instruct Jettison to drop namespaces alltogether - if users would
like to use some JSON utilities and parse JSON sequences without worrying about
w
11 matches
Mail list logo
