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 <[EMAIL PROTECTED]> 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
>>> [EMAIL PROTECTED]
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>
> ---
> Daniel Kulp
> [EMAIL PROTECTED]
> 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
