Sergey Beryozkin wrote:
> 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.
>
Yes.
> > 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 ?
>
Transacted methods.
I am not that familiar with Spring/Guice et. al. either, just that i
would like to investigate their features further to determine if we need
to do something specific or not for application-level filters.
> > 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 could allow functionality to obtain the abstract model for any
resource class, or even inject a model for a resource onto a resource.
The harder bit is augmenting the runtime model to add functionality to
respond to GET/OPTIONs/URIs. I could expose that for manipulation by
plugins to add/modify their own stuff (i had some half baked stuff to do
that, but removed it). It would need some tidying up. As i said if you
need it we can work on it.
BTW what i do with WADL support is augment the runtime model, but i have
to be careful because it can be intrusive and interfere with the
application. This is why i now only support the WADL for the application
as whole, or using the OPTIONs for each resource (unless implemented
explicitly by the developer).
I also have (not very well documented) plug-in support for processing of
resource methods of various signatures (see my blog on Scala to do
pre-condition support using closures).
> > 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.
>
In terms of the abstract model it should be easy to do this:
@Path("/")
public class R {
@Context AbstractModel m;
@ProduceMime("application/wsdl") public getWsdl() {
// Reason on the abstract model
// return WSDL document generated on the abstract model
}
}
BTW another reason why one might want to use the abstract model is
because of the interface support i will be implementing, meaning that
annotations may be on the interface method and not the class method. The
model will hide such details.
> 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)...
>
Yes, i am not saying that IoC frameworks would solve everything,
specifically i am referring to the application-specific pre/post invoke
support offered by IoC frameworks.
Paul.
>
> Thanks, Sergey
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109