we have two distinct jax-ws @WebServices with different target namespaces. however, these two services each declare a single @WebMethod with same name, but different parameter types (which in both cases is a single custom java class). we deploy them to websphere servers and have our WSDL/XSD generated dynamically.
apparently, we end up with two sets of WSDL/XSD where we have different ports, different namespaces for everything, but same operation name and same request/response type names and element names (again, namespaces are different).
when we call these webservices, one of them works, the other is not able to unmarshall the message because it magically expects the request type from the first one, which is clearly said in the exception that we receive.
i was able to reproduce this locally, using only jaxb and the issue appears to be as follows: SOAP messages like "soap:Body/ns1:request1" and "soap:Body/ns2:request1" somehow conflict with eachother when they are unmarshalled within the same JAXBContext and the one jaxb-annotated class referenced last wins.
WSDL spec says nothing about this (as ports are different), and even the internet doesn't know about this too much at all, so i wonder if there's something really wrong with what we do. common sense suggests this must be entirely possible.
the issue is very similar to this [unanswered] post: http://www.coderanch.com/t/463070/Web-Services/java/method-classes-conflict. and is exactly the same as this [unanswered really] post: Jaxb objects with same name (the guy doesn't really explain, why this style of doing things is not recommended).
the question really is: is it possible to declare two jax-ws services with methods having same names but different arguments and then deploy them in one web application?
