Re: Handling exceptions/errors when using Restlet for Client and Server....

[Richard Berger]

Excellent points - I didn't quite realize that the Status was restlet
specific and now it makes more sense to me that (as you put it) the illusion
isn't extended all the way to Exceptions.  

Thanks for your ongoing assistance and information!
RB

--
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/Handling-exceptions-errors-when-using-Restlet-for-Client-and-Server-tp7578190p7578206.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2984253

Re: Handling exceptions/errors when using Restlet for Client and Server....

[Tim Peierls]

On Wed, Jul 11, 2012 at 8:04 PM, Richard Berger wrote:

> Do you think that this problem has persisted this long due to the lack of
> clients built with Restlet (vs. the much larger number of servers built
> with Restlet)?
>

That's not really a fair question: You're leading the witness, counsel. :-)


The concept of tunneling exception information via the Status is
meaningless unless both client and server are Restlet-based, and one of the
wonderful things about Restlet is that it doesn't impose that kind of
coupling on the developer. Clients can't in general assume a particular
structure of the error response entity; all they can really count on is the
status code and associated reason phrase. If the client has specific
knowledge of how a given server serves its error responses, Restlet has all
the tools necessary to take advantage of that knowledge.

Still, since the client proxying machinery can do such a neat job of
creating the illusion of a remote Java call in the case that you *do* have
Restlet on both sides, it seems a shame that the illusion doesn't
extend quite as neatly to exceptions. There might be an issue already to
address this; I can't find it just at the moment.


Thanks again for providing the workaround!!
>

You're welcome!

--tim

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2984237

Re: Handling exceptions/errors when using Restlet for Client and Server....

[Richard Berger]

Tim:

Thanks for the update to your code and for the explanation.  While my code
is a little different than yours, sending along a StringRepresentation of
the error in the response's entity and then having the client look in the
entity in case of an error worked just fine for me.

Would be much cleaner to just be able to use status.getDescription() but I
guess that will have to wait for the fixes to ClientInvocationHandler.

Do you think that this problem has persisted this long due to the lack of
clients built with Restlet (vs. the much larger number of servers built
with Restlet)?

Thanks again for providing the workaround!!
RB

On Wed, Jul 11, 2012 at 1:52 PM, Tim Peierls [via Restlet Discuss] <
ml-node+s1400322n757820...@n2.nabble.com> wrote:

