Skip to main content

Web service deploys with no errors but gives 404 error

9 replies [Last post]
steveor
Offline
Joined: 2006-03-02
Points: 0

Hi

I'm having a problem deploying my war file, hoping for some
help. I'm Using java 5, glassfish 41 jax-wsh 2.0 (from 20/3/06)

I generated my servlet from wsdl using wsimport/xjc using
jax-ws 2.0 and jax-b libs (and included them in the war file since the validator tool suggested this - I was previously getting an error about a depreciated missing class)

I then had problems with my deployment descriptors confusing my endpoints - think I fixed that

After some struggling everything uploads without error even
with logging on finest but on launching I just get 404. I tried to turn all the logging on but just get initialising messages.

I've used netbeans 5.5, glassfish gui and autodeploy as methods to deploy the service but I'm stuck now.

I get 404 when I send a soap message from the client I wrote.

Any ideas, I may well be doing something silly since I'm new to this (it's an R&D project)

regards
Steve

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vijaysr
Offline
Joined: 2003-06-11
Points: 0

Hi Steve,

> Helps a bit - I perhaps misunderstood the
> relationship
> between JAX-WS and Glassfish, I assumed that
> Glassfish was
> the appserver RI for JAX-WS and that JAX-WS was a
> replacement for JAX-RPC based interfaces.

JAXWS is indeed JAXRPC2.0 or "JAXRPC made easy" with additional features. GlassFish is an implementation of JavaEE5 and JAXWS is part of JavaEE5. You can use JAXWS APIs directly (just as detailed in Java Web Service Developer PAck samples) but that is not portable across JavaEE5 platforms. For using JAXWS in a portable way across JavaEE5 platforms, you need to make your app 109 compliant. 109 compliant services using JAXWS will be portable. Hope this explanation clears things.

> leave
> these in the java files then do I just build and
> deploy the
> war (includes wsdl, class files, library files)
> without
> having to write deployment descriptors? Do I have to
> copy the annotations to my endpoint?

'dochez' has answered this.

vijaysr
Offline
Joined: 2003-06-11
Points: 0

1. Are you developing a webservice based Java Web Service Developer pack (JWSDP) and trying to deploy it on GlassFish ? If so, ensure that your service works properly on JWSDP - there is a separate JAXWS forum which can help you with that.

2. If you are developing a JavaEE5 based web service that is JSR109 compliant, then the deployment descriptor you are using is wrong.

3. In JavaEE5, the simplest service need not have any descriptors !!!! Checkout my blog http://blogs.sun.com/vijaysr

4. If you have a wsdl and you trying to develop a service and a client out of it, you may want to checkout the unit test we have at glassfish/appserv-tests/devtests/webservice/annotations/wsdltojava

5. You can also find lots of other test scenarios being tested at glassfish/appserv-tests/devtests/webservice/annotations/ and glassfish/appserv-tests/devtests/webservice/ejb_annotations/

If none of these helps, give us more info : what wsdl you are using, how did you package the WAR, is there any exceptions in server.log etc

steveor
Offline
Joined: 2006-03-02
Points: 0

Hi Vijay

Thanks for the response - very interesting

Gave the method you suggested a go - still nothing -I get a blank page but no 404

In no special order -
1 - JAXWS/JAX-B is a means to an end here. I have a large
wsdl of about 200K with all xsd's imported for portability.
The server side receives a soap message with header and body. The body contains an xml document.
The endpoint implementation opens the document and extracts
bits of the message - (its actually an alarm)

2 - not bothered about JR109 this is R&D, just want it to
work and be simple to deploy (the nature of the project is
more to do with tool support than anything else!)

3 - cool - didn't realise I could get rid of them - good

4 - had a look - wasn't really sure what I was looking for

I assume from your blog that any java class with annotation
@webservice once compiled and dropped into the autodeploy dir will become a service endpoint - no need for an implements blah_interface - I can live with that

But I want to build my service around a wsdl so I have generated the data binding classes with wsimport (I didn't notice much difference from using xjc other than 3 service
interfaces and a client side service). I surely need the service and interface files to at least determine the form
of my java 'class file' endpoint implementation?

Do I still need to reference to these interfaces?

