Subtle hiding of allowed methods in case of a 404

A bit of nit-picking maybe. With the new ServerResource the updateAllowedMethods is not called if a isExists() returns false. The use case is for OPTIONS on a /whatever/non-existing-yet It used to return a 404 Not Found in combo with listing PUT as a valid Allow: method to invite the client

Re: Using a REST layer for UI and services

you might want to give http://kauriproject.org a try it has restlet and all its goodies underneath, but adds - a java and rest-service-wiring (based on spring and then some) - some templating, routing, and client-side ajax/js support (including a form-model) that helps out in this webservice

Re: stream closed errors

Just a final confirmation from our side. All tests on all environments run properly now, thx for the fix and the wrap up in 2.0.1 By the way: are the artifacts also going to be published on http://maven.restlet.org/org/restlet/jse/org.restlet/ ? -marc= On 09/03/2010 04:43 PM, Marc Portier

continuous integration setup

By the way you might be interested to learn we've set up a continuous integration build for restlet on our hudson server http://ci.outerthought.org/job/restlet.org_4KAURI/ We basically set this up for continued automated testing of our own (open) framework on top of restlet.org, but of course

Re: stream closed errors

On 08/28/2010 06:44 PM, Jerome Louvel wrote: Hi Freya, This is probably related to the Message#finalize() which is called at GC time and closes the underlying entity streams. The problem with Tomcat and probably Jetty as well is that those streams might have been reused for other call,

Re: stream closed errors

On 09/03/2010 10:39 AM, Jerome Louvel wrote: Hi Marc, Thanks for the investigation. I've fixed the regressions in SVN trunk and the build should pass again. It does on my machine. Thanks for the fixes, normal (ant) build works indeed. I need the maven artifacts however and am building with

response.release() versus response.exhaust() in 2.0

Hi all, We've recently upgraded to restlet 2.0 and are facing a number of odd 'hangs' during our junit testcases. As far as we can tell now, we're facing some variant of what is mentioned here: http://restlet-discuss.1400322.n2.nabble.com/Suspended-thread-doing-Client-put-td4479317.html And

Re: thinking about standard rest service api's

Ben Johnson wrote: Hi Marc I'll be interested to read through your wiki. A small comment - you've got a typo on 'RestService API Allignment'. 'Allignment' should be 'Alignment'. thx, fixed, looking forward to your feedback -marc= --

[announce] kauriproject.org

We're very happy to announce the first invitation release of the Kauri project http://kauriproject.org/ Our goal with Kauri is to bring a new style of web application development: * by combining middle-tier and browser-side development techniques and optimizing their interaction * by offering

Re: multipart representation

Hi Jerome, thx for your response and the implementation suggestions Jerome Louvel wrote: [...] we could make a Representation based similar composite that - holds a list of embedded Representations (of which some are referring to files on disk, and some just hold parameter-values) - all to

multipart representation

Hi all, I'ld like to start on a solution for http://restlet.tigris.org/issues/show_bug.cgi?id=71 I personally think the design of the multipart support in http-client:

Re: Session

Stephan Koops wrote: one of the main points of REST is, that there is no session state on the server. If you want to have a session state, than you do not follow the REST architecture style. uh, yes, but: observation 1- there *is* server side state in ReSTful apps. As Stephan points out

MetadataService extension check blocks PUT to file://

Hi, I'm looking for a way to allow PUT on - file:/// URI's - to resources that have no extension - by pushing entities of type application/octet-stream (or whatever would be the metadata-service's default-mime) Currently the file-client-helper checks the metadata-consistency of the file being

Re: MetadataService extension check blocks PUT to file://

, Marc Portier [EMAIL PROTECTED] wrote: Hi, I'm looking for a way to allow PUT on - file:/// URI's - to resources that have no extension - by pushing entities of type application/octet-stream (or whatever would be the metadata-service's default-mime) Currently the file-client-helper checks

Re: Best Practice For Restlet

cleverpig wrote: oh,sure! I had submitted contributors agreement to you,and translated restlet tutorial in Chinese. So I can join to expand outline and make translation. The documentation is managed with the Daisy CMS. (more info on http://www.daisycms.org/) The system provides features

Re: various xslt related remarks

Jerome Louvel wrote: Hi Marc, thx for this, I do think there is more stuff that needs to happen, I'm just not sure yet about the whole approach. * I need to have a second look and provide a test case, but the IMHO clear remaining short-term 'issue' to solve in the current

Re: various xslt related remarks

Jerome Louvel wrote: Hi Marc and Joe, I've extracted some of your writings into the existing RFE: Refactor TransformRepresentation http://restlet.tigris.org/issues/show_bug.cgi?id=377 and into a new RFE: Support DomSource, SaxSource and StreamSource

Re: various xslt related remarks

Joe Nellis wrote: Hi Mark, *1* TransformRepresentation doesn't seem to have a way to inject xslt parameters. Am I missing it? Is there someone having a patch or opinion on how to do it? (ideas welcomed both on implementation and usage level) This is done with the JAXP convention on the

various xslt related remarks

Hi all, I'm working on some tests for issue 377 (http://restlet.tigris.org/issues/show_bug.cgi?id=377) During that work I'm encountering some side-wise stuff that I hope some of you might have an answer/opinion on: (or can refer me to docs or known issues) *1* TransformRepresentation

Re: JavaPolis

Makunas, Michael wrote: Hi all- Anyone going to JavaPolis in Antwerp next month? If so, do you know if anyone is doing a REST/Restlet BOF or meetup type of thing? doesn't look like it: http://www.javapolis.com/confluence/display/JP07/BOFs only related talk seems to be:

Re: [docs] Poll for participation and input.

Some of my TOC additions embedded, feel free to comment... (incorporated the suggestions from issue 21 and those made in this thread already) I also added a big section on doing reslet based development as I think there is a big difference in listing 'what it is and does' versus 'how one

UPDATE (was Re: [DAISY] mails on [EMAIL PROTECTED])

, beside the sender email address. Do you mind using [EMAIL PROTECTED] instead to better reflect the URI that we'll soon use (http://wiki.restlet.org) for it? Thanks, Jerome 2007/10/4, Marc Portier [EMAIL PROTECTED]: Hi all, some explanation: those subscribed to [EMAIL PROTECTED] will have seen

Re: [DAISY] mails on [EMAIL PROTECTED]

Jerome Louvel wrote: Hi Marc, This looks good, beside the sender email address. Do you mind using [EMAIL PROTECTED] instead to better reflect the URI that we'll soon use (http://wiki.restlet.org) for it? done regards, -marc=

[DAISY] mails on [EMAIL PROTECTED]

Hi all, some explanation: those subscribed to [EMAIL PROTECTED] will have seen a bulk of mails prefixed with [DAISY] passing by recently. These emails communicate ongoing changes to the documentation, we've decided now to direct those to the commit list, this can be changed later if

Re: Bug: DirectoryResource is broken if used with relative paths

Rob Heittman wrote: With trunk rev 2170 Joel's problem still manifests. I confirmed issue 352 solved, but this is something different. LocalReference.getFileReference() does not make the ./ go away. I think it should: LocalReference.java:86 return

Re: Developer Guide (was Re: getEntityAsObject()?)

: don't worry: there is an automated task in daisy to make a new branch of your documents based on the old one (I am not suggesting to rewrite everything from scratch for eveery release :-)) -marc= Best regards, Jerome 2007/9/12, Marc Portier [EMAIL PROTECTED]: there is of course a good

Re: sessions debate (was Re: some benchmarking)

Kyrre Kristiansen wrote: simple round-robin of a cookie-less system. And, if you want to make quick, highly reliable services, load balancing is almost as king as cache... Kyrre, thx for pointing me to this, I read this as the intrinsic point that 'resource-state' should be shared in the

Re: Scripting and Restlets

Alex Milowski wrote: The init() function is called. If the init function returns an object, then methods on that object are called instread of global functions. obviously I like this more... I've currently implemented this as a very terse Application class that just compiles the script

sessions debate (was Re: some benchmarking)

Rob Heittman wrote: Great article, Serge! I would offer this viewpoint on the Session concept. The transparent instant availability of an general-purpose Session, as in JSP/Servlet, is ridiculously convenient for about a billion reasons, and therefore a powerful seduction to not really

docs initiative (Re: getEntityAsObject()?)

Stanczak Group wrote: I would be happy to help as well. Rob Heittman wrote: It does seem there is a lack of documentation. Is there more some where? I think I've read most everything. A major documentation initiative is on the roadmap for later this year. I think there will be lots

pseudo-protocols (was Re: How I would like to see Spring integrated)

Jerome Louvel wrote: Hi Joe, There is a plan to add WAR packaging support for NRE in version 1.1 M2. It will let the Restlet component (manager) automatically make the decision for classpath authority for you. Your URIs will look like war://app/scripts/init.groovy instead. See details at:

Re: encoding of URI's

(as POST URI's can hold request params in both URI and body, and e.g. servlet API request.getParameters() combines those) regards, -marc= Best regards, Jerome -Message d'origine- De : Marc Portier [mailto:[EMAIL PROTECTED] De la part de Marc Portier Envoyé : jeudi 26 juillet 2007 15

Re: encoding of URI's

Jerome Louvel wrote: Hi Marc, [...] Just a follow up question: for reading the request params I found: - from the query-string request.getResourceRef().getQueryAsForm(); // optional param charset - from the http body request.getEntityAsForm(); (noticing this last one doesn't have an

encoding of URI's

Short question, I was testing the sample for Users and Orders recently (org.restlet.example.tutorial.Part12) When I enter as test URL: http://localhost:8182/users/me/orders/REST-ME-SOME-€ in the browser, it will transform it to the utf-8 + formencoded version:

Re: Directory listing fails on symbolic links

Thierry Boileau wrote: Hi Marc, Thanks a lot for having reported this problem. An issue has been created : http://restlet.tigris.org/issues/show_bug.cgi?id=337 ok, thx for confirming this as a defect. I've taken the liberty of adding my proposed fix in patch-format to the issue. I

failing samples in svn-trunk

Hi there, Wile trying out the samples I've ran into some issues with those in org.restlet.example.book.rest.ch7.* When trying out the PUT of a new user I'm just getting a 200 (OK) (I was expecting a 201 created?) Trying to GET it afterwards yields a 500 Internal error. Jul 24, 2007 11:40:51

Directory listing fails on symbolic links

Hi all, I'm testing an adapted version of org.restlet.example.tutorial.Part06 to make it display a directory listing of my home directory The changed part looks like this: // Create an application Application application = new Application(component.getContext()) {