> I've updated the snippet in https://pastebin.com/3nzsjFi1 to demonstrate
> a potential workaround using a custom StatusService and special client-side
> handling. This example just deals with a StringRepresentation to pass a
> custom error status description, but the technique could be generalized to
> use an arbitrary custom error representation.
>
> The use of the client proxy mechanism is orthogonal to this workaround,
> but since this snippet was originally about how ResourceExceptions passed
> through this mechanism don't preserve full error information, I've kept it
> in.
>
> The heart of the problem, as I see it, is that the ClientInvocationHandler
> throws away important information when handling errors. Until that's
> changed, the best you can do is to explicitly manage the error entity, as
> in the workaround in the snippet. It's not pretty, but it works.
>
> --tim
>
> On Tue, Jul 10, 2012 at 8:36 PM, Richard Berger <[hidden 
> email]
> > wrote:
>
>> And one further note, wrapping the client resource does not seem to
>> change the results.
>>
>> That is to say, going from:
>>   ClientResource commitsResource = new ClientResource(getContext(),
>> commitsRef);
>>   commitsRep = commitsResource.get();
>>
>> To:
>> ClientResource clientResource = new ClientResource(commitsRef);
>> CommitmentsResource commitsResource =
>> clientResource.wrap(CommitmentsResource.class);
>> Representation commitsRep = null;
>> commitsRep = commitsResource.represent();
>>
>> Changes nothing
>> RB
>>
>> On Tue, Jul 10, 2012 at 4:22 PM, Richard Berger <[hidden 
>> email]
>> > wrote:
>>
>>> Yes, I only see this problem when I go through my Restlet client, not
>>> when using a browser.   In order to make sure the API I am developing is
>>> usable by real client developers, I figured I should also build a client.
>>>  I chose Restlet as the technology for that client - perhaps that wasn't
>>> the best possible choice (if no one else does that).
>>>
>>> Thanks for the response...
>>> RB
>>>
>>>
>>> On Tue, Jul 10, 2012 at 2:09 PM, Bjorn Roche [via Restlet Discuss] <[hidden
>>> email] > wrote:
>>>
 I can't help you directly, but I can say that I use restlet server (but
 not client) and I am pretty sure I DON'T have this problem. Is this a bug
 in the client that it can't access the http status message? That is what
 I'm gathering from the thread you linked as well.

 bjorn

 On Jul 10, 2012, at 1:18 PM, Richard Berger wrote:

 > My question is similar to that raised at:
 >
 http://restlet-discuss.1400322.n2.nabble.com/Sending-server-side-exceptions-error-codes-back-to-client-td7219795.html#a7229629
 >
 http://restlet-discuss.1400322.n2.nabble.com/Sending-server-side-exceptions-error-codes-back-to-client-td7219795.html#a7229629
 > , but since that has not been answered and this seems like a really
 basic

 > issue, I thought I would try posting again.
 >
 > The question is simply this - how to get the details of an
 error/exception
 > that occurs on the Restlet server back to my Restlet client?
 >
 > I can see how to do this if my client were just a browser (I could
 construct
 > an HTML page on the server and return it).
 >
 > I thought that it would be pretty simple - set the Status code and
 Status
 > description.  But as the discussion above points out, that doesn't
 work.
 >
 > I then thought that I could just set the Status code and send back a
 String
 > Representation of the error message.  But that doesn't work either.
  In
 > particular, if I have:
 >  msg = "error xyz occurred";
 >  this.setStatus(Status.SERVER_ERROR_INTERNAL, msg);
 >  StringRepresentation result = new StringRepresentation(msg,
 > MediaType.TEXT_PLAIN);
 >  return result;
 > The client side call:
 >  commitsRep = commitsResource.get();
 > Sets commitsRep == null (!).  Note: it is only set to null when the
 status
 > != 200.
 >
>>>

Re: External JAXB Context resolver

[Bhagyashree Bhati]

Thanks for the quick response. So setting the context factory with
jaxb.properties does work. But I want to initialize my own JaxbContext and
tell restlet to use that context. Instead of using the context instanciated
in JaxbRepresentation class.I want to do this because i want to utilize
MOXy's functionality of being able to create a rendering of an object based
on the Java-types and java-attributes provided with an xml.

--
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/External-JAXB-Context-resolver-tp7578194p7578203.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983991

Re: Handling exceptions/errors when using Restlet for Client and Server....

[Tim Peierls]

I've updated the snippet in https://pastebin.com/3nzsjFi1 to demonstrate a
potential workaround using a custom StatusService and special client-side
handling. This example just deals with a StringRepresentation to pass a
custom error status description, but the technique could be generalized to
use an arbitrary custom error representation.

The use of the client proxy mechanism is orthogonal to this workaround, but
since this snippet was originally about how ResourceExceptions passed
through this mechanism don't preserve full error information, I've kept it
in.

The heart of the problem, as I see it, is that the ClientInvocationHandler
throws away important information when handling errors. Until that's
changed, the best you can do is to explicitly manage the error entity, as
in the workaround in the snippet. It's not pretty, but it works.

--tim

On Tue, Jul 10, 2012 at 8:36 PM, Richard Berger wrote:

