RE: Client Custom Header
Hi Jean-Philippe,
If your goal is to systematically add cookies to your client requests, you
should definitely use the Restlet API (Request#cookies property) instead of
setting a custom header. To set the cookies on the server-side, you need
instead to use the Response#cookieSettings property. For complete mapping
between Restlet API and HTTP headers, check this page:
http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/324-restlet/130-restl
et.html
The Client class is a stateless connector that is not appropriate for cookie
management. It was designed to be shared by several threads/applications.
Even though it is possible to instantiate several of them in the same JVM,
it is recommended to share them (of course based on the protocol they
support, HTTP(S) in your case).
I would instead suggest using a CookieFilter in front of the Client to
systematically add the cookies (maybe based on the target URI
). I dont see
why this wouldnt work as you say in your previous email. Note that your
clientHelper bean doesnt seem used nor useful.
Are you sure that you send outgoing requests to the myFilter bean and not
just to the client one? In order for filtering to happen, you need to
explicitly call it. It will then forward the call to the next Restlet
attached, the client one in your case.
Also, note that we have a RFE to provide a cookie manager filter, able to
store cookie settings and to send them again based on target URI and other
criteria:
http://restlet.tigris.org/issues/show_bug.cgi?id=42
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com
De : Jean-Philippe Steinmetz [mailto:caskate...@gmail.com]
Envoyé : mercredi 5 mai 2010 04:38
À : discuss@restlet.tigris.org
Objet : Re: Client Custom Header
Since no one seems to have responded to this problem I was hoping someone
could shed some light on cookie setting. Similarly to adding my own header
to all outgoing client requests I could instead set a cookie. My one
requirement here is that I don't want to modify every outgoing request
individually. In other words, the following code won't work...
request.getCookies().add(myCookie, value);
Instead I need a solution where I set the cookie for the Client instance
once and it is respected across all future connections and requests. Is this
possible? Or am I really stuck having to add it to every outgoing request?
Also please note it is not possible to set the cookie on the server side.
On Mon, May 3, 2010 at 5:24 PM, Jean-Philippe Steinmetz
caskate...@gmail.com wrote:
Hi Stephan,
Thank you for the response. I've implemented a filter and created one while
setting the next property to be my client but I am not getting any calls
to the beforeHandle function. My code looks like the following.
class MyFilter extends Filter
{
public MyFilter() { this(null);
public MyFilter(Context context) { this(context, null); }
public MyFilter(Context context, Restlet next) { super(context, next); }
public int beforeHandle(Request request, Response response)
{
System.out.println(HIT!);
return CONTINUE;
}
}
And my Spring configuration looks like this...
bean id=client class=org.restlet.Client
constructor-arg index=0
bean class=org.restlet.Context/
/constructor-arg
constructor-arg index=1
util:constant static-field=org.restlet.data.Protocol.HTTP/
/constructor-arg
/bean
bean id=clientHelper
class=com.noelios.restlet.ext.httpclient.HttpClientHelper
constructor-arg ref=client/
/bean
bean id=myFilter class=MyFilter
property name=next ref=client /
/bean
What am I missing? Thanks again.
Jean-Philippe
On Sat, May 1, 2010 at 3:49 AM, Stephan Koops stephan.ko...@web.de wrote:
Hi Jean,
the access is on both sides the same. That's an advantage of Restlet.
To add the header for every request you could create a filter. It adds
the header. Instead of send the request directly by the Client object
you set the Client as next Restlet in the filter and your application
sends all request via the filter.
(I hope that's right ...)
best regards
Stephan
Jean-Philippe Steinmetz schrieb:
Hi,
I'm trying to add a custom HTTP header to outgoing requests when using
the restlet client API. Ideally i'm looking for some way to implement
a helper class that can inject my header into every request as they
are processed. However in looking through the documentation i'm not
really finding what i'm looking for. I see in the FAQ it's possible to
access headers but this seems to be from the server perspective. How
do I get access from a client perspective?
Thanks in advance,
Jean-Philippe Steinmetz
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447
RE: Re: Re: Restlet JSE Client Charset
Hi Chen, For this purpose, you can override this method: ServerResource#toRepresentation(Object):Representation Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603358
RE: setting the character set of the returned representation
Hi Chen,
What looks even odder is that you need to change this property on Response
entities. Is it because you can fix the server-side (cf. you other email)?
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com
De : CB [mailto:chen.be...@gmail.com]
Envoyé : vendredi 16 avril 2010 22:47
À : discuss@restlet.tigris.org
Objet : Re: setting the character set of the returned representation
hi,
indeed strange.
Another option - correct me if I'm wrong is using a
org.restlet.router.Filter:
@Override
protected void afterHandle(Request request, Response response) {
// TODO Auto-generated method stub
super.afterHandle(request, response);
response.getEntity().setCharacterSet(CharacterSet.UTF_8);
}
This way I don't need to override the ServerResource#doHandle for each of my
ServerResources.
Let me know if you think that I'm doing it wrong.
thanks,
Chen.
On Fri, Apr 16, 2010 at 19:59, Thierry Boileau thierry.boil...@noelios.com
wrote:
Hi Chen,
as a quick workaround, you can override the ServerResource#doHandle(Variant)
method:
@Override
protected Representation doHandle(Variant variant) throws ResourceException
{
variant.setCharacterSet(your character set);
return super.doHandle(variant);
}
But that sounds odd...
Best regards,
Thierry Boileau
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2585
526 dsMessageId=2585526
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603359
RE: What to do about sessions?
Hi Matt, For tracking purpose, we already have a RFE entered to support Google Accounts in our GAE edition: http://restlet.tigris.org/issues/show_bug.cgi?id=779 Any contribution welcome ;) Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com De : Matt Kennedy [mailto:stinkym...@gmail.com] Envoyé : mardi 20 avril 2010 18:24 À : discuss@restlet.tigris.org Objet : Re: What to do about sessions? Dj, I'm glad you asked this. I've really lucked out so far and have always worked in an environment that uses client certificates for authentication. The identity of the user is established on every single connection, and I never have to worry about it. But in the near future, I'm going to have to solve the same problem that you're looking at now. You make some astute observations, HTTP_BASIC is only safe over HTTPS, which is very limiting, especially when deploying to GAE. HTTP_DIGEST has some poorly understood compatibility problems with different HTTP clients, furthermore, it isn't what GAE uses natively. It seems that for the GAE edition in particular it would be nice to have an Authenticator that could integrate with the GAE APIs. I'm sure if it isn't done by the time I have to tackle that project that I'll wind up writing one. Does the restlet team have any specific advice for creating a subclass of Authenticator that can get the Google account identity? Specifically a way to use a restlet to write the login example given on this link: http://code.google.com/appengine/docs/java/users/overview.html -Matt On Apr 20, 2010, at 11:37 AM, dj wrote: Hey Stephen, Ok so I get that sessions shouldn't be supported by rest, totally fine with that. I'm confused about how to use basic auth then instead, if that's the preferred method. If we use basic auth, then we need to send the username and password as plain text, right? This could be fixed by using https. But this also implies that every rest call made must supply username:password in the request, right? In that case, then in order to protect the user, every rest call should be done using https. Is that correct? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590 591 dsMessageId=2590591 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603377
RE: What to do about sessions?
Hi Marc, Version 2.0 of the Restlet API now has full provision for asynchronous call processing on both client-side and server-side. We are also working on an enhanced default connector for version 2.1 (part of the org.restlet.jar file) that will leverage non-blocking NIO to offer better scalability for scenarios needing thousands of concurrent clients per JVM. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -Message d'origine- De : Marc Larue [mailto:m...@rupy.se] Envoyé : jeudi 22 avril 2010 21:27 À : discuss@restlet.tigris.org Objet : Re: What to do about sessions? Well, I wrote my own NIO application server, so yes on both accounts! Polling is not an option, I need to support thousands of concurrent clients per hardware. http://rupy.googlecode.com /m On Thu, 22 Apr 2010, Tal Liron wrote: It's hard for me to see Comet as RESTful. I would consider it a new use of HTTP that demands a new way of thinking. You'd probably want to use a lower level API than Restlet, so you can fully leverage asynchronicity. Have you considered repeat rapid polling instead of using Comet? On 04/21/2010 05:12 PM, Marc Larue wrote: Ok, I realize you are all talking mostly from a B2B perspective. I'm developing a realtime comet system for multiplayer games (Ajax, JSON, Rupy); so my perspective is a little different. Right now I'm trying to figure out how to make my XSS messaging system as cheaply scalable as possible; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Laruem...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau --
RE: Re: Android and WCF DataService
Any luck with whats going on with the Android version of Restlet? Thierry- I have been working on my android app...but noticed some strange behaviors in the android logs that I wanted to pass your way. Here is a cut of sample code I am using in my app. String remoteServiceEndPoint = http://blah.blah.blah/iMMeta/webdataservice.svc;; Service myService = new Service(remoteServiceEndPoint); SysShoot ActiveShoot= new SysShoot(); ShootProviderHelper myHelper = new ShootProviderHelper(); QuerySysShoot theShootQuery = myService.createQuery(/sysShoots()?$filter=isActive eq true, SysShoot.class); IteratorSysShoot iShoot= theShootQuery.iterator(); Below is a snipit of log from my app that spits out for the above code. I wanted to check with you on a few things. 04-30 11:15:32.625: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:33.115: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:33.575: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:15:34.034: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:34.055: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:45.764: INFO/org.restlet(518): Get the metadata for http://digital-furnace.com/iMMeta/webdataservice.svc/ at http://digital-furnace.com/iMMeta/webdataservice.svc/$metadata 04-30 11:15:45.945: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:46.485: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:46.965: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:15:47.275: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:47.295: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:53.944: DEBUG/dalvikvm(518): GC freed 12463 objects / 646712 bytes in 109ms 04-30 11:16:01.104: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:16:01.725: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:16:02.234: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:16:02.555: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:16:02.574: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:16:06.775: DEBUG/dalvikvm(518): GC freed 14622 objects / 764968 bytes in 98ms 04-30 11:16:11.654: DEBUG/dalvikvm(518): GC freed 13481 objects / 835208 bytes in 107ms 04-30 11:16:16.834: DEBUG/dalvikvm(518): GC freed 13575 objects / 809480 bytes in 92ms 04-30 11:16:22.145: DEBUG/dalvikvm(518): GC freed 13529 objects / 808816 bytes in 111ms 04-30 11:16:27.974: DEBUG/dalvikvm(518): GC freed 14672 objects / 874640 bytes in 113ms 04-30 11:16:33.394: DEBUG/dalvikvm(518): GC freed 13786 objects / 820520 bytes in 99ms 04-30 11:16:38.265: DEBUG/dalvikvm(518): GC freed 13235 objects / 822288 bytes in 101ms So for Service myService = new Service(remoteServiceEndPoint); QuerySysShoot theShootQuery = myService.createQuery(/sysShoots()?$filter=isActive eq true, SysShoot.class); IteratorSysShoot iShoot= theShootQuery.iterator(); 1- It is doing a roundtrip to the server...Is there anyway to cache the requests until the query is actually called by hitting the iterator or someother method to start getting the results? It seems kinda Chatty over Chunky 2-There is a TON of GC going on for all the objects getting created as you can tell by the logs. The result of the query is not very big...but there are a log of objects being subject to GC. Is that normal? My app becomes non-responsive until the last GC(although I thought the GC was non-blocking..unless the CPU is maxed). As you can tell from the timestamps...it takes quite a while for the GC to finish. Any help sorting out what is going on with
Re: Re: Re: Restlet JSE Client Charset
I think Jerome meant ClientResource#toRepresentation... On Wed, May 5, 2010 at 8:03 AM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Chen, For this purpose, you can override this method: ServerResource#toRepresentation(Object):Representation Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603358 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603489
Re: Client Custom Header
Hi Jerome,
As I said the server side isn't an option and I need to do this
systematically. The Filter seems like the way to go. You're right that
I was sending through the client instead of the filter. However my
aplication expects a Client object and the Filter does not have the
same API. Do I need to instead extend Client instead of filter?
You may want to reconsider how Filter hooks in. It's inappropriate for
it to change the API. A Filter should really attach to an object, not
wrap it.
Jean-Philippe
On May 5, 2010, at 4:36 AM, Jerome Louvel jerome.lou...@noelios.com
wrote:
Hi Jean-Philippe,
If your goal is to systematically add cookies to your client
requests, you should definitely use the Restlet API (Request#cookies
property) instead of setting a custom header. To set the cookies on
the server-side, you need instead to use the Response#cookieSettings
property. For complete mapping between Restlet API and HTTP headers,
check this page:
http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/324-restlet/130-restlet.html
The Client class is a stateless connector that is not appropriate
for cookie management. It was designed to be shared by several
threads/applications. Even though it is possible to instantiate
several of them in the same JVM, it is recommended to share them (of
course based on the protocol they support, HTTP(S) in your case).
I would instead suggest using a CookieFilter in front of the Client
to systematically add the cookies (maybe based on the target URI…).
I don’t see why this wouldn’t work as you say in your previous
email. Note that your “clientHelper” bean doesn’t seem used nor
useful.
Are you sure that you send outgoing requests to the “myFilter”
bean and not just to the “client” one? In order for filtering to
happen, you need to explicitly call it. It will then forward the cal
l to the ‘next’ Restlet attached, the “client” one in your cas
e.
Also, note that we have a RFE to provide a cookie manager filter,
able to store cookie settings and to send them again based on target
URI and other criteria:
http://restlet.tigris.org/issues/show_bug.cgi?id=42
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com
De : Jean-Philippe Steinmetz [mailto:caskate...@gmail.com]
Envoyé : mercredi 5 mai 2010 04:38
À : discuss@restlet.tigris.org
Objet : Re: Client Custom Header
Since no one seems to have responded to this problem I was hoping
someone could shed some light on cookie setting. Similarly to adding
my own header to all outgoing client requests I could instead set a
cookie. My one requirement here is that I don't want to modify every
outgoing request individually. In other words, the following code
won't work...
request.getCookies().add(myCookie, value);
Instead I need a solution where I set the cookie for the Client
instance once and it is respected across all future connections and
requests. Is this possible? Or am I really stuck having to add it to
every outgoing request? Also please note it is not possible to set
the cookie on the server side.
On Mon, May 3, 2010 at 5:24 PM, Jean-Philippe Steinmetz caskate...@gmail.com
wrote:
Hi Stephan,
Thank you for the response. I've implemented a filter and created
one while setting the next property to be my client but I am not
getting any calls to the beforeHandle function. My code looks like
the following.
class MyFilter extends Filter
{
public MyFilter() { this(null);
public MyFilter(Context context) { this(context, null); }
public MyFilter(Context context, Restlet next) { super(context,
next); }
public int beforeHandle(Request request, Response response)
{
System.out.println(HIT!);
return CONTINUE;
}
}
And my Spring configuration looks like this...
bean id=client class=org.restlet.Client
constructor-arg index=0
bean class=org.restlet.Context/
/constructor-arg
constructor-arg index=1
util:constant static-field=org.restlet.data.Protocol.HTTP/
/constructor-arg
/bean
bean id=clientHelper
class=com.noelios.restlet.ext.httpclient.HttpClientHelper
constructor-arg ref=client/
/bean
bean id=myFilter class=MyFilter
property name=next ref=client /
/bean
What am I missing? Thanks again.
Jean-Philippe
On Sat, May 1, 2010 at 3:49 AM, Stephan Koops stephan.ko...@web.de
wrote:
Hi Jean,
the access is on both sides the same. That's an advantage of Restlet.
To add the header for every request you could create a filter. It adds
the header. Instead of send the request directly by the Client object
you set the Client as next Restlet in the filter and your application
sends all request via the filter.
(I hope that's right ...)
best regards
Stephan
Jean-Philippe
Retrying requests
Hello everyone,
I have a restlet resource that sometimes produces an exception during
processing. Since the exception is the fault of the server and not the fault
of the client I would like to retry the request. When an exception occurs I
get rolled back all the way to the Finder. In the Finder's handle function
i'd like to attempt to retry processing of the request when I see these
exceptions. Here's an example of the Finder I would like to implement.
@Override
public void handle(Request request, Response response)
{
int count = 0;
while (count MAX_RETRIES)
{
try
{
super.handle(request, response);
break;
} catch (MyException e) {
count++;
}
}
}
The behavior i'm seeing, however, is that once the exception is caught the
response is immediately sent back to the client and retry processing ceases.
If this is expected behavior how would I go about making this happen?
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603790
Re: Retrying requests
I usually do this sort of thing in the ServerResource itself. Just wrap the
problematic lines in the code you just provided only replace the call to
super.handle with whatever calls throw the exception. Are you doing something
in particular that makes this a bad strategy?
-Matt
On May 5, 2010, at 8:45 PM, Jean-Philippe Steinmetz wrote:
Hello everyone,
I have a restlet resource that sometimes produces an exception during
processing. Since the exception is the fault of the server and not the fault
of the client I would like to retry the request. When an exception occurs I
get rolled back all the way to the Finder. In the Finder's handle function
i'd like to attempt to retry processing of the request when I see these
exceptions. Here's an example of the Finder I would like to implement.
@Override
public void handle(Request request, Response response)
{
int count = 0;
while (count MAX_RETRIES)
{
try
{
super.handle(request, response);
break;
} catch (MyException e) {
count++;
}
}
}
The behavior i'm seeing, however, is that once the exception is caught the
response is immediately sent back to the client and retry processing ceases.
If this is expected behavior how would I go about making this happen?
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603796
Re: Retrying requests
I just tested that scenario out and it works. Unfortunately though the way
it's all coded up so far requires a lot more code refactoring to edit each
resource than it would be to handle it in the Finder itself. Albeit it would
probably be more correct. Just trying to save myself some time =)
On Wed, May 5, 2010 at 5:56 PM, Matt Kennedy stinkym...@gmail.com wrote:
I usually do this sort of thing in the ServerResource itself. Just wrap
the problematic lines in the code you just provided only replace the call to
super.handle with whatever calls throw the exception. Are you doing
something in particular that makes this a bad strategy?
-Matt
On May 5, 2010, at 8:45 PM, Jean-Philippe Steinmetz wrote:
Hello everyone,
I have a restlet resource that sometimes produces an exception during
processing. Since the exception is the fault of the server and not the fault
of the client I would like to retry the request. When an exception occurs I
get rolled back all the way to the Finder. In the Finder's handle function
i'd like to attempt to retry processing of the request when I see these
exceptions. Here's an example of the Finder I would like to implement.
@Override
public void handle(Request request, Response response)
{
int count = 0;
while (count MAX_RETRIES)
{
try
{
super.handle(request, response);
break;
} catch (MyException e) {
count++;
}
}
}
The behavior i'm seeing, however, is that once the exception is caught the
response is immediately sent back to the client and retry processing ceases.
If this is expected behavior how would I go about making this happen?
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603799
Re: Retrying requests
You can probably save yourself a lot of work by inserting an extra level of
inheritance. It is a pain to throw in try-catch blocks all over the place, but
if you think about it you might be able to put your try loop in a new
superclass to your resources and get the same functionality. It is usually
fairly easy to change around your inheritance hierarchy and change some method
names, especially if you have a nice refactoring helper like Eclipse.
-Matt
On May 5, 2010, at 9:06 PM, Jean-Philippe Steinmetz wrote:
I just tested that scenario out and it works. Unfortunately though the way
it's all coded up so far requires a lot more code refactoring to edit each
resource than it would be to handle it in the Finder itself. Albeit it would
probably be more correct. Just trying to save myself some time =)
On Wed, May 5, 2010 at 5:56 PM, Matt Kennedy stinkym...@gmail.com wrote:
I usually do this sort of thing in the ServerResource itself. Just wrap the
problematic lines in the code you just provided only replace the call to
super.handle with whatever calls throw the exception. Are you doing
something in particular that makes this a bad strategy?
-Matt
On May 5, 2010, at 8:45 PM, Jean-Philippe Steinmetz wrote:
Hello everyone,
I have a restlet resource that sometimes produces an exception during
processing. Since the exception is the fault of the server and not the fault
of the client I would like to retry the request. When an exception occurs I
get rolled back all the way to the Finder. In the Finder's handle function
i'd like to attempt to retry processing of the request when I see these
exceptions. Here's an example of the Finder I would like to implement.
@Override
public void handle(Request request, Response response)
{
int count = 0;
while (count MAX_RETRIES)
{
try
{
super.handle(request, response);
break;
} catch (MyException e) {
count++;
}
}
}
The behavior i'm seeing, however, is that once the exception is caught the
response is immediately sent back to the client and retry processing ceases.
If this is expected behavior how would I go about making this happen?
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603822
Binding Restlet service to specific IP of multiple IP machine
Hi, There is a machine with dual(multiple) IPs. I want to bind the Restlet service to a specific ip of this machine, so that if request comes to any other IPs of this machine, the request should be discarded. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603924
