cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "KARR, DAVID" <dk0...@att.com>
Subject RE: Strategies for randomizing or verifying port number for JAXRSServerFactoryBean, or using local transport
Date Mon, 15 Jan 2018 19:20:36 GMT
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Monday, January 15, 2018 2:47 AM
> To: users@cxf.apache.org
> 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: users@cxf.apache.org
> >> 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?
> >
Mime
View raw message