> And one further note, wrapping the client resource does not seem to change
> the results.
>
> That is to say, going from:
>   ClientResource commitsResource = new ClientResource(getContext(),
> commitsRef);
>   commitsRep = commitsResource.get();
>
> To:
> ClientResource clientResource = new ClientResource(commitsRef);
> CommitmentsResource commitsResource =
> clientResource.wrap(CommitmentsResource.class);
> Representation commitsRep = null;
> commitsRep = commitsResource.represent();
>
> Changes nothing
> RB
>
> On Tue, Jul 10, 2012 at 4:22 PM, Richard Berger <[hidden 
> email]
> > wrote:
>
>> Yes, I only see this problem when I go through my Restlet client, not
>> when using a browser.   In order to make sure the API I am developing is
>> usable by real client developers, I figured I should also build a client.
>>  I chose Restlet as the technology for that client - perhaps that wasn't
>> the best possible choice (if no one else does that).
>>
>> Thanks for the response...
>> RB
>>
>>
>> On Tue, Jul 10, 2012 at 2:09 PM, Bjorn Roche [via Restlet Discuss] <[hidden
>> email] > wrote:
>>
>>> I can't help you directly, but I can say that I use restlet server (but
>>> not client) and I am pretty sure I DON'T have this problem. Is this a bug
>>> in the client that it can't access the http status message? That is what
>>> I'm gathering from the thread you linked as well.
>>>
>>> bjorn
>>>
>>> On Jul 10, 2012, at 1:18 PM, Richard Berger wrote:
>>>
>>> > My question is similar to that raised at:
>>> >
>>> http://restlet-discuss.1400322.n2.nabble.com/Sending-server-side-exceptions-error-codes-back-to-client-td7219795.html#a7229629
>>> >
>>> http://restlet-discuss.1400322.n2.nabble.com/Sending-server-side-exceptions-error-codes-back-to-client-td7219795.html#a7229629
>>> > , but since that has not been answered and this seems like a really
>>> basic
>>>
>>> > issue, I thought I would try posting again.
>>> >
>>> > The question is simply this - how to get the details of an
>>> error/exception
>>> > that occurs on the Restlet server back to my Restlet client?
>>> >
>>> > I can see how to do this if my client were just a browser (I could
>>> construct
>>> > an HTML page on the server and return it).
>>> >
>>> > I thought that it would be pretty simple - set the Status code and
>>> Status
>>> > description.  But as the discussion above points out, that doesn't
>>> work.
>>> >
>>> > I then thought that I could just set the Status code and send back a
>>> String
>>> > Representation of the error message.  But that doesn't work either.
>>>  In
>>> > particular, if I have:
>>> >  msg = "error xyz occurred";
>>> >  this.setStatus(Status.SERVER_ERROR_INTERNAL, msg);
>>> >  StringRepresentation result = new StringRepresentation(msg,
>>> > MediaType.TEXT_PLAIN);
>>> >  return result;
>>> > The client side call:
>>> >  commitsRep = commitsResource.get();
>>> > Sets commitsRep == null (!).  Note: it is only set to null when the
>>> status
>>> > != 200.
>>> >
>>> > So, I could set the status to 200 and then return the
>>> StringRepresentation
>>> > and then on the client, check to see if I have a StringRepresentation
>>> (which
>>> > would be an error) or some other type (which would be a success).
>>> >
>>> > But surely there has got to be an easier way - what am I missing?  (I
>>> have
>>> > created my own StatusService on the server, I have thrown my own
>>> exception,
>>> > but no joy).
>>> >
>>> > Thanks in advance for any hep - and thanks to Tim P for collecting all
>>> the
>>> > links in the thread above - but those weren't enough for me to work
>>> around
>>> > the problem.
>>> >
>>> > RB
>>> >
>>> > --
>>> > View this message in context:
>>> http://restlet-discuss.1400322.n2.nabble.com/Handling-exceptions-errors-when-using-Restlet-for-Client-and-Server-tp7578190.html
>>> > Sent from the Restlet Discuss mailing list archive at Nabble.com.
>>> >
>>> > ---

Re: Empty server response in 2.1 RC5

[Thierry Boileau]

Hello all,

thanks for mentioning this topic, I've updated the migration guide.

Best regards,
Thierry Boileau


