Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Mon, 7 Mar 2011 17:40:00 +0000 (UTC)
From: "Sergey Beryozkin (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <1655287330.1540.1299519600289.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <893684097.107.1299274185861.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Issue Comment Edited: (CXF-3379) @Context fails to inject
 Application instance
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003460#comment-13003460 ] 

Sergey Beryozkin edited comment on CXF-3379 at 3/7/11 5:39 PM:
---------------------------------------------------------------

Hi Ben

Please stay with with me for a moment while I'm trying to grasp this idea.
I can see why an Application can be injected in a plain servlet web app for the latter to dynamically get the service objects. So that makes sense.

Actually, MyApplication.getWidgetDao() kind of start making sense too. So we have a root resource and it delegates to that widgetDao... Definitely the non-Spring option :-) but I can see the picture a bit better, thanks.

So yes, the patch looks fine so far, you might want to drop contextMessage.getExchange() it can only be null if message.seyExchange(new ExchangeImpl()) was not done in the test, never null in the real case...Same for the endpoint representation, even on the client side. 

The only missing bit is the related ThreadLocal implementation, to be located in impl.tl subpackage and it will need to be initialized in the InjectionUtils, which is where the thread-safe proxy is initially injected. 

May be the time has come to remove most of those explicit thread local implementations and use generic proxies instead. I'd probably leave ThreadLocalMessageContext only, so that we can avoid NPEs in the JAX-WS/JAX-RS case. Please feel free to open a related JIRA, but probably we will keep explicit TL implementations in 2.4.0 and work on it later on...

thanks   


      was (Author: sergey_beryozkin):
    Hi Ben

Please stay with with me for a moment while I'm trying to grasp this idea.
I can see why an Application can be injected in a plain servlet web app for the latter to dynamically get the service objects. So that makes sense.

Actually, MyApplication.getWidgetDao() kind of start making sense too. So we have a root resource and it delegates to that widgetDao... Definitely the non-Spring option :-) but I can see the picture a bit better, thanks.

So yes, the patch looks fine so far, you might want to drop contextMessage.getExchange() it can only be null if message.seyExchange(new ExchangeImpl()) was not done in the test, never null in the real case...Same for the endpoint representation, even on the client side. 

The only missing bit is the related ThreadLocal implementation, to be located in impl.tl subpackage and it will need to be initialized in the InjectionUtils, which is where the thread-safe proxy is initially injected. 

May be the time has come to remove most of those explicit thread local implementations and use generic proxies instead. I'd probably leave ThreadLocalMessageContext only, so that we can avoid NPEs in the JAX-WS/JAX-RS case. Please feel free to open a related JIRA, but probably we won't do this refactoring before 2.4.0...

thanks   


> @Context fails to inject Application instance
> ---------------------------------------------
>
>                 Key: CXF-3379
>                 URL: https://issues.apache.org/jira/browse/CXF-3379
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.3.3
>            Reporter: Ben Noordhuis
>
> Quoting JSR 311:
> "The instance of the application-supplied Application subclass can be injected into a class field or method parameter using the @Context annotation. Access to the Application subclass instance allows configuration information to be centralized in that class. Note that this cannot be injected into the Application subclass itself since this would create a circular dependency."
> JAXRSUtils.createContextValue() doesn't handle this. This bug exists in 2.3.x and HEAD.
> I'd submit a patch but I don't know where (or if) the Application class is registered after it's instantiated by CXFNonSpringJaxrsServlet.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira