Santiago,
thanks for reminding me. I KNEW we talked about that but just couldn't
remember about the annotations' name! :-)
Luckily I answered "yes this works" in the lecture. ;-)
BTW, interesting to see how much interest (and how less knowledge) there is
"in the field" on JAX-RS. I'll try to give more lectures on it, next time
hopefully with the annotation's name in mind.
Regards
Markus
From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
Sent: Montag, 28. Juli 2014 15:44
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: POJO holding several header parameters
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