Strategies for randomizing or verifying port number for JAXRSServerFactoryBean, or using local transport

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Strategies for randomizing or verifying port number for JAXRSServerFactoryBean, or using local transport

David M. Karr
Our codebase is going to have some unit tests using JAXRSServerFactoryBean.  To be reliable, I not only have to ensure that I use a port number that is uncommon, I have to make sure that the other unit tests are using a different port.

Besides just using a plain random number generator in a range, are there any viable strategies for doing this?

I thought about using "local transport" (https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Testing), which might solve this problem, but it appears that doing this requires at least a small change on the client side (setting DIRECT_DISPATCH on the request context), and I'm not sure our client interface is even compatible.  We're using Client to get a WebTarget, and then an Invocation.Builder.  Is it even possible to set this to use direct dispatch?
Reply | Threaded
Open this post in threaded view
|

RE: Strategies for randomizing or verifying port number for JAXRSServerFactoryBean, or using local transport

David M. Karr
> -----Original Message-----
> From: KARR, DAVID
> Sent: Friday, January 12, 2018 2:31 PM
> To: [hidden email]
> Subject: Strategies for randomizing or verifying port number for
> JAXRSServerFactoryBean, or using local transport
>
> Our codebase is going to have some unit tests using
> JAXRSServerFactoryBean.  To be reliable, I not only have to ensure that
> I use a port number that is uncommon, I have to make sure that the other
> unit tests are using a different port.
>
> Besides just using a plain random number generator in a range, are there
> any viable strategies for doing this?
>
> I thought about using "local transport"
> (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__cwiki.apache.org_confluence_display_CXF20DOC_JAXRS-
> 2BTesting&d=DwIFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=HLSf-QGNUTDyT41PijTXyOMDk707zXxi-
> bJP7X8li3s&s=n2pLBzH8YBAvtug2zK-MgiRtBaFo5e3thOgIICL9jzY&e= ), which
> might solve this problem, but it appears that doing this requires at
> least a small change on the client side (setting DIRECT_DISPATCH on the
> request context), and I'm not sure our client interface is even
> compatible.  We're using Client to get a WebTarget, and then an
> Invocation.Builder.  Is it even possible to set this to use direct
> dispatch?

As an update, I'm trying to get local transport working.

In our current code, we produce a "client" object of type "org.apache.cxf.jaxrs.client.spec.ClientImpl", then get a Target, then get a Builder.

I tried doing the following:

        WebClient.getConfig(client).getRequestContext().put(LocalConduit.DIRECT_DISPATCH, Boolean.TRUE);

This fails with "Not a valid Client" in "org.apache.cxf.jaxrs.client.WebClient.getConfig(Object)" because it needs to be an instance of "org.apache.cxf.jaxrs.client.Client".

I now see that the declared type of "client" is "javax.ws.rs.client.Client".

Confusing.  What can I do here?
Reply | Threaded
Open this post in threaded view
|

Re: Strategies for randomizing or verifying port number for JAXRSServerFactoryBean, or using local transport

Sergey Beryozkin
Administrator
Hi David

WebClient.getConfig() would work but only if you pass to it
InvocationBuilder (JAX-RS 2.0 Client.target().request(), etc)

But you can set whatever properties you need to pass to the CXF client
runtime on the JAX-RS 2.0 Client Configuration which is simpler.

By the way, I'm not sure DIRECT_DISPATCH is still needed for non-proxy
clients to try the local transport, try both options...

Cheers, Sergey
On 12/01/18 23:17, KARR, DAVID wrote:

>> -----Original Message-----
>> From: KARR, DAVID
>> Sent: Friday, January 12, 2018 2:31 PM
>> To: [hidden email]
>> Subject: Strategies for randomizing or verifying port number for
>> JAXRSServerFactoryBean, or using local transport
>>
>> Our codebase is going to have some unit tests using
>> JAXRSServerFactoryBean.  To be reliable, I not only have to ensure that
>> I use a port number that is uncommon, I have to make sure that the other
>> unit tests are using a different port.
>>
>> Besides just using a plain random number generator in a range, are there
>> any viable strategies for doing this?
>>
>> I thought about using "local transport"
>> (https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__cwiki.apache.org_confluence_display_CXF20DOC_JAXRS-
>> 2BTesting&d=DwIFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
>> xy2uk0vYF_EA&m=HLSf-QGNUTDyT41PijTXyOMDk707zXxi-
>> bJP7X8li3s&s=n2pLBzH8YBAvtug2zK-MgiRtBaFo5e3thOgIICL9jzY&e= ), which
>> might solve this problem, but it appears that doing this requires at
>> least a small change on the client side (setting DIRECT_DISPATCH on the
>> request context), and I'm not sure our client interface is even
>> compatible.  We're using Client to get a WebTarget, and then an
>> Invocation.Builder.  Is it even possible to set this to use direct
>> dispatch?
>
> As an update, I'm trying to get local transport working.
>
> In our current code, we produce a "client" object of type "org.apache.cxf.jaxrs.client.spec.ClientImpl", then get a Target, then get a Builder.
>
> I tried doing the following:
>
> WebClient.getConfig(client).getRequestContext().put(LocalConduit.DIRECT_DISPATCH, Boolean.TRUE);
>
> This fails with "Not a valid Client" in "org.apache.cxf.jaxrs.client.WebClient.getConfig(Object)" because it needs to be an instance of "org.apache.cxf.jaxrs.client.Client".
>
> I now see that the declared type of "client" is "javax.ws.rs.client.Client".
>
> Confusing.  What can I do here?
>
Reply | Threaded
Open this post in threaded view
|

RE: Strategies for randomizing or verifying port number for JAXRSServerFactoryBean, or using local transport

David M. Karr
> -----Original Message-----
> From: Sergey Beryozkin [mailto:[hidden email]]
> Sent: Monday, January 15, 2018 2:47 AM
> To: [hidden email]
> Subject: Re: Strategies for randomizing or verifying port number for
> JAXRSServerFactoryBean, or using local transport
>
> Hi David
>
> WebClient.getConfig() would work but only if you pass to it
> InvocationBuilder (JAX-RS 2.0 Client.target().request(), etc)
>
> But you can set whatever properties you need to pass to the CXF client
> runtime on the JAX-RS 2.0 Client Configuration which is simpler.
>
> By the way, I'm not sure DIRECT_DISPATCH is still needed for non-proxy
> clients to try the local transport, try both options...

Thanks, but I've decided this entire approach is overkill.  I don't need to test the network.  I ended up using the ClientRequestFilter mechanism.  It does what I need without mess or fuss.

> On 12/01/18 23:17, KARR, DAVID wrote:
> >> -----Original Message-----
> >> From: KARR, DAVID
> >> Sent: Friday, January 12, 2018 2:31 PM
> >> To: [hidden email]
> >> Subject: Strategies for randomizing or verifying port number for
> >> JAXRSServerFactoryBean, or using local transport
> >>
> >> Our codebase is going to have some unit tests using
> >> JAXRSServerFactoryBean.  To be reliable, I not only have to ensure
> that
> >> I use a port number that is uncommon, I have to make sure that the
> other
> >> unit tests are using a different port.
> >>
> >> Besides just using a plain random number generator in a range, are
> there
> >> any viable strategies for doing this?
> >>
> >> I thought about using "local transport"
> >> (https://urldefense.proofpoint.com/v2/url?u=https-
> >> 3A__cwiki.apache.org_confluence_display_CXF20DOC_JAXRS-
> >> 2BTesting&d=DwIFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> >> xy2uk0vYF_EA&m=HLSf-QGNUTDyT41PijTXyOMDk707zXxi-
> >> bJP7X8li3s&s=n2pLBzH8YBAvtug2zK-MgiRtBaFo5e3thOgIICL9jzY&e= ), which
> >> might solve this problem, but it appears that doing this requires at
> >> least a small change on the client side (setting DIRECT_DISPATCH on
> the
> >> request context), and I'm not sure our client interface is even
> >> compatible.  We're using Client to get a WebTarget, and then an
> >> Invocation.Builder.  Is it even possible to set this to use direct
> >> dispatch?
> >
> > As an update, I'm trying to get local transport working.
> >
> > In our current code, we produce a "client" object of type
> "org.apache.cxf.jaxrs.client.spec.ClientImpl", then get a Target, then
> get a Builder.
> >
> > I tried doing the following:
> >
> >
> WebClient.getConfig(client).getRequestContext().put(LocalConduit.DI
> RECT_DISPATCH, Boolean.TRUE);
> >
> > This fails with "Not a valid Client" in
> "org.apache.cxf.jaxrs.client.WebClient.getConfig(Object)" because it
> needs to be an instance of "org.apache.cxf.jaxrs.client.Client".
> >
> > I now see that the declared type of "client" is
> "javax.ws.rs.client.Client".
> >
> > Confusing.  What can I do here?
> >