You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Glen Mazza <gl...@verizon.net> on 2008/05/13 12:42:05 UTC
Writing Maven/JUnit test cases for web service calls
Hello,
I'd like to add JUnit test cases to the Maven version of my "DoubleIt"
web service provider[1]. The types of things I'd like to test are (1)
that an integer fed is actually doubled in the response, (2) not
well-formed SOAP requests are rejected, and (3) non-schema valid SOAP
requests are rejected.
I can think of two main ways of doing this:
1.) Write test cases the standard Maven way, i.e., create a test folder
that it is sibling of the service/src/main folder and write the test
cases there. That would require having an embedded Tomcat or Jetty
instance that reads the either the WAR file in target (or, equivalently,
the exploded war also in target), and makes a servlet out of that so the
test cases can work. I'm not sure if embedded Tomcat/Jetty can handle
this though--most/all of our CXF test cases don't work with WAR-file
hosted web service providers.
or
2.) Create a separate "systests" project that doesn't test anything
until the WAR is (manually) deployed on a non-embedded servlet
container--*then* run the tests. CXF also has this type of test--but
I'm unsure how appropriate it would be for the types of tests I'm
thinking of here.
Any suggestions which is best? What have others done for web service
provider testing?
Thanks,
Glen
[1] http://www.jroller.com/gmazza/date/20080417
XmlAnyElement not unmarshalled to JAXBElement in 2.0.6
Posted by Hartmut Lang <ha...@ericsson.com>.
I have this JAXBObject
....
@XmlAnyElement(lax = true)
protected List<Object> any;
In cxf 2.0.4 the Object is of type "javax.xml.bind.JAXBElement".
In cxf 2.0.6 the Object is of type
"com.sun.org.apache.xerces.internal.dom.ElementNSImpl".
Why is there a different behaviour after the Object is unmarshalled?
How do I get the 2.0.4 behaviour in 2.0.6?
Any help welcome!
Hartmut Lang
Re: Writing Maven/JUnit test cases for web service calls
Posted by Bernd Schuller <b....@fz-juelich.de>.
Hi,
would it not be "best practice" to use standard unit tests
completely independent of CXF for testing (1) the business logic
(i.e. verifying that indeed 2*2=4).
In the other cases (2) and (3) you're testing the SOAP engine, which
should not really be your concern as application developer.
Nonetheless, the war-file approach seems best for this, as it mimics the
final deployment and can be considered a proper integration test.
Best regards,
Bernd.
Glen Mazza wrote:
>
> I'd like to add JUnit test cases to the Maven version of my "DoubleIt"
> web service provider[1]. The types of things I'd like to test are (1)
> that an integer fed is actually doubled in the response, (2) not
> well-formed SOAP requests are rejected, and (3) non-schema valid SOAP
> requests are rejected.
>
> I can think of two main ways of doing this:
>
> 1.) Write test cases the standard Maven way, i.e., create a test folder
> that it is sibling of the service/src/main folder and write the test
> cases there. That would require having an embedded Tomcat or Jetty
> instance that reads the either the WAR file in target (or, equivalently,
> the exploded war also in target), and makes a servlet out of that so the
> test cases can work. I'm not sure if embedded Tomcat/Jetty can handle
> this though--most/all of our CXF test cases don't work with WAR-file
> hosted web service providers.
>
> or
>
> 2.) Create a separate "systests" project that doesn't test anything
> until the WAR is (manually) deployed on a non-embedded servlet
> container--*then* run the tests. CXF also has this type of test--but
> I'm unsure how appropriate it would be for the types of tests I'm
> thinking of here.
>
> Any suggestions which is best? What have others done for web service
> provider testing?
>
> Thanks,
> Glen
>
> [1] http://www.jroller.com/gmazza/date/20080417
--
Dr. Bernd Schuller | mail: b.schuller@fz-juelich.de
| phone: +49 2461 61-8736 (fax: -6656)
Distributed Systems and Grid Computing | personal blog:
Juelich Supercomputing Centre | http://www.jroller.com/page/gridhaus
http://www.fz-juelich.de/jsc |
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
Re: Writing Maven/JUnit test cases for web service calls
Posted by nicolas de loof <ni...@apache.org>.
https://issues.apache.org/jira/browse/CXF-1586
2008/5/14 Daniel Kulp <dk...@apache.org>:
>
> On May 14, 2008, at 10:50 AM, nicolas de loof wrote:
>
> That works fine, but this only moves the requirement to set the WSDL
>> location from the Spring context to the maven pom.xml
>>
>> Is there any option to avoid any wsdlLocation in the annotation ?
>>
>
> Hmm... I THOUGHT that -wsdlLocation "" would have done it, but apparently
> not. :-(
>
> Could you log a bug/feature request?
>
> Dan
>
>
>
>>
>> 2008/5/14 Daniel Kulp <dk...@apache.org>:
>>
>>
>>> On May 14, 2008, at 10:40 AM, nicolas de loof wrote:
>>>
>>> I came into an issue with the [2] cxf configuration (wihtout a
>>>> wsdlLocation)
>>>> : as my service Implementation is generated using wsdl2java (maven
>>>> plugin)
>>>> from some ${basedir} WSDL path, I get a generated @WebService
>>>> wsdlLocation
>>>> to point to my local file (D:/...). Then the application startup fails
>>>> on
>>>> my
>>>> unix server. I had to force the wsdlLocation in <jaxws:endpoint> to my
>>>> WEB-INF/wsdl.
>>>>
>>>>
>>> FYI: there is a -wsdlLocation flag to wsdl2java that can be used to
>>> force
>>> a different location to be generated into the code. Thus, you could
>>> have
>>> wsdl2java generate "WEB-INF/wsdl/foo.wsdl" into the annotation.
>>>
>>>
>>>
>>> ---
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
Re: Writing Maven/JUnit test cases for web service calls
Posted by Daniel Kulp <dk...@apache.org>.
On May 14, 2008, at 10:50 AM, nicolas de loof wrote:
> That works fine, but this only moves the requirement to set the WSDL
> location from the Spring context to the maven pom.xml
>
> Is there any option to avoid any wsdlLocation in the annotation ?
Hmm... I THOUGHT that -wsdlLocation "" would have done it, but
apparently not. :-(
Could you log a bug/feature request?
Dan
>
>
> 2008/5/14 Daniel Kulp <dk...@apache.org>:
>
>>
>> On May 14, 2008, at 10:40 AM, nicolas de loof wrote:
>>
>>> I came into an issue with the [2] cxf configuration (wihtout a
>>> wsdlLocation)
>>> : as my service Implementation is generated using wsdl2java (maven
>>> plugin)
>>> from some ${basedir} WSDL path, I get a generated @WebService
>>> wsdlLocation
>>> to point to my local file (D:/...). Then the application startup
>>> fails on
>>> my
>>> unix server. I had to force the wsdlLocation in <jaxws:endpoint>
>>> to my
>>> WEB-INF/wsdl.
>>>
>>
>> FYI: there is a -wsdlLocation flag to wsdl2java that can be used
>> to force
>> a different location to be generated into the code. Thus, you
>> could have
>> wsdl2java generate "WEB-INF/wsdl/foo.wsdl" into the annotation.
>>
>>
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Writing Maven/JUnit test cases for web service calls
Posted by nicolas de loof <ni...@apache.org>.
That works fine, but this only moves the requirement to set the WSDL
location from the Spring context to the maven pom.xml
Is there any option to avoid any wsdlLocation in the annotation ?
2008/5/14 Daniel Kulp <dk...@apache.org>:
>
> On May 14, 2008, at 10:40 AM, nicolas de loof wrote:
>
>> I came into an issue with the [2] cxf configuration (wihtout a
>> wsdlLocation)
>> : as my service Implementation is generated using wsdl2java (maven plugin)
>> from some ${basedir} WSDL path, I get a generated @WebService wsdlLocation
>> to point to my local file (D:/...). Then the application startup fails on
>> my
>> unix server. I had to force the wsdlLocation in <jaxws:endpoint> to my
>> WEB-INF/wsdl.
>>
>
> FYI: there is a -wsdlLocation flag to wsdl2java that can be used to force
> a different location to be generated into the code. Thus, you could have
> wsdl2java generate "WEB-INF/wsdl/foo.wsdl" into the annotation.
>
>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
Re: Writing Maven/JUnit test cases for web service calls
Posted by Daniel Kulp <dk...@apache.org>.
On May 14, 2008, at 10:40 AM, nicolas de loof wrote:
> I came into an issue with the [2] cxf configuration (wihtout a
> wsdlLocation)
> : as my service Implementation is generated using wsdl2java (maven
> plugin)
> from some ${basedir} WSDL path, I get a generated @WebService
> wsdlLocation
> to point to my local file (D:/...). Then the application startup
> fails on my
> unix server. I had to force the wsdlLocation in <jaxws:endpoint> to my
> WEB-INF/wsdl.
FYI: there is a -wsdlLocation flag to wsdl2java that can be used to
force a different location to be generated into the code. Thus, you
could have wsdl2java generate "WEB-INF/wsdl/foo.wsdl" into the
annotation.
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Writing Maven/JUnit test cases for web service calls
Posted by nicolas de loof <ni...@apache.org>.
>
>
>>
>> [1] http://www.jroller.com/gmazza/date/20080417#WFstep6
>> [2] http://www.jroller.com/gmazza/date/20080417#WFstep8
>>
>
> For the CXF stuff in [2], you only have the address and implementor
> defined. Everything else is taken from the annotations. What's
> interesting is that with that configuration, you are letting CXF generate a
> new wsdl as there isn't a wsdlLocation specified anywhere for CXF. Not a
> big deal, but I'm not sure if that's what you intended since your metro
> configuration is specifying a wsdl.
>
>
I came into an issue with the [2] cxf configuration (wihtout a wsdlLocation)
: as my service Implementation is generated using wsdl2java (maven plugin)
from some ${basedir} WSDL path, I get a generated @WebService wsdlLocation
to point to my local file (D:/...). Then the application startup fails on my
unix server. I had to force the wsdlLocation in <jaxws:endpoint> to my
WEB-INF/wsdl.
Re: Writing Maven/JUnit test cases for web service calls
Posted by Mick Knutson <mi...@gmail.com>.
Here is what I do:
In my (Spring) ApplicationContext-test.xml
<!-- Factory to create the dynamic proxy -->
<bean id="userClientFactory"
class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean">
<property name="serviceClass"
value="com.baselogic.service.UserManager"/>
<property name="address"
value="http://localhost:8080/webapp-2.2/cxf/UserService"/>
<property name="serviceFactory" ref="jaxwsAndAegisServiceFactory"/>
</bean>
<!-- Add Test Webservice Clients
=======================================-->
<!-- Web service dynamic proxy -->
<bean id="userClient"
class="com.baselogic.service.impl.UserManagerImpl"
factory-bean="userClientFactory"
factory-method="create"/>
Then in my unit testNg test:
@Test(groups = {"functional" })
public void testGetUser() throws Exception {
UserManager userManager = (UserManager) applicationContext.getBean(
"userClient");
User user = userManager.find("-1");
Assert.assertNotNull(user.getUsername());
Assert.assertEquals("mickknutson", user.getUsername());
Assert.assertEquals("Mick", user.getFirstName());
Assert.assertEquals("Knutson", user.getLastName());
}
On Wed, May 14, 2008 at 7:27 AM, Daniel Kulp <dk...@apache.org> wrote:
>
> Glen,
>
> On May 14, 2008, at 12:26 AM, Glen Mazza wrote:
>
> 2008-05-13 Daniel Kulp wrote:
>>
>>> That said, with JAX-WS, in your "setup" method you can just call:
>>> Endpoint ep = Endpoint.publish("http://localhost:8080/blah", myImpl);
>>>
>>
>> Interesting...I did not know that was part of JAX-WS. I always assumed
>> that was either CXF-specific or part of the simple front end.
>>
>
> Nope. Part of the JAX-WS spec actually.
>
> In order for this to work, though, I think myImpl (the SIB) may need to
>> have more annotation values than if the SIB were wrapped within the WAR,
>> correct? From what I can tell, the SIB's configuration is the sum of
>> its @WebService annotation values[1] plus its jaxws:endpoint
>> configuration in the cxf-servlet.xml[2], therefore to do
>> Endpoint.publish(), anything otherwise in [2] would need to move to [1].
>>
>> [1] http://www.jroller.com/gmazza/date/20080417#WFstep6
>> [2] http://www.jroller.com/gmazza/date/20080417#WFstep8
>>
>
> For the CXF stuff in [2], you only have the address and implementor
> defined. Everything else is taken from the annotations. What's
> interesting is that with that configuration, you are letting CXF generate a
> new wsdl as there isn't a wsdlLocation specified anywhere for CXF. Not a
> big deal, but I'm not sure if that's what you intended since your metro
> configuration is specifying a wsdl.
>
> For the most part, if your @WebService annotation has the portName,
> serviceName, and endpointInterface stuff (actually, just the
> endpointInterface really as the rest can be defaulted), it should work.
> The trick is if you want it to use a wsdl or generate one. If you want it
> to use a wsdl, you need the wsdlLocation specified. Unfortunately, since
> that is burned into the code with an annotation, it's hard to deal with if
> the location is different for your unit test compared to when packaged in a
> war. However, you can also do it via: (this works with CXF, not sure
> about Metro)
>
> Endpoint ep = Endpoint.create(impl);
> ep.getProperties().put(
> "javax.xml.ws.wsdl.description",
> wsdlLocation);
> ep.publish("http://localhost:8080/blah");
>
>
> You might be able to do:
> Source source = new StreamSource(wsdlLocation);
> ep.setMetaData(source);
>
> or something to set the wsdl.
>
>
>
> (BTW, is there a more precise terminology you use for WAR-file based web
>> service providers vs. Endpoint.publish()'ed web service providers?)
>>
>
> I generally refer to the Endpoint.publish(...) stuff as "standalone"
> servers/services as they don't require a hosting container. A simple
> standalone main method is fine.
>
> and CXF (or Metro) will automatically setup an embedded http server
>>> (jetty for CXF, metro uses the http stuff that is now part of Java6)
>>>
>>
>> BTW #2, how is CXF supposed to interact with Java6 now that Metro is in
>> it by default--is CXF intended to be swapped in, similar to changing the
>> XML parser, i.e., just by placing its libs in jre/endorsed, or will the
>> CXF libs still be separate? I'm not sure how this will work.
>>
>
> Actually, it should just work (outside of an OSGi container running on
> Java6) without endorsing anything. When you call the JAX-WS API's, it looks
> in the context classloader for a META-INF/services/javax.xml.ws.spi.Provider
> file that contains the classname of the provider to use. The default impl
> in the JDK does not have that file. CXF does. Thus, if CXF is on the
> classpath, CXF will be used. Nothing special needs to be done. (caveat: CXF
> 2.1 needs JDK6 update 4 or later. CXF 2.0.x will not work on update 4 or
> later. This is due to the jaxws-api version being upgraded to 2.1 in update
> 4). That all said, this does create some support issues. With JDK5, if
> cxf is not on the classpath, nothing works. You get class not found things.
> On JDK6, your application might actually work, but it will use metro
> instead of CXF. Thus, CXF specific things (like spring configuration)
> wouldn't be picked up and you end up with wacky support requests. I've
> seen stack traces that are obviously metro stack traces, not CXF.
> Something to keep an eye out for.
>
>
> OSGi is more complex as finding the
> META-INF/services/javax.xml.ws.spi.Provider file cannot be done in OSGi.
> Guillaume Nodet is working on solutions for that. It actually affects
> other things like JAX-RS, SAAJ, even woodstox, as they also all use the
> META-INF/services directory to find the implementation.
>
>
> Dan
>
>
>
>>
>> Thanks,
>> Glen
>>
>>
>>
>>> that you can then hit. You don't need a war or anything. That may
>>> have some issues with the wsdlLocation annotation on the classes
>>> though. (don't forget to call stop in the tearDown)
>>>
>>> I would just use one of the above. It's pretty simple.
>>>
>>> The CXF systest stuff goes one further by forking the server into a
>>> separate process instead of running it in-process with the test
>>> client.
>>> In general, that's probably overkill for simple unit style
>>> testing. However, it does make sure there is a completely clean
>>> separation between client/server and the only communication is through
>>> the soap messages. No "statics" or anything that can pollute the
>>> results.
>>>
>>> Dan
>>>
>>>
>>>
>>> 2.) Create a separate "systests" project that doesn't test anything
>>>> until the WAR is (manually) deployed on a non-embedded servlet
>>>> container--*then* run the tests. CXF also has this type of test--but
>>>> I'm unsure how appropriate it would be for the types of tests I'm
>>>> thinking of here.
>>>>
>>>> Any suggestions which is best? What have others done for web service
>>>> provider testing?
>>>>
>>>> Thanks,
>>>> Glen
>>>>
>>>> [1] http://www.jroller.com/gmazza/date/20080417
>>>>
>>>>
>>>>
>>> ---
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
--
---
Thank You…
Mick Knutson
BASE Logic, inc.
Website: http://www.baselogic.com
Blog: http://www.baselogic.com/blog
BLiNC Magazine: http://www.blincmagazine.com
Linked IN: http://www.linkedin.com/in/mickknutson
DJ Mick: http://www.djmick.com
MySpace: http://www.myspace.com/mickknutson
Tahoe: http://tahoe.baselogic.com
Re: (Moved from users) Re: Writing Maven/JUnit test cases for web
service calls
Posted by Glen Mazza <gl...@verizon.net>.
2008-05-14 Daniel Kulp wrote:
>
> Actually, to follow up, if you check section 7.2.2 about the developer
> responsibilities, it states:
>
> The wsdl-file element specifies a location of the WSDL description of
> the
> service. The location is relative to the root of the module.
>
> Thus, I think the "wsdl" dir is more of convention, but you would
> still need to specify it as part of the wsdlLocation.
Yes, I see now. Thanks.
Glen
> What's
> interesting is their examples don't even do that. They just use
> "WEB-INF/joe.wsdl" or similar. (see 8.3)
>
> Dan
>
Re: (Moved from users) Re: Writing Maven/JUnit test cases for web service calls
Posted by Daniel Kulp <dk...@apache.org>.
Actually, to follow up, if you check section 7.2.2 about the developer
responsibilities, it states:
The wsdl-file element specifies a location of the WSDL description of
the
service. The location is relative to the root of the module.
Thus, I think the "wsdl" dir is more of convention, but you would
still need to specify it as part of the wsdlLocation. What's
interesting is their examples don't even do that. They just use
"WEB-INF/joe.wsdl" or similar. (see 8.3)
Dan
On May 14, 2008, at 12:14 PM, Daniel Kulp wrote:
>
> On May 14, 2008, at 11:53 AM, Glen Mazza wrote:
>
>> 2008-05-14 Daniel Kulp wrote:
>>>
>>> Well, no. For example, how would we know the filename of the wsdl
>>> to even grab from that directory?
>>>
>>
>> Sorry to grill you here--I'm just trying to get this as correct as it
>> can get. Just to clarify, then, while it may not pick up files
>> from the
>> WEB-INF/wsdl folder by default as I was thinking, that folder should
>> still be the default location to look for WSDLs that are specified
>> using
>> wsdlLocation (i.e., if no directory structure is provided), correct?
>>
>>> From the JSR-109 Spec[1], Version 1.2 (April 28, 2006):
>
> Just FYI: with CXF being a standalone JAX-WS provider, JSR-109
> stuff is not required to be supported. For example, we don't
> support injecting any @WebServiceRef things in at all at this point
> either. That's a J2EE thing. I don't think any of us really
> have delved into JSR109 as it pertains to CXF only. I know the
> Geronimo folks obviously have, but it's part of the web service
> deployer stuff, not something ingrained into CXF.
>
> Thus, in short, I DOUBT the current stuff in CXF will look in WEB-
> INF/wsdl if you just specify a wsdlLocation of "foo.wsdl". The JAX-
> WS spec for standalone doesn't require it. I could be wrong
> though. With all the work Jarek and Jeff did for Geronimo, some of
> it might have been pushed into CXF.
>
> Dan
>
>
>
> There are a couple things in JSR-109 that don't match
>
>> Section 5.4: WSDL files are located relative to the root of the
>> module
>> and are typically located in the wsdl directory that is co-located
>> with
>> the module deployment descriptor or a subdirectory of it.
>>
>> Section 5.4.1: The wsdl directory is a well-known location that
>> contains
>> WSDL files and any relative content the WSDL files may reference.
>> WSDL
>> files and their relative references will be published during
>> deployment.
>> See sections 8.2.4 and 8.2.5 for more details.
>>
>> Section 8.2.4: "A Web Services for Java EE provider is
>> required to provide a URL that maintains the referential integrity of
>> the WSDL document the service-ref (or a javax.xml.ws.WebServiceRef
>> annotated Web service reference) is bound to if the wsdl-file
>> (wsdlLocation in WebServiceRef) element refers to a document
>> located in
>> the wsdl directory or one of its subdirectories."
>>
>> Section 8.2.5: "A Web Services for Java EE provider is required to
>> support publishing a deployed WSDL document if the
>> wsdlLocation element in the Web service annotations (described in
>> section 5.3.2.1 and 5.3.2.2) or Web services deployment descriptor
>> (webservices.xml) wsdl-file element refers to a WSDL file contained
>> in
>> the wsdl directory or subdirectory, as described in section 5.4.1. A
>> vendor may support publication of WSDL files packaged in other
>> locations, but these are considered non-portable."
>>
>> What I'm trying to say is that, in terms of WSDL resolution, there is
>> indeed a difference between the WEB-INF/wsdl folder and the
>> WEB-INF/banana folder, and CXF captures that difference? I may
>> need to
>> research this more.
>>
>> Thanks,
>> Glen
>>
>> [1] http://jcp.org/aboutJava/communityprocess/mrel/jsr109/index.html
>>
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: (Moved from users) Re: Writing Maven/JUnit test cases for web service calls
Posted by Daniel Kulp <dk...@apache.org>.
On May 14, 2008, at 11:53 AM, Glen Mazza wrote:
> 2008-05-14 Daniel Kulp wrote:
>>
>> Well, no. For example, how would we know the filename of the wsdl
>> to even grab from that directory?
>>
>
> Sorry to grill you here--I'm just trying to get this as correct as it
> can get. Just to clarify, then, while it may not pick up files from
> the
> WEB-INF/wsdl folder by default as I was thinking, that folder should
> still be the default location to look for WSDLs that are specified
> using
> wsdlLocation (i.e., if no directory structure is provided), correct?
>
>> From the JSR-109 Spec[1], Version 1.2 (April 28, 2006):
Just FYI: with CXF being a standalone JAX-WS provider, JSR-109 stuff
is not required to be supported. For example, we don't support
injecting any @WebServiceRef things in at all at this point either.
That's a J2EE thing. I don't think any of us really have delved
into JSR109 as it pertains to CXF only. I know the Geronimo folks
obviously have, but it's part of the web service deployer stuff, not
something ingrained into CXF.
Thus, in short, I DOUBT the current stuff in CXF will look in WEB-INF/
wsdl if you just specify a wsdlLocation of "foo.wsdl". The JAX-WS
spec for standalone doesn't require it. I could be wrong though.
With all the work Jarek and Jeff did for Geronimo, some of it might
have been pushed into CXF.
Dan
There are a couple things in JSR-109 that don't match
> Section 5.4: WSDL files are located relative to the root of the module
> and are typically located in the wsdl directory that is co-located
> with
> the module deployment descriptor or a subdirectory of it.
>
> Section 5.4.1: The wsdl directory is a well-known location that
> contains
> WSDL files and any relative content the WSDL files may reference. WSDL
> files and their relative references will be published during
> deployment.
> See sections 8.2.4 and 8.2.5 for more details.
>
> Section 8.2.4: "A Web Services for Java EE provider is
> required to provide a URL that maintains the referential integrity of
> the WSDL document the service-ref (or a javax.xml.ws.WebServiceRef
> annotated Web service reference) is bound to if the wsdl-file
> (wsdlLocation in WebServiceRef) element refers to a document located
> in
> the wsdl directory or one of its subdirectories."
>
> Section 8.2.5: "A Web Services for Java EE provider is required to
> support publishing a deployed WSDL document if the
> wsdlLocation element in the Web service annotations (described in
> section 5.3.2.1 and 5.3.2.2) or Web services deployment descriptor
> (webservices.xml) wsdl-file element refers to a WSDL file contained in
> the wsdl directory or subdirectory, as described in section 5.4.1. A
> vendor may support publication of WSDL files packaged in other
> locations, but these are considered non-portable."
>
> What I'm trying to say is that, in terms of WSDL resolution, there is
> indeed a difference between the WEB-INF/wsdl folder and the
> WEB-INF/banana folder, and CXF captures that difference? I may need
> to
> research this more.
>
> Thanks,
> Glen
>
> [1] http://jcp.org/aboutJava/communityprocess/mrel/jsr109/index.html
>
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
(Moved from users) Re: Writing Maven/JUnit test cases for web service
calls
Posted by Glen Mazza <gl...@verizon.net>.
2008-05-14 Daniel Kulp wrote:
> On May 14, 2008, at 10:57 AM, Glen Mazza wrote:
>
> > 2008-05-14 Daniel Kulp wrote:
> >>> In order for this to work, though, I think myImpl (the SIB) may
> >> need
> >>> to
> >>> have more annotation values than if the SIB were wrapped within the
> >>> WAR,
> >>> correct? From what I can tell, the SIB's configuration is the sum
> >>> of
> >>> its @WebService annotation values[1] plus its jaxws:endpoint
> >>> configuration in the cxf-servlet.xml[2], therefore to do
> >>> Endpoint.publish(), anything otherwise in [2] would need to move to
> >>> [1].
> >>>
> >>> [1] http://www.jroller.com/gmazza/date/20080417#WFstep6
> >>> [2] http://www.jroller.com/gmazza/date/20080417#WFstep8
> >>
> >> For the CXF stuff in [2], you only have the address and implementor
> >> defined. Everything else is taken from the annotations. What's
> >> interesting is that with that configuration, you are letting CXF
> >> generate a new wsdl as there isn't a wsdlLocation specified anywhere
> >> for CXF. Not a big deal, but I'm not sure if that's what you
> >> intended since your metro configuration is specifying a wsdl.
> >>
> >
> > Are you sure? I placed the WSDL file in the WEB-INF/wsdl
> > folder--doesn't JSR-109 or the JAX-WS spec someplace indicate that if
> > you place the WSDL file there, the JAX-WS implementation (here,
> > CXFServlet) will look in that place by default? (isn't there
> > something
> > magical about that location, i.e., the wsdlLocation by default *is*
> > WEB-INF/wsdl, no?)
>
> Well, no. For example, how would we know the filename of the wsdl
> to even grab from that directory?
>
Sorry to grill you here--I'm just trying to get this as correct as it
can get. Just to clarify, then, while it may not pick up files from the
WEB-INF/wsdl folder by default as I was thinking, that folder should
still be the default location to look for WSDLs that are specified using
wsdlLocation (i.e., if no directory structure is provided), correct?
>>From the JSR-109 Spec[1], Version 1.2 (April 28, 2006):
Section 5.4: WSDL files are located relative to the root of the module
and are typically located in the wsdl directory that is co-located with
the module deployment descriptor or a subdirectory of it.
Section 5.4.1: The wsdl directory is a well-known location that contains
WSDL files and any relative content the WSDL files may reference. WSDL
files and their relative references will be published during deployment.
See sections 8.2.4 and 8.2.5 for more details.
Section 8.2.4: "A Web Services for Java EE provider is
required to provide a URL that maintains the referential integrity of
the WSDL document the service-ref (or a javax.xml.ws.WebServiceRef
annotated Web service reference) is bound to if the wsdl-file
(wsdlLocation in WebServiceRef) element refers to a document located in
the wsdl directory or one of its subdirectories."
Section 8.2.5: "A Web Services for Java EE provider is required to
support publishing a deployed WSDL document if the
wsdlLocation element in the Web service annotations (described in
section 5.3.2.1 and 5.3.2.2) or Web services deployment descriptor
(webservices.xml) wsdl-file element refers to a WSDL file contained in
the wsdl directory or subdirectory, as described in section 5.4.1. A
vendor may support publication of WSDL files packaged in other
locations, but these are considered non-portable."
What I'm trying to say is that, in terms of WSDL resolution, there is
indeed a difference between the WEB-INF/wsdl folder and the
WEB-INF/banana folder, and CXF captures that difference? I may need to
research this more.
Thanks,
Glen
[1] http://jcp.org/aboutJava/communityprocess/mrel/jsr109/index.html
Re: Writing Maven/JUnit test cases for web service calls
Posted by Daniel Kulp <dk...@apache.org>.
On May 14, 2008, at 10:57 AM, Glen Mazza wrote:
> 2008-05-14 Daniel Kulp wrote:
>>> In order for this to work, though, I think myImpl (the SIB) may
>> need
>>> to
>>> have more annotation values than if the SIB were wrapped within the
>>> WAR,
>>> correct? From what I can tell, the SIB's configuration is the sum
>>> of
>>> its @WebService annotation values[1] plus its jaxws:endpoint
>>> configuration in the cxf-servlet.xml[2], therefore to do
>>> Endpoint.publish(), anything otherwise in [2] would need to move to
>>> [1].
>>>
>>> [1] http://www.jroller.com/gmazza/date/20080417#WFstep6
>>> [2] http://www.jroller.com/gmazza/date/20080417#WFstep8
>>
>> For the CXF stuff in [2], you only have the address and implementor
>> defined. Everything else is taken from the annotations. What's
>> interesting is that with that configuration, you are letting CXF
>> generate a new wsdl as there isn't a wsdlLocation specified anywhere
>> for CXF. Not a big deal, but I'm not sure if that's what you
>> intended since your metro configuration is specifying a wsdl.
>>
>
> Are you sure? I placed the WSDL file in the WEB-INF/wsdl
> folder--doesn't JSR-109 or the JAX-WS spec someplace indicate that if
> you place the WSDL file there, the JAX-WS implementation (here,
> CXFServlet) will look in that place by default? (isn't there
> something
> magical about that location, i.e., the wsdlLocation by default *is*
> WEB-INF/wsdl, no?)
Well, no. For example, how would we know the filename of the wsdl
to even grab from that directory?
The tell-tale sign would be to startup tomcat and look in the
catalina.out (assuming default logging levels) and see if it says if
it's building from class or wsdl.
> Also, in terms of having "CXF generate a new WSDL", that always
> happens
> anyway, correct, if only for the soap:address URL to be updated
> appropriately with the web service's location?
Well, kind of. There is a difference between building a whole new
wsdl or updating an existing wsdl. When building from class, we need
to create all new schemas, new portTypes, etc.... When updating, we
need to parse the exising wsdl, update all the locations, and then
write it out. Ideally, this allows the imports to remain as imports,
the ordering to remain, comments, whitespace, etc...
Dan
>
>
> Thanks,
> Glen
>
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Writing Maven/JUnit test cases for web service calls
Posted by Glen Mazza <gl...@verizon.net>.
2008-05-14 Daniel Kulp wrote:
> > In order for this to work, though, I think myImpl (the SIB) may
> need
> > to
> > have more annotation values than if the SIB were wrapped within the
> > WAR,
> > correct? From what I can tell, the SIB's configuration is the sum of
> > its @WebService annotation values[1] plus its jaxws:endpoint
> > configuration in the cxf-servlet.xml[2], therefore to do
> > Endpoint.publish(), anything otherwise in [2] would need to move to
> > [1].
> >
> > [1] http://www.jroller.com/gmazza/date/20080417#WFstep6
> > [2] http://www.jroller.com/gmazza/date/20080417#WFstep8
>
> For the CXF stuff in [2], you only have the address and implementor
> defined. Everything else is taken from the annotations. What's
> interesting is that with that configuration, you are letting CXF
> generate a new wsdl as there isn't a wsdlLocation specified anywhere
> for CXF. Not a big deal, but I'm not sure if that's what you
> intended since your metro configuration is specifying a wsdl.
>
Are you sure? I placed the WSDL file in the WEB-INF/wsdl
folder--doesn't JSR-109 or the JAX-WS spec someplace indicate that if
you place the WSDL file there, the JAX-WS implementation (here,
CXFServlet) will look in that place by default? (isn't there something
magical about that location, i.e., the wsdlLocation by default *is*
WEB-INF/wsdl, no?)
Also, in terms of having "CXF generate a new WSDL", that always happens
anyway, correct, if only for the soap:address URL to be updated
appropriately with the web service's location?
Thanks,
Glen
Re: Writing Maven/JUnit test cases for web service calls
Posted by Glen Mazza <gl...@verizon.net>.
2008-05-14 Daniel Kulp wrote:
> > In order for this to work, though, I think myImpl (the SIB) may need
> > to
> > have more annotation values than if the SIB were wrapped within the
> > WAR,
> > correct? From what I can tell, the SIB's configuration is the sum of
> > its @WebService annotation values[1] plus its jaxws:endpoint
> > configuration in the cxf-servlet.xml[2], therefore to do
> > Endpoint.publish(), anything otherwise in [2] would need to move to
> > [1].
> >
> > [1] http://www.jroller.com/gmazza/date/20080417#WFstep6
> > [2] http://www.jroller.com/gmazza/date/20080417#WFstep8
>
> For the CXF stuff in [2], you only have the address and implementor
> defined. Everything else is taken from the annotations. What's
> interesting is that with that configuration, you are letting CXF
> generate a new wsdl as there isn't a wsdlLocation specified anywhere
> for CXF. Not a big deal, but I'm not sure if that's what you
> intended since your metro configuration is specifying a wsdl.
>
Thanks for pointing this out, I confirmed from the Tomcat catalina.out
log that it was indeed regenerating a WSDL from the class. I fixed my
blog entry to include the wsdlLocation info.
Glen
Re: Writing Maven/JUnit test cases for web service calls
Posted by Daniel Kulp <dk...@apache.org>.
Glen,
On May 14, 2008, at 12:26 AM, Glen Mazza wrote:
> 2008-05-13 Daniel Kulp wrote:
>> That said, with JAX-WS, in your "setup" method you can just call:
>> Endpoint ep = Endpoint.publish("http://localhost:8080/blah",
>> myImpl);
>
> Interesting...I did not know that was part of JAX-WS. I always
> assumed
> that was either CXF-specific or part of the simple front end.
Nope. Part of the JAX-WS spec actually.
> In order for this to work, though, I think myImpl (the SIB) may need
> to
> have more annotation values than if the SIB were wrapped within the
> WAR,
> correct? From what I can tell, the SIB's configuration is the sum of
> its @WebService annotation values[1] plus its jaxws:endpoint
> configuration in the cxf-servlet.xml[2], therefore to do
> Endpoint.publish(), anything otherwise in [2] would need to move to
> [1].
>
> [1] http://www.jroller.com/gmazza/date/20080417#WFstep6
> [2] http://www.jroller.com/gmazza/date/20080417#WFstep8
For the CXF stuff in [2], you only have the address and implementor
defined. Everything else is taken from the annotations. What's
interesting is that with that configuration, you are letting CXF
generate a new wsdl as there isn't a wsdlLocation specified anywhere
for CXF. Not a big deal, but I'm not sure if that's what you
intended since your metro configuration is specifying a wsdl.
For the most part, if your @WebService annotation has the portName,
serviceName, and endpointInterface stuff (actually, just the
endpointInterface really as the rest can be defaulted), it should
work. The trick is if you want it to use a wsdl or generate one.
If you want it to use a wsdl, you need the wsdlLocation specified.
Unfortunately, since that is burned into the code with an annotation,
it's hard to deal with if the location is different for your unit test
compared to when packaged in a war. However, you can also do it
via: (this works with CXF, not sure about Metro)
Endpoint ep = Endpoint.create(impl);
ep.getProperties().put(
"javax.xml.ws.wsdl.description",
wsdlLocation);
ep.publish("http://localhost:8080/blah");
You might be able to do:
Source source = new StreamSource(wsdlLocation);
ep.setMetaData(source);
or something to set the wsdl.
> (BTW, is there a more precise terminology you use for WAR-file based
> web
> service providers vs. Endpoint.publish()'ed web service providers?)
I generally refer to the Endpoint.publish(...) stuff as "standalone"
servers/services as they don't require a hosting container. A simple
standalone main method is fine.
>> and CXF (or Metro) will automatically setup an embedded http server
>> (jetty for CXF, metro uses the http stuff that is now part of Java6)
>
> BTW #2, how is CXF supposed to interact with Java6 now that Metro is
> in
> it by default--is CXF intended to be swapped in, similar to changing
> the
> XML parser, i.e., just by placing its libs in jre/endorsed, or will
> the
> CXF libs still be separate? I'm not sure how this will work.
Actually, it should just work (outside of an OSGi container running on
Java6) without endorsing anything. When you call the JAX-WS API's, it
looks in the context classloader for a META-INF/services/
javax.xml.ws.spi.Provider file that contains the classname of the
provider to use. The default impl in the JDK does not have that
file. CXF does. Thus, if CXF is on the classpath, CXF will be
used. Nothing special needs to be done. (caveat: CXF 2.1 needs JDK6
update 4 or later. CXF 2.0.x will not work on update 4 or later.
This is due to the jaxws-api version being upgraded to 2.1 in update
4). That all said, this does create some support issues. With
JDK5, if cxf is not on the classpath, nothing works. You get class
not found things. On JDK6, your application might actually work, but
it will use metro instead of CXF. Thus, CXF specific things (like
spring configuration) wouldn't be picked up and you end up with wacky
support requests. I've seen stack traces that are obviously metro
stack traces, not CXF. Something to keep an eye out for.
OSGi is more complex as finding the META-INF/services/
javax.xml.ws.spi.Provider file cannot be done in OSGi. Guillaume
Nodet is working on solutions for that. It actually affects other
things like JAX-RS, SAAJ, even woodstox, as they also all use the META-
INF/services directory to find the implementation.
Dan
>
>
> Thanks,
> Glen
>
>
>>
>> that you can then hit. You don't need a war or anything. That may
>> have some issues with the wsdlLocation annotation on the classes
>> though. (don't forget to call stop in the tearDown)
>>
>> I would just use one of the above. It's pretty simple.
>>
>> The CXF systest stuff goes one further by forking the server into a
>> separate process instead of running it in-process with the test
>> client.
>> In general, that's probably overkill for simple unit style
>> testing. However, it does make sure there is a completely clean
>> separation between client/server and the only communication is
>> through
>> the soap messages. No "statics" or anything that can pollute the
>> results.
>>
>> Dan
>>
>>
>>
>>> 2.) Create a separate "systests" project that doesn't test anything
>>> until the WAR is (manually) deployed on a non-embedded servlet
>>> container--*then* run the tests. CXF also has this type of test--
>>> but
>>> I'm unsure how appropriate it would be for the types of tests I'm
>>> thinking of here.
>>>
>>> Any suggestions which is best? What have others done for web
>>> service
>>> provider testing?
>>>
>>> Thanks,
>>> Glen
>>>
>>> [1] http://www.jroller.com/gmazza/date/20080417
>>>
>>>
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Writing Maven/JUnit test cases for web service calls
Posted by Glen Mazza <gl...@verizon.net>.
2008-05-13 Daniel Kulp wrote:
> Glen,
>
> On May 13, 2008, at 6:42 AM, Glen Mazza wrote:
>
> > Hello,
> >
> > I'd like to add JUnit test cases to the Maven version of my "DoubleIt"
> > web service provider[1]. The types of things I'd like to test are (1)
> > that an integer fed is actually doubled in the response, (2) not
> > well-formed SOAP requests are rejected, and (3) non-schema valid SOAP
> > requests are rejected.
> >
> > I can think of two main ways of doing this:
> >
> > 1.) Write test cases the standard Maven way, i.e., create a test
> > folder
> > that it is sibling of the service/src/main folder and write the test
> > cases there. That would require having an embedded Tomcat or Jetty
> > instance that reads the either the WAR file in target (or,
> > equivalently,
> > the exploded war also in target), and makes a servlet out of that so
> > the
> > test cases can work. I'm not sure if embedded Tomcat/Jetty can handle
> > this though--most/all of our CXF test cases don't work with WAR-file
> > hosted web service providers.
>
> This would work. The embedded jetty can pick up a war directory
> fairly easily. We have a couple of tests that do this. Take a look
> at the BookServerSpring.java class in the systests module. (package:
> org.apache.cxf.systest.jaxrs) It would startup the exploded war
> easily and allow you to hit it.
>
>
Excellent, thanks for the tip! [Sie auch, Bernd, fuer Ihre Hilfe!] This
will save me a lot of time.
> That said, with JAX-WS, in your "setup" method you can just call:
> Endpoint ep = Endpoint.publish("http://localhost:8080/blah", myImpl);
Interesting...I did not know that was part of JAX-WS. I always assumed
that was either CXF-specific or part of the simple front end.
In order for this to work, though, I think myImpl (the SIB) may need to
have more annotation values than if the SIB were wrapped within the WAR,
correct? From what I can tell, the SIB's configuration is the sum of
its @WebService annotation values[1] plus its jaxws:endpoint
configuration in the cxf-servlet.xml[2], therefore to do
Endpoint.publish(), anything otherwise in [2] would need to move to [1].
[1] http://www.jroller.com/gmazza/date/20080417#WFstep6
[2] http://www.jroller.com/gmazza/date/20080417#WFstep8
(BTW, is there a more precise terminology you use for WAR-file based web
service providers vs. Endpoint.publish()'ed web service providers?)
> and CXF (or Metro) will automatically setup an embedded http server
> (jetty for CXF, metro uses the http stuff that is now part of Java6)
BTW #2, how is CXF supposed to interact with Java6 now that Metro is in
it by default--is CXF intended to be swapped in, similar to changing the
XML parser, i.e., just by placing its libs in jre/endorsed, or will the
CXF libs still be separate? I'm not sure how this will work.
Thanks,
Glen
>
> that you can then hit. You don't need a war or anything. That may
> have some issues with the wsdlLocation annotation on the classes
> though. (don't forget to call stop in the tearDown)
>
> I would just use one of the above. It's pretty simple.
>
> The CXF systest stuff goes one further by forking the server into a
> separate process instead of running it in-process with the test
> client.
> In general, that's probably overkill for simple unit style
> testing. However, it does make sure there is a completely clean
> separation between client/server and the only communication is through
> the soap messages. No "statics" or anything that can pollute the
> results.
>
> Dan
>
>
>
> > 2.) Create a separate "systests" project that doesn't test anything
> > until the WAR is (manually) deployed on a non-embedded servlet
> > container--*then* run the tests. CXF also has this type of test--but
> > I'm unsure how appropriate it would be for the types of tests I'm
> > thinking of here.
> >
> > Any suggestions which is best? What have others done for web service
> > provider testing?
> >
> > Thanks,
> > Glen
> >
> > [1] http://www.jroller.com/gmazza/date/20080417
> >
> >
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
Re: Writing Maven/JUnit test cases for web service calls
Posted by Daniel Kulp <dk...@apache.org>.
Glen,
On May 13, 2008, at 6:42 AM, Glen Mazza wrote:
> Hello,
>
> I'd like to add JUnit test cases to the Maven version of my "DoubleIt"
> web service provider[1]. The types of things I'd like to test are (1)
> that an integer fed is actually doubled in the response, (2) not
> well-formed SOAP requests are rejected, and (3) non-schema valid SOAP
> requests are rejected.
>
> I can think of two main ways of doing this:
>
> 1.) Write test cases the standard Maven way, i.e., create a test
> folder
> that it is sibling of the service/src/main folder and write the test
> cases there. That would require having an embedded Tomcat or Jetty
> instance that reads the either the WAR file in target (or,
> equivalently,
> the exploded war also in target), and makes a servlet out of that so
> the
> test cases can work. I'm not sure if embedded Tomcat/Jetty can handle
> this though--most/all of our CXF test cases don't work with WAR-file
> hosted web service providers.
This would work. The embedded jetty can pick up a war directory
fairly easily. We have a couple of tests that do this. Take a look
at the BookServerSpring.java class in the systests module. (package:
org.apache.cxf.systest.jaxrs) It would startup the exploded war
easily and allow you to hit it.
That said, with JAX-WS, in your "setup" method you can just call:
Endpoint ep = Endpoint.publish("http://localhost:8080/blah", myImpl);
and CXF (or Metro) will automatically setup an embedded http server
(jetty for CXF, metro uses the http stuff that is now part of Java6)
that you can then hit. You don't need a war or anything. That may
have some issues with the wsdlLocation annotation on the classes
though. (don't forget to call stop in the tearDown)
I would just use one of the above. It's pretty simple.
The CXF systest stuff goes one further by forking the server into a
separate process instead of running it in-process with the test
client. In general, that's probably overkill for simple unit style
testing. However, it does make sure there is a completely clean
separation between client/server and the only communication is through
the soap messages. No "statics" or anything that can pollute the
results.
Dan
> 2.) Create a separate "systests" project that doesn't test anything
> until the WAR is (manually) deployed on a non-embedded servlet
> container--*then* run the tests. CXF also has this type of test--but
> I'm unsure how appropriate it would be for the types of tests I'm
> thinking of here.
>
> Any suggestions which is best? What have others done for web service
> provider testing?
>
> Thanks,
> Glen
>
> [1] http://www.jroller.com/gmazza/date/20080417
>
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog