Re: [Resteasy-users] Eventhandler registration for JAXB while unmarhsalling in Resteasy

[Savvas Andreas Moysidis]

Hi Kaushal,

If I am understanding your requirement right then you probably want to look
into ReaderInterceptor(s) and implement one of those. You should  be able
to register them with @Provider.

HTH,
Savvas
On 17 Mar 2016 16:11, "Kaushal Kishore Agrawal" 
wrote:

> Hi All,
>
> Is there any way in which I can register custom event handler in resteasy
> for JAXB unmarshalling. Can it be done in a declarative way, like the way
> we use to add providers
>
> I need the same to register a custom ValidationEventHandler
>
> Thanks,
> Kaushal Kishore
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] Converting interceptor from RestEasy 2 to 3

[Savvas Andreas Moysidis]

​Hi Fausto,

It doesn't look like there is a more straightforward solution to this ​than
what you've some up with. What I'd have done however is make the
TokenValidatorInterceptor a "non-managed" class (in whatever DI framework
you are using) meaning a simple, plain class. Then I'd inject all its
required dependencies into the DynamicFeature (since it's @Provider) and
have that instantiate and register a TokenValidatorInterceptor. In that
sense (and in GRASP parlance) the latter would act as a "creator" of the
former.

HTF,
Savvas

On 1 February 2016 at 17:03, Fausto Santos  wrote:

> I'm converting an application from RestEasy 2 to 3. There is one
> authorization interceptor that implements PreProcessInterceptor and
> AcceptedByMethod interfaces. This interceptor is responsible for verifying
> an encrypted token in the request, and then authorizing or not the
> execution of a given method. There is also a @TokenValidationNotRequired
> annotation, to avoid the validation of the token on some methods, including
> the authentication method.
>
> So I changed the PreProcessInterceptor to a ContainerRequestFilter, and as
> the AcceptByMethod interface is deprecated I decided to use the Name
> Binding feature, then I would have to change the annotation to
> @TokenValidationRequired and put it in all methods that need authorization
> checking. This would result in a huge refactoring, and it's a bit insecure
> because other developers may forget to use the annotation. It's better to
> explicit annotate methods that doesn't need authorization checking, than
> doing the opposite.
>
> So I implemented a DynamicFeature that verifies methods that doesn't have
> the @TokenValidationNotRequired annotation and bind the
> TokenValidationInterceptor to them, like this:
>
> context.register(TokenValidatorInterceptor.class);
>
> The problem is that if I leave the interceptor annotated with @Provider,
> it becomes a global interceptor. If I remove it, the interceptor is
> correctly binded, but the autowiring on it's properties doesn't happen. I
> solved the problem by injecting the application context in the
> DynamicFeature and then getting the interceptor from the context, like this:
>
>
> context.register(applicationContext.getBean(TokenValidatorInterceptor.class));
>
> Is there an easier, or more correct, way of doing this? Something like a
> reverse name binding, that only binds the interceptor to methods that
> doesn't have the specific annotation?
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] Starting new thread(s) during calls

[Savvas Andreas Moysidis]

Hi Sean,

If your goal is to process a request in a separate thread other than the
handler thread then (assuming you are using a JAX-RS 2.0 implementation)
the AsyncResponse API is probably the safest way of achieving that.

Have a look at: https://jersey.java.net/documentation/latest/async.html

HTH,
Savvas





On 29 October 2015 at 21:22, Sean Dawson  wrote:

>
> Hello,
>
> A general question if anyone here knows off-hand or could point me to an
> answer.  Perhaps it depends on the http client or server or whatever but
>
> If I start a new Java thread in server code that handles a RestEasy call,
> does that new thread execute fully even if the original call has
> ended/returned?  Or does it get canceled/interrupted/etc?
>
> Thank you.
>
>
>
> --
>
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] Distributed transactions with REST resources

[Savvas Andreas Moysidis]

Hi Rodrigo,

Well, I'm thinking that if your requirements are such that your application
cannot tolerate an eventual consistency of such a level then probably a
more traditional XA type of solution would be more appropriate for your
circumstances.

HTH,
Savvas


On 8 June 2015 at 19:02, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:

 Guys,

 Once again, thank you both for your help.

 Savvas, that's really an option we're considering. But like Michael said,
 it would be just a workaround, not really an atomic transaction. But it
 is indeed one option. I'm still trying to weight which of the two pays off.

 Regards,
 Rodrigo.

 On Mon, Jun 8, 2015 at 8:28 AM, Michael Musgrove mmusg...@redhat.com
 wrote:

  I am not sure this will always be the best solution if the inserts at
 the two servers need to be treated as a single business operation.

 The solution you propose means that the inserts do not happen atomically
 and therfore you will put Consistency and Isolation at risk - ie other
 applications will see some of the inserts before both transactions have
 committed.

 Mike

  Hi Rodrigo,

  Does this really have to be in the classical sense of a distributed
 transaction? Can you not have App B embed a undo hypermedia link in its
 response?

  Given the following steps:

  1) App A starts transaction and inserts some rows
 2) App A makes REST call to app B
 3) App B inserts rows in a separate transaction and returns a 200
 response including a undo hypermedia link
 5) App A commits own transaction

  If steps 1 or 2 fail App A rollsback transaction so no problem there.
 If step 3 fails then a 500 response (or even a 4** one in case of
 validation errors) will be returned in which case App A can again rollback
 its transaction
 If step 5 fails then App A makes a POST request to the undo URL

  Savvas

 On 2 June 2015 at 18:03, Michael Musgrove mmusg...@redhat.com wrote:

  REST-AT and JTA are different transaction models. Unfortunately we
 only provide an inbound bridge to go from REST-AT to JTA but I think you
 need the other direction ie JTA to REST-AT.

 There may be a workaround for you though which I would need to
 experiment with. You would need to start a REST-AT transaction and emulate
 what we do with the inbound bridge by manually starting a bridge.
 Something similar to:

 1) EJB in web app A will start a REST-AT transaction
 2) EJB in web app A will start an InboundBridge (instead of the JTA
 transaction):
 InboundBridge inboundBridge =
 InboundBridgeManager.getInstance().createInboundBridge(enlistmentUrl from
 step 1);
 inboundBridge.start();
 3) EJB in web app A will perform JTA work (insert some records in a
 database)
 4) invoke REST endpoint in app B passing the enlistmentUrl in a Link
 header
 5) Mark up the REST endpoint in app B (using the
 javax.transaction.Transactional annotation) - this will automatically start
 an instance of the inbound bridge
 6) commit the REST-AT transaction started in step 1. This will cause the
 work done in B and in A to commit within the context of the single REST-AT
 transaction.

 The only other ways to we have for distributed transactions are:

 - distributed remoting protocol for JTA (think EJBs)
 - and of course we JTS too;
 - web services transactions (XTS, WS-AT)
 - BlackTie for C based clients

 Mike

   Mike,

  I have been reading the docs and taking a look at the code samples.
 I'm still unsure however if the protocol/api covers the scenario I'm in:

  I have a client web app (A), and a REST endpoint (B). Two separate
 applications. Client in web app A is not a REST endpoint itself, just a
 regular stateless EJB.

  So in my scenario the stateless EJB in web app A will start a
 transaction, insert some records in a database and invoke REST endpoint in
 app B, which in turn will also run a transaction to insert records in a
 database. We need to make sure these two transactions are atomic. That
 meaning, the two transactions should be only one.

  To me it seems that the protocol only covers scenarios where both
 participants in the transaction are REST resources, which in my case is not
 true. The client needs to participate in the transaction and it's just a
 regular EJB.

  Is this really the case?

  Regards!

 On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
 wrote:

 Thanks a lot, Mike! Exactly what I needed.

 On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove mmusg...@redhat.com
 wrote:

  The narayana transaction manager has a rest service that creates
 [transaction] Coordinator resources. These resources map onto conventional
 ACID transactions. It is up to your service to decide what to do when the
 transaction is completing. However, we also have a JTA Bridge that 
 will
 detect when your JAX-RS service performs JTA work (JMS, JPA etc) and
 automatically enlist those XA participants with the currently active
 coordinator.

 Our on-line docs [1] contains descriptions of the [REST-AT] protocol

Re: [Resteasy-users] Mapping with Static Content?

[Savvas Andreas Moysidis]

Hi Peter,

Have you considered using some other solution for serving static content
(e.g. Apache in front of your app server or a CDN repository)?

Regards,
Savvas

On 8 May 2015 at 04:44, Peter Luttrell pluttr...@gmail.com wrote:

 I just posted a question on StackOverflow that might be better answered
 here.


 http://stackoverflow.com/questions/30111978/hosting-static-content-and-jax-rs-services-under-the-same-root-context

 Thanks,
 Peter Luttrell

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] Can I change the type of an @FormParam parameter without having the change the HTML client code?

[Savvas Andreas Moysidis]

Hi Jim,

Have you given this a try to see if it works? :)

Yes, that will work as long as the id form param is an string
representation of an integer within the legal min-max range. You'll get a
400 Bad Request response if it's not.

As a general note though, all HTTP attributes (headers, cookies, request
and form params etc) will hit the JAX-RS endpoint as strings. The JAX-RS
provider will then try to convert those strings into whatever type is
defined in the resource class or the handler method, based on some default
type conversion rules.

HTH,
Savvas

On 19 April 2015 at 03:02, Jim Showalter j...@jimandlisa.com wrote:

 For example, could I change:

 @FormParam(id)String id

 to:

 @FormParam(id)Integer id

 It's easy to do this for path and query params, but form params have an
 input-type in the HTML, and I don't know if RESTEasy is
 smart/helpful enough to ignore that an honore the type I declare in Java.



 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] RESTEasy Runtime client propagation.

[Savvas Andreas Moysidis]

Hi Jacub,

Like you suggest, using an ExceptionMapper server-side and registering
a ClientResponseFilter client side should do the trick and is probably the
least intrusive way of achieving that goal.

On the ClientResponseFilter, you can probe the http response status and run
your logic accordingly.

HTH,
Savvas

On 27 February 2015 at 13:14, John D. Ament john.d.am...@gmail.com wrote:

 Hi Jakub!

 I think you're looking for ContainerResponseFilter.

 John

 On Fri, Feb 27, 2015 at 8:03 AM Jakub Narloch jmnarl...@gmail.com wrote:

 So,

 After a quick research I am trying to find the counterpart
 of ClientErrorInterceptor for RESTEasy 3.x, any sugestions?

 Regards,
 Jakub Narloch

 2015-02-27 11:37 GMT+01:00 Jakub Narloch jmnarl...@gmail.com:

 Hi,

 I think I have a quite interesting use case in our project, I had
 existing service layer that now is being translated into JAX-RS endpoints
 by exposing the existing service interfaces without changes and consuming
 them through RESTEasy client proxies. Everything seems ok except for one
 thing, we are struggling with RuntimeExceptions. Basically we had defined
 some application level exceptions that we wish to propagate to the client.
 Since they were runtime we didn't had defined the throws clauses for them.
 We would like to have those exceptions propagated to the client, but at the
 moment only what we got was some InternalServerErrrorException being thrown
 on client side.

 The question is only how we should approach to this problem, is there a
 way to register a ExceptionMapper and then register a ClientResponseFilter
 to process that, or there is maybe other way?

 Regards,
 Jakub Narloch


 
 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub
 for all
 things parallel software development, from weekly thought leadership
 blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users



 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] validation of method parameters

[Savvas Andreas Moysidis]

Hi Dave,

Not really sure why the bean validation stuff doesn't work but in order to
bind form params you probably need to configure your resource method and
binding class in a different way. Try the following:

@GET
public my object class, not important
resourceMethod(@Valid @*BeanParam* MyParams params)
{
...
}

public class MyParams {

@FormParam(a)
private ArrayListString stringList = new ArrayList();

...
}

This should bind your form params into your MyParams class.