> --tim
>
>
> On Tue, Jul 10, 2012 at 10:41 PM, Robert Brewer  wrote:
>
>> Ioannis Mavroukakis wrote:
>> > Hi Robert, you say "most" so that makes me assume some of them work.
>> > What are the functional differences between the ones that do work and
>> the
>> > ones that don't ?
>>
>> I tracked down the problem to some code I used to add an additional HTTP
>> header. I found the code here:
>>
>>
>> http://blog.arc90.com/2008/09/15/custom-http-response-headers-with-restlet/
>>
>> Here is the offending code:
>>
>> Form responseHeaders =
>> (Form)
>> getResponse().getAttributes().get(HeaderConstants.ATTRIBUTE_HEADERS);
>> if (responseHeaders == null) {
>>   responseHeaders = new Form();
>>   getResponse().getAttributes().put(HeaderConstants.ATTRIBUTE_HEADERS,
>> responseHeaders);
>> }
>> // The following line causes server to send empty replies on Restlet 2.1
>> RC5
>> responseHeaders.add("Access-Control-Allow-Origin", "*");
>>
>> I switched to the method explained here:
>>
>>
>> http://restlet-discuss.1400322.n2.nabble.com/Adding-response-headers-in-restlet-2-1-x-td7240340.html
>>
>> and now things work OK. Should I open a bug for the previous method? At
>> the very least it should be mentioned in the 2.1 migration guide.
>>
>> --
>>
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2982983
>>
>
> It should be mentioned in the migration guide, but it isn't a bug, it's a
change in the method signature.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983719

Potential security issue - fixed in current snapshots.

[Thierry Boileau]

Hello all,

