Menu
▾
▴
resteasy-users — A general discussion list for the projects end users of RESTEasy.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2010 |
Jan
(1) |
Feb
(2) |
Mar
(6) |
Apr
(5) |
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(6) |
Dec
(4) |
| 2011 |
Jan
(4) |
Feb
(18) |
Mar
(9) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(11) |
Aug
(7) |
Sep
(12) |
Oct
(28) |
Nov
(12) |
Dec
(11) |
| 2012 |
Jan
(20) |
Feb
(21) |
Mar
(19) |
Apr
(12) |
May
(44) |
Jun
(23) |
Jul
(14) |
Aug
(26) |
Sep
(23) |
Oct
(7) |
Nov
(42) |
Dec
(15) |
| 2013 |
Jan
(62) |
Feb
(20) |
Mar
(14) |
Apr
(52) |
May
(29) |
Jun
(46) |
Jul
(20) |
Aug
(55) |
Sep
(27) |
Oct
(53) |
Nov
(29) |
Dec
(21) |
| 2014 |
Jan
(35) |
Feb
(44) |
Mar
(12) |
Apr
(37) |
May
(24) |
Jun
(17) |
Jul
(13) |
Aug
(1) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
(11) |
Feb
(8) |
Mar
(10) |
Apr
(7) |
May
(17) |
Jun
(11) |
Jul
(13) |
Aug
(14) |
Sep
(6) |
Oct
(3) |
Nov
(7) |
Dec
(3) |
| 2016 |
Jan
(1) |
Feb
(4) |
Mar
(8) |
Apr
(2) |
May
(2) |
Jun
(10) |
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
|
From: Savvas A. M. <sav...@gm...> - 2014-10-28 23:40:33
|
(*) meant to say: "...the method for generating *WebTarget*s"! On 28 October 2014 23:37, Savvas Andreas Moysidis < sav...@gm...> wrote: > > 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 <rod...@gm...> 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 < >> sav...@gm...> 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 <rod...@gm...> 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 < >>>> sav...@gm...> 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 <mar...@gm...> 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 < >>>>>> rod...@gm...> 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 >>>>>> Res...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Resteasy-users mailing list >>>>> Res...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Resteasy-users mailing list >>>> Res...@li... >>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Resteasy-users mailing list >>> Res...@li... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>> >>> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Resteasy-users mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-users >> >> > |
|
From: Savvas A. M. <sav...@gm...> - 2014-10-28 23:37:45
|
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 <rod...@gm...> 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 < > sav...@gm...> 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 <rod...@gm...> 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 < >>> sav...@gm...> 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 <mar...@gm...> 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 <rod...@gm...> >>>>> 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 >>>>> Res...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Resteasy-users mailing list >>>> Res...@li... >>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Resteasy-users mailing list >>> Res...@li... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>> >>> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Resteasy-users mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-users >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users > > |
|
From: Rodrigo U. <rod...@gm...> - 2014-10-28 12:41:03
|
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 <
sav...@gm...> 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 <rod...@gm...> 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 <
>> sav...@gm...> 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 <mar...@gm...> 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 <rod...@gm...>
>>>> 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
>>>> Res...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Resteasy-users mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
|
|
From: Savvas A. M. <sav...@gm...> - 2014-10-28 09:50:50
|
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 <rod...@gm...> 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 <
> sav...@gm...> 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 <mar...@gm...> 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 <rod...@gm...>
>>> 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
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
|
|
From: Rodrigo U. <rod...@gm...> - 2014-10-28 01:23:21
|
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 <
sav...@gm...> 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 <mar...@gm...> 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 <rod...@gm...>
>> 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
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
|
|
From: Savvas A. M. <sav...@gm...> - 2014-10-28 00:21:24
|
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 <mar...@gm...> 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 <rod...@gm...>
> 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
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
|
|
From: Mario D. <mar...@gm...> - 2014-10-27 23:24:54
|
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 <rod...@gm...> wrote: > > [...] > How should we implement a pool of Client objects in this scenario? Is there a common solution? > > Regards, > Rodrigo Uchoa. |
|
From: Rodrigo U. <rod...@gm...> - 2014-10-27 16:39:49
|
Hi guys!
I have a client web application that uses the Client API to make REST calls
to a REST business layer.
The javax.ws.rs.client.Client docs clearly states that Client objects are
expensive to create and dispose, and only a small number of them should be
created, which makes me think they should be pooled somehow.
Our initial thought was to instantiate and then close every Client object
we use, making code like this:
public void doSomething() {
Client client = ClientBuilder.newClient();
//do a bunch of stuff here
client.close();
}
Every method that needs to invoke REST services are coded like the example
above. That means every time a client web request comes in, a new Client
object is created and then closed. The exact opposite of what the docs
advises us to do.
How should we implement a pool of Client objects in this scenario? Is there
a common solution?
Regards,
Rodrigo Uchoa.
|
|
From: Danilo C. M. <dco...@gm...> - 2014-09-20 17:22:33
|
Hello there,
I am sorry if this message is a duplicate, but I think there was an issue
with the delivery of the first one. I am trying to follow an example from
RESTEasy's documentation (Chapter 8. Linking resources) in order to have
Atom links injected directly into my entity objects, but I simply can't get
it to work when I try to return JSON instead of XML. (I believe that I have
correctly forced the use of Jettison as per RESTEasy's documentation.)
Below are the pertinent code snippets:
ArticleResource.java
@Path("/article")
> public class ArticleResource {
>
> @Inject
> ArticleService articleService; // it just returns fake entities
>
> @AddLinks
> @LinkResource(value = Article.class)
> @GET
> @Path("{id}")
> @Produces("application/json")
> public Response getArticle(@PathParam("id") String id) throws Exception
> {
> Article article = articleService.getArticle(id);
> return Response.status(200).entity(article).build();
> }
> @LinkResource(value = Article.class)
> @POST
> @Produces("application/json")
> public Response postArticle() throws Exception {
> Article article = articleService.createArticle(new Article());
> return Response.status(201).entity(article).build();
> }
> }
Article.java
@Mapped(namespaceMap = @XmlNsMap(jsonName = "atom", namespace = "
> http://www.w3.org/2005/Atom
> "))
> @XmlRootElement(name = "article")
> @XmlAccessorType(XmlAccessType.NONE)
> public class Article {
>
> @XmlID
> @XmlAttribute
> private String id;
> @XmlElementRef
> private RESTServiceDiscovery rest;
> }
And here are the responses I get when I set all the @Produces in
ArticleResource.java to "application/xml"
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
> <article id="138">
> <atom:link rel="self" href="
> http://localhost:8080/cad-jax-rs/rest/article/138" />
> <atom:link rel="add" href="http://localhost:8080/cad-jax-rs/rest/article"
> />
> </article>
and "application/json"
{
> "id":"138",
> "RESTServiceDiscovery":null
> }
Regarding my Maven pom.xml file, I believe that the important bits are the
following:
<dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-jaxrs</artifactId>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-links</artifactId>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-jaxb-provider</artifactId>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-jettison-provider</artifactId>
> <scope>provided</scope>
> </dependency>
The version numbers are being imported from the resteasy-bom artifact
(3.0.8.Final) that is not listed above.
Could anyone please try to spot any obvious errors or provide any guidance
at all? I would greatly appreciate any help on this matter. In case further
information is required, I will gladly provide it.
Thank you all in advance.
Respectfully yours,
Danilo Cominotti Marques
P.S.: In case I wanted to use Jackson 2 instead of Jettison, would it be
completely impossible to get automatic Atom links injection to work?
|
|
From: Danilo C. M. <dco...@gm...> - 2014-09-20 15:40:17
|
Hello there,
I am trying to follow an example from RESTEasy's documentation (Chapter 8.
Linking resources) in order to have Atom links injected directly into my
entity objects, but I simply can't get it to work when I try to return JSON
instead of XML. (I believe that I have correctly forced the use of Jettison
as per RESTEasy's documentation.) Below are the pertinent code snippets:
ArticleResource.java
@Path("/article")
> public class ArticleResource {
>
> @Inject
> ArticleService articleService; // it just returns fake entities
>
> @AddLinks
> @LinkResource(value = Article.class)
> @GET
> @Path("{id}")
> @Produces("application/json")
> public Response getArticle(@PathParam("id") String id) throws Exception
> {
> Article article = articleService.getArticle(id);
> return Response.status(200).entity(article).build();
> }
> @LinkResource(value = Article.class)
> @POST
> @Produces("application/json")
> public Response postArticle() throws Exception {
> Article article = articleService.createArticle(new Article());
> return Response.status(201).entity(article).build();
> }
> }
Article.java
@Mapped(namespaceMap = @XmlNsMap(jsonName = "atom", namespace = "
> http://www.w3.org/2005/Atom"))
> @XmlRootElement(name = "article")
> @XmlAccessorType(XmlAccessType.NONE)
> public class Article {
>
> @XmlID
> @XmlAttribute
> private String id;
> @XmlElementRef
> private RESTServiceDiscovery rest;
> }
And here are the responses I get when I set all the @Produces in
ArticleResource.java to "application/xml"
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
> <article id="138">
> <atom:link rel="self" href="
> http://localhost:8080/cad-jax-rs/rest/article/138" />
> <atom:link rel="add" href="http://localhost:8080/cad-jax-rs/rest/article"
> />
> </article>
and "application/json"
{
> "id":"138",
> "RESTServiceDiscovery":null
> }
Regarding my Maven pom.xml file, I believe that the important bits are the
following:
<dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-jaxrs</artifactId>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-links</artifactId>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-jaxb-provider</artifactId>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-jettison-provider</artifactId>
> <scope>provided</scope>
> </dependency>
The version numbers are being imported from the resteasy-bom artifact
(3.0.8.Final) that is not listed above.
Could anyone please try to spot any obvious errors or provide any guidance
at all? I would greatly appreciate any help on this matter. In case further
information is required, I will gladly provide it.
Thank you all in advance.
Respectfully yours,
Danilo Cominotti Marques
P.S.: In case I wanted to use Jackson 2 instead of Jettison, would it be
completely impossible to get automatic Atom links injection to work?
|
|
From: Bill B. <bb...@re...> - 2014-09-17 18:45:27
|
See here for details: http://bill.burkecentral.com/2014/09/17/resteasy-3-0-9-released/ -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2014-09-12 14:51:41
|
Master should be buildable now. Please don't submit a PR without doing a full successful build. Between Keycloak, conferences, and summer vacations, I should be able to spend more time on Resteasy now. Much thanks to Ron and the community in holding things together while I was busy. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Savvas A. M. <sav...@gm...> - 2014-08-15 21:54:51
|
Hello There, I've come across an issue with the "Last-Modified" header that gets sent with a response. More specifically, I have a resource method that is setting a "Last-Modified:" header in the following way: ................................................................................................................................. return builder.lastModified(myEntity.getModificationDate()).links(selfLink).build(); This is all fine and I can see in the response the the header is set indeed: Last-Modified: 2014-08-15 22:24:20.0 And then I have a second method which is testing for preconditions as in: ResponseBuilder builder = request.evaluatePreconditions(modificationDate); But when this method runs I am getting a parse exception: ....................................................................................................................................................................................................... "Caused by: org.jboss.resteasy.util.DateUtil$DateParseException: Unable to parse the date 2014-08-15 22:24:20.0" I understand I can implement my own ParamConverter<Date> perhaps(?), but is the provider meant to be using the same format for setting and parsing this header? Any thoughts? I am using the resteasy provider that comes with WildFly 8.0.0-Final (I think this is version 3.0.6.Final) Thanks, Savvas |
|
From: Scot F. <sf...@re...> - 2014-07-18 16:29:58
|
All,
I found a super easy solution to Tom's question...
In the client, depending on how (and if) you use ProxyFactory (this assumes its being used), all one needs do is define their own messsage reader and viola, you can manage the unmarshalling. As a simple example, let's say you have a resource Foo:
public class MyReader implements MessageBodyReader<Object> {
@Override
public boolean isReadable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType) {
return // Determine if you can read this type...maybe something like "return type == SomeClassIknow.class";
}
@Override
public Object readFrom(Class<Object> type, Type genericType, Annotation[] annotations, MediaType mediaType, MultivaluedMap<String, String> httpHeaders, InputStream entityStream) throws IOException, WebApplicationException {
try {
return // Do your unmarshalling... Something like:
// Create your unmarshaller named "u"
// return u.unmarshal(entityStream, type);
} catch (JAXBException ex) {
ex.printStackTrace(System.err);
throw new RuntimeException(ex);
}
}
}
public class FooFactory {
static {
// This is the magic...
ResteasyProviderFactory.getInstance().addMessageBodyReader(MyReader.class);
}
public Foo getFoo(final String uri) {
return ProxyFactory.create(Foo.class, uri, ...);
}
}
Above, the assumption is one isn't presenting a RestEasyProviderFactory to ProxyFactory.create(...) but instead using the default one as that in ProxyFactory - namely ResteasyProviderFactory.getInstance()...
Now when one makes calls to the Foo resource, the custom message reader will be used and will unmarshall appropriately for you :)
Flossy
----- Original Message -----
> From: "Tom Butt" <tb...@re...>
> To: "John D. Ament" <joh...@gm...>
> Cc: res...@li...
> Sent: Tuesday, July 15, 2014 12:56:05 PM
> Subject: Re: [Resteasy-users] media type and versioning
>
> John,
> Right, but when you use application/xml it's NOT triggered, and there's
> the root element <foo>, so it doesn't have a specific TYPE to unmarshall
> it to. This ends up meaning that it *might* pick FooType or
> VersionedFooType. I'm currently testing the concept of accepting
> application/xml in my MessageBodyReader and pivoting in the "isReadable"
> method on the media type and the *type*.
> -Tom
>
> ----- Original Message -----
> From: "John D. Ament" <joh...@gm...>
> To: "Tom Butt" <tb...@re...>
> Cc: res...@li...
> Sent: Tuesday, July 15, 2014 10:37:47 AM
> Subject: Re: [Resteasy-users] media type and versioning
>
> Tom,
>
> Is your MessageBodyReader/Writer annotated with @Produces/@Consumes? If so,
> then it should only be triggered for those types.
>
> John
>
>
> On Tue, Jul 15, 2014 at 12:31 PM, Tom Butt <tb...@re...> wrote:
>
> > I currently have a resource that consumes "application/xml", but I'm
> > moving to custom media types for versioning. So, the issue happens in
> > marshal/unmarshal as the root element is the same for both. I have a
> > messagebodyreader/writer to handle the custom media types in place, and it
> > works well. My concern is that I don't want my messagebodyreader/writer to
> > consume/produce application/xml.
> >
> > So, I let's say I have an endpoint defined as http://something.com/foo
> >
> > it accepts application/xml and application/vnd.tom.foo+xml
> > When you use application/xml, you expect a "FooType"
> > When you use application/vnd.tom.foo+xml, you expect a "VersionedFooType"
> >
> > Both are in the same namespace and both have the same root element <foo>.
> >
> > IF you use application/vnd.tom.foo+xml, all is peachy. We hit the
> > messagebodyreader, it unmarshalls a VersionedFooType and life is good.
> >
> > If, however, you use application/xml, we don't get into the
> > messagebodyreader (as I really don't want EVERY call to have to hit this),
> > and so what it unmarshalls is anybody's guess (quite often it's
> > VersionedFooType rather than the previously used FooType.)
> >
> > The solutions that have come to mind are
> > 1. Allow the MessageBodyReader to consume/produce application/xml, and
> > then I can perform a check in the readFrom or writeTo on the *Type*. If
> > it's "FooType" and "application/xml" I can handle it here. This feels a
> > bit off to me as I'll have every resource going through this provider, and
> > this edge case for a non-custom media type (not even sure this works, but
> > it seems that it would.)
> > 2. Change the root element of the VersionedFooType to be "<versionedFoo>"
> > rather than "<foo>"
> >
> >
> > The real crime here might be the mixture of custom media types with
> > non-custom media types, but it seems this is a natural progression if one
> > was to move from a non-versioned API to a versioned one using custom media
> > types. Maybe I'm overlooking something really simple here, and I hope
> > that's the case!
> >
> > Thanks in advance!
> > -Tom
> >
> >
> > ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > _______________________________________________
> > Resteasy-users mailing list
> > Res...@li...
> > https://lists.sourceforge.net/lists/listinfo/resteasy-users
> >
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
--
Make It So Number One
|
|
From: Tom B. <tb...@re...> - 2014-07-15 16:56:13
|
John,
Right, but when you use application/xml it's NOT triggered, and there's the root element <foo>, so it doesn't have a specific TYPE to unmarshall it to. This ends up meaning that it *might* pick FooType or VersionedFooType. I'm currently testing the concept of accepting application/xml in my MessageBodyReader and pivoting in the "isReadable" method on the media type and the *type*.
-Tom
----- Original Message -----
From: "John D. Ament" <joh...@gm...>
To: "Tom Butt" <tb...@re...>
Cc: res...@li...
Sent: Tuesday, July 15, 2014 10:37:47 AM
Subject: Re: [Resteasy-users] media type and versioning
Tom,
Is your MessageBodyReader/Writer annotated with @Produces/@Consumes? If so,
then it should only be triggered for those types.
John
On Tue, Jul 15, 2014 at 12:31 PM, Tom Butt <tb...@re...> wrote:
> I currently have a resource that consumes "application/xml", but I'm
> moving to custom media types for versioning. So, the issue happens in
> marshal/unmarshal as the root element is the same for both. I have a
> messagebodyreader/writer to handle the custom media types in place, and it
> works well. My concern is that I don't want my messagebodyreader/writer to
> consume/produce application/xml.
>
> So, I let's say I have an endpoint defined as http://something.com/foo
>
> it accepts application/xml and application/vnd.tom.foo+xml
> When you use application/xml, you expect a "FooType"
> When you use application/vnd.tom.foo+xml, you expect a "VersionedFooType"
>
> Both are in the same namespace and both have the same root element <foo>.
>
> IF you use application/vnd.tom.foo+xml, all is peachy. We hit the
> messagebodyreader, it unmarshalls a VersionedFooType and life is good.
>
> If, however, you use application/xml, we don't get into the
> messagebodyreader (as I really don't want EVERY call to have to hit this),
> and so what it unmarshalls is anybody's guess (quite often it's
> VersionedFooType rather than the previously used FooType.)
>
> The solutions that have come to mind are
> 1. Allow the MessageBodyReader to consume/produce application/xml, and
> then I can perform a check in the readFrom or writeTo on the *Type*. If
> it's "FooType" and "application/xml" I can handle it here. This feels a
> bit off to me as I'll have every resource going through this provider, and
> this edge case for a non-custom media type (not even sure this works, but
> it seems that it would.)
> 2. Change the root element of the VersionedFooType to be "<versionedFoo>"
> rather than "<foo>"
>
>
> The real crime here might be the mixture of custom media types with
> non-custom media types, but it seems this is a natural progression if one
> was to move from a non-versioned API to a versioned one using custom media
> types. Maybe I'm overlooking something really simple here, and I hope
> that's the case!
>
> Thanks in advance!
> -Tom
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
|
|
From: John D. A. <joh...@gm...> - 2014-07-15 16:37:56
|
Tom, Is your MessageBodyReader/Writer annotated with @Produces/@Consumes? If so, then it should only be triggered for those types. John On Tue, Jul 15, 2014 at 12:31 PM, Tom Butt <tb...@re...> wrote: > I currently have a resource that consumes "application/xml", but I'm > moving to custom media types for versioning. So, the issue happens in > marshal/unmarshal as the root element is the same for both. I have a > messagebodyreader/writer to handle the custom media types in place, and it > works well. My concern is that I don't want my messagebodyreader/writer to > consume/produce application/xml. > > So, I let's say I have an endpoint defined as http://something.com/foo > > it accepts application/xml and application/vnd.tom.foo+xml > When you use application/xml, you expect a "FooType" > When you use application/vnd.tom.foo+xml, you expect a "VersionedFooType" > > Both are in the same namespace and both have the same root element <foo>. > > IF you use application/vnd.tom.foo+xml, all is peachy. We hit the > messagebodyreader, it unmarshalls a VersionedFooType and life is good. > > If, however, you use application/xml, we don't get into the > messagebodyreader (as I really don't want EVERY call to have to hit this), > and so what it unmarshalls is anybody's guess (quite often it's > VersionedFooType rather than the previously used FooType.) > > The solutions that have come to mind are > 1. Allow the MessageBodyReader to consume/produce application/xml, and > then I can perform a check in the readFrom or writeTo on the *Type*. If > it's "FooType" and "application/xml" I can handle it here. This feels a > bit off to me as I'll have every resource going through this provider, and > this edge case for a non-custom media type (not even sure this works, but > it seems that it would.) > 2. Change the root element of the VersionedFooType to be "<versionedFoo>" > rather than "<foo>" > > > The real crime here might be the mixture of custom media types with > non-custom media types, but it seems this is a natural progression if one > was to move from a non-versioned API to a versioned one using custom media > types. Maybe I'm overlooking something really simple here, and I hope > that's the case! > > Thanks in advance! > -Tom > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users > |
|
From: Tom B. <tb...@re...> - 2014-07-15 16:31:19
|
I currently have a resource that consumes "application/xml", but I'm moving to custom media types for versioning. So, the issue happens in marshal/unmarshal as the root element is the same for both. I have a messagebodyreader/writer to handle the custom media types in place, and it works well. My concern is that I don't want my messagebodyreader/writer to consume/produce application/xml. So, I let's say I have an endpoint defined as http://something.com/foo it accepts application/xml and application/vnd.tom.foo+xml When you use application/xml, you expect a "FooType" When you use application/vnd.tom.foo+xml, you expect a "VersionedFooType" Both are in the same namespace and both have the same root element <foo>. IF you use application/vnd.tom.foo+xml, all is peachy. We hit the messagebodyreader, it unmarshalls a VersionedFooType and life is good. If, however, you use application/xml, we don't get into the messagebodyreader (as I really don't want EVERY call to have to hit this), and so what it unmarshalls is anybody's guess (quite often it's VersionedFooType rather than the previously used FooType.) The solutions that have come to mind are 1. Allow the MessageBodyReader to consume/produce application/xml, and then I can perform a check in the readFrom or writeTo on the *Type*. If it's "FooType" and "application/xml" I can handle it here. This feels a bit off to me as I'll have every resource going through this provider, and this edge case for a non-custom media type (not even sure this works, but it seems that it would.) 2. Change the root element of the VersionedFooType to be "<versionedFoo>" rather than "<foo>" The real crime here might be the mixture of custom media types with non-custom media types, but it seems this is a natural progression if one was to move from a non-versioned API to a versioned one using custom media types. Maybe I'm overlooking something really simple here, and I hope that's the case! Thanks in advance! -Tom |
|
From: sdoca s. <sd...@sh...> - 2014-07-10 14:55:29
|
Thanks! (sorry for the late reply) Shelli ----- Original Message ----- From: "William Antônio Siqueira" <wil...@gm...> To: "sdoca sdoca" <sd...@sh...> Cc: res...@li... Sent: Monday, July 7, 2014 11:24:13 AM Subject: Re: [Resteasy-users] 2.3.7.Final - JAX-RS Version? JAX-RS 1.1 and I know because AS 7(EAP 6) implements JEE 6 and it has RESTEasy 2.3.7 ;) -- William Antônio Siqueira Java Support Analyst http://fxapps.blogspot.com http://www.williamantonio.wordpress.com http://williamprogrammer.com 2014-07-07 14:10 GMT-03:00 sdoca sdoca < sd...@sh... > : Hi, This may seem like an easy question, but I don't know where to find the answer. Which version of JAX-RS does RESTEasy 2.3.7 implement? Thanks! ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Resteasy-users mailing list Res...@li... https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: William A. S. <wil...@gm...> - 2014-07-07 17:24:41
|
JAX-RS 1.1 and I know because AS 7(EAP 6) implements JEE 6 and it has RESTEasy 2.3.7 ;) -- *William Antônio Siqueira* *Java Support Analyst* *http://fxapps.blogspot.com <http://fxapps.blogspot.com>* *http://www.williamantonio.wordpress.com <http://www.williamantonio.wordpress.com>* *http://williamprogrammer.com <http://williamprogrammer.com>* 2014-07-07 14:10 GMT-03:00 sdoca sdoca <sd...@sh...>: > Hi, > > This may seem like an easy question, but I don't know where to find the > answer. Which version of JAX-RS does RESTEasy 2.3.7 implement? > > Thanks! > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users > |
|
From: sdoca s. <sd...@sh...> - 2014-07-07 17:10:55
|
Hi, This may seem like an easy question, but I don't know where to find the answer. Which version of JAX-RS does RESTEasy 2.3.7 implement? Thanks! |
|
From: Stanley S. <sta...@ya...> - 2014-07-04 07:53:34
|
Hello, I know in RESTEasy, custom exceptions have to extend ResponseProcessingException to be able to be thrown from ClientResponseFilter on the client side. However, that doesn't work for us. We have a lot of exceptions we throw from the provider side and there is no way we go through all of them and change them to extend ResponseProcessingException. Even if we had the time, we have to introduce a dependency on jaxrs for the package with our business exceptions and we don't want that. We want the framework to be entirely transparent and honor our custom client response filter when we throw our business exceptions. Is there any way to throw a custom exception from our ClientResponseFilter or any other idea in such a way that RESTEasy will let it propagate to the caller without any changes? If not, why RESTEasy doesn't enhance the framework to support this kind of behavior? It seems like an important feature to have. Thanks, Stanley Stanev |
|
From: Stanley S. <sta...@ya...> - 2014-07-04 07:52:33
|
Hello, I know in RESTEasy, custom exceptions have to extend ResponseProcessingException to be able to be thrown from ClientResponseFilter on the client side. However, that doesn't work for us. We have a lot of exceptions we throw from the provider side and there is no way we go through all of them and change them to extend ResponseProcessingException. Even if we had the time, we have to introduce a dependency on jaxrs for the package with our business exceptions and we don't want that. We want the framework to be entirely transparent and honor our custom client response filter when we throw our business exceptions. Is there any way to throw a custom exception from our ClientResponseFilter or any other idea in such a way that RESTEasy will let it propagate to the caller without any changes? If not, why RESTEasy doesn't enhance the framework to support this kind of behavior? It seems like an important feature to have. Thanks, Stanley Stanev |
|
From: Till W. <ti...@tw...> - 2014-07-02 07:39:12
|
Can anybody help here? May be a simple example? Best regards, Till On 12.06.14 10:08, ti...@tw... wrote: > Hello, > > Can anyone tell me how to use the XmlNamespacePrefixMapper included in RestEasy? > I tried different approaches, but it did not work and documentation seem to be > very rare... > > Anyone having any experiance with altering the namespace prefixes for the > resulting XML from a ReatEasy call? > > Best Regards, > Till |
|
From: Peter W. <me...@pe...> - 2014-07-01 14:14:38
|
Hi Bill, Thanks, that did the trick -- Peter Wright On 1 July 2014 at 13:34:45, Bill Burke (bb...@re...) wrote: If you write a ClientResponseFilter you can do the processing there. The only thing is is that your exceptions need to extend ResponseProcessingException or they will be wrapped in one. On 7/1/2014 4:19 AM, Peter Wright wrote: > Hi Bill, > > I did, yes - this is the code: > > https://github.com/petergeneric/stdlib/blob/e09fc586edbee4d7ff3b5040742726e4bb9a595c/guice/restclient/src/main/java/com/peterphi/std/guice/restclient/resteasy/impl/ResteasyClientErrorInterceptor.java > > On 6/30/2014 5:17 PM, Bill Burke wrote: >> What did you do in your clienterrorinterceptor? Convert it to an exception? >> >> >> On 6/30/2014 12:48 PM, Peter Wright wrote: >>> Hi, >>> >>> I’ve been using the (now deprecated) proxy client since resteasy 2. I’m >>> using 3.0.7.Final and am wanting to use WebTarget to build the dynamic >>> proxy using ResteasyClient.target(url).proxy(interface). >>> >>> I use a server-side ExceptionMapper that produces a structured >>> representation of the exception which is then used by the client to >>> produce more descriptive client-side errors about what failed on the >>> server, which server and why. I had been using ClientErrorInterceptor >>> for this, but I see that the new dynamic proxy client no longer uses >>> ClientErrorInterceptor… is there a way to do this in the new dynamic >>> proxy client? I’ve tried using a ReaderInterceptor and DynamicFeature >>> but it doesn’t seem to get called when (for example) a 404 error is >>> returned. >>> >>> Any pointers would be much appreciated. >>> >>> -- >>> Peter >>> >>> >>> ------------------------------------------------------------------------------ >>> Open source business process management suite built on Java and Eclipse >>> Turn processes into business applications with Bonita BPM Community Edition >>> Quickly connect people, data, and systems into organized workflows >>> Winner of BOSSIE, CODIE, OW2 and Gartner awards >>> http://p.sf.net/sfu/Bonitasoft >>> >>> >>> >>> _______________________________________________ >>> Resteasy-users mailing list >>> Resteasy-users@... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > >> > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Resteasy-users mailing list Res...@li... https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: Bill B. <bb...@re...> - 2014-07-01 12:34:40
|
If you write a ClientResponseFilter you can do the processing there. The only thing is is that your exceptions need to extend ResponseProcessingException or they will be wrapped in one. On 7/1/2014 4:19 AM, Peter Wright wrote: > Hi Bill, > > I did, yes - this is the code: > > https://github.com/petergeneric/stdlib/blob/e09fc586edbee4d7ff3b5040742726e4bb9a595c/guice/restclient/src/main/java/com/peterphi/std/guice/restclient/resteasy/impl/ResteasyClientErrorInterceptor.java > > On 6/30/2014 5:17 PM, Bill Burke wrote: >> What did you do in your clienterrorinterceptor? Convert it to an exception? >> >> >> On 6/30/2014 12:48 PM, Peter Wright wrote: >>> Hi, >>> >>> I’ve been using the (now deprecated) proxy client since resteasy 2. I’m >>> using 3.0.7.Final and am wanting to use WebTarget to build the dynamic >>> proxy using ResteasyClient.target(url).proxy(interface). >>> >>> I use a server-side ExceptionMapper that produces a structured >>> representation of the exception which is then used by the client to >>> produce more descriptive client-side errors about what failed on the >>> server, which server and why. I had been using ClientErrorInterceptor >>> for this, but I see that the new dynamic proxy client no longer uses >>> ClientErrorInterceptor… is there a way to do this in the new dynamic >>> proxy client? I’ve tried using a ReaderInterceptor and DynamicFeature >>> but it doesn’t seem to get called when (for example) a 404 error is >>> returned. >>> >>> Any pointers would be much appreciated. >>> >>> -- >>> Peter >>> >>> >>> ------------------------------------------------------------------------------ >>> Open source business process management suite built on Java and Eclipse >>> Turn processes into business applications with Bonita BPM Community Edition >>> Quickly connect people, data, and systems into organized workflows >>> Winner of BOSSIE, CODIE, OW2 and Gartner awards >>> http://p.sf.net/sfu/Bonitasoft >>> >>> >>> >>> _______________________________________________ >>> Resteasy-users mailing list >>> Resteasy-users@... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > >> > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
10 messages has been excluded from this view by a project administrator.
