WSDL-location help?

[oskar.carlstedt]

Hi all!!

I just want to ask if it is a requirement to put the wsdl file in the WEB-INF/wsdl folder. I want to have my WSDL (with a lot of schema-imports) on a more common place (an http://...... url).

Doing this will casue JBossWS (JBoss 4.0.5.GA and JBossWS 1.2) to fail the deployment and ask for a WSDL file in the WEB-INF/wsdl folder.

So, is it possible to have the WSDL file on a remote server and still develop a service endpoint?

Thanks
Oskar

[monowai]

You shouldn't have to create WSDL files at all. If you're using annotations and jbossws-1.2 then the WSDL is created and published during deployment whenever the deployer spots a @webservice. v. easy!!

simply navigate to
http://localhost/jbossws/services

to see which endpoints were detected and deployed. click on the link and there's your WSDL.

using a command like the following, you can create java client side artifacts directly from the deployed services:

wsconsume http://localhost/myapp-myapp_webservice_ejb-HEAD/SomeBeanFSB?wsd
l -k -s \maven\myapp\src\ -p myapp.tests.ws.mytestpkg

[oskar.carlstedt]

Hi!

Thanks for your help. I'm sorry to say, that is not what I actually need or do. I want to have control over my contract (the WSDL-file). That is why I'm using contract first development. I have external parts using my services (contracts). Therefore generated contacts is not a good solution for me. But that is another topic.

So, I have created the WSDL-file, and my own web service provider. I had to do this because I want to use xml beans as data binding framework.

@Stateless
@WebServiceProvider(
 serviceName = "MyService",
 portName = "MyServiceSoap11Port",
 targetNamespace = "http://my.domain.com/my-service",
 wsdlLocation = "WEB-INF/wsdl/my-service.wsdl")
@ServiceMode(value = Service.Mode.PAYLOAD)
public class MyServiceEndpointProvider implements Provider<Source> {
 ...
}

So, what I want to do is to point out wsdlLocation="http://..." instead of wsdlLocation="WEB-INF/...".

Why do I want to do this? Just because I see the contract as a complete separate part of the solution. My service (might be services) implements this contract. I might have several services that implements the same contract, but doing different things in different situations.

So, my question still is: Is it a must to point out the wsdlLocation to a local path within the generated war.

Best
Oskar

[zauberlehrling]

The JSR181 specification (http://jcp.org/en/jsr/detail?id=181) says in 4.1 Annotation: javax.jws.WebService:

wsdlLocation:
The location of a pre-defined WSDL
describing the service. The wsdlLocation is
a URL (relative or absolute) that refers to a
pre-existing WSDL file. The presence of a
wsdlLocation value indicates that the
service implementation bean is implementing
a pre-defined WSDL contract. The JSR-181
tool MUST provide feedback if the service
implementation bean is inconsistent with the
portType and bindings declared in this
WSDL. Note that a single WSDL file might
contain multiple portTypes and multiple
bindings. The annotations on the service
implementation bean determine the specific
portType and bindings that correspond to
the Web Service.

My interpretation is that something like

@Webservice(..
 wsdlLocation="http:\\ .. "
 ..)

should be possible.

[oskar.carlstedt]

Thanks!!!

I will post this issue as a bug.

//Oskar

[heiko.braun]

Taken from the JAX-WS 2.0 specs, section 5.2.5.3:

Use of @WebService(wsdlLocation) and Metadata

There are some restrictions on the packaging of the description and any associated metadata documents.
The goal of these restrictions is to make it possible to publish an endpoint without forcing a JAX-WS
implementation to retrieve, store and patch multiple documents from potentially remote sites.
The value of the wsdlLocation annotation element on an endpoint implementation class, if any, MUST
be a relative URL. <b>The document it points to MUST be packaged with the application.</b> Moreover, it MUST
follow the requirements in section 5.2.5.4 below (?Application-specified Service?).

Therefore i don't consider this to be a bug.