CXF
  1. CXF
  2. CXF-2674

@Resource not injecting WebServiceContext in jaxws intereceptor

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: 2.2.5
    • Fix Version/s: Invalid
    • Component/s: None
    • Environment:

      tomcat 6.0.18, Spring 2.5, Spring Security 2.0.5, cxf-2.2.5 with wss4j-1.5.8

      Description

      If you want to inject the WebServiceContext into a In/Out-Interceptor configured with xml (e.g. <jaxws:ininterceptors><bean id="someInterceptor" class="test.SomeInterceptor"/></jaxws:ininterceptors />) with the @resource annotation, the WebServiceContext is null. (Even with component-scan enabled and annotation-config defined)

      If you inject the WebServiceContext into the interceptor with a property-setter in the xml (e.g. <property name="ctx" value="javax.xml.ws.WebServiceContext" />) the instance is not empty, but holding nothing (like MessageContext )

      The documentation suggest the way with the @Resource annotation, so this is rather confusing.

      The work-around I found, is to set the properties I wanted to set on the message in the handleMessage method of the interceptor (e.g. message.put("someKey", someValue); )
      I would rather see the @Resource injection working.

      Regards,

      Auke Noppe
      Developer @ Ymor (.nl)

      1. webservicecontext_test.zip
        13 kB
        Auke Noppe
      2. logging.log
        21 kB
        Auke Noppe

        Activity

        Hide
        Daniel Kulp added a comment -

        This is technically an "issue" with Spring. The spring injection engine has a hard coded "exclude" that excludes it from injecting any @Resource things of type javax.xml.ws.WebServiceContext. It's even mentioned in the javadoc:

        http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/context/annotation/CommonAnnotationBeanPostProcessor.html

        We've done SOME work to try and get around it, but apparently not enough. Can you create a small testcase?

        You can get around it by doing something like:

        <property name="ctx" value="org.apache.cxf.jaxws.context.WebServiceContextImpl" />

        to get an instance of exactly what would be injected.

        Show
        Daniel Kulp added a comment - This is technically an "issue" with Spring. The spring injection engine has a hard coded "exclude" that excludes it from injecting any @Resource things of type javax.xml.ws.WebServiceContext. It's even mentioned in the javadoc: http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/context/annotation/CommonAnnotationBeanPostProcessor.html We've done SOME work to try and get around it, but apparently not enough. Can you create a small testcase? You can get around it by doing something like: <property name="ctx" value="org.apache.cxf.jaxws.context.WebServiceContextImpl" /> to get an instance of exactly what would be injected.
        Hide
        Auke Noppe added a comment - - edited

        A small Eclipse testproject demonstrating the @resource injection that is not working.
        the logging output is also attached.
        I didn't attach any libs because of the upload-filesize.

        Show
        Auke Noppe added a comment - - edited A small Eclipse testproject demonstrating the @resource injection that is not working. the logging output is also attached. I didn't attach any libs because of the upload-filesize.
        Hide
        Auke Noppe added a comment -

        I read the javadoc of the CommonAnnotationBeanPostProcessor and isn't it an idea to override the CommonAnnotationBeanPostProcessor and sets a BeanFactory on the property "resourceFactory" in the cxf-extension-jaxws.xml?
        This way, the CommonAnnotationBeanPostProcessor will be overridden only when the xml is imported in the application cxf xml configfile.

        Show
        Auke Noppe added a comment - I read the javadoc of the CommonAnnotationBeanPostProcessor and isn't it an idea to override the CommonAnnotationBeanPostProcessor and sets a BeanFactory on the property "resourceFactory" in the cxf-extension-jaxws.xml? This way, the CommonAnnotationBeanPostProcessor will be overridden only when the xml is imported in the application cxf xml configfile.
        Hide
        Daniel Kulp added a comment -

        I just realized you are dealing with cxf Interceptors, not jax-ws handlers. The WebServiceContext would be completely irrelevant in an interceptor as they aren't a JAXWS concept. The WebServiceContext is really just a thin wrapper around the SoapMessage that is passed into the interceptors handleMessage method. Thus, it's really not needed.

        Show
        Daniel Kulp added a comment - I just realized you are dealing with cxf Interceptors, not jax-ws handlers. The WebServiceContext would be completely irrelevant in an interceptor as they aren't a JAXWS concept. The WebServiceContext is really just a thin wrapper around the SoapMessage that is passed into the interceptors handleMessage method. Thus, it's really not needed.
        Hide
        Auke Noppe added a comment -

        so, a 'work-around' for this would be to put attributes on the soapmessage and read them from the WebServiceContext in the webserviceimpl?

        Show
        Auke Noppe added a comment - so, a 'work-around' for this would be to put attributes on the soapmessage and read them from the WebServiceContext in the webserviceimpl?
        Hide
        Daniel Kulp added a comment -


        Correct. The Message object passed into the interceptor is the context for that request. Stuff put there is retrievable later.

        Show
        Daniel Kulp added a comment - Correct. The Message object passed into the interceptor is the context for that request. Stuff put there is retrievable later.

          People

          • Assignee:
            Daniel Kulp
            Reporter:
            Auke Noppe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development