[GitHub] [cxf] reta commented on issue #541: CXF-8020 use System.currentTimeMillis()

[GitBox <gi...@apache.org>]

reta commented on issue #541: CXF-8020 use System.currentTimeMillis()
URL: https://github.com/apache/cxf/pull/541#issuecomment-482621417
 
 
   These are just sample projects, it is very unlikely that `System.currentTimeMillis()` vs `new Date().getTime()` in this particular case would make the difference. Thank you.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Re: Question about Apache cxf client compatibility with jersey client

[Andy McCright <j....@gmail.com>]

Hi Akshay,

I think it _can_ work, but it is a little risky. I believe it works because
Jersey's ClientConfig class is an implementation of
java.ws.rs.core.Configurable.  But in general, mixing implementations can
lead to problems - generally in the classloading space.

Do you need Jersey at all?  If not, then you could use CXF's equivalent (
org.apache.cxf.jaxrs.client.spec.ClientConfigurableImpl). Another
alternative would be to avoid any dependency on the implementation in your
application code - and just use the spec APIs - for example:

verifyingClient = ClientBuilder.newBuilder()
                               .property(ApacheClientProperties.SSL_CONFIG,
sslConfigurator)
                               .register(new ApacheConnectorProvider())
                               .build();

Hope this helps,

Andy

On Sun, Apr 14, 2019 at 11:05 PM Akshay Hegade <ak...@gmail.com>
wrote:

> Hi Team,
>
>
>
> I have question related to cxf-rt-rs-client-3.3.1
>
>
>
> *Background* :
>
> I am working on legacy application which uses jersey-client-2.7 for http
> requests, since jersey-client-2.7 does not support *HTTP PATCH* method, we
> are using cxf-rt-rs-client-3.3.1.
>
> And HTTP PATCH started to work without any changes after *inclusion* of
> cxf-rt-rs-client-3.3.1.jar in our class path along with its dependencies.
>
>
>
> *Reason* :
>
> javax.ws.rs.client.FactoryFinder.java has following piece of code
>
>    - String serviceId = "META-INF/services/“ + factoryId;
>
>
>
> javax.ws.rs.client.ClientBuilder.java has following piece of code
>
>    - Object delegate =
>    FactoryFinder.find("javax.ws.rs.client.ClientBuilder",
>    "org.glassfish.jersey.client.JerseyClientBuilder");
>
>
>
> Since  cxf-rt-rs-client-3.3.1 in class path along with jersey-client-2.7,
> the precedence is given to cxf-rt-rs-client-3.3.1.
>
>
>
> And we are using passing org.glassfish.jersey.client.ClientConfig to
> javax.ws.rs.client.ClientBuilder
>
>
>
> *Code Snippet* :
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>       ClientConfig clientConfig = new ClientConfig();
>
>       clientConfig.property(ApacheClientProperties.SSL_CONFIG,
> sslConfigurator);
>
>       ConnectorProvider connectorProvider = new ApacheConnectorProvider();
>
>       clientConfig.connectorProvider(connectorProvider);
>
>
>
>       verifyingClient = ClientBuilder.newBuilder()
>
>           .withConfig(*clientConfig*).build();
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
>
>
>
> *Question* :
>
> Whether jersey’s concrete class  org.glassfish.jersey.client.ClientConfig
> can be used along with javax.ws.rs.client.ClientBuilder ?
>
>
>
> Please revert back at your earliest convenience.
>
>
>
> Thanks,
>
> Akshay
>

Question about Apache cxf client compatibility with jersey client

[Akshay Hegade <ak...@gmail.com>]

Hi Team,



I have question related to cxf-rt-rs-client-3.3.1



*Background* :

I am working on legacy application which uses jersey-client-2.7 for http
requests, since jersey-client-2.7 does not support *HTTP PATCH* method, we
are using cxf-rt-rs-client-3.3.1.

And HTTP PATCH started to work without any changes after *inclusion* of
cxf-rt-rs-client-3.3.1.jar in our class path along with its dependencies.



*Reason* :

javax.ws.rs.client.FactoryFinder.java has following piece of code

   - String serviceId = "META-INF/services/“ + factoryId;



javax.ws.rs.client.ClientBuilder.java has following piece of code

   - Object delegate =
   FactoryFinder.find("javax.ws.rs.client.ClientBuilder",
   "org.glassfish.jersey.client.JerseyClientBuilder");



Since  cxf-rt-rs-client-3.3.1 in class path along with jersey-client-2.7,
the precedence is given to cxf-rt-rs-client-3.3.1.



And we are using passing org.glassfish.jersey.client.ClientConfig to
javax.ws.rs.client.ClientBuilder



*Code Snippet* :

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

      ClientConfig clientConfig = new ClientConfig();

      clientConfig.property(ApacheClientProperties.SSL_CONFIG,
sslConfigurator);

      ConnectorProvider connectorProvider = new ApacheConnectorProvider();

      clientConfig.connectorProvider(connectorProvider);



      verifyingClient = ClientBuilder.newBuilder()

          .withConfig(*clientConfig*).build();

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>





*Question* :

Whether jersey’s concrete class  org.glassfish.jersey.client.ClientConfig
can be used along with javax.ws.rs.client.ClientBuilder ?



Please revert back at your earliest convenience.



Thanks,

Akshay