Hi,
The question lurking here is the official API of the
MessageBodyReader. How does the interceptor choose the right class to
pass to it?
Have a look please at JAXRSUtils.readFromMessageBody()
One thing we may need to figure out is how AegisElementProvider can handle
isReadable/isWriteabl
The question lurking here is the official API of the
MessageBodyReader. How does the interceptor choose the right class to
pass to it?
On Tue, Oct 21, 2008 at 1:26 PM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
>
>
>> OK, here's the problem. I don't know how providers actually get used
>> in the
OK, here's the problem. I don't know how providers actually get used
in the real code. I guess it's time to clone the systest and see how
it comes out.
You won't see then in the actual system tests. Actually, there're custom providers there, but they're registered from Spring and
that's the
OK, here's the problem. I don't know how providers actually get used
in the real code. I guess it's time to clone the systest and see how
it comes out.
On Tue, Oct 21, 2008 at 1:15 PM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
> Hi
>
>
>> Do you participate in the JSR Process for this thing? As
Hi
Do you participate in the JSR Process for this thing? As the FR
stands, @Provider seems to be required.
I don't participate - I started working with our JAX-RS impl at the time it was
at 0.5 or 0.4 level.
I'm asking questions though periodically.
@Provider is needed only if a CXF user wh
Do you participate in the JSR Process for this thing? As the FR
stands, @Provider seems to be required.
The cast is really ugly.
I'd be inclined to at least add a GenericAegisProvider that would
allow a user to avoid the cast. Adding the property thing we discussed
before and having the user pass
Hi,
First the good news - I heroically :-) fixed the AegisTest by adding a plain old cast when passing AegisTestBean.class and your
provider works perfectly well. This is how it works for JAXB too.
The RI/required section of the 1.0 FR calls for a MessageBodyReader
that delivers JAXBElements
The RI/required section of the 1.0 FR calls for a MessageBodyReader
that delivers JAXBElements! In other words, they aren't really
thinking about delivering arbitrary Java objects. Since putting
@Provider on a generic class is likely to prove chaotic (or maybe it
just works), I'm not quite sure wha
I'll try the experiment with the breakpoint again.
The API of MessageBodyReader suggests to me that, indeed, it expects
end-programmers to declare things like:
MessageBodyReader r = new SomeProviderOrAnother();
MyClass x = r.readFrom(MyClass.class, )
I want to look at the spec to see if its
The abstract providers (JAXB and Aegis) are declared as subclasses of
MessageBodyReader, not MessageBodyReader. That in turn
forces the parameter to be readFrom(Class type, ...), which
requires the input to be the one and only Object.class object.
Extending from MessageBodyReader ? What does
The abstract providers (JAXB and Aegis) are declared as subclasses of
MessageBodyReader, not MessageBodyReader. That in turn
forces the parameter to be readFrom(Class type, ...), which
requires the input to be the one and only Object.class object.
I don't see how you can assert that JAXB works wh
Hi,
I'm getting into trouble here now that I'm debugging a test case.
readFrom takes Class, not Class. I don't see how the JAXB
code could work, as it will try to obtain a type for 'Object.class',
Unfortunately Class does not compile. Plain Class is passed in to it from above and it has all t
I also note that even the systest never calls the JAXB 'readFrom'
routine. You really need a test for that.
On Mon, Oct 20, 2008 at 8:20 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> I'm getting into trouble here now that I'm debugging a test case.
>
> readFrom takes Class, not Class. I don't
I'm getting into trouble here now that I'm debugging a test case.
readFrom takes Class, not Class. I don't see how the JAXB
code could work, as it will try to obtain a type for 'Object.class',
which is the only thing in the world of type Class, AFAIK. My
code certainly won't work. I note that none
Hi Benson
I missed your merge email to the jax-rs module, the one introducing the AegisProvider. Even though there might still be some work
left to do there, this is great nonetheless, thanks. Perhaps Aegis fans such as Dan Diephouse will notice it too :-). In CXF JAX-RS
we can support 3 data b
ut in case of Aegis
it's not clear what else to check for. MediaType check should be
sufficient...
Cheers, Sergey
-Original Message-
From: Benson Margulies [mailto:[EMAIL PROTECTED]
Sent: 14 October 2008 23:11
To: dev@cxf.apache.org
Subject: Re: Aegis versus jaxrs
I haven't be
te), but we'll
> additionally register AegisProvider using Spring so that it can take
> precedence over the default JAXB provider which handles
> application/xml...
>
> Cheers, Sergey
>
> -Original Message-
> From: Benson Margulies [mailto:[EMAIL PROTECTED]
> Se
: dev@cxf.apache.org
Subject: Re: Aegis versus jaxrs
I appreciate the cache. However, the minimum number of contexts is the
number of packages!
A property that takes a context object would, however, solve all of
this for both Aegis and JAXB, so I'm excited.
Can you tell me how to make a uni
ies.
>
> Cheers, Sergey
>
> -Original Message-
> From: Benson Margulies [mailto:[EMAIL PROTECTED]
> Sent: 14 October 2008 01:00
> To: dev@cxf.apache.org; Daniel Kulp
> Subject: Re: Aegis versus jaxrs
>
> OK, now we reach the crux of the matter. JAX-RS creates
: dev@cxf.apache.org; Daniel Kulp
Subject: Re: Aegis versus jaxrs
OK, now we reach the crux of the matter. JAX-RS creates lots of
JAXBContexts, where 'normal' CXF manages to share one through an
entire service. Am I getting the idea that this is just an inescapable
aspect of the architect
use for it.
> About Schema : I presume you ask about the one from javax.xml.validation
> ?
> I just added it recently to support the optional schema validation...
>
> Cheers, Sergey
>
> -Original Message-
> From: Benson Margulies [mailto:[EMAIL PROTECTED]
> Sent:
Subject: Re: Aegis versus jaxrs
I think I finally have a sensible question by analogy with JAXB.
JAXBContext objects have a variety of options and properties. The
JAXBDataBinding allows the CXF app to control these items. The user
can make their own context and inject it into the data binding, or the
Schema: what's with the .xsd files? Does it ever let JAXB generate schema?
How would it ever aggregate across all the individual classes?
On Sun, Oct 12, 2008 at 7:13 AM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> I think I finally have a sensible question by analogy with JAXB.
>
> JAXBContex
I think I finally have a sensible question by analogy with JAXB.
JAXBContext objects have a variety of options and properties. The
JAXBDataBinding allows the CXF app to control these items. The user
can make their own context and inject it into the data binding, or the
user can set various propert
Hi
Sergey,
I'm not feeling like I'm doing a very good job of explaining myself
here. It's probably true that the best way for me to proceed is to
code something and with some comments that say: 'Sergey, I'm
frustrated HERE.' ...
Yea, please do it :-) ! I do hope though that you wouldn't need
Sergey,
I'm not feeling like I'm doing a very good job of explaining myself
here. It's probably true that the best way for me to proceed is to
code something and with some comments that say: 'Sergey, I'm
frustrated HERE.' I've not been having the time to do more for CXF
than to address users with
Hi Benson
I'm sorry If I'm too slow :-) but I'm still not getting what is it that you're
proposing.
That said, I believe that may be we should postponse the discussion on how to
improve the overall
JAX-RS implementation until after it reaches 1.0.
In meantime, if we had even a basic JAX-RS Aeg
I think I'm beginning to get the idea of what I'm trying to complain about.
An AegisDatabinding object has input configuration and it has state.
As it goes along, it constructs mappings for types.
I'm having trouble swallowing a situation in which each individual
JAX-RS item does this independent
Hi
When a CXF service offers JAX-RS, some CXF-specific configuration is
involved, no? So, could we not have some properties at the service level
which the ProviderFactory consumes-if-provided? Aegis in particular has a
set of configuration options, it would be very cumbersome to force those to
b
When a CXF service offers JAX-RS, some CXF-specific configuration is
involved, no? So, could we not have some properties at the service level
which the ProviderFactory consumes-if-provided? Aegis in particular has a
set of configuration options, it would be very cumbersome to force those to
be conf
Hi
If I'm reading the JAX-RS code correctly, which I'm probably not, it doesn't
use the JAXB DataBinding object. It interacts class-by-class with JAXB.
At the moment yes, and this is a reson I excluded a jaxb-databinding module, just to minimize the size of the
cxf-jaxrs bundle. I think jaxb
31 matches
Mail list logo
