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

Reply via email to