The only standard context class the injection of which is not supported is
JAX-RS 2.0 Configuration.
It is supported in the new Client API, but I've honestly no idea what
does it mean to inject it into a given JAX-RS service resource class...
Having it used directly by the application class does not seem to make
sense, but may be I'm wrong, I'll need to look into it further.
Can you please give me a favor and investigate if people are using it at
all as a server-side injected context ? I'll open a JIRA in meantime to
track the issue
Thanks, Sergey
On 23/07/14 17:09, Sergey Beryozkin wrote:
HttpSerletRequest/etc also have to be supported in mist cases...
Cheers, Sergey
On 23/07/14 15:22, Sergey Beryozkin wrote:
On 23/07/14 12:31, Grant Yang wrote:
This code makes me wonder what will happen if we just have
@Context
public void setString(String string) {
System.out.println("shall that happen?"\n");
}
CXF supports custom contexts by creating proxies with the help of Java
Proxy so in this case it won't be created as well as for any other
non-interface types.
No validation has been done so far on the injection, we are starting
doing some work around it.
Next, when you have
@Context
public void setMyInterface(MyInterface interface) {
System.out.println("shall that happen?"\n");
}
you will get a proxy injected but also NPE at runtime unless a
ContextProvider supporting MyInterface. We will be working on avoiding
keeping such proxies if no ContextProvider is available
Sergey
--
View this message in context:
http://cxf.547215.n5.nabble.com/context-injection-through-setter-method-method-name-restriction-tp5746712p5746783.html
Sent from the cxf-dev mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com