-
1. Re: <jaxws:client> configuration not picked up from jbossws-cxf.xml
kimba74 Jun 13, 2012 9:59 AM (in response to 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
-
2. Re: <jaxws:client> configuration not picked up from jbossws-cxf.xml
asoldano Jun 13, 2012 11:55 AM (in response to kimba74)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.
-
3. Re: <jaxws:client> configuration not picked up from jbossws-cxf.xml
kimba74 Jun 13, 2012 12:21 PM (in response to asoldano)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
-
4. Re: <jaxws:client> configuration not picked up from jbossws-cxf.xml
asoldano Jun 18, 2012 5:38 PM (in response to kimba74)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
-
5. Re: <jaxws:client> configuration not picked up from jbossws-cxf.xml
kimba74 Jun 19, 2012 8:07 AM (in response to asoldano)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
-
6. Re: <jaxws:client> configuration not picked up from jbossws-cxf.xml
asoldano Jun 21, 2012 11:01 AM (in response to kimba74)Sorry for the late reply, please write to alessio(dot)soldano(at)jboss(dot)com
Thanks
-
7. Re: <jaxws:client> configuration not picked up from jbossws-cxf.xml
asoldano Jun 21, 2012 11:41 AM (in response to kimba74)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.