A minor side note: The convention many frameworks use when binding http
params at method level is the POJO one (i.e. *set*This()/*get*This() rather
than addThis() etc)

HTF,
Savvas

On 19 February 2015 at 19:48, Dave J devdevdata...@gmail.com wrote:

 Hello,

 After some nontrivial research I thought I would try this list in the
 hopes more expert users could help me figure out where I am going wrong.
 I am using RESTeasy 3.0.9. I am trying to affect validation of a parameter
 coming in on the URL for a GET request.

 I use a class to aggregate validation  storage of the set of parameters
 coming in on the URL.

 I start with this:

 @GET
 public my object class, not important
 resourceMethod(@Valid @Form MyParams params)
 {
 ...
 }

 The parameter of interest is a String, and can occur more than once. Let's
 name it a.
 I would like to validate each occurrence (I want to check that its length
 is within a certain range), and if valid, I would like to add the String to
 a list. Otherwise, stop and report the error.

 So within the MyParams class

 public class MyParams {

 private ArrayListString stringList = new ArrayListString();

 ...

 // Would rather this return void, but validation doesn't like
 constraints on void methods
 @QueryParam('a)
 public String addString(@Size(min=8,max=10) String str) {
 stringList.add(str);
 return null;
  }
 }


 However in this scenario, the incoming string is neither validated nor
 added to the list.

 Is it possible to do this within RESTeasy? I'm happy to provide more info
 if needed.

 Thanks.



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?

[Savvas Andreas Moysidis]

Great, thanks for the input Bill.

On 29 October 2014 13:20, Bill Burke bbu...@redhat.com wrote:

 By default, Resteasy only allows one connection per Client.  You have to
 use ResteadyClient(Builder) to expand this.  Other than that, it should
 be threadsafe.

 Personally, I'd create the Client as an application-scoped CDI bean and
 inject it, or create one with SPring and inject it, or create one in a
 servlet listener and add it to ServletContext.  If you create per
 request, then you lose any socket connection pooling that Apache Http
 Client does.

 On 10/27/2014 8:21 PM, Savvas Andreas Moysidis wrote:
  The question, I suppose, is whether Client implementations are
  thread-safe or not which is something that is not stipulated by the
  interface contract.
 
  If they are(something which is sort of implied by the javadoc), then you
  could maybe declare and use a single instance like the following? (in a
  JavaEE context)
 
  @Singleton
  public class SomeService {
 
   private Client restClient;
 
   @PostConstruct
   private void init() {
   restClient = ClientBuilder.newClient();
   }
 
 .
   // Use restClient object here
 
 .
 
   @PreDestroy
   private void cleanUp() {
   restClient.close();
   }
  }
 
  On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com
  mailto:mariodi...@gmail.com wrote:
 
  I'd be interested in hearing what common practice is regarding
  pooled Client objects, too. Do people use the Apache objects pool
  library? That's the only option I've heard of. Are there other
  mainstream solutions?
 
  Mario
 
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
  rodrigo.uc...@gmail.com mailto:rodrigo.uc...@gmail.com wrote:
   
[...]
 
   How should we implement a pool of Client objects in this scenario?
 Is there a common solution?
  
   Regards,
   Rodrigo Uchoa.
 
 
 
  
 --
  ___
  Resteasy-users mailing list
  Resteasy-users@lists.sourceforge.net
  mailto:Resteasy-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/resteasy-users
 
 
 
 
 
 --
 
 
 
  ___
  Resteasy-users mailing list
  Resteasy-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/resteasy-users
 

 --
 Bill Burke
 JBoss, a division of Red Hat
 http://bill.burkecentral.com


 --
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users

--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?

[Savvas Andreas Moysidis]

Hi Rodrigo,

That's precisely what my example above showcases. :)

It may well be the case that the Client class is not thread-safe indeed but
can I ask though what evidence have you got to believe that?

Perhaps taking a look at the source code would clarify things? (or a
commiter following this thread could verify instead)

On 28 October 2014 01:23, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:

 if Client implementations are thread-safe, shouldn't a single instance be
 enough? Thus having a single instance for the whole app would do it. I
 don't think it's the case.

 On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis 
 savvas.andreas.moysi...@gmail.com wrote:

 The question, I suppose, is whether Client implementations are
 thread-safe or not which is something that is not stipulated by the
 interface contract.

 If they are(something which is sort of implied by the javadoc), then you
 could maybe declare and use a single instance like the following? (in a
 JavaEE context)

 @Singleton
 public class SomeService {

 private Client restClient;

 @PostConstruct
 private void init() {
 restClient = ClientBuilder.newClient();
 }
 .
 // Use restClient object here
 .

 @PreDestroy
 private void cleanUp() {
 restClient.close();
 }
 }

 On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:

 I'd be interested in hearing what common practice is regarding pooled
 Client objects, too. Do people use the Apache objects pool library? That's
 the only option I've heard of. Are there other mainstream solutions?

 Mario

  On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
 wrote:
 
  [...]

  How should we implement a pool of Client objects in this scenario? Is
 there a common solution?
 
  Regards,
  Rodrigo Uchoa.



 --
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users




 --

 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users




 --

 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users


--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?

[Savvas Andreas Moysidis]

right...took a quick look at the jsr spec (
http://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf)
but nothing seems to be mentioned about thread-safety in client-api
implementations...so, this seems to largely be an implementation property
rather than a spec requirement..

anyway, I dug through the implementation I am using (
*org.glassfish.jersey.client.JerseyClient*) and from what I can see the
method for generating *WebRequest*s at least seems to be perfectly
thread-safe:

@Override
public JerseyWebTarget target(String uri) {
checkNotClosed();
checkNotNull(uri, LocalizationMessages.CLIENT_URI_TEMPLATE_NULL());
return new JerseyWebTarget(uri, this);
}

(note: checkNotNull is some preconditions-checking library statically
imported and LocalizationMessages.CLIENT_URI_TEMPLATE_NULL() is an actual
method call using a bizarre naming convention I've never come across
before... )

with checkNotClosed() having an implementation of:
void checkNotClosed() {
checkState(!closedFlag.get(),
LocalizationMessages.CLIENT_INSTANCE_CLOSED());
}

and with the class variable closedFlag declared as:
private final AtomicBoolean closedFlag = new AtomicBoolean(false);

which of course is thread-safe.

So, using a single instance and invoking only the various flavours of the
target() method seems to be safe. Wouldn't be so sure about the various
provider registration methods though...

Savvas

On 28 October 2014 12:40, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:

 Savvas,

 I have no evidence whatsoever. :)

 But it seems strange to me that if implementations should be thread-safe,
 this information is not written in bold in the javadocs :) Or it could be
 decision left up to vendors to decide.

 Anyway, if it is indeed thread-safe it makes things a lot easier since a
 single instance can be used throughout the app.

 On Tue, Oct 28, 2014 at 7:50 AM, Savvas Andreas Moysidis 
 savvas.andreas.moysi...@gmail.com wrote:

 Hi Rodrigo,

 That's precisely what my example above showcases. :)

 It may well be the case that the Client class is not thread-safe indeed
 but can I ask though what evidence have you got to believe that?

 Perhaps taking a look at the source code would clarify things? (or a
 commiter following this thread could verify instead)

 On 28 October 2014 01:23, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:

 if Client implementations are thread-safe, shouldn't a single instance
 be enough? Thus having a single instance for the whole app would do it. I
 don't think it's the case.

 On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis 
 savvas.andreas.moysi...@gmail.com wrote:

 The question, I suppose, is whether Client implementations are
 thread-safe or not which is something that is not stipulated by the
 interface contract.

 If they are(something which is sort of implied by the javadoc), then
 you could maybe declare and use a single instance like the following? (in a
 JavaEE context)

 @Singleton
 public class SomeService {

 private Client restClient;

 @PostConstruct
 private void init() {
 restClient = ClientBuilder.newClient();
 }

 .
 // Use restClient object here

 .

 @PreDestroy
 private void cleanUp() {
 restClient.close();
 }
 }

 On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:

 I'd be interested in hearing what common practice is regarding pooled
 Client objects, too. Do people use the Apache objects pool library? That's
 the only option I've heard of. Are there other mainstream solutions?

 Mario

  On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
 wrote:
 
  [...]

  How should we implement a pool of Client objects in this scenario?
 Is there a common solution?
 
  Regards,
  Rodrigo Uchoa.



 --
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users




 --

 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users




 --

 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users




 --

 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists

Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?

[Savvas Andreas Moysidis]

The question, I suppose, is whether Client implementations are thread-safe
or not which is something that is not stipulated by the interface contract.

If they are(something which is sort of implied by the javadoc), then you
could maybe declare and use a single instance like the following? (in a
JavaEE context)

@Singleton
public class SomeService {

private Client restClient;

@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.

@PreDestroy
private void cleanUp() {
restClient.close();
}
}

On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:

 I'd be interested in hearing what common practice is regarding pooled
 Client objects, too. Do people use the Apache objects pool library? That's
 the only option I've heard of. Are there other mainstream solutions?

 Mario

  On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
 wrote:
 
  [...]

  How should we implement a pool of Client objects in this scenario? Is
 there a common solution?
 
  Regards,
  Rodrigo Uchoa.



 --
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users

--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users