thanks to the contributation of Danny Leshem, a potential vulnerability has
been fixed today in the current snapshot of the 2.0 and 2.1 branches, and
the current master (future release 2.2).
This vulnerability may be exploited when generating the representation of a
failure response.
By default, the status filter generates an HTML representation that
includes data from the error status, especially its description.
In case this description integrates data coming from the client request
(for example a Web form), the older code did not take care to escape the
untrusted data into the HTML content. This could lead to allow the
injection of Javascript code into the error status page.
The fix consists in escaping the data (with
org.restlet.engine.util.StringUtils#htmlEscape) before inserting it into
the HTML content. This fix has been applied to 2.0 and 2.1 branches, and
the current master.

In case you customize the status filter,  we also suggest you to call the
org.restlet.engine.util.StringUtils#htmlEscape method in order to prevent
such potential issue.

Best regards,
Thierry Boileau

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983690

Re: Empty server response in 2.1 RC5

[Tim Peierls]

It should be mentioned in the migration guide, but it isn't a bug, it's a
change in the method signature.

--tim

On Tue, Jul 10, 2012 at 10:41 PM, Robert Brewer  wrote:

> Ioannis Mavroukakis wrote:
> > Hi Robert, you say "most" so that makes me assume some of them work.
> > What are the functional differences between the ones that do work and the
> > ones that don't ?
>
> I tracked down the problem to some code I used to add an additional HTTP
> header. I found the code here:
>
> http://blog.arc90.com/2008/09/15/custom-http-response-headers-with-restlet/
>
> Here is the offending code:
>
> Form responseHeaders =
> (Form)
> getResponse().getAttributes().get(HeaderConstants.ATTRIBUTE_HEADERS);
> if (responseHeaders == null) {
>   responseHeaders = new Form();
>   getResponse().getAttributes().put(HeaderConstants.ATTRIBUTE_HEADERS,
> responseHeaders);
> }
> // The following line causes server to send empty replies on Restlet 2.1
> RC5
> responseHeaders.add("Access-Control-Allow-Origin", "*");
>
> I switched to the method explained here:
>
>
> http://restlet-discuss.1400322.n2.nabble.com/Adding-response-headers-in-restlet-2-1-x-td7240340.html
>
> and now things work OK. Should I open a bug for the previous method? At
> the very least it should be mentioned in the 2.1 migration guide.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2982983
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983458

Re: Restlet thread pool exhaustion

[Ioannis Mavroukakis]

Hi Thierry,

Yes with regards to the jetty extension. I don't use the Restlet client for my 
testing, I use loadUI. 

Thanks,
Ioannis

On 11 Jul 2012, at 08:24, Thierry Boileau  wrote:

> Hello Robert, Ioanis,
> 
> did you try to use the "simple" or "jetty" extensions? They provide a HTTP 
> server connector that we consider to be more stable than the internal HTTP 
> connector which is fine for development but not for production systems. We 
> are on the way to provide a good one with the 2.1 release.
> I guess the same question applies for the client application : you can use 
> the "net" or the "httpclient" extensions. We consider also that these 
> extensions provide a more stable client connector than the internal one.
> 
> Best regards,
> Thierry Boileau
> 
> 
> Yes it was. I let Restlet do all the heavy resource lifting and made sure my 
> domain logic was as clean as possible. I do not recall a single instance 
> where I had to explicitly clean up something belonging to Restlet.
> 
> >> Hi Robert, neat project you have going on there. I will answer a tiny part
> >> of your question, I've load tested 2.1-RC5 heavily and after careful 
> >> tweaking
> >> I've yet to reach the worker limit scenario you detail here.
> >>
> >> My setup is: 150 maxThreads, 10 minThreads, 145 lowThreads, maxQueued 20
> >> but ofc YMMV.
> >
> > Thanks for the reply Ioannis. So did the careful tweaking you did come down 
> > to just those parameters above?
> >
> > --
> > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2977064
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2977951
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983299

Re: Empty server response in 2.1 RC5

[Robert Brewer]

Ioannis Mavroukakis wrote:
> Hi Robert, you say "most" so that makes me assume some of them work.
> What are the functional differences between the ones that do work and the
> ones that don't ?

I tracked down the problem to some code I used to add an additional HTTP 
header. I found the code here:

http://blog.arc90.com/2008/09/15/custom-http-response-headers-with-restlet/

Here is the offending code:

Form responseHeaders =
(Form) 
getResponse().getAttributes().get(HeaderConstants.ATTRIBUTE_HEADERS);
if (responseHeaders == null) {
  responseHeaders = new Form();
  getResponse().getAttributes().put(HeaderConstants.ATTRIBUTE_HEADERS, 
responseHeaders);
}
// The following line causes server to send empty replies on Restlet 2.1 RC5
responseHeaders.add("Access-Control-Allow-Origin", "*");

I switched to the method explained here:

http://restlet-discuss.1400322.n2.nabble.com/Adding-response-headers-in-restlet-2-1-x-td7240340.html

and now things work OK. Should I open a bug for the previous method? At the 
very least it should be mentioned in the 2.1 migration guide.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2982983

Re: External JAXB Context resolver

[Thierry Boileau]

Hello,

from what I see, the standard way of configuring JAXB is made via a
"jaxb.properties" file (generated by MOXy generally) included inside the
bean package.
I contains this kind of property whick refers to MOXy :

javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory


Best regards,
Thierry Boileau

Hi,
>
> I want to configure my Restlet Application to start with a JaxbContext
> provided through configuration. Lets say, I want to use MOXy
> (http://www.eclipse.org/eclipselink/moxy.php) as my Jaxb context resolver.
> Is it possible to configure this externally, say through restlet.xml ?
>
> --
> View this message in context:
> http://restlet-discuss.1400322.n2.nabble.com/External-JAXB-Context-resolver-tp7578194.html
> Sent from the Restlet Discuss mailing list archive at Nabble.com.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983131
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983263

Re: Restlet thread pool exhaustion

[Thierry Boileau]

Hello Robert, Ioanis,

did you try to use the "simple" or "jetty" extensions? They provide a HTTP
server connector that we consider to be more stable than the internal HTTP
connector which is fine for development but not for production systems. We
are on the way to provide a good one with the 2.1 release.
I guess the same question applies for the client application : you can use
the "net" or the "httpclient" extensions. We consider also that these
extensions provide a more stable client connector than the internal one.

Best regards,
Thierry Boileau


Yes it was. I let Restlet do all the heavy resource lifting and made sure
> my domain logic was as clean as possible. I do not recall a single instance
> where I had to explicitly clean up something belonging to Restlet.
>
> >> Hi Robert, neat project you have going on there. I will answer a tiny
> part
> >> of your question, I've load tested 2.1-RC5 heavily and after careful
> tweaking
> >> I've yet to reach the worker limit scenario you detail here.
> >>
> >> My setup is: 150 maxThreads, 10 minThreads, 145 lowThreads, maxQueued 20
> >> but ofc YMMV.
> >
> > Thanks for the reply Ioannis. So did the careful tweaking you did come
> down to just those parameters above?
> >
> > --
> >
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2977064
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2977951
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983229