Experts,
recently I gave a lecture on JAX-RS at JUG Karlsruhe. In the following
discussion I was asked one question I was uncertain whether this is
possible. I checked the spec and did not find a clarification, so I'd like
to ask for your opinions.
Parameters can get injected into resources. The type of the receiving member
may be anything which can initialize from String. Hence, the JAX-RS
container creates an instance of that type, and forwards the parameter as a
String to that instance. So far, so good.
Sometimes it makes sense to have interrelated parameters stored in a shared
object. For example, caching. Typically "cache-control", "max-age" and so
on, are sematically interrelated, and it might be beneficial for passing
around that values, if all of them are in some shared object like
"CacheConfig".
It definitively is possible to build such a "CacheConfig" manually from the
already injected values. The question I was asked by the JUG was: Wouldn't
it be good if the annotations (@HeaderParam etc.) are placed at the shared
object (like "CacheConfig"), so JAX-RS could simply build one shared
instance for all those values?
Example:
class MyResource {
@GET public X foo(CacheCfg cc) {.}
.
}
class CacheCfg {
@HeaderParam("cache-control") String ctrl;
@HeaderParam("max-age") String max;
}
From the aspect of an extension vendor I think this is an appealing idea, as
I could have all "my" WebDAV stuff in one single place, separated cleanly
from the application's "own" parameters.
What do you think, is this a feature we should add to JAX-RS 2.1?
Regards
-Markus