RE: Re: How to tell Restlet not to use the chunked trunsfer encoding.

2011-12-09 Thread Mark Kharitonov
I have searched the Restlet 2.0.10 source code for the string 
setRe​questEntityBuffering​ and it does not exist.

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


RE: Re: How to tell Restlet not to use the chunked trunsfer encoding.

2011-12-09 Thread Mark Kharitonov
There is something I do not understand. Is it the client who has to call 
ClientResource.setRe​questEntityBuffering​(true) ?

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


Re: Serious bug in ClientResource

2011-12-09 Thread Arjohn Kampman
Fix verified, it works as expected now. Thanks.

On 08/12/2011 10:12, Thierry Boileau wrote:
 Hello Arjohn,
 the snapshots are refreshed three times in a day, and the maven
 repository once a day. I've just checked, you can test it.
 Best regards,
 Thierry Boileau

-- 
Arjohn Kampman - www.aduna-software.com

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


Re: Re: How to tell Restlet not to use the chunked trunsfer encoding.

2011-12-09 Thread Thierry Boileau
Hello Mark,

I forgot to say the API has been updated only for the 2.1 trunk, not the
2.0 branch. There is still a workaround (see
http://restlet.tigris.org/issues/show_bug.cgi?id=1219). You can have a look
at the end of this mail.

There is something I do not understand. Is it the client who has to call
ClientResource.setRe​questEntityBuffering​(true) ?
yes, all happens on client side. As GAE does not support chunked entities,
the client has to send an instance of Representation with a known size, by
doing so the client connector won't use chunked encoding.

Best regards,
Thierry Boileau
here is an excerpt of issue 1219 (
http://restlet.tigris.org/issues/show_bug.cgi?id=1219) :

A solution is to wrap the sent entity in a Representation that expand the
chunked entity, store it in memory, then calculate the size.
Or to change the behaviour of the ClientResource. It could be
something like that:
ClientResource res = new ClientResource(remoteUri) {
  @Override
  protected Representation toRepresentation(Object source, Variant target) {
Representation result = null;
if (source != null) {
  org.restlet.service.ConverterService cs = getConverterService();
  result = cs.toRepresentation(source, target, this);
  if (result != null) {
try {
  final ByteArrayOutputStream os = new ByteArrayOutputStream();
  BioUtils.copy(result.getStream(), os);
  OutputRepresentation rep = new OutputRepresentation(
result.getMediaType()) {
  @Override
  public void write(OutputStream outputStream) throws IOException {
outputStream.write(os.toByteArray());
  }
};
  rep.setSize(os.size());
  result = rep;
} catch (IOException e) {
  e.printStackTrace();
}
  }
}
  return result;
 }
};


If all your client calls are issued from an instance of
org.restlet.Application, you can use and outbound filter that copes with
this feature.

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

RE: Re: Re: How to tell Restlet not to use the chunked trunsfer encoding.

2011-12-09 Thread Mark Kharitonov
But my client side does not use Restlet. What should the HTTP request contain 
to tell the server not to use the chunked encoding?

Thanks.

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


Re: Re: Re: How to tell Restlet not to use the chunked trunsfer encoding.

2011-12-09 Thread Thierry Boileau
Hello Mark,

in this case, I'm not sure to understand your question.
Your client sends requests to the server which may contain entities, which
may be chunked, or not.
In case the entity is chunked, any server (not only restlet-based), by
default, will do its best to consider the entity and recover the exact
entity by concatenating all chunks sent by the client.
Do you mean to tell your server (I guess it's based on Restlet) to refuse
chunked requests?

Best regards,
Thierry Boileau

But my client side does not use Restlet. What should the HTTP request
 contain to tell the server not to use the chunked encoding?

 Thanks.

 --

 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2891906


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

Re: Multiple versions of API in production

2011-12-09 Thread Paul Morris
Thanks for your comments Thierry.

From: Thierry Boileau 
thierry.boil...@noelios.commailto:thierry.boil...@noelios.com
Reply-To: discuss 
discuss@restlet.tigris.orgmailto:discuss@restlet.tigris.org
Date: Wed, 7 Dec 2011 05:58:52 -0600
To: discuss@restlet.tigris.orgmailto:discuss@restlet.tigris.org 
discuss@restlet.tigris.orgmailto:discuss@restlet.tigris.org
Subject: Re: Multiple versions of API in production

Hello Paul,

just of few thoughts, I've no precise answer.
Using a Redirector, you keep an API stable pointing to the desired version but 
from the point of view of the client, all of this is transparent and you're 
likely to expose only one API. If this is desired, don't hesitate. The 
Redirector is quite quick, it does not instantiate a new Request each time 
(especially it does not read and rewrite the entity). If you want the clients 
to access any versions, these versions must appear, and the redirections won't 
be transparent. You can still use a Redirector but in one of the following 
modes : MODE_CLIENT_PERMANENT, MODE_CLIENT_FOUND, MODE_CLIENT_SEE_OTHER, 
MODE_CLIENT_TEMPORARY.

Best regards,
Thierry Boileau

Trying to implement some sort of versioning for an enterprise API. It could 
interface with external APIs eventually so I want to do it right.

Resources will likely be grouped into war files (or maybe even JSE apps at some 
point who knows) that will be deployed on the server and the idea is to be able 
to have multiple versions live at the same time if need be. So in the case of 
war files in a container there might be a bundle1012.war with a context base of 
../v1.0.12/bundle and a bundle1013.war with a base of ../v1.0.13/bundle etc.)

I was thinking of having a Redirector running at root and rewriting the URL 
based on conditions (a la ../bundle/resource redirected to 
../v1.0.12/bundle/resource). So for one case it could redirect every call to 
the latest version but then make it easy for me to back out and use the 
previous version. Or it could read attributes of the request and act on those 
to redirect some clients to one version and others to another.

Any thoughts on this? Comments on latency from the redirection? Am I going 
about this the right way? Any recommended reading?

Thanks.

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

This message and any included attachments are intended only for the addressee. 
The information contained in this message is confidential and may constitute 
proprietary or non-public information under international, federal, or state 
laws. Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail.

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