Re: [jboss-user] [JBoss Web Services Development] - Installing JBossWS Native on JBAS 5.1.0
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion
"Installing JBossWS Native on JBAS 5.1.0"
To view the discussion, visit: http://community.jboss.org/message/546983#546983
--------------------------------------------------------------
> ANIL SALDHANA wrote:
>
> If I need to integration testing with JBossWS, I would prefer to see an ant script that does not have many directories with a lot of duplicated jars and tests/docs etc.
which duplicated jars? The only things I see that might seem "duplicated" (but actually are not) are the container integration related directories (deploy/resources/jbossws-jbossXYZ). Of course just one of them is used, depending on the selected target container.
> The requirement is very simple - provide the least painful means to install the latest version of JBossWS on to an existing AS install.
We do run integration testing using the binary distribution every night. We had an issue with 3.3.0 testing that went un-noticed (the reason being the hudson job not starting from a clean AS at every binary distribution installation), but that problem with testing is being resolved, while the actual issue in the distribution is fixed in 3.3.1 (available since yesterday).
Besides that, installing the binary distribution for integration testing is really a matter of 2 commands:
cp ant.properties.example ant.properties
ant -Djboss510.home=/home/alessio/jboss-5.1.0.GA -Djbossws.integration.target=jboss510 deploy-jboss51
.. assuming you're using AS 5.1.0. Please note the contents in ant.properties are overwritten by the env props you provide to ant, so you don't need to edit ant.properties in a automatic job running the tests.
If that really hurts, we can even try avoiding enforcing the copy of ant.properties.example when env props are provided. The rest does not seem that painfull to me.
The script removes what needs to be removed from the AS and copies what needs to be copied.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546983#546983]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-user] [JBoss Web Services CXF] - XTS tests broken in AS trunk after switch to CXF stack in 3.3.0
by Andrew Dinn
Andrew Dinn [http://community.jboss.org/people/adinn] replied to the discussion
"XTS tests broken in AS trunk after switch to CXF stack in 3.3.0"
To view the discussion, visit: http://community.jboss.org/message/546982#546982
--------------------------------------------------------------
Hi Jim,
> Jim Ma wrote:
>
> The Contextutils.getActionFromMessageAttributes(msgInfo) is intended to get action value when there is no wsdl provided in service impl class(Service built from class) CXF simply uses MessageInfo.getExtensionAttributes() != null to check if this service is built from service class (with no wsdl location provided) . There is probably some issue when the wsdl have extension to put in the extensionAttributes of MessageInfo . The NPE guard should be added in ContextUtils.getAction() . Andrew, can you paste the wsdl ? Is there anything special in your wsdl file ?
There +is+ wsdl provided in the service imple class as my earlier post showed
> @WebService(targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", name = "ActivationPortType",
> wsdlLocation = "/WEB-INF/wsdl/wscoor-activation-binding.wsdl",
> serviceName = "ActivationService",
> portName = "ActivationPortType"
> )
> @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
> // @EndpointConfig(configName = "Standard WSAddressing Endpoint")
> @HandlerChain(file="/handlers.xml")
> @Addressing(required=true)
> public class ActivationPortTypeImpl implements ActivationPortType
> {
> . . .
There is nothing unusual about this wsdl. It extends a standard wsdl defined by OASIS WS-C with a binding for the Activation Coordinator service.
> <?xml version="1.0" encoding="utf-8"?>
> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" targetNamespace="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:wsaw="http://www.w3.org/2006/02/addressing/wsdl">
>
>
> <wsdl:import
> namespace="http://docs.oasis-open.org/ws-tx/wscoor/2006/06"
> location="wscoor.wsdl" />
>
>
> <wsdl:binding name="Activation_SOAPBinding" type="wscoor:ActivationPortType">
> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
> <wsdl:operation name="CreateCoordinationContextOperation">
> <soap:operation soapAction="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext"/>
> <wsdl:input message="wscoor:CreateCoordinationContext">
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output message="wscoor:CreateCoordinationContextResponse">
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation>
> </wsdl:binding>
>
>
> <wsdl:service name="ActivationService">
> <wsdl:port binding="wscoor:Activation_SOAPBinding" name="ActivationPortType">
> <wsaw:UsingAddressing required="true"/>
> <soap:address location="http://localhost:9000/ws-c11/ActivationService"/>
> </wsdl:port>
> </wsdl:service>
>
>
> </wsdl:definitions>
>
The imported file wscoor.wsdl is exactly as provided by the OASIS WS-C 1.1 standard. It merely defines the types and messages for the Activation Coordinator and Registration Coordinator web services.
> <?xml version="1.0" encoding="utf-8"?>
> <!--
> OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS President.
> OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS President.
> Copyright OASIS Open 2006. All Rights Reserved.
> This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself must not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
> The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
> This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> -->
> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" targetNamespace="http://docs.oasis-open.org/ws-tx/wscoor/2006/06">
> <wsdl:types>
> <xs:schema>
> <!--
> <xs:import
> namespace='http://www.w3.org/2005/08/addressing'
> schemaLocation='ws-addr.xsd' />
> -->
> <xs:import
> namespace='http://docs.oasis-open.org/ws-tx/wscoor/2006/06'
> schemaLocation='wscoor.xsd' />
> </xs:schema>
> </wsdl:types>
> <!-- Messages -->
> <wsdl:message name="CreateCoordinationContext">
> <wsdl:part name="parameters" element="wscoor:CreateCoordinationContext"/>
> </wsdl:message>
> <wsdl:message name="CreateCoordinationContextResponse">
> <wsdl:part name="parameters" element="wscoor:CreateCoordinationContextResponse"/>
> </wsdl:message>
> <wsdl:message name="Register">
> <wsdl:part name="parameters" element="wscoor:Register"/>
> </wsdl:message>
> <wsdl:message name="RegisterResponse">
> <wsdl:part name="parameters" element="wscoor:RegisterResponse"/>
> </wsdl:message>
> <!-- Port Types -->
> <wsdl:portType name="ActivationPortType">
> <wsdl:operation name="CreateCoordinationContextOperation">
> <wsdl:input message="wscoor:CreateCoordinationContext"
> wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext"/>
> <wsdl:output message="wscoor:CreateCoordinationContextResponse"
> wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext..."/>
> </wsdl:operation>
> </wsdl:portType>
> <wsdl:portType name="RegistrationPortType">
> <wsdl:operation name="RegisterOperation">
> <wsdl:input message="wscoor:Register"
> wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register"/>
> <wsdl:output message="wscoor:RegisterResponse"
> wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegisterResponse"/>
> </wsdl:operation>
> </wsdl:portType>
> </wsdl:definitions>
Anyway, the problem does not seem to me to be anything to do with the wsdl nor indeed the service impl bean definition. Both the wsdl and the @Action annotation specify that the reponse should use the same action
http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext... http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext...
and indeed that is the actionstored in the msginfo hashmap. The problem is that CXF is storing it with one key and looking it up with different keys.
I don't think the problem is safeguarded just by checking for null. Somehgow the MAPAggregator shoudl idenitfy that an Acton was provided. I think it should be looking for a map entry with the key under which the action has been installed. If it does not detect it this way how else will it idenitfy that the action was specified in the wsdl and in the @Action annotation?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546982#546982]
Start a new discussion in JBoss Web Services CXF at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-user] [JBoss Web Services CXF] - XTS tests broken in AS trunk after switch to CXF stack in 3.3.0
by Andrew Dinn
Andrew Dinn [http://community.jboss.org/people/adinn] replied to the discussion
"XTS tests broken in AS trunk after switch to CXF stack in 3.3.0"
To view the discussion, visit: http://community.jboss.org/message/546977#546977
--------------------------------------------------------------
> Richard Opalka wrote:
>
> Is it true Andrew it was tested with cxf 2.2.5?
> If yes, could you create a JIRA and provide a
> simple test case to reproduce that problem?
Well, I ran this on AS trunk which uses JBossWS 3..3.0. The release notes for 3.3.0 state that it is based on CXF 2.2.8.
These tests worked fine on hudson running on AS trunk up to 31 May. After that the hudson build started failing. I believe this coincided with the installation of 3.3.0 into AS trunk and the consequent switch to use CXF as the WS stack. Now it may be that the tests also fail on an older JBossWS-CXF -- I don't know about that for sure. But they certainly fail now on 3.3.0-CXF.
The error seems obvious and simple to me:
when creating the reply message CXF processes the @Action{output=XXX} annotation and installs the extension attribute
* [key=JAXWSAConstants.WSA_ACTION_QNAME, value = XXX] in the msginfo.
when aggregating the reply MAP values CXF looks up the action in the msginfo using keys
* JAXWSAConstants.WSAW_ACTION_QNAME,
* Names.WSA_NAMESPACE_WSDL_METADATA+Names.WSAW_ACTION_NAME
* Names.WSA_NAMESPACE_WSDL_NAME_OLD+Names.WSAW_ACTION_NAME
none of these match the key it used to install the property but it clearly expects that one of them must match.
Now, it looks to me like the check is either using the wrong key (miscoded JAXWSAConstants.WSAW_ACTION_QNAME for JAXWSAConstants.WSA_ACTION_QNAME) or else has omitted to also check for th installed key. I guess it is remotely possible that this check is only supposed to find actions installed using the 3 keys it actually tries. However, in that case i) it needs to guard against null and ii) something else later on ought to be looking for the action using the installed key. I find it hard to believe that this is actually the case.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546977#546977]
Start a new discussion in JBoss Web Services CXF at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month