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 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. >>>>> >>> >>> > >
