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