Hi Sergey,
Sergey Beryozkin wrote:
> Hello,
>
> Apologies if a similar question has been asked before.
>
> What is the recommended way (now or once it becomes supported) to add
> custom extensions to Jersey ?
>
Two main forms of extension, message body reader/writer, and
configuration (ApplicationConfig) have been pushed to the JAX-RS API.
Other public extension areas are:
1) MVC with templates, using the @Provider mechanism; and
2) IoC integration using ComponentProvider interface.
3) Extending the Jersey Servlet.
4) Container support.
5) JSON extensions.
Each is slightly different in what needs to be done. The evolution of
these areas has been driven to various extents by developer input.
> For example. It's a hypothetical example but hopefully it will clarify
> what I'm looking for.
>
> Suppose I'd like to support the following request :
>
> GET /myresources?$filter[id > 1]
>
> That is I'd like to get back the collection of resources with ids > 1
> only. This is a feature which I'm going to say my service runtime will
> support automatically, without an application code having to deal with it.
>
> 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.
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.
> Another possible example. Just for fun, I'd like to generate a WSDL 2.0
> representation (even though I like WADL :-)) for my resource known to
> support just GEt & POST. Once again I need an access to the resource
> class, but in this case before the invocation occurs.
>
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.
> Can you please advise me on how one can provide such extensions in
> Jersey ? If it's not possible now, are there any plans in Jersey to let
> users plugin custom extensions in the future ?
>
Not so sure about the first case, i think i would need to see more
examples/reasons to better understand it. The latter case looks doable,
it will require some public plug-in to expose to expose WSDL at runtime
rather then deploy time.
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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109