Is there a reference to the use of the various web service
annotations (wsimport generated others such as these

@WebService(name = "NotificationConsumerInterface", targetNamespace = "tmf854.v1.ws", wsdlLocation = "C:\\MTOSI-REFERENCE\\MTOSI-REFERENCE\\NotifyService/web/WEB-INF/wsdl/NotificationService.wsdl")
@SOAPBinding(parameterStyle = ParameterStyle.BARE)

regards
Steve

vijaysr
Offline
Joined: 2003-06-11
Points: 0

Comments in line :

> 1 - JAXWS/JAX-B is a means to an end here. I have a
> large
> wsdl of about 200K with all xsd's imported for
> portability.
> The server side receives a soap message with header
> and body. The body contains an xml document.
> The endpoint implementation opens the document and
> extracts
> bits of the message - (its actually an alarm)

You might want to use the dispatch interface. Looks like you are trying to use JAXWS-RI; then https://jax-ws.dev.java.net/ may be of more help.

> 3 - cool - didn't realise I could get rid of them -
> good

My statement that Depl Desc are not needed is true for JSR109 compliant services running on GlassFish.

> 4 - had a look - wasn't really sure what I was
> looking for

You might want to look at the provider test which uses the provider interface - not sure if that is what you want - jaxws forum may provide more help because you are using their RI

> I assume from your blog that any java class with
> annotation
> @webservice once compiled and dropped into the
> autodeploy dir will become a service endpoint - no
> need for an implements blah_interface - I can live
> with that

My blog was a java-wsdl case; here you are starting with Java - in that case you run wsimport on your wsdl and use the generated SEI to implement your endpoint, package it all together etc etc How you package, what you package, how you deploy depends on the platform you are using.

> But I want to build my service around a wsdl so I
> have generated the data binding classes with wsimport
> (I didn't notice much difference from using xjc other
> than 3 service
> interfaces and a client side service). I surely need
> the service and interface files to at least determine
> the form
> of my java 'class file' endpoint implementation?

My previous comment applies here - for wsdl-java cases, you package everything

> Do I still need to reference to these interfaces?

For wsdl-java, yes

I can (try to) be of more help is glassfish is your platform of deployment. For standalone JAXWS-RI which uses the kind of descriptor you listed in your first post, jaxws / jwsdp forums will be of more help

steveor
Offline
Joined: 2006-03-02
Points: 0

Thanks Vijay

Helps a bit - I perhaps misunderstood the relationship
between JAX-WS and Glassfish, I assumed that Glassfish was
the appserver RI for JAX-WS and that JAX-WS was a
replacement for JAX-RPC based interfaces.

I don't actually have a deployment appserver in mind other
than it supports JAX-WS and is not Axis based (no offence but other team members are investigating Axis/XMLbeans
solns). Glassfish with JAX-WS seemed to fit the bill.

The most important reqs are (this is research for our own RI)

1 - Start with wsdl
2 - performance
3 - no JAX-RPC artifacts (I'm looking for something that may eventually support rich MEP's and JMS type topics)

I'll focus on the Dispatch interface documentation - I'm looking for a solution that scales to millions of messages per day using soap (built around a wsdl contract) - do I read correctly that this is probably the best soln?

Your last point about still needing the interfaces was useful.
I started with a wsdl file (ie 200K's worth - I can't use
wscompile since wsdl contains group element and wscompile
chokes).Wsimport does work and generated the annotations
automatically on the interfaces from my wsdl. If I leave
these in the java files then do I just build and deploy the
war (includes wsdl, class files, library files) without
having to write deployment descriptors? Do I have to copy the annotations to my endpoint?

I am using glassfish for my version of our RI - others are writing an Axis version and others are using commercial ESB
platforms. All start from the same wsdl

regards
Steve

dochez
Offline
Joined: 2003-06-10
Points: 0

Steve

You do not necessarily need to have deployment descriptor in your war file. As you said, you can just take the output the wsimport, the wsdl and add your implementation classes and deploy your war file. The web services deployment backend will for instance define few defaults like the endpoint address and such. Look at the devtests, in appserv-tests/devtests/webservices, you will find example of xml less deployments.

You don't need to copy all the annotations from your SEI to your endpoint, you do however at least need
@WebService(endpointInterface=com.foo.bar.MyGeneratedSEI)

Hope this helps.

steveor
Offline
Joined: 2006-03-02
Points: 0

Thanks 'dochez'

Good news is that after reading the advice above I'm getting
closer. No 404 error

My client using the dispatch interface sends a one way message to the configured end point doesn't return any error.

I got rid of the sun*.xml files and only used web.xml
(netbeans build-imp.xml file insists - I assume I still require this)

If I use glassfish admin to slightly change context root the
client receives

HTTP Status-Code 404: Not Found - Not Found
at com.sun.xml.ws.transport.http.client.HttpClientTransport.checkResponseCode(HttpClientTransport.java:285)
...

Changing the context root back fixes the problem so there is obviously something there.

Out of curiosity, I dont see any displayed wsdl at
"http://localhost:8080/mtosi/v1/NotifyService?WSDL";

should I see anything? (nothing in admin gui either)

PS

regarding the simple web services with inline descriptors,
If my application contains several class files then I just
use a war file?

vijaysr
Offline
Joined: 2003-06-11
Points: 0

> Good news is that after reading the advice above I'm
> getting
> closer. No 404 error

:)

> If I use glassfish admin to slightly change context
> root the
> client receives
>
> HTTP Status-Code 404: Not Found - Not Found
> at
> at
> at
> at
> com.sun.xml.ws.transport.http.client.HttpClientTranspo
> rt.checkResponseCode(HttpClientTransport.java:285)
> ...
>
> Changing the context root back fixes the problem so
> there is obviously something there.
>
> Out of curiosity, I dont see any displayed wsdl at
> "http://localhost:8080/mtosi/v1/NotifyService?WSDL";
>
> should I see anything? (nothing in admin gui either)

When you deploy a webservice, we publish the wsdl and the address at which the WSDL is published is embedded in the soap:address element of this published wsdl.

Now if you change the context-root, the WSDL will have to be published again to reflect this change in its URL. This is not happening as of now.

This is indeed an issue and we talking about this internally to see if changing the context root for a web service should allowed or not.

For now, you can take it that you cannot change the context-root of an already deployed webservice.

> regarding the simple web services with inline
> descriptors,
> If my application contains several class files then I
> just
> use a war file?

When you deploy a war file with multiple classes each with @WebService, we will consider each of them as an individual service, create required descriptors and deploy them.

Hope this helps

steveor
Offline
Joined: 2006-03-02
Points: 0

Thanks Vijay

regards
Steve