> -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Monday, January 15, 2018 2:47 AM > To: [email protected] > 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: [email protected] > >> 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? > >
