Hi Markus,
We added @BeanParam in 2.0:
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/BeanParam.html
That's what you're asking for, right? Note that the param needs an annotation not to be confused with the parameter entity.
-- Santiago
On Jul 25, 2014, at 12:31 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> 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