Re: Different operations (post) on same resource design
On 2010-11-16 17.45, Tim Peierls wrote: What's wrong with proliferation of resources? Changing a password and exporting to a database sound like two very different things; wouldn't you *want* to expose them as different resources? I agree, that's how I do it. A GET on /contacts/id/changePassword would return a form with the fields to fill in for the command, and a POST executes it. Same thing with exportToSap: a GET would return a form with the possible export options, and a POST performs it (or I would do it using GET actually, since it's a query). This also makes authorization easier, if you want to differentiate who is allowed to perform different operations on the same contact. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682392
RE: 2.1 JSE : RecipientInfo/Via chokes on : in token
Hello Guido, I've fixed the writing of the Via header which now accepts host[:port] values (in both 2.0 branch and 2.1 trunk). A few things need to be done however. I've entered an issue for that http://restlet.tigris.org/issues/show_bug.cgi?id=1203. Thansk for your report. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682425
Re: Hang when calling setStatus with CLIENT_ERROR_BAD_REQUEST
Hello, are you using the internal client and/or server connectors? I suggest you add the jetty server connector (on server side) and, if it still block, use one of the available client connectors such as net or httpclient. You can have a look here for more details about connectors http://wiki.restlet.org/docs_2.0/37-restlet.html Best regards, Thierry Boileau version: 2.0.3 (stable) I am seeing this too, although not only on CLIENT_ERROR_BAD_REQUEST. Did you get anywhere discovering what it might be ? Regards Fraser -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2680149 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682408
RE: Nested routers and keeping remaining part
Hello, I wonder if the probleme does not reside on the default matching mode of the root router. As there are nested routes (under /bbb, /ccc), I think you should specify the start with mode, instead of the equals mode. You just have to update the root router as follow: router.setDefaultMatchingMode(Template.MODE_STARTS_WITH); Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682433
RE: BufferOverflowException when response size exceeds 8192 bytes
Hello Tom, thanks a lot for your help, the fix is available in the svn repository. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682439
RE: I want to upload a file to the server from a java client but receive a (415) error code
Hello,
in your case, you don't need to use a FileRepresentation on server side.
You can just replace the type of the parameter:
@Post
public FileRepresentation receive(Representation file){
[...]
}
Having said that, you still have access to the Representation#disposition
attribute on server side.
Best regards,
Thierry Boileau
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682443
RE: InputStream In not closing properly in InputRepresentation Class
Hello Somu, thanks for your help. I've entered an issue in order to tkae care of this problem: http://restlet.tigris.org/issues/show_bug.cgi?id=1204. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682451
Re: Best way to get automatic JavaScript minification in Restlet
Hello Tim,
thanks a lot for having entered an issue. This has been fixed (I've checked
with your code) a few minutes earlier, see
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682395
.
The remaining size of a target buffer was not taken into account when
filling it.
Best regards,
Thierry Boileau
I just filed issue 1198 which has one file Java program that demonstrates
the problem.
http://restlet.tigris.org/issues/show_bug.cgi?id=1198
http://restlet.tigris.org/issues/show_bug.cgi?id=1198--tim
On Mon, Nov 8, 2010 at 9:03 PM, Tim Peierls t...@peierls.net wrote:
On Wed, Jul 28, 2010 at 6:27 PM, Tim Peierls t...@peierls.net wrote:
I wrote a Restlet Filter to minify application/x-javascript resources in
afterHandle (using JSMin now, but I'll probably switch to YUI Compressor).
As of 2.1-M1 (JSE edition), and using the internal connector only, I'm
getting a BufferOverflowException when I use this code in afterHandle:
Representation result =
new WriterRepresentation(mediaType, out.size()) {
public void write(Writer writer) throws IOException {
out.writeTo(writer);
}
};
response.setEntity(result);
where out is a CharArrayWriter that has been written to by a
YUICompressor instance and then flushed. It seems to only happen on fairly
large files, so it might be another manifestation of the
BufferOverflowException bug that was fixed back in January or so. I was
getting a different kind of exception in 2.0.x, something about writing to
closed socket, but it wasn't preventing things from working, whereas this
is.
As a workaround, I'm using this code:
Representation result =
new StringRepresentation(out.toString());
response.setEntity(result);
which means creating a copy of the entire minified file in memory, but
works with no warnings.
Another thing that might be worth mentioning is that the Filter this code
is part of is wrapped around a Directory with this code:
private Restlet getDirectoryOptionallyMinified(String path, boolean
minify) {
// XXX Can't figure out how to do this with Reference
construction,
// but it doesn't matter.
String ref = createClapReference(getClass().getPackage()) + / +
path;
Restlet directory = new Directory(getContext(), ref);
if (minify) {
Filter minified = new MinificationFilter();
minified.setNext(directory);
directory = minified;
}
return directory;
}
If no one sees any obvious gaffes in this code, I'll try to turn it into a
simple test program that illustrates the problem.
--tim
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682449
Re: BufferOverflowException when response size exceeds 8192 bytes
Would this bug affect the 2.0 branch at all? On 11/17/2010 05:33 AM, Thierry Boileau wrote: Hello Tom, thanks a lot for your help, the fix is available in the svn repository. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682439 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682556
RE: BufferOverflowException when response size exceeds 8192 bytes
Hi Tal, Actually no, this occurred in a class introduced by the new NIO connector. Best regards, Jerome -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -Message d'origine- De : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : mercredi 17 novembre 2010 21:59 À : discuss@restlet.tigris.org Objet : Re: BufferOverflowException when response size exceeds 8192 bytes Would this bug affect the 2.0 branch at all? On 11/17/2010 05:33 AM, Thierry Boileau wrote: Hello Tom, thanks a lot for your help, the fix is available in the svn repository. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682439 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682556 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682565
