Spaces in Media Type Parameters?
I just ran across an issue with media type parameters on the Content-Type header that have spaces. I assumed that quoted values would be OK but I get an exception from Restlet. My assumption was I could send: Content-Type: application/docbook+xml; version='my version 1.0' but the space character inside the quoted parameter value seems to be disallowed. This is allowed: Content-Type: application/docbook+xml; version='my%20version%201.0' In addition, the system throws an exception and I get a 500 response. I would think there would be a more graceful way of handling such an error (e.g 400 Bad request). --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379742
Re: Guidance on Atom/APP in Restlet
Sorry to jump in so late on this thread... On Fri, Jul 17, 2009 at 11:32 AM, Tim Peierlst...@peierls.net wrote: Some rambling newbie Restlet design questions: Background: I'm in the preliminary stages of a ground-up redesign of an existing non-Restlet application. I'm (naturally) convinced that Restlet is the way to go for this redesign, and I'm pretty sure I want the UI to be GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get cracking on a Restlet-Guice extension before too long, or not, depending on how you define too.) My analysis of the existing application keeps leading me to the Atom Publishing Protocol, because the key elements of that application feel like collections of publishable/updatable resources (and collections of such collections). It doesn't fit the canonical examples of APP, however, which leads to my first questions: Does anyone know of APP being used successfully outside of the usual document/news item examples that everyone uses to explain it? If so, what criteria would you use to determine whether APP is really appropriate to my resource design? I use the APP for all kinds of applications. I use it as a basic storage and retrieval mechanism. Of course, I use a lot of advanced features found inside Atomojo for querying feeds and that is most certainly outside of the APP as a protocol. I'm sort of hoping the answer is a resounding yes to this, in which case my second question is: If I want to design my application around APP but I don't intend to use a file-based storage system like eXist, what does Atomojo have for me that the Restlet Atom extension doesn't? Is there something else that I should know about? I think you are a bit confused about what Atomojo has to offer. First of all, there is a server that supports the APP and provides different storage mechanisms. There are currently two storage mechanisms: files and the eXist XML database. I've considered writing an Amazon S3 storage back end but I haven't quite gotten to it yet. Basically, storage is something that you can change in the server. The server itself maintains an index and supports different kinds of metadata and query services independent of the storage used. You can use these services to build applications--which is what I do. Atomojo also provides: * a Java client for interacting with the APP * a Javascript client for doing the same * a web server component that uses configures itself using atom feeds (a special wrap-up of Restlet) * some other application components for building web applications. Much of this still needs documentation. :( --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379543
RE: A simple URI problem
duh. thank you. webpost wrote: url-pattern/myResource/*/url-pattern router.attach(/myResource/buildings, BuildingsResource.class); That looks to me that you URL to buildings is http://localhost/ myResource/myResource/buildings. With myResource part duplicated. /Filip -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377470 -- View this message in context: http://n2.nabble.com/A-simple-URI-problem-tp3363341p3377346.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379511
RE: Re: JAX RS ExceptionMappers by MessageBodyWriter
Actually, come to think of it, what I'm talking about *should* be possible. I just ran a test and if I throw any sort of exception in a writeTo method, the status code received by the client is a generic 500. RESTlet somehow manages to catch the error and deal with it (maybe it caches headers until the first byte of the response has been written?). Since RESTlet appears to be capable of dealing with such errors, should it not also try to find a relevant ExceptionMapper before triggering a generic 500 error? I apologise if I'm talking rubbish here, maybe I'm missing something obvious. Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379510
Re: Server connector parameters ignored when configuring from Spring
Hello again Can anyone asnwer smth about my issue ? Hello, While developing my restlet application i faced following problem. Im using restlet 2.0m3 with Jetty server connector and configuring my server from Spring. This is snippet of XML file bean id=springComponent class=org.restlet.ext.spring.SpringComponent init-method=start property name=clientsList list valuehttp/value /list /property property name=server bean class=org.restlet.ext.spring.SpringServer id=springServer constructor-arg value=http type=java.lang.String/ constructor-arg value=4343 type=int/ property name=parameters map entry key=acceptorThreads value=20/ entry key=acceptQueueSize value=400/ entry key=maxThreads value=800/ /map /property /bean /property property name=defaultTarget ref=springRouter/ /bean The expected behaviour of passing the parameters to underlying jetty instance has not occurred. While debugging and researchign source code i found following in class JettyServerHelper method public SeriesParameter getHelpedParameters() always returns empry parameters because method getHelped() returns null. Can anyone give me a hand and explain if this is a bug or i'm configuring server connector incorrectly ? -- Regards, Evgeny Shepelyuk -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379927
Encoding setup for compression
hi, I am using restlet 1.1.5 to practise compression, it contains some steps like: 1. client send a request to server and tells server what compression formats can be supported. 2. server accepts the request and check these compression forats such as gzip, then compress the representation ans send back to client. my question is just that how server notify client what format has been used in the server side? I can not find any functionality in response class. Thanks and Regards, Johnson -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379920
RE: Patch for JAX-RS extension on GAE
Hi Martin, Thanks again, your patch has been applied. It would be nice if you could test it with the new edition packaging that is available for the 2.0 snapshots and soon for 2.0 M4. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Martin Krasser [mailto:krass...@googlemail.com] Envoyé : dimanche 26 juillet 2009 07:29 À : discuss@restlet.tigris.org Objet : Patch for JAX-RS extension on GAE Hi, first of all, I want to say that Restlet is a great framework. Really enjoy working with it. For issue 818 http://restlet.tigris.org/issues/show_bug.cgi?id=818 I attached a patch that gets the JAX-RS extension running on GAE. A description of the patch was added as comment. It would be great if this patch could make it into 2.0-M4. Regards, Martin -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23756 10 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379939
RE: Question about 'org.restlet.engine.Engine.registerHelper(ClassLoader, URL, List, Class)'
Hi Marcelo, Good point, I've just made this change in SVN trunk to catch all throwables. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : webp...@tigris.org [mailto:webp...@tigris.org] Envoyé : vendredi 24 juillet 2009 15:51 À : discuss@restlet.tigris.org Objet : RE: Question about 'org.restlet.engine.Engine.registerHelper(ClassLoader, URL, List, Class)' Hi Jerome, [disclaimer]I haven't seen the changes you made to the code in SVN.[/disclaimer] That catch won't do the work because the throwable I am getting (NoClassDefFoundError) is not an exception. I wonder if it makes sense to replace the catch-Exception by a catch-Throwable or, if you prefer to be less aggressive ;-), keep the catch-Exception and add a catch-LinkageError. Cheers, Marcelo -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23751 90 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379942
Is Representation in acceptRepresentation == Request.getEntity() ?
If I am implementing: public void acceptRepresentation( Representation rep ) { // ... } Is using that rep exactly the same as if I had instead done: Representation rep1 = getRequest().getEntity(); ? Is the rep being passed to acceptRepresentation() just a convenience? - Paul -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380079
Re: Checking for Request Entity
On Tue, Jul 28, 2009 at 05:34, webp...@tigris.org wrote: Dont know why getRequest().isEntityAvailable() returns true, however getRequest().getEntity().getMediaType() return null if the request entity is missing. OK, thanks, that's helpful. I'd still like to understand the behavior though. Can anyone help? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380138