You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dennis Sosnoski <dm...@sosnoski.com> on 2011/01/16 22:41:52 UTC
WS-RM integration test for server side
I've been working on writing integration tests that check WS-RM delivery
assurances on the server side, after seeing some problems in this area
when I tested using sample code
(http://mail-archives.apache.org/mod_mbox/cxf-dev/201101.mbox/browser).
I'm trying to use
systests/ws-specs/src/test/java/org.apache.cxf.systest.ws.rm.SequenceTest as
a starting point, but since I want to check the message delivery to the
server I need a very different organization.
I'd like to add in- and out-message recorders to the greeterBus
configuration build by ControlImpl, which it looks like I should be able
to do in the passed-in configuration file, then run the service
in-process so that I can potentially access the recorders from the test
code. But how can I find the recorders from the test code?
It looks like I could get the BusFactory default bus setting after the
call to Control.startGreeter(), since it sets this to the
newly-constructed greeterBus, but I hate to rely on a side-effect like
this. Can someone suggest a cleaner way to handle this?
Thanks for any advice,
- Dennis
--
Dennis M. Sosnoski
Java SOA and Web Services Consulting <http://www.sosnoski.com/consult.html>
Axis2/CXF/Metro SOA and Web Services Training
<http://www.sosnoski.com/training.html>
Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
Re: WS-RM integration test for server side
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
On 01/17/2011 04:28 PM, Dennis Sosnoski wrote:
> ...
> I'm now wondering, though, if I'm better off just bypassing the whole
> Server/Control logic in these tests and instead just starting an
> in-process service instance directly in my test code. That way I can
> control the bus configuration and don't need to play any games with
> passing data. Anyone see any drawbacks to this approach for server-side
> testing?
>
I gave this a try, but I've got a problem during the RM sequence
creation. The request goes out and the successful response comes back
(as shown by console logging), but the
org.apache.cxf.ws.rm.Proxy.createSequence() call returns null. There's
an interesting comment in this method, BTW: "// tried using separate
thread - did not help either". It's nice to see an occasional comment in
the code, but that one is a bit scarey.
I traced this further to the response message handling, where
Proxy$RMClient.processResult() is being called and expecting to get the
message data as a List. The MessageImpl has a null for the
java.util.List entry in defaultContents[], so it returns null.
Anyone have an idea why this might be messing up, given that both the
request and the response message look ok?
Thanks again,
- Dennis
Re: WS-RM integration test for server side
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
On 01/17/2011 03:12 PM, Freeman Fang wrote:
>
> On 2011-1-17, at 上午5:41, Dennis Sosnoski wrote:
>
>> ...
>>
>> I'd like to add in- and out-message recorders to the greeterBus
>> configuration build by ControlImpl, which it looks like I should be able
>> to do in the passed-in configuration file, then run the service
>> in-process so that I can potentially access the recorders from the test
>> code. But how can I find the recorders from the test code?
>>
>> ...
> Hi,
>
> How about add two publich methods in
> org.apache.cxf.systest.ws.rm.ControlImpl, just like
>
> public List<Interceptor<? extends Message>>
> getGreeterBusInInterceptors() {
> return greeterBus.getInInterceptors();
> }
>
> public List<Interceptor<? extends Message>>
> getGreeterBusOuInterceptors() {
> return greeterBus.getOutInterceptors();
> }
I don't think this would work, since the Interceptors are not going to
support conversion to/from XML... are they?
>
> Or more specifically, just return the in/out recorder interceptor you
> are concerned about, just like
>
> public Interceptor getInMessageRecorder() {
> for (Interceptor interceptor : greeterBus.getInInterceptors()) {
> if
> (interceptor.getClass().getName().equals("org.apache.cxf.systest.ws.util.InMessageRecorder"))
> {
> return interceptor;
> }
> }
> return null;
> }
>
> public Interceptor getOutMessageRecorder() {
> for (Interceptor interceptor : greeterBus.getOutInterceptors()) {
> if
> (interceptor.getClass().getName().equals("org.apache.cxf.systest.ws.util.OutMessageRecorder"))
> {
> return interceptor;
> }
> }
> return null;
> }
>
> So that you can get In/OutMessageRecorders whenever you want to use it.
Same issue applies here. I could use calls to Control to get the actual
recorded data without too much trouble, as List<byte[]>.
I'm now wondering, though, if I'm better off just bypassing the whole
Server/Control logic in these tests and instead just starting an
in-process service instance directly in my test code. That way I can
control the bus configuration and don't need to play any games with
passing data. Anyone see any drawbacks to this approach for server-side
testing?
- Dennis
Re: WS-RM integration test for server side
Posted by Freeman Fang <fr...@gmail.com>.
On 2011-1-17, at 上午5:41, Dennis Sosnoski wrote:
> I've been working on writing integration tests that check WS-RM
> delivery
> assurances on the server side, after seeing some problems in this area
> when I tested using sample code
> (http://mail-archives.apache.org/mod_mbox/cxf-dev/201101.mbox/
> browser).
> I'm trying to use
> systests/ws-specs/src/test/java/
> org.apache.cxf.systest.ws.rm.SequenceTest as
> a starting point, but since I want to check the message delivery to
> the
> server I need a very different organization.
>
> I'd like to add in- and out-message recorders to the greeterBus
> configuration build by ControlImpl, which it looks like I should be
> able
> to do in the passed-in configuration file, then run the service
> in-process so that I can potentially access the recorders from the
> test
> code. But how can I find the recorders from the test code?
>
> It looks like I could get the BusFactory default bus setting after the
> call to Control.startGreeter(), since it sets this to the
> newly-constructed greeterBus, but I hate to rely on a side-effect like
> this. Can someone suggest a cleaner way to handle this?
>
Hi,
How about add two publich methods in
org.apache.cxf.systest.ws.rm.ControlImpl, just like
public List<Interceptor<? extends Message>>
getGreeterBusInInterceptors() {
return greeterBus.getInInterceptors();
}
public List<Interceptor<? extends Message>>
getGreeterBusOuInterceptors() {
return greeterBus.getOutInterceptors();
}
Or more specifically, just return the in/out recorder interceptor you
are concerned about, just like
public Interceptor getInMessageRecorder() {
for (Interceptor interceptor :
greeterBus.getInInterceptors()) {
if
(interceptor
.getClass
().getName
().equals("org.apache.cxf.systest.ws.util.InMessageRecorder")) {
return interceptor;
}
}
return null;
}
public Interceptor getOutMessageRecorder() {
for (Interceptor interceptor :
greeterBus.getOutInterceptors()) {
if
(interceptor
.getClass
().getName
().equals("org.apache.cxf.systest.ws.util.OutMessageRecorder")) {
return interceptor;
}
}
return null;
}
So that you can get In/OutMessageRecorders whenever you want to use it.
Freeman
~
> Thanks for any advice,
>
> - Dennis
>
> --
>
> Dennis M. Sosnoski
> Java SOA and Web Services Consulting <http://www.sosnoski.com/consult.html
> >
> Axis2/CXF/Metro SOA and Web Services Training
> <http://www.sosnoski.com/training.html>
> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>
--
Freeman Fang
------------------------
FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org