re: Cannot obtain UriInfo in isWriteable() for custom providers

[K Fung <kf...@gmail.com>]

Hi everyone,

I have a question about the technique described at
http://cxf.547215.n5.nabble.com/Cannot-obtain-UriInfo-in-isWriteable-for-custom-providers-td5023534.html.
Wouldn't it be possible to run into a race condition involving the injected
variables?

Per section 4.1 JAX-RS specification, "By default a single instance of each
provider class is instantiated for each JAX-RS application". This means
that any instance variable injection (e.g., such as those done by @Context)
may be overwritten by the next thread that uses that provider. To put it
even more succinctly...

1. A single instance of MyJSONProvider has been instantiated by the CXF
JAX-RS framework
2. Request one reaches MyJSONProvider and CXF injects A into
context. Request one is in the MyJSONProivder.isWriteable method.
3. Request two reaches MyJSONProvider and CXF injects B into the context.
Request two is in the MyJSONProvider.writeTo method.
4. Request one resumes. It sees "B" in the context instead of "A" :(

Is there a way within CXF to allow a provider to be created for each
request? Alternatively, can variables be injected in a provider in a
thread-safe way (perhaps using ThreadLocal)?

I should also mention that we're not afraid of getting into modifying CXF
JAX-RS internals. So if we need to implement something within CXF, we could
give that a whirl too.

Thanks in advance!

Cheers,
kl

Re: Cannot obtain UriInfo in isWriteable() for custom providers

[K Fung <kf...@gmail.com>]

> Currently all the providers (as opposed to root resource classes which can
> have various lifecycles) are treated as singletons by CXF.
> But the contexts are thread-safe, the providers get the thread-safe proxies
> injected early at the init time...

I should have debugged this further before asking this question (there
are limitations to code reviews by sight ... heh) :-)

Indeed thread-safe proxies are injected and this cares of the possible
race condition.

Thx for the quick response!

Regards,
kl

Re: Cannot obtain UriInfo in isWriteable() for custom providers

[Sergey Beryozkin <sb...@gmail.com>]

Hi KL
On 31/01/12 00:10, K Fung wrote:
> Hi everyone,
>
> I have a question about the technique described at
> http://cxf.547215.n5.nabble.com/Cannot-obtain-UriInfo-in-isWriteable-for-custom-providers-td5023534.html.
> Wouldn't it be possible to run into a race condition involving the injected
> variables?
>
> Per section 4.1 JAX-RS specification, "By default a single instance of each
> provider class is instantiated for each JAX-RS application". This means
> that any instance variable injection (e.g., such as those done by @Context)
> may be overwritten by the next thread that uses that provider. To put it
> even more succinctly...
>
> 1. A single instance of MyJSONProvider has been instantiated by the CXF
> JAX-RS framework
> 2. Request one reaches MyJSONProvider and CXF injects A into
> context. Request one is in the MyJSONProivder.isWriteable method.
> 3. Request two reaches MyJSONProvider and CXF injects B into the context.
> Request two is in the MyJSONProvider.writeTo method.
> 4. Request one resumes. It sees "B" in the context instead of "A" :(
>
> Is there a way within CXF to allow a provider to be created for each
> request? Alternatively, can variables be injected in a provider in a
> thread-safe way (perhaps using ThreadLocal)?
>

Currently all the providers (as opposed to root resource classes which 
can have various lifecycles) are treated as singletons by CXF.
But the contexts are thread-safe, the providers get the thread-safe 
proxies injected early at the init time...

> I should also mention that we're not afraid of getting into modifying CXF
> JAX-RS internals. So if we need to implement something within CXF, we could
> give that a whirl too.

Sounds good indeed :-)

thanks, Sergey
>
> Thanks in advance!
>
> Cheers,
> kl
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com