<jaxws:client> configuration not picked up from jbossws-cxf.xml

[kimba74]

Hi everyone,

I'm trying to access a 3rd-party Web Service from within my webapp. Unfortunately I have to add additional classes to the client's JAXContext for it to work. According to the CXF Users Manual and from discussions I had with Daniel Kulp from Apache it should be possible to add these additional classes by configuring the client for CXF as follows:

<jaxws:client name="{urn:name:space:of:service}PortName" createdFromAPI="true">
        <jaxws:dataBinding>
            <bean class="org.apache.cxf.jaxb.JAXBDataBinding">
                <property name="ExtraClass">
                    <list>
                        <value>an.additional.binding.ObjectFactory</value>
                        <value>an.other.additional.binding.ObjectFactory</value>
                    </list>
                </property>
            </bean>
        </jaxws:dataBinding>
    </jaxws:client>

I've been experimenting with this now for three days and it doesn't work at all.

During my debugging work this weekend I logged out which beans get registered with the CXF Bus as the javax.xml.ws.Service gets created and the port gets retrieved. According to the smart guys from Apache CXF I should see a bean being created that has the name "{urn:name:space:of:service}PortName" but I don't. The only one that comes close is a bean called "{urn:name:space:of:service}PortName.jaxws-client.proxyFactory" which is of type "org.apache.cxf.jaxws.JaxWsProxyFactoryBean".

I'm also unable to add additional interceptors to the Web Service Client as described in the CXF Users Manual.

Is it possible that the jbossws-cxf.xml is only pulled in for Web Service Endpoint implementation but not for Web Service consumers?

Thanks,

Steffen

[kimba74]

Ok, am I the only one that is trying to deploy an enterprise app with Web Service clients in it that wants to configure them the way CXF allows you two?

Any help, ideas, suggestions?

Thanks,

Steffen

[asoldano]

Here I am with a preliminary reply.

Yes, the jbossws-cxf.xml is for the deployment endpoints only and is used by jbossws integration to allow controlling details of the endpoints declared through standard means (web.xml). Its contents are added as child context to the one created using the Apache CXF defaults (which means you can still provide a cxf.xml in the deployment, be sure to put it where CXF classloading mechanism can see it, e.g in WEB-INF/classes if using war archives).

Assuming you really want to use a CXF spring-configuration-based client in your deployment, you can simply have a spring bean descriptor (call it something different from cxf.xml -say client.xml-) with the client only declarations. Then you create a SpringBus pointing to that descriptor and use the bus to create the client the cxf way.

Soon I'll have a look if there's a way for tuning the JAXBContext as you need without having to go through the spring beans declarations.

[kimba74]

Alessio,

Thanks for the response. I have tried quite a few things and somehow none of them were really working. One thing I ran into while debugging was: I configured a <cxf:bus> in the jbossws-cxf.xml for logging purposes but that resulted in the Endpoint deployer not finding my configured WSDL (in @WebService and jbossws-cxf.xml) files anymore (which are provided in the WAR's WEB-INF/wsdl or in the JAR's META-INF/wsdl directory). I will try giving the cxf.xml in the classpath a shot and see if that helps, I'll keep you updated on that.

Is there any other way to configure CXF than by using their Spring based XML? From reading CXF's User Manual I did not see any other option, but then I only had a few days for going through the material.

Yes, a future JBossWS mechanism for adding additional Java classes to the JAXB Context of Endpoints as well as Clients would be VERY much appreciated, please keep me posted on that. Don't hesitate to ask if I could help with anything, I would very much like to contribute to JBossWS if I can/may.

Thanks,

Steffen

[asoldano]

Hi Steffen,

I'm evaluating possible improvement options for allowing setting the additional classes for jaxws client without the need of the spring descriptor and will also try that anyway.

We do have a mechanism for specified JAXBIntroductions that could be extended for this configuration too. We could also have a jaxws feature for this, similarly to what Metro does with UsesJAXBContextFeature / @UsesJAXBContext [1][2].

To speed up the process, any chance you can provide a simple example of a scenario where the client would need any additional class (so that I can easily create a testcase)?

Thanks

[1] http://weblogs.java.net/blog/jitu/archive/2008/08/control_of_jaxb.html

[2] http://fpaste.org/rGYH/

[kimba74]

Alessio,

Yes, I do have a small sample application I used for testing and "debugging". I can email it to you if you like.

Though I'm a huge fan of annotation based solutions, this is a case where I'm not to fond of it. The reason, the moment you add annotations to your code you tie yourself down to one stack implementation only, and in this case of Web Services, the actual endpoint implementation will have to be aware of the additional classes. Since those classes could be loaded dynamically at runtime there is no elegant way to propagate them to the endpoint implementation.

Use Case:

• Project X creates a JAR file with an XSD, the corresponding JAXB classes, a WSDL referencing afore mentioned XSD, and a SEI utilizing the JAXB classes and makes this JAR available to other projects
• Project X's XSD specifies an "envelope" like structure with the envelops "payload" element being declared abstract and meant for substitution
• Project A creates an XSD in which they extend the payload's type and create an element "payloadA" that substitutes the "payload" element from the main XSD
• Project A also creates the corresponding JAXB classes for their new XSD
• Project A now creates an endpoint implementing the SEI from Project X but expecting the "payload" element of an incoming request to be "payloadA". Since "payloadA" is never referenced in the WSDL the JAXBContext will not be able to unmarshal the incoming request

Back to the annotations, in the above mentioned Use Case the annotation would absolutely be a viable option. However, if you want to load a JAR containing let's say a "payloadB" JAXB implementation at runtime because you might not have access to the actual endpoint implementation you can not relay on the annotation alone. So if you do introduce an annotation it would be great if this feature couldalso be used via external configuration file. I do understand your motivation for moving away from the Spring configuration file as you don't want to be depending on an additional framework just for reading your config but I believe in a "specialized" case like this you almost have no other choice unless you approach it via CDI.

Let me know where you want me to email you the example project to.

Thanks for looking into that,

Steffen

[asoldano]

Sorry for the late reply, please write to alessio(dot)soldano(at)jboss(dot)com

Thanks

[asoldano]

Back to the annotations, in the above mentioned Use Case the annotation would absolutely be a viable option. However, if you want to load a JAR containing let's say a "payloadB" JAXB implementation at runtime because you might not have access to the actual endpoint implementation you can not relay on the annotation alone. So if you do introduce an annotation it would be great if this feature couldalso be used via external configuration file. I do understand your motivation for moving away from the Spring configuration file as you don't want to be depending on an additional framework just for reading your config but I believe in a "specialized" case like this you almost have no other choice unless you approach it via CDI.

As a general comment on this annotation topic, I think I see what you mean. Something I might also explore (but I really need to create a testcase first / see your test application) is extending jaxbintros [1] and using it to basically add @XmlSeeAlso annotation metadata for your not-xmlseealso-annotated classes. So you'd end up with configuring this in a descriptor. But this is still really just an idea I need to reason/work on.

[1] https://issues.jboss.org/browse/JBWS-2852