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.
