Hi Paul
Thanks for the detailed response.
>> To automatically support a feature like this one on top of Jersey, I'd
>> need an access to an actual resource class so that I could figure out
>> few things about the actual collection class and its individual members.
>> I this case I'd need my extension be invoked after the actual invocation
>> on the resource class occurs.
>>
>
> You could use a message body writer that operates on a Java type
> returned by the invocation on the resource and that type encapsulates
> the collection and other information.
Yes indeed, you're right, message body writers can help in cases like the one I described. Readers might be handly in some cases too.
> Note that for general pre/post interceptors i would prefer to rely on an
> IoC framework rather than reinventing, unless there are a whole bunch of
> use-cases that are hard to do with an IoC framework.
I'm not quite sure how far one can get with an IoC framework if the requirement is to provide add-on features without an application developer having to deal with them (with minor exceptions). I suppose I just don't know Spring well. As far as I can see it can help with the AOP XML configuration thus facilitating an out-of-band pre/post processing of requests but I'd be a bit concerned about relying *completely* on the AOP support - it's a bit too complicated and a bit too fine-grained to be counted upon as the main mechanism for add-on features in a higher level product. Are you aware of some other features in say Spring which would help with adding custom features without affecting the (JAX-RS) application code much ?
> Jersey has an abstract resource model API, which may be more appropriate
> to operate on rather than the resource class itself. This model
> abstracts from the runtime annotations and ensures that one does not
> need to validate/process. We use this model to generate WADL and also
> generate runtime information for invocation on resource classes. There
> is an ant task to generate WADL from compiled classes and you could do a
> similar thing for WSDL 2.0. It is a little more tricky to do it at
> runtime, as there is no exposed plug in point.
This sounds interesting. If Jersey provided an extension point such that at runtime one or more registered entities can use this abstract model and then let the request proceed or block it then it would likely be quite useful. Perhaps the reference to the actual resource class should also be available as it may need to be checked for custom annotations, etc.
What would be your initial thoughts on such an extension point ?
> I like to drive changes/refactoring of Jersey to support new
> requirements based on feedback/use-cases/requests from developers. If
> you would like to work together on what you need i would be happy to do
> that.
What I'd like to do is to be able to add a number of add-on features without the application code being affected. Some minimal coupling like relying on some JAX-RS-runtime specific annotations in the actual code would not be a big problem. I can use message body providers, but I'm not sure they'll work in all the variations...Ideally I'd like to be able to do it at a JAX-RS level but I'm also interested in how Jersey can help.
Generating various sorts of metadata documents, supporting sophisticated queries, etc, on the fly, are just some of the examples. I can go and list some more concrete examples but I hope you can agree that it may not be easy to use IoC frameworks when a feature is to be provided on top of the application code (resource class)...
Thanks, Sergey
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland