You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by "Steven E. Harris" <se...@panix.com> on 2007/05/03 04:02:57 UTC

jaxws:endpoint wsdlLocation attribute -- form for class path reference?

Im' trying to define an endpoint via the <jaxws:endpoint> element in a
Spring configuration file, and I can't figure out how to use the
wsdlLocation attribute to point to a file in my WAR.

According to the "JAX-WS Configuration" document¹ on the CXF site, the
wsdlLocation attribute is used as follows:

,----
| The location of the WSDL. Can be on the classpath, file system, or be
| hosted remotely.
`----

My WSDL file is in may WAR's WEB-INF/wsdl directory. I've tried using
the following as values for wsdlLocation:

  /WEB-INF/wsdl/myfile.wsdl
  WEB-INF/wsdl/myfile.wsdl
  /wsdl/myfile.wsdl
  wsdl/myfile.wsdl
  classpath:WEB-INF/wsdl/myfile.wsdl

None of them work. The first four fail as follows:

,----
| Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing '/WEB-INF/wsdl/myfile.wsdl'.: java.io.FileNotFoundException: \WEB-INF\wsdl\myfile.wsdl (The system cannot find the path specified)
| 	at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
| 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
| 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
| 	at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:177)
| 	at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:141)
| 	at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:81)
| 	... 42 more
| Caused by: java.io.FileNotFoundException: \WEB-INF\wsdl\myfile.wsdl (The system cannot find the path specified)
| 	at java.io.FileInputStream.open(Native Method)
| 	at java.io.FileInputStream.<init>(FileInputStream.java:106)
| 	at java.io.FileInputStream.<init>(FileInputStream.java:66)
| 	at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
| 	at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
| 	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653)
| 	at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186)
| 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
| 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
| 	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
| 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:225)
| 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283)
| 	... 48 more
`----

The last one -- the "classpath" scheme -- fails for being an invalid
URL scheme.

I see that WSDLManagerImpl sets up a ResourceManagerWSDLLocator that
looks like a fancy catalog resolver, but I can see that it fails to
find any of my candidate paths in its getBaseInputSource() method.

Do I need to configure something specifically to be able to refer to a
file within my WAR?


Footnotes: 
¹ http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html

-- 
Steven E. Harris

Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

Posted by "Steven E. Harris" <se...@panix.com>.

Daniel Kulp <dk...@apache.org> writes:

> In the second phase in cxf-servlet.xml in your war, it should work 

Indeed it does. It took me studying CXFServlet.loadAdditionalConfig()
to figure out that I should segment my "in-Servlet" beans from some
others in a file located at "WEB-INF/cfx-servlet.xml" by default (or
specified via the Servlet parameter "config-location").

I skipped that several times, missing the difference from
"WEB-INF/cfx/cfx-servlet.xml", which initializes the CXFServlet (or
something).

-- 
Steven E. Harris

Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

Posted by "Steven E. Harris" <se...@panix.com>.

[WARNING: Much rambling follows.]

Daniel Kulp <dk...@apache.org> writes:

> Basically, in the servlet, we need to have some objects that the
> Servlet provides set into the bus that spring creates.  Those
> objects aren't created by any spring xml or anything like that.

A bus is first created by Spring, without these Servlet-related
objects wired in, but when the CXFServlet gets created, it needs to
add things to the bus already created and held by Spring. One of the
things that the CXFServlet adds is a special Resource resolver that
uses the ServletContext to find things. It also creates a child
ApplicationContext to hold objects loaded from the
"post-Servlet-initialization" configuration file. Is that correct?

> There may be some way to pre-initialize the context with those
> objects such that they could be built right into the bus
> immediately.  I really don't know.  If so, that could solve the
> problem and we could just do everything all at once and be done with
> it.

Well, why not ask Servlet users to specify a parameter to Spring's
ContextLoaderListener telling it which kind of ApplicationContext to
create? Right now, it defaults to XmlWebApplicationContext. However,
it will honor a "contextClass" parameter and load the specified class
instead. You could load BusApplicationContext right from the start.

Actually, that's probably not the right idea; the Spring
WebApplicationContext variants already take the hierarchy of a Web
application into account, with a root context and various per-Servlet
child contexts. It just looks to me like there's an extra context for
the CXFServlet: one BusApplicationContext, created by
SpringBusFactory.createBus(), and a GenericApplicationContext if the
Servlet-specific user-provided CXF configuration file is found.

Maybe the documentation has been too liberal with prescribing
Spring-based configuration for the CXFServlet. It looks like there
should be no CXFServlet-dependent configuration in the root
application context, as the Servlet hasn't been loaded yet when those
definitions are processed.

As endpoints depend upon the Servlet -- or maybe they only sometimes
depend upon the Servlet -- the example shown here looks wrong:

  Declaring your server beans
  http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html

The META-INF/cxf/cxf-servlet.xml file doesn't need to be loaded there,
or at least it shouldn't be necessary; it should be loaded by
CXFServlet no matter what, rather than conditionally as it is now in
loadSpringBus():

,----
| if (ctx == null) {
|    bus = new SpringBusFactory().createBus("/META-INF/cxf/cxf-servlet.xml");
| } else {
|    bus = new SpringBusFactory(ctx).createBus();
| }
`----

The jaxws:endpoint definition should be moved into a user-provided
cxf-servlet.xml file, or whatever is designated by the Servlet's
"config-location" parameter.

That would mimic Spring's existing setup: a root context for the whole
Web application, with "namespace"-specific contexts for individual
Servlets, or at least like Spring's DispatcherServlet.

Change BusApplicationContext to accept not just one configuration file
parameter, but an array of them. Then have CXFServlet pass its own
configuration file -- /META-INF/cxf/cxf-servlet.xml -- and the
user-provided file (if it exists) to a new
SpringBusFactory.createBus() overload that also takes an array of
configuration files. That would help get rid of the second-stage
configuration done by loadAdditionalConfig().

Well, maybe there's still too much work done in between when the Bus
is created and when the system is ready to process user-provided
Spring definitions such as jaxws:endpoint. Those ideas won't work.

Digging through the code, I see one point that looks like it should be
addressed: SpringBusFactory.createBus() should not be used as it is by
CXFServlet.

Three cases are possible: Either the user already initialized CXF in
some parent ApplicationContext before CXFServlet got loaded, or the
user has not, and there is no bean called "cxf" in the Servlet's
parent ApplicationContext. There's the third case that there is no
parent ApplicationContext at all, such as when the user has not
employed Spring's ContextLoaderListener.

If there is no existing parent ApplicaitonContext, call on
SpringBusFactory.createBus("/META-INF/cxf/cxf-servlet.xml"), as we do
now. Configure the Servlet-Bus interaction. Later proceed to check for
a user-provided Servlet-specific configuration file and create a child
GenericApplicationContext if such a file is present.

If there is no existing "cxf" bean in an existing parent
ApplicationContext, again, like above, call on
SpringBusFactory.createBus("/META-INF/cxf/cxf-servlet.xml"), as we do
now. Configure the Servlet-Bus interaction. Later proceed to check for
a user-provided Servlet-specific configuration file and create a child
GenericApplicationContext if such a file is present.

However, if there is an existing "cxf" bean,
SpringBusFactory.createBus() should /not/ be used, as it creates a new
BusApplicationContext each time, in this case unnecessarily. It does
avoid reloading the default configuration files, but it still creates
an extra ApplicationContext. Instead, call something like
SpringBusFactory.getBus(), which would just

  return (Bus)context.getBean(DEFAULT_BUS_ID);

Carry on setting up the Servlet-Bus interaction, then check if there's
a user-provided CXFServlet configuration file and create a child
GenericApplicationContext if such a file is present. That eliminates
creating an extra BusApplicationContext just to gain access to an
existing bus instance.

I see that SpringBusFactory just extends BusFactory, so its interface
wouldn't be as flexible as I thought. This has been a lot of rambling,
but the I do now agree that the Servlet-dependent Spring beans need to
be in a separate configuration file from the root ApplicationContext's
configuration files. It looks like the CXFServlet-SpringBusFactory
interaction could be cleaned up some to avoid spurious creation of
extra ApplicationContexts. Finally, the documentation should clarify
which CXF Spring configuration directives depend on CXFServlet and
hence need to live in a separate configuration file.

-- 
Steven E. Harris

Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

Posted by Daniel Kulp <dk...@apache.org>.

On Thursday 03 May 2007 12:45, Steven E. Harris wrote:
> > If you know of a way to clean that up a bit, I'd love to hear it.
>
> First I'll need to understand this phase distinction better.

First point: I am by no means a spring expert.   Quite the opposite.  
I've avoided spring as much as possible.  :-)   

Basically, in the servlet, we need to have some objects that the Servlet 
provides set into the bus that spring creates.   Those objects aren't 
created by any spring xml or anything like that.   There may be some way 
to pre-initialize the context with those objects such that they could be 
built right into the bus immediately.   I really don't know.   If so, 
that could solve the problem and we could just do everything all at once 
and be done with it.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

Posted by "Steven E. Harris" <se...@panix.com>.

Daniel Kulp <dk...@apache.org> writes:

> In a servlet, the contents of WEB-INF aren't available on the
> classpath (except for WEB-INF/classes).

I didn't realize that.

> They are grabbed via the ServletContext.  If you look at the CXF
> servlet code, we create a spring bus using the normal configs, the
> servlet then adds a ResourceResolver for the ServletContext stuff
> and registers the Servlet based HTTP stuff, then we load the
> cxf-servlet.xml configs.

Does this mean that I don't need to explicitly import cxf-servlet.xml
in my Spring application context definition?

> What this means is if you are starting services in the first phase,
> they probably won't work.  The contents of WEB-INF won't be
> available.  The HTTP Destination stuff won't be registered, etc....
>
> In the second phase in cxf-servlet.xml in your war, it should work
> (outside the maven jetty:run command) and I've verified it in tomcat
> 5.5.23.

How can I tell which phase in which I'm starting services? My Spring
application context definition looks almost exactly like the example
here:

  http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html
  "Declaring your server beans"

That is, import three CXF XML files, then define a single endpoint via
<jaxws:endpoint>. Does the put the service in the first phase or
second phase?

> If you know of a way to clean that up a bit, I'd love to hear it. 

First I'll need to understand this phase distinction better.

-- 
Steven E. Harris

Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

Posted by Daniel Kulp <dk...@apache.org>.

Steven,

In a servlet, the contents of WEB-INF aren't available on the classpath 
(except for WEB-INF/classes).   They are grabbed via the ServletContext.    
If you look at the CXF servlet code, we create a spring bus using the 
normal configs, the servlet then adds a ResourceResolver for the 
ServletContext stuff and registers the Servlet based HTTP stuff, then we 
load the cxf-servlet.xml configs.   

What this means is if you are starting services in the first phase, they 
probably won't work.   The contents of WEB-INF won't be available.   The 
HTTP Destination stuff won't be registered, etc....

In the second phase in cxf-servlet.xml in your war, it should work 
(outside the maven jetty:run command) and I've verified it in tomcat 
5.5.23.

If you know of a way to clean that up a bit, I'd love to hear it. 

Dan



On Wednesday 02 May 2007 22:02, Steven E. Harris wrote:
> Im' trying to define an endpoint via the <jaxws:endpoint> element in a
> Spring configuration file, and I can't figure out how to use the
> wsdlLocation attribute to point to a file in my WAR.
>
> According to the "JAX-WS Configuration" document¹ on the CXF site, the
> wsdlLocation attribute is used as follows:
>
> ,----
>
> | The location of the WSDL. Can be on the classpath, file system, or
> | be hosted remotely.
>
> `----
>
> My WSDL file is in may WAR's WEB-INF/wsdl directory. I've tried using
> the following as values for wsdlLocation:
>
>   /WEB-INF/wsdl/myfile.wsdl
>   WEB-INF/wsdl/myfile.wsdl
>   /wsdl/myfile.wsdl
>   wsdl/myfile.wsdl
>   classpath:WEB-INF/wsdl/myfile.wsdl
>
> None of them work. The first four fail as follows:
>
> ,----
>
> | Caused by: javax.wsdl.WSDLException: WSDLException:
> | faultCode=PARSER_ERROR: Problem parsing
> | '/WEB-INF/wsdl/myfile.wsdl'.: java.io.FileNotFoundException:
> | \WEB-INF\wsdl\myfile.wsdl (The system cannot find the path
> | specified) at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown
> | Source) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> | at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at
> | org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl
> |.java:177) at
> | org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.
> |java:141) at
> | org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.j
> |ava:81) ... 42 more
> | Caused by: java.io.FileNotFoundException: \WEB-INF\wsdl\myfile.wsdl
> | (The system cannot find the path specified) at
> | java.io.FileInputStream.open(Native Method)
> | 	at java.io.FileInputStream.<init>(FileInputStream.java:106)
> | 	at java.io.FileInputStream.<init>(FileInputStream.java:66)
> | 	at
> | sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnectio
> |n.java:70) at
> | sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLCo
> |nnection.java:161) at
> | com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurren
> |tEntity(XMLEntityManager.java:653) at
> | com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determine
> |DocVersion(XMLVersionDetector.java:186) at
> | com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(
> |XML11Configuration.java:771) at
> | com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(
> |XML11Configuration.java:737) at
> | com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser
> |.java:107) at
> | com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser
> |.java:225) at
> | com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Do
> |cumentBuilderImpl.java:283) ... 48 more
>
> `----
>
> The last one -- the "classpath" scheme -- fails for being an invalid
> URL scheme.
>
> I see that WSDLManagerImpl sets up a ResourceManagerWSDLLocator that
> looks like a fancy catalog resolver, but I can see that it fails to
> find any of my candidate paths in its getBaseInputSource() method.
>
> Do I need to configure something specifically to be able to refer to a
> file within my WAR?
>
>
> Footnotes:
> ¹ http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

Posted by "Steven E. Harris" <se...@panix.com>.

"Jiang, Ning \(Willem\)" <Ni...@iona.com> writes:

> Can you tell me are you use windows vista?

No, it's Windows XP.

> There could be lots of troubles when you run the progame in the
> "C:\Program Files" directory, because of the Vista's User Account
> Control security feature.

I see: something else to look forward to with Vista. For the moment,
though, that one's not contributing to my grief.

-- 
Steven E. Harris

RE: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

Posted by "Jiang, Ning (Willem)" <Ni...@iona.com>.

Hi Steven,

Can you tell me are you use windows vista?
There could be lots of troubles when you run the progame in the "C:\Program Files" directory, because of the Vista's User Account Control security feature.

I tried the kit on apache-tomcat-5.5.23, I don't know if the issue relate to your apache-tomcat-6.0.10. 

Hopes these infomations will help you.

Cheers,
Willem.


-----Original Message-----
From: Steven E. Harris [mailto:seh@panix.com]
Sent: Thu 5/3/2007 11:31
To: cxf-user@incubator.apache.org
Subject: Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?
 
"Jiang, Ning \(Willem\)" <Ni...@iona.com> writes:

> I just try the latest kit's (build with latest trunk) helloworld
> sample with the wsdlLocation="WEB-INF/wsdl/hello_world.wsdl".
> 
> It is workable. 

That's good to hear.

> Can you check your wsdl in the war or try the CXF helloworld sample?

Actually, I'm deploying via an explode WAR directory, but my WSDL is
in the proper place in the directory. I just tried deploying via an
actual WAR file as well. The files are in the directory and in the
WAR. I tried matching your location specification above:
"WEB-INF/wsdl/myfile.wsdl". No matter what, the search fails,
apparently taking the current working directory as the base for the
search:

Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'WEB-INF/wsdl/myfile.wsdl'.: java.io.FileNotFoundException: C:\Program Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl (The system cannot find the path specified)
	at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
	at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:177)
	at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:141)
	at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:81)
	... 42 more
Caused by: java.io.FileNotFoundException: C:\Program Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl (The system cannot find the path specified)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:106)
	at java.io.FileInputStream.<init>(FileInputStream.java:66)
	at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
	at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653)
	at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:225)
	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283)
	... 48 more


If I start Tomcat from a shell, the same error arises, but the current
working directory matches that of the shell that called startup.sh.

I'll give up for now and try again with tomorrow's snapshots.

-- 
Steven E. Harris

Re: cxf servlet and jaxws:endpoint questions

Posted by Willem Jiang <ni...@iona.com>.

Hi Sergey,

There are some tricks in the CXF servlet transport.
Because we need to support the generate the service address dynamically 
with the different request, all the magical thing happened in the 
ServletController's updateDests method.
In this way,  we can support http://localhost/myapp/services/GreetMe and 
http://MyBox/myapp/services/GreetMe at the same time.

And jaxws:endpoint/@address just a suffix of the address.
If you specify the address with /services/GreetMe , you have to access 
the endpoint with the URL like
http://localhost/myapp/services/services/GreetMe

Willem.

Sergey Beryozkin wrote:
> HI
>
> Just a follow-up question...
> So is the rule of thumb is to use wildcard url patterns, like "/services/*" and then use jaxws:endpoint/@address
> values like "/GreetMe" ? 
>
> I'm wondering why specifying a pattern like "/services/GreetMe" doesn work...Casually glancing through a servler code didn't give me an answer so I'll probably have to look harder :-).
>
> Cheers, Sergey
>
>
> ----- Original Message ----- 
> From: "Sergey Beryozkin" <se...@iona.com>
> To: <cx...@incubator.apache.org>
> Sent: Wednesday, September 12, 2007 1:22 PM
> Subject: Re: cxf servlet and jaxws:endpoint questions
>
>
> Hi Chris
>
> It does work, super !
> Thanks for a quick reply,
> Sergey
>
> ----- Original Message ----- 
> From: "Christopher Moesel" <Ch...@avid.com>
> To: <cx...@incubator.apache.org>
> Sent: Wednesday, September 12, 2007 1:14 PM
> Subject: RE: cxf servlet and jaxws:endpoint questions
>
>
> Hi Sergey,
>
> The following combination *should* work...
>
> In web.xml, the url-pattern for the servlet-mapping:
> /hello/*
>
> In the jaxws:endpoint/@address:
> /world
>
> I believe that the difference between implementor and implementorClass
> is this:
>
> implementor: a reference to an *instance* of your SEI implementation (in
> Spring, you use this style: #myServiceEndpointImp)
>
> implementorClass: the fully qualified classname of your SEI
> implementation, which must have a default constructor (for example,
> com.mycompany.MyServiceEndpointImpl)
>
> I hope that helps!
>
> -Chris
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
> Sent: Wednesday, September 12, 2007 7:55 AM
> To: cxf-user@incubator.apache.org
> Subject: cxf servlet and jaxws:endpoint questions
>
> Hi
>
> I have few questions with respect to deploying a cxf servlet into tomcat
> :
>
> * how to use/combine correctly a servlet's url pattern and an
> jaxws:endpoint/@address values ?
>
> For example, suppose I have a webapp "test" and I want my servlet to
> recognize this pattern : /hello/world
>
> As such, I'd like 
> GET http://localhost:8080/test/hello/world?wsdl 
>
> to return me a wsdl.
>
> In web.xml I've tried
> /hello/*
> /hello/world
>
> and in jaxws:endpoint/@address I tried
> /hello/world
> /world
>
> with no luck, the above request returns no service is available
>
> * what is the difference between jaxws:endpoint/@implementer and
> jaxws:endpoint/@implementerClass attributes ?
>
> Thanks, Sergey
>
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
>