On Feb 19, 2009, at 6:39 PM, Roytman, Alex wrote:
> Hello Paul,
>
> Thank you, an excellent example!
>
> Very helpful for my cleanup service as I was trying to use @Context
> to register my own @Context type where your example just use it for
> Injectable.
>
> Currently, apart from request, there is only singleton scope. Any
> plans to have a session scope (and session concept and
> encapsulation) in JAX-RS and Jersey?
>
Session scope is supported for resource classes when deploying as a
Web app. Singleton injectable providers will work on such session-
scope resource classes, because the singleton scope is wider than the
session scope.
I do not want to go beyond support for that because of the breaking of
the stateless REST constraint. You can do the same trick i defined
using HttpContext with the Servlet session attributes. But i would
recommend using Spring or Guice for proper session support.
> Also besides sharing a common injectables, do you see any other ways
> of communicating from request scope Resources to Singleton
> resources. For example by injecting @JaxRsResource("optional/
> resource/path") SingletoneResourceInterface. Session level resources
> could work as well.
>
Hmm... think the best way to do that if really needed is to support a
generic proxying class injected as a singleton whose generic value
represents the injection type, then one can do a get on the proxy e.g.
@QueryParam("xxx") Proxy<String> ps;
...
String s = ps.get()
> Another thing I wanted to mention is Provider filtering. Let's say I
> use a third party library of providers and some of them conflict
> with my own. I would need a way of excluding some of them by either
> some sort of precedence or regular expressions
>
You can do that by being explicit about all the provider classes you
require and not using class scanning for certain packages. To do that
create your own ResourceConfig impl, perhaps extending say
PackagesResourceConfig to scan for certain packages, then add classes
explicitly.
Paul.