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 end of the story. The runtime will pick them up and 'prefer' them to the default ones (though it will try to use the
default ones if custom ones can't satisfy a given request). Or they can be registered from code, but that is it.
JAXRSInInterceptor will interact with ProviderFactory to find the right MessageBodyReader and JAXRSInInterceptor will check for
MessageBodyWriters. There's a quite a lot of generics unfriendly code in ProviderFactory - but I was so in a hurry at a time I
honestly didn't have time to clean that code well - it's one of the objectives on the JAX-RS docs page though :-)
Cheers, Sergey
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 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 who wrote a custom provider would
want to start using Jersey, so for that provider be picked up by Jersey
they'd need to ensure @Provider is there. We'll most likely need it for TCK
too - but may be we'll be able to auto-generate an appropriate Spring
configuration for the tests depending on custom(TCK) providers
The cast is really ugly.
Agreed - but the user won't see it ever. Only us who write the tests will.
I'd be inclined to at least add a GenericAegisProvider<T> that would
allow a user to avoid the cast. Adding the property thing we discussed
before and having the user pass in root classes would allow them to
get by with Object.class, as well.
Why would a (CXF) user have to pass Object.class ? No CXF user using JAXB
passes Object.class,
as far as the users are concerned they do
public Book update(Book)
or similar. I don't see why a CXF user will need to worry about it
all...They won't interact with the providers directly.
Well, the only exception if they start wriring a composite MessageBodyReader
and eben in that case they probably won't need to worry about all these
casts.
Or am I missing something ? Can you provide an example please if I am ?
Cheers, Sergey
On Tue, Oct 21, 2008 at 9:55 AM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
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! In other words, they aren't really
thinking about delivering arbitrary Java objects.
I think Jersey does do arbitrary objects too using Object.
@Provider on a generic class is likely to prove chaotic (or maybe it
just works), I'm not quite sure what to do. Is @Provider in the
version of the spec we are implementing.
@Provider is the annotation on which Jersey relies to scan the classpath
for
the all available custom providers such that a user does not have to
explicitly configure them.
We don't do the classpath scanning and to be honest I don't really like
this
feature anyway - there's just too much magic happening and it's only
likely
to lead to maintenance/provider clashes issues. And one would probably
need
to configure which packages can be scanned too - so I don't see any
advantage. We may need to start supporting it (scanning classpath for
providers) by the time we start working on meeting the TCK requirements
though.
On Tue, Oct 21, 2008 at 9:12 AM, Benson Margulies
<[EMAIL PROTECTED]>
wrote:
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<MyClass> r = new SomeProviderOrAnother<MyClass>();
MyClass x = r.readFrom(MyClass.class, ....)
Agreed, but it's not good for arbitrary objects...
I want to look at the spec to see if its authors gave any examples of
this kind, which is why I asked for a spec pointer.
Sorry, here're the page
[1] https://jsr311.dev.java.net/
Cheers, Sergey
It is possible to have an AegisProvider that works 'generically'
(haha), but the programmer would have to program into it a list of
classes for it to start from, via perhaps that setProperties call you
mentioned in earlier email.
