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