[ https://issues.jboss.org/browse/JBWS-3291?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3291: ---------------------------------- Fix Version/s: jbossws-native-4.0 (was: jbossws-native-4.0.0.Beta1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3291?page=com.atlassian.jira.plugin.... ] Richard Opalka commented on JBWS-3291: -------------------------------------- <ropalka> asoldano, I'm investigating JBWS-3291 ATM and I think we're not going to fix it <ropalka> asoldano, let me explain current situation <ropalka> asoldano, there are two design issues related to this (I'm talking about Native) <asoldano> ropalka, reading... <ropalka> * we depend on wsdl4j thirdparty artifact that doesn't allow operation name with same name (so called wsdl overloaded methods) - typical exception thrown for such WSDLs is: <ropalka> - http://fpaste.org/0nTL/ <ropalka> * JBossWS Native was designed in the way it also doesn't allow overloaded methods for endpoints - I was trying to fix it locally but it results in API changes explosion <ropalka> - I started modifying Native to lookup operation not only via QName (operationName) key, but via both QName (operationName) & soapAction <asoldano> ropalka, I can immagine... <ropalka> - this would require complete Native redesign because <ropalka> - we'd need to pass soapAction everywhere <ropalka> - our Native was designed in the way this might little bit work for WS-A usecases where soapAction is in the envelope <asoldano> ropalka, mmhh... not something to spend time on now imho... <ropalka> - this will not work for standard soap messages where soapAction is present in HTTP request header - would require further Native changes to propagate it to all invocations <ropalka> asoldano, conclusion <ropalka> asoldano, Native was designed with precondition overloaded methods are not allowed on both client & server side <ropalka> - also because of wsdl4j dependency (that is forbidding it too) <asoldano> ropalka, btw, does the same usecase work with cxf? <asoldano> ropalka, I assume not.. <ropalka> - also because further design decisions <ropalka> asoldano, I can try it, but if it depend on wsdl4j too, then no <asoldano> ropalka, if you can, just give that a try too <ropalka> asoldano, give me few minutes <asoldano> ropalka, sure, np <ropalka> asoldano, I need to move the test case from native to shared-testsuite ... <asoldano> ropalka, JimMa: in the mean time, 4.0.0.Beta1 is finally released * ropalka 's refactoring test case to try CXF how it deals with overloaded WSDL operations ... <ropalka> asoldano, great ;) <ropalka> asoldano, OK, I've got the result <ropalka> asoldano, the same applies for CXF, it doesn't allow you WSDL overloaded methods <ropalka> asoldano, see - http://fpaste.org/MoSj/ <asoldano> ropalka, ok, then we can conclude that this is a limitation with wsdl4j and can't be fixed <ropalka> asoldano, in case of CXF it's not wsdl4j issue - it's design limitation <ropalka> asoldano, and AFAIK org.apache.cxf.service.model.InterfaceInfo is reused on both client & server CXF side <ropalka> asoldano, so it's not easily fixable on CXF side too :( <ropalka> asoldano, I'll close this JBWS-3291 bug as won't fix <asoldano> ropalka, ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3291?page=com.atlassian.jira.plugin.... ] Richard Opalka edited comment on JBWS-3291 at 5/11/11 6:27 AM: --------------------------------------------------------------- <ropalka> asoldano, I'm investigating JBWS-3291 ATM and I think we're not going to fix it <ropalka> asoldano, let me explain current situation <ropalka> asoldano, there are two design issues related to this (I'm talking about Native) <asoldano> ropalka, reading... <ropalka> * we depend on wsdl4j thirdparty artifact that doesn't allow operation name with same name (so called wsdl overloaded methods) - typical exception thrown for such WSDLs is: <ropalka> - http://fpaste.org/0nTL/ <ropalka> * JBossWS Native was designed in the way it also doesn't allow overloaded methods for endpoints - I was trying to fix it locally but it results in API changes explosion <ropalka> - I started modifying Native to lookup operation not only via QName (operationName) key, but via both QName (operationName) & soapAction <asoldano> ropalka, I can immagine... <ropalka> - this would require complete Native redesign because <ropalka> - we'd need to pass soapAction everywhere <ropalka> - our Native was designed in the way this might little bit work for WS-A usecases where soapAction is in the envelope <asoldano> ropalka, mmhh... not something to spend time on now imho... <ropalka> - this will not work for standard soap messages where soapAction is present in HTTP request header - would require further Native changes to propagate it to all invocations <ropalka> asoldano, conclusion <ropalka> asoldano, Native was designed with precondition overloaded methods are not allowed on both client & server side <ropalka> - also because of wsdl4j dependency (that is forbidding it too) <asoldano> ropalka, btw, does the same usecase work with cxf? <asoldano> ropalka, I assume not.. <ropalka> - also because further design decisions <ropalka> asoldano, I can try it, but if it depend on wsdl4j too, then no <asoldano> ropalka, if you can, just give that a try too <ropalka> asoldano, give me few minutes <asoldano> ropalka, sure, np <ropalka> asoldano, I need to move the test case from native to shared-testsuite ... <asoldano> ropalka, JimMa: in the mean time, 4.0.0.Beta1 is finally released <ropalka> asoldano, great ;) <ropalka> asoldano, OK, I've got the result <ropalka> asoldano, the same applies for CXF, it doesn't allow you WSDL overloaded methods <ropalka> asoldano, see - http://fpaste.org/MoSj/ <asoldano> ropalka, ok, then we can conclude that this is a limitation with wsdl4j and can't be fixed <ropalka> asoldano, in case of CXF it's not wsdl4j issue - it's design limitation <ropalka> asoldano, and AFAIK org.apache.cxf.service.model.InterfaceInfo is reused on both client & server CXF side <ropalka> asoldano, so it's not easily fixable on CXF side too :( <ropalka> asoldano, I'll close this JBWS-3291 bug as won't fix <asoldano> ropalka, ok was (Author: ropalka): <ropalka> asoldano, I'm investigating JBWS-3291 ATM and I think we're not going to fix it <ropalka> asoldano, let me explain current situation <ropalka> asoldano, there are two design issues related to this (I'm talking about Native) <asoldano> ropalka, reading... <ropalka> * we depend on wsdl4j thirdparty artifact that doesn't allow operation name with same name (so called wsdl overloaded methods) - typical exception thrown for such WSDLs is: <ropalka> - http://fpaste.org/0nTL/ <ropalka> * JBossWS Native was designed in the way it also doesn't allow overloaded methods for endpoints - I was trying to fix it locally but it results in API changes explosion <ropalka> - I started modifying Native to lookup operation not only via QName (operationName) key, but via both QName (operationName) & soapAction <asoldano> ropalka, I can immagine... <ropalka> - this would require complete Native redesign because <ropalka> - we'd need to pass soapAction everywhere <ropalka> - our Native was designed in the way this might little bit work for WS-A usecases where soapAction is in the envelope <asoldano> ropalka, mmhh... not something to spend time on now imho... <ropalka> - this will not work for standard soap messages where soapAction is present in HTTP request header - would require further Native changes to propagate it to all invocations <ropalka> asoldano, conclusion <ropalka> asoldano, Native was designed with precondition overloaded methods are not allowed on both client & server side <ropalka> - also because of wsdl4j dependency (that is forbidding it too) <asoldano> ropalka, btw, does the same usecase work with cxf? <asoldano> ropalka, I assume not.. <ropalka> - also because further design decisions <ropalka> asoldano, I can try it, but if it depend on wsdl4j too, then no <asoldano> ropalka, if you can, just give that a try too <ropalka> asoldano, give me few minutes <asoldano> ropalka, sure, np <ropalka> asoldano, I need to move the test case from native to shared-testsuite ... <asoldano> ropalka, JimMa: in the mean time, 4.0.0.Beta1 is finally released * ropalka 's refactoring test case to try CXF how it deals with overloaded WSDL operations ... <ropalka> asoldano, great ;) <ropalka> asoldano, OK, I've got the result <ropalka> asoldano, the same applies for CXF, it doesn't allow you WSDL overloaded methods <ropalka> asoldano, see - http://fpaste.org/MoSj/ <asoldano> ropalka, ok, then we can conclude that this is a limitation with wsdl4j and can't be fixed <ropalka> asoldano, in case of CXF it's not wsdl4j issue - it's design limitation <ropalka> asoldano, and AFAIK org.apache.cxf.service.model.InterfaceInfo is reused on both client & server CXF side <ropalka> asoldano, so it's not easily fixable on CXF side too :( <ropalka> asoldano, I'll close this JBWS-3291 bug as won't fix <asoldano> ropalka, ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3291?page=com.atlassian.jira.plugin.... ] Richard Opalka commented on JBWS-3291: -------------------------------------- The typical Native exception looks like: --- Caused by: java.lang.IllegalArgumentException: Duplicate operation with name=echo, found in binding '{http://jbws3291.jaxws.ws.test.jboss.org/}EndpointBinding'. at com.ibm.wsdl.BindingImpl.getBindingOperation(Unknown Source) [:1.6] at org.jboss.ws.tools.wsdl.WSDL11Reader.getBindingOperation(WSDL11Reader.java:1113) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDL11Reader.getOperationStyle(WSDL11Reader.java:1122) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDL11Reader.processPortTypeOperations(WSDL11Reader.java:789) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDL11Reader.processPortType(WSDL11Reader.java:776) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDL11Reader.processBinding(WSDL11Reader.java:1208) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDL11Reader.processPort(WSDL11Reader.java:1733) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDL11Reader.processPorts(WSDL11Reader.java:1718) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDL11Reader.processServices(WSDL11Reader.java:1688) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDL11Reader.processDefinition(WSDL11Reader.java:182) [:4.0.0-SNAPSHOT] at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:129) [:4.0.0-SNAPSHOT] at org.jboss.ws.metadata.umdm.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:293) [:4.0.0-SNAPSHOT] at org.jboss.ws.metadata.builder.jaxws.JAXWSWebServiceMetaDataBuilder.buildWebServiceMetaData(JAXWSWebServiceMetaDataBuilder.java:199) [:4.0.0-SNAPSHOT] at org.jboss.ws.metadata.builder.jaxws.JAXWSServerMetaDataBuilder.setupProviderOrWebService(JAXWSServerMetaDataBuilder.java:50) [:4.0.0-SNAPSHOT] at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilderJSE.buildMetaData(JAXWSMetaDataBuilderJSE.java:63) [:4.0.0-SNAPSHOT] at org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect.start(UnifiedMetaDataDeploymentAspect.java:64) [:4.0.0-SNAPSHOT] at org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer.internalDeploy(WSDeploymentAspectDeployer.java:123) [:4.0.0-SNAPSHOT] at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA] ... 44 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3291?page=com.atlassian.jira.plugin.... ] Richard Opalka commented on JBWS-3291: -------------------------------------- Even more we claim to be WS-I profile compliant. As Jim Ma properly pointed out this is forbidden by WS-I spec. --- 5.4.3 Distinctive Operations Operation name overloading in a wsdl:portType is disallowed by the Profile. R2304 A wsdl:portType in a DESCRIPTION MUST have operations with distinct values for their name attributes. Note that this requirement applies only to the wsdl:operations within a given wsdl:portType. A wsdl:portType may have wsdl:operations with names that are the same as those found in other wsdl:portTypes. --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira