Re: URI matching again
Jonathan, I hope you don't mind the suggestion, but I wonder if you'd be open to possibly shifting your URL scheme a little? For example, if /user/list routes to the "list of users" resource, which is what I call a "collection", you might want to consider something like this: /users /users/{id} I have the impression that this scheme is becoming fairly common in RESTful web services, and it was used repeatedly in the new book, RESTful Web Services (which I highly recommend). HTH, Avi On 6/8/07, Jonathan Hall <[EMAIL PROTECTED]> wrote: Hi, Is it possible to do this: /user /user/{id} /user/list The problem comes from the app thinking list is just a {id} variable. I thought router.setRoutingMode(Router.FIRST) sounded like it would pick the route I wished by the order they were attached. In which case this would work: /user /user/list /user/{id} However, it seems to not work like that. No matter what order I attach the routes they seem to end up in the same order in a RouteList. I also need to have optional parameters attached to all of the urls. Any ideas? Best Regards, Jon -- Avi Flax Senior Technologist arc90 | http://arc90.com
Re: afterHandle logging
Jim, just want you to know that it's very helpful of you to post your findings as you learn this stuff. For every one of you, who is figuring this stuff out, there's at least a few of me, people who need/want to figure this stuff out, but don't currently have the time to get to it. This kind of thing is what makes this community great - as individuals learn things, and contribute, the entire community benefits, and we all make better progress than we would separately. I, for instance, am new to Java, and of course, Restlet too, so I sometimes feel as if I have a double learning curve to deal with - but that's ok, I'm enjoying it - in large part because Restlet is so elegantly designed. I am looking forward to that Developer's Guide though! As long as I'm rambling, I just released my first Restlet app yesterday; it's up and in service. 13 days from start of development to launch! And I must say, I've been very, very happy with Restlet. It's really superb software. Finally, to reel myself back in, my just-released app, perhaps not coincidentally, is really missing only one important feature: comprehensive, useful logging. So I'm very glad to see that you've been dealing with it, bringing it up. If you end up having anything else to share about it, I'd love to hear about it. Thanks! Avi On 6/8/07, Jim Edwards-Hewitt <[EMAIL PROTECTED]> wrote: This seems to be my day for learning more about Java logging and answering my own questions. I didn't realize that was a feature of Java logging, not of LogFilter. In case anyone else is trying to do the same thing, here's a good reference: http://www.javalobby.org/java/forums/t18515.html -- Jim -- Avi Flax Senior Technologist arc90 | http://arc90.com
Re: Conditional GETs?
Jerome, I'm eagerly awaiting this snapshot! No pressure, but are we looking at a matter of days here, or is it more like weeks? Thanks! Avi On 6/16/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: Hi all, This RFE is now fixed in SVN trunk and will be testable in the upcoming 1.1 snapshot. Great optimization, thanks Stian for the idea. Best regards, Jerome
Re: Conditional GETs?
Great news, thanks! Avi On 6/18/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: Hi Avi, A matter of days! Version 1.0.2 is pending too. Best regards, Jerome
Re: afterHandle logging
Jim, that's really useful info, thanks! -- Avi Flax Lead Technologist arc90 | http://arc90.com
Re: form submission fails to redirect on success
Thierry, Actually, I think setRedirectRef() (which in HTTP is expressed as a "Location" response header) *is* appropriate when the Response Status is SUCCESS_CREATED (HTTP: "201 Created"). It is used to indicate to the client the URI of the newly created Resource. That's the current state, and it makes sense, but I think it may be causing some confusion, because even though in HTTP both SUCCESS_CREATED and the REDIRECTION_* statuses make use of the "Location" header, it has different semantic meaning in the two different cases; in the case of SUCCESS_CREATED it indicates the Location (URI) of the newly created Resource, in the case of REDIRECTION_*, it indicates the new Location (URI) of the original resource. So, we may want to consider adding a new method for use in the SUCCESS_CREATED case: instead of setRedirectRef(), perhaps it could be something like setNewResourceRef() - and the two should probably be mutually exclusive somehow, or they would collide and/or overwrite each other. Avi -- Avi Flax Lead Technologist arc90 | http://arc90.com On 6/29/07, Thierry Boileau <[EMAIL PROTECTED]> wrote: Hello Michael, after reading the spec, SUCCESS_CREATED shows that the operation succeeds and allows you also to provide a representation with some information about the new resource, including "a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate". I don't think it can be meant as a redirection. I think also that the redirecRef is only used when the status of the response is a redirection status (3xx). The main explanation for this design choice is that there are several redirection status, and no default one. best regards, Thierry Boileau On 6/28/07, Michael Vogel <[EMAIL PROTECTED]> wrote: > Hello, > > I'm new to using restlets and have been experimenting with simple test > pages to make sure i understand how to use it (and so that i can write > some examples to help my coworkers learn it). > > I wrote a simple form submission test that works, except that the > redirection after returning SUCCESS_CREATED doesn't happen. I am under > the impression that setting getResponse().setRedirectRef(); > sets the location header and redirects the browser to whatever URL is > specified. > > If i send the state REDIRECTION_SEE_OTHER, it redirects correctly. > > From the HTTP spec, it appears that using REDIRECTION_SEE_OTHER to > redirect the client to a view of > the created item after a post is acceptable, so I'm going with that > for now, but I thought SUCCESS_CREATED was supposed to do that also. > > Am I incorrect in expecting it to redirect on SUCCESS_CREATED? > > thanks for your time, > > Michael >
Re: form submission fails to redirect on success
Jerome: That seems like a great solution. I took a look at Response.java and I really like that you also added a setLocationRef() method, but kept setRedirectRef() and getRedirectRef(), both for backwards compatibility and because sometimes those methods really do make sense. Very nice! Thanks, Avi On 6/30/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: Hi all, There is indeed some ambiguity in the "redirectRef" property name as it indeed is used for resource creations as well (indicated in the Javadocs). In order to clarify this, I've added a "locationRef" property and deprecated "redirectRef" in SVN trunk. I hope this sounds good to everyone, let me know otherwise. Best regards, Jerome
Re: Restlet and Velocity template location.
Stuart, I myself had some issues with this recently, when developing my first Restlet app. However, my app is "standalone", i.e. it doesn't use the Servlet adapter to run inside a Servlet Server, it uses one of the included extensions to embed an HTTP server. I think that may make a big difference in how to reference templates, so I'm not sure my experience/setup would be helpful for you. If you'd like, though, I'd be happy to share. Hopefully someone will have some advice for your specific situation. -- Avi Flax Lead Technologist arc90 | http://arc90.com On 7/2/07, Stuart Owen <[EMAIL PROTECTED]> wrote: Hi, I'm trying to use the TemplateRepresentation for the Velocity extension as part of a webapp, but I am having problems configuring the template location. The API docs for TemplateRepresentation species that only the template name is required and the full path is resolved by the configuration. I've tried setting webapp.resource.loader.path=/templates/ within my WEB-INF/velocity.properties, which works for the VelocityViewServlet, but doesn't appear to be picked up by Restlet. So any advice on how I configure restlet to use my velocity.properties within a webapp? thanks, Stuart
Re: best way to iterate over a NodeSet in a DomRepresentation
On 7/13/07, Christopher Townson <[EMAIL PROTECTED]> wrote: (I've always preferred using jdom in the past, despite the introduction of a new dependency, so am not very familiar with the org.w3c.dom api ... but I presume it must be similar enough :D) Chris, if you prefer JDOM - I think I do too, although I am new to Java - why bother working with the W3C DOM at all? If it's because that's how DomRepresentation works, then why not create a JDomRepresentation, as a subclass of either DomRepresentation or it's superclass, XmlRepresentation? In fact, I wonder whether such a class might be a good candidate for inclusion in Restlet itself. I'm still a Java newbie, but if you'd be interested in developing this class together, and maybe even submitting it as a patch to Restlet, I'd be game. Meantime, I'll be trying to figure out how to use the JAXB extension. Take care, Avi -- Avi Flax Lead Technologist arc90 | http://arc90.com
Re: comments/feedback requested
On 7/18/07, Adam Taft <[EMAIL PROTECTED]> wrote: I like the webdav status code use, 102 Processing. Seems very appropriate. Sorry to come into this late, but this caught my eye. If this is a RESTful web service, wouldn't HTTP's "202 Accepted" be a more appropriate Response Code for asynchronous processing? Avi
How to use JDBC Extension?
Hi all, I'm new to Java, so please forgive the basic question. I'm interested in having a Restlet application integrate with a JDBC database. My question is: should I just find some JDBC tutorial out on the webs somewhere, or is the Restlet JDBC extension intended for basic db integration? I looked at the Javadocs, and searched the mailing list archive, but couldn't find a general description of the extension and how to use it. If the extension is good for basic integration, could someone post a code sample on how that's done? Thanks, Avi -- Avi Flax Lead Technologist arc90 | http://arc90.com
Re: best way to iterate over a NodeSet in a DomRepresentation
On 7/23/07, Klotz, Leigh <[EMAIL PROTECTED]> wrote: Here's a first implementation. The methods all return raw JDOM objects. It might be desirable to return representations instead; i.e. JDOMElementRepresentation, etc. In this case, you'd implement a sanitizeJDOMObject to convert to them to these subclasses. Leigh, this looks great! I'm really glad that you've gone ahead and contributed this - I had hoped to get to it but now I don't have to. One question: I wonder if we could remove the dependency on com.xerox.docushare.util.JDOMUtil. It looks like it's only being used as a convenient shorthand to parse XML into a Document. I'd think it might be better for Restlet to reduce dependencies, and it'd be OK to use the more verbose syntax here. Thanks, Avi -- Avi Flax Lead Technologist arc90 | http://arc90.com
Re: How to use JDBC Extension?
On 7/25/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: > Hi Avi, > > The JDBC extension is mostly useful if you want to manipulate your database > through XML representations (XML requests and XML responses). For other use > cases, such as supporting Resources as Domain Objects, I would recommend > more classic solutions such as using Hibernate, iBatis or EJB directly > within your Restlet Resources (eventually directly using JDBC if you > prefer). > > Best, > Jerome > Jerome, Thanks! This is exactly what I needed to know. -- Avi Flax Lead Technologist arc90 | http://arc90.com
Slow to retrieve Request Entity?
I seem to be having some kind of performance problem trying to retrieve the request entity. I've tried a few different approaches, and I can't figure it out. I'm using Restlet 1.0.5 with the bundled Simple server, Intel Core Duo, Mac OS X 10.4.10, Java 5.0, Eclipse. I've tried reducing my test case down to the bare bones. At this point my test App looks like this: import org.restlet.Restlet; import org.restlet.Server; import org.restlet.data.MediaType; import org.restlet.data.Protocol; import org.restlet.data.Request; import org.restlet.data.Response; public class TestApp { public static void main(String[] args) throws Exception { Restlet restlet = new Restlet() { @Override public void handle(Request request, Response response) { try { response.setEntity(request.getEntity().getText(), MediaType.TEXT_PLAIN); System.exit(1); } catch (Exception e) { e.printStackTrace(); } } }; new Server(Protocol.HTTP, 3000, restlet).start(); } } and these are the only JAR files in my build path: com.noelios.restlet.ext.simple_3.1.jar com.noelios.restlet.jar org.restlet.jar org.simpleframework.jar My JVM args are: -server -Xprof My test script: time curl -X POST -d @post.xml -H Content-Type:application/xml http://localhost:3000/ post.xml is a 2.5K xml file. No matter what I do, request.getEntity().getText() seems to take about 2 seconds. This seems way too slow. Looking through the profiling results I found: Flat profile of 4.02 secs (390 total ticks): Thread-17 Interpreted + native Method 97.3% 0 + 183java.net.SocketInputStream.socketRead0 1.1% 2 + 0java.lang.AbstractStringBuilder. 0.5% 1 + 0java.lang.ClassLoader.loadClassInternal 0.5% 1 + 0java.util.Arrays.copyOf 0.5% 1 + 0sun.misc.Resource.getBytes 100.0% 5 + 183Total interpreted So it looks as though java.net.SocketInputStream.socketRead0 is taking a lot of time - I think. I'm still new to Java, so not exactly sure how to read this. Could this be something wrong with my system configuration? Am I missing something? Thanks for any help!!! -- Avi Flax Lead Technologist arc90 | http://arc90.com
Re: Slow to retrieve Request Entity?
Rob, great call, switching to Jetty did the trick. Thanks! On 10/8/07, Rob Heittman <[EMAIL PROTECTED]> wrote: > > Simple has given me some indigestion on OS X 10.4. Any chance you can try it > with the regular java.net HTTP connector and/or Jetty and see if you get the > same result? That would help isolate it. > > - Original Message - > From: "Avi Flax" <[EMAIL PROTECTED]> > To: discuss@restlet.tigris.org > Sent: Monday, October 8, 2007 11:09:30 PM (GMT-0500) America/New_York > Subject: Slow to retrieve Request Entity? > > I seem to be having some kind of performance problem trying to > retrieve the request entity. > > I've tried a few different approaches, and I can't figure it out. > > I'm using Restlet 1.0.5 with the bundled Simple server, Intel Core > Duo, Mac OS X 10.4.10, Java 5.0, Eclipse. > > I've tried reducing my test case down to the bare bones. > > At this point my test App looks like this: > > import org.restlet.Restlet; > import org.restlet.Server; > import org.restlet.data.MediaType; > import org.restlet.data.Protocol; > import org.restlet.data.Request; > import org.restlet.data.Response; > > public class TestApp { > > public static void main(String[] args) throws Exception { > > Restlet restlet = new Restlet() { > @Override > public void handle(Request request, Response response) { > try { > response.setEntity(request.getEntity().getText(), MediaType.TEXT_PLAIN); > System.exit(1); > } catch (Exception e) { > e.printStackTrace(); > } > } > }; > > new Server(Protocol.HTTP, 3000, restlet).start(); > } > > } > > and these are the only JAR files in my build path: > > com.noelios.restlet.ext.simple_3.1.jar > com.noelios.restlet.jar > org.restlet.jar > org.simpleframework.jar > > My JVM args are: -server -Xprof > > My test script: > time curl -X POST -d @post.xml -H Content-Type:application/xml > http://localhost:3000/ > > post.xml is a 2.5K xml file. > > No matter what I do, request.getEntity().getText() seems to take about > 2 seconds. This seems way too slow. > > Looking through the profiling results I found: > > Flat profile of 4.02 secs (390 total ticks): Thread-17 > > Interpreted + native Method > 97.3% 0 + 183 java.net.SocketInputStream.socketRead0 > 1.1% 2 + 0 java.lang.AbstractStringBuilder. > 0.5% 1 + 0 java.lang.ClassLoader.loadClassInternal > 0.5% 1 + 0 java.util.Arrays.copyOf > 0.5% 1 + 0 sun.misc.Resource.getBytes > 100.0% 5 + 183 Total interpreted > > So it looks as though java.net.SocketInputStream.socketRead0 is taking > a lot of time - I think. I'm still new to Java, so not exactly sure > how to read this. > > Could this be something wrong with my system configuration? Am I > missing something? > > Thanks for any help!!! > > -- > Avi Flax > Lead Technologist > arc90 | http://arc90.com > -- Avi Flax Lead Technologist arc90 | http://arc90.com
Re: Restlet 1.0.6 released
Great news! Thanks Jerome, Thierry, and every contributor! -- Avi Flax | Arc90 | http://arc90.com On 11/8/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > Hi all, > > The sixth maintenance release of Restlet 1.0 is available. It fixes several > bugs found in version 1.0.5 and provides a few documentation clarifications. > > > Thanks to Thierry for the hard work in pushing this release and for all the > contributors. We are trying to keep the list up to date here: > http://www.restlet.org/about/team > > Changes log: > http://www.restlet.org/documentation/1.0/changes > > Download links: > http://www.restlet.org/downloads/1.0/restlet-1.0.6.zip > http://www.restlet.org/downloads/1.0/restlet-1.0.6.exe > > Maven repositories: > http://maven.restlet.org will be updated on the 15th > http://maven.noelios.com has the new artifacts > > Best regards, > Jerome Louvel >
Re: Exceptions in general
Chalk me up for wanting exceptions too. I'm currently building my own REST "framework" on top of Restlet - essentially a standard way to quickly and easily implement a REST API using my company's general idioms - and exceptions would be real handy. For example, I have a class hierarchy that looks something like this: + org.restlet.resource.Resource + com.arc90.ext.restlet.resource.Resource (abstract) + com.arc90.ext.restlet.resource.CollectionResource (abstract) + com.arc90.ext.restlet.resource.JDBCCollectionResource (abstract) - com.arc90.someapp.api.rest.resources.SomeResource (concrete) (BTW I'm relatively new to Java, and formal OOP in general, so if what I'm doing doesn't make sense, don't skewer me. I welcome constructive criticism though!) Some of the abstract Resource subclasses in the middle there provide implementation, but they're abstract, so I don't know what a real concrete class is going to need to do, and how it wants to handle exceptions. So what I'd like to do is just throw exceptions from the middle layer on up to the higher-level concrete classes, and deal with them there. I'm talking about, specifically, from methods like getRepresentation(), put(), post(), delete(), etc. Since they're declared by the superclass as throwing no exceptions, I can't throw exceptions in my subclasses. End result is, if I wanted my high-level class to call the lower-level method, I have to check statuses before proceeding: package com.arc90.someapp.api.rest.resources; import com.arc90.ext.restlet.resource.JDBCCollectionResource; public class SomeResource extends JDBCCollectionResource { @Override public void put(Representation representation) { // do stuff // ... // call super.put() to actually do the magic super.put(representation); // check whether that actually worked or not if (getResponse().isSuccess()) { // ok, success, call getRepresentation() to return a new representation Representation representation = getRepresentation(getPreferredVariant()); // oops, now I have to check again whether *that* worked or not if (getResponse().isError()) { // deal with the problem... } } else { // deal with the problem... } } } Again, I don't know how much my opinion is worth, since I'm still inexperienced with Java, and, honestly, to robust usage of exceptions, but this is where my head is at right now. BTW, I've recently read some interesting essays on exceptions. If anyone else is interested, I've bookmarked them here: http://del.icio.us/avi4now/exceptions Thanks, Avi -- Avi Flax | Arc90 | http://arc90.com On 11/28/07, Rob Heittman <[EMAIL PROTECTED]> wrote: > I haven't rigorously studied the problem yet, but my general feeling is with > Tim -- checked exceptions in high level API.
Re: Shell extension for Restlet
This is a great idea! I'm looking forward to future builds, this'll be very useful for testing my services. Q: in the current build, is it possible to send a representation with a POST of a different mediatype than a webform? such as an XML document? If not, how do you anticipate doing that? maybe "contents request set" or something like that? Thanks! Avi
Re: Shell extension for Restlet
Sounds good! Thanks, Avi -- Avi Flax » Partner » Arc90 » http://arc90.com
Re: Restlets and Asynchronous Request Processing
e discussion, I would be > happy to upload my local patches to the issue tracker. > > > > Sample code usage now follows: > > > > public void handle(Request request, Response response) > > { > > final MessageHandler handler = new MessageHandler(response); > > BlockingQueueRepresentation entity = new > BlockingQueueRepresentation( MediaType.TEXT_HTML, handler.getQueue()); > > response.setEntity(entity); > > response.suspend(60L * 1000L); // suspend for 60seconds maximum > timeout > > > > new Thread("Message-Pulse") { > > public void run() > > { > > // start the message stream > > handler.getQueue().add(new > StringRepresentation("Testing...")); > > handler.getResponse().resume(false); > > > > try > > { > > // send 10 messages, one every 3 seconds > > for (int i=0; i < 10; i++) > > { > > sleep(3000L); > > handler.getQueue().add(new > StringRepresentation(String.format("%d %TT", i, new Date(; > > handler.getResponse().resume(false); > > } > > } > > catch (InterruptedException e) > > { > > e.printStackTrace(); > > } > > finally > > { > > // complete the response, roughly 30 seconds after response > initiated, therefore before 60 seconds timeout > > handler.getQueue().add(new > StringRepresentation("")); > > handler.getResponse().resume(true); > > } > > } > > }.start(); > > } > > > > public class MessageHandler > > { > > public MessageHandler(Response response) > > { > > _response = response; > > _queue = new LinkedBlockingQueue(); > > } > > > > public BlockingQueue getQueue() > > { > > return _queue; > > } > > > > public Response getResponse() > > { > > return _response; > > } > > > > private final Response _response; > > private final BlockingQueue _queue; > > } > > > > public class BlockingQueueRepresentation extends OutputRepresentation > > { > > public BlockingQueueRepresentation(MediaType > mediaType, BlockingQueue representations) > > { > > super(mediaType); > > _representations = representations; > > } > > > > @Override > > public void write(OutputStream outputStream) throws IOException > > { > > List representations = new > LinkedList(); > > > > _representations.drainTo(representations); > > > > if (!representations.isEmpty()) > > { > > for (Representation representation : representations) > > { > > representation.write(outputStream); > > } > > } > > } > > > > private final BlockingQueue _representations; > > } > > > > Kind Regards, > > John Fallows > > > > > > -- Avi Flax » Partner » Arc90 » http://arc90.com
Re: Client Timeout
Sorry to resurrect an old thread, but I was just thinking about this... I think it might be useful if both Client and Request had a setConnectTimeout() method. This seems to me like a very general and very useful parameter, one which deserves API support, instead of being buried in connector parameters. The Client's connect timeout could be used as the default for all requests made by that Client, which could be overridden for a given Request by calling setConnectTimeout() for the Request. Or am I missing something? Thanks, Avi
Re: Client Timeout
Sure, I'll do that. Thanks! Avi On 2/14/08, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > Hi Avi, > > I agree with you for this property, at least for the Client class. I'm not > sure about the change on Request. I don't want to give to much control on > the Connectors to Applications contained in a Component. > > We also have connectors like JDBC where I'm not sure if we'll be able to > take advantage of it. We can just ignore the property in this case. > > Do you want to propose patch or at least enter a RFE? > > Best regards, > Jerome > > > -Message d'origine- > > De : Avi Flax [mailto:[EMAIL PROTECTED] > > Envoyé : mercredi 13 février 2008 18:58 > > À : discuss@restlet.tigris.org > > Objet : Re: Client Timeout > > > > > Sorry to resurrect an old thread, but I was just thinking about > > this... I think it might be useful if both Client and Request had a > > setConnectTimeout() method. This seems to me like a very general and > > very useful parameter, one which deserves API support, instead of > > being buried in connector parameters. > > > > The Client's connect timeout could be used as the default for all > > requests made by that Client, which could be overridden for a given > > Request by calling setConnectTimeout() for the Request. > > > > Or am I missing something? > > > > Thanks, > > Avi > > -- Avi Flax » Partner » Arc90 » http://arc90.com
Re: RESTClient
Resurrecting this thread because I just stumbled across RESTClient myself -- and I like it! My team and I use curl extensively and regularly, and it definitely has its place. But a RESTful GUI will be very helpful in getting beginners really using/thinking HTTP, instead of browsers. Version 2.0 was released on January 30th, so if anyone tried the 1.x versions, you may want to download 2.0 and check it out. http://code.google.com/p/rest-client/ Avi -- Avi Flax » Partner » Compulsive Technologist » Arc90 » http://arc90.com On 11/30/07, Paul J. Lucas <[EMAIL PROTECTED]> wrote: > On Nov 30, 2007, at 6:05 AM, Lars Heuer wrote: > > > RESTClient is a Java platform client application to test RESTful > > webservices. <http://code.google.com/p/rest-client/> > > IMHO, command-line test tools are better because they're far more > easily automated. I just write Perl script wrappers around curl. > > - Paul >
Re: Congratulation!"Restlet: Official Developer's Guide to RESTful Web Applications in Java" will be out!
This is great news! I've pre-ordered five copies for Arc90. I'm really looking forward to the book! Avi -- Avi Flax » Partner » Compulsive Technologist » Arc90 » http://arc90.com On 2/25/08, Jerome Louvel <[EMAIL PROTECTED]> wrote: > For those wanting to pre-order, I've added an affiliated link on our books > page: > http://www.restlet.org/documentation/books
Re: Serving PDF content
All: I work with Ben, and our project is written in Groovy. So far using Restlet in Groovy is going pretty well. When we have some time we'll post something about what we've learned. In the meantime, to address this specific need: Groovy doesn't support anonymous classes. So we can't use the exact code that Michael helpfully posted: On Tue, Mar 18, 2008 at 7:29 PM, Michael Terrington <[EMAIL PROTECTED]> wrote: > And in the represent() method return a representation with the PDF > content. An easy way to do that would be to override > OutputRepresentation like so: > > Representation response = >new OutputRepresentation(MediaType.APPLICATION_PDF) { > @Override > public void write(OutputStream outputStream) { >// write your pdf data to the outputStream > } >}; > Instead, we've had to write a ByteArrayOutputRepresentation class, whose constructors accept either a ByteArray or an InputStream, whose contents is then written to the OutputStream in write(). For future users of Restlet on Groovy, I'd like to suggest that this class (or a similar one) be added to the Restlet API. I'd like some feedback on this idea; unless I hear otherwise I'll create a RFE and submit a patch for it. Thanks, Avi -- Avi Flax » Partner » Compulsive Technologist » Arc90 » http://arc90.com
Re: Serving PDF content
On Wed, Mar 26, 2008 at 3:03 PM, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > Hi Avi, > > Why don't you try using an InputRepresentation instead? It is a concrete > class, you just need to pass an InputStream (ex: ByteArrayInputStream). Thanks Jerome, that's perfect. For some reason I missed that class, or thought it was abstract, or something. -- Avi Flax » Partner » Compulsive Technologist » Arc90 » http://arc90.com
Published Article on Groovy and Restlet
Hi all, I just posted this article on Groovy and Restlet, and I thought it might be of interest: http://blog.arc90.com/2008/06/building_restful_web_apps_groovy_restlet_part_1.php It's very, very basic, but the idea is that if there's interest, it'll be a series, so it'll get more advanced. If you're interested in seeing more please let me know! Goodnight! Avi -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Published Article on Groovy and Restlet
Thanks Jerome, I'm glad you liked it! Part 2 is coming soon. -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Use a proxy server with a Client?
Hi all, does anyone know of a way to have a Client use a proxy server when making a request? Thanks! -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Use a proxy server with a Client?
Rob, thank you for the thorough and informative answer! I really appreciate it. The system properties approach for the Net connector will suffice for me for now, but I really think this ought to be available via the Client API. A method like void setUseProxy(String host, int port) would make sense to me. Thanks again! Avi On Thu, Jun 12, 2008 at 10:54 PM, Rob Heittman <[EMAIL PROTECTED]> wrote: > > Thara S had an open question about this in another thread. I think the > answer is here: > > http://restlet.tigris.org/issues/show_bug.cgi?id=317 > > For the Net connector you ought to be able to use the common idiom of > setting the system properties http.proxyHost and http.proxyPort. > > This idiom does not work with the Apache HttpClient connector anyway. Steve > Loughran went to big lengths to fix this > here: http://jira.smartfrog.org/jira/browse/SFOS-629 and he also contributed > some ideas to the bug report. I'd rather set properties on the client > context, like configuring server properties, though ... > If enough people think this is a big deal, I'm happy to propose a patch and > see if Jerome's willing to bump it earlier. > - R > On Thu, Jun 12, 2008 at 6:55 PM, Avi Flax <[EMAIL PROTECTED]> wrote: >> >> Hi all, does anyone know of a way to have a Client use a proxy server >> when making a request? > >
Re: Published Article on Groovy and Restlet
Part 2 is published: http://blog.arc90.com/2008/06/building_restful_web_apps_groovy_restlet_part_2.php I look forward to any feedback! (I plan to add a link to the wiki page, but I'm waiting for my registration confirmation email.) (If the community considers this spammy and would prefer that I cease announcing new articles, just say the word and I will desist.) -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: XForm integration with the RestLet framework possible?
On Fri, Jul 4, 2008 at 3:41 PM, ilango <[EMAIL PROTECTED]> wrote: I have an XForm built on the OPS XForms processor. Rather than use the OPS > pipelines for connecting my XForms to datasources I would like to use the > Restlet Framework to connect my XForm fields to datasources like MySQL, a > Web Service, XML databases like eXist, etc. > > I would like to get XML data into my XForm, regardless of the type of > datasource. I'm not feeling this. Not sure this is something that the framework, or even an extension, should handle. Could be a slippery slope towards the framework trying to be everything for everyone. Why not just write the glue yourself in a Resource subclass? -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: XForm integration with the RestLet framework possible?
On Mon, Jul 7, 2008 at 7:30 PM, ilango <[EMAIL PROTECTED]> wrote: Could you elaborate more on this Resource subclass? > See: http://www.restlet.org/documentation/1.0/firstResource or:http://www.restlet.org/documentation/1.1/firstResource depending on which version of Restlet you're using.
Re: 1.0 to 1.1 Migration Guide
This is a GREAT idea, I'd love to see this! I'm currently working on 1.0 and 1.1 apps, so I might be able to help. Let me know if there's something specific I can help with. -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Restlet 1.1 M5 released
On Thu, Aug 7, 2008 at 04:18, Jerome Louvel <[EMAIL PROTECTED]> wrote: > Despite our initial plan, we had to introduce a new milestone release before > reaching our first release candidate version. This is due to several > important features that we needed to publish before the RC in order to have > enough time for community feed-back, before freezing the API. Our goal now > is to fix all pending bugs before releasing 1.1 RC1. Sounds like a good release, and a solid plan. I am a little disappointed by the delayed final release, but I'm confident that it'll be a reliable, well-thought-out, and well-tested release of Great Software. Thanks Jerome, Thierry, and all the other contributors! -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Restlet 1.1 Default Status Page on a 406 Error?
The 1.1 Tutorial states in section 8, Displaying Error Pages: > Maybe a resource was not found or an acceptable representation isn't > available? In this case, or when > any unhandled exception is be intercepted, the Application or the Component > will automatically provide > a default status page for you. ( http://www.restlet.org/documentation/1.1/tutorial#part08 ) I have a situation where a client is requesting a mediatype which my resource doesn't support. Restlet is correctly returning a 406 error, but it's not returning an entity with a status page. It is logging a WARNING: Aug 31, 2008 3:21:18 PM com.noelios.restlet.LogFilter afterHandle INFO: 2008-08-31 15:21:18 127.0.0.1 - - 3000 GET /people - 406 0 - 7 http://slices:3000 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1 http://slices:3000/people Aug 31, 2008 3:21:18 PM com.noelios.restlet.http.HttpServerConverter commit WARNING: A response with an unavailable entity was returned. Ignoring the entity for resource "http://slices:3000/people. In this case, shouldn't the default status service return an HTML entity with a "status page"? -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
INFO in NRE SecurityUtils
I'm using 1.0, so this may already be fixed in 1.1, but a quick search of the list didn't turn up anything, so I thought I'd ask. I'm using Basic HTTP Auth, and I've implemented a subclass of Guard, wherein I've overridden doHandle(). I know that's not the recommended approach, but I don't think it's relevant to this question. I keep seeing entries in my logs that look like this: Sep 11, 2008 6:02:50 PM com.noelios.restlet.util.SecurityUtils parseResponse INFO: Basic HTTP authentication succeeded: identifier=avif. The thing is, this is even in cases where basic auth fails, in my Guard, wherein I call challenge(response). I think this log record is really just saying "I was able to successfully parse the Authorization header into a ChallengeResponse object", which is good info, but: (A) it should be a FINE or FINER, not an INFO, and (B) the message is misleading. Does that make sense? Thanks, Avi -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: INFO in NRE SecurityUtils
On Fri, Sep 12, 2008 at 04:17, Thierry Boileau <[EMAIL PROTECTED]>wrote: > that makes sense. I notice also that in Restlet 1.1 no message is logged > when the response is successfully parsed (class "HttpBasicHelper"). I've > updated the svn repository. > Great, thanks Thierry!
Re: Django’s Cache Framework
On Mon, Sep 15, 2008 at 11:40, Rob Heittman <[EMAIL PROTECTED]> wrote: > I agree! > Want to tack that reference on to > http://restlet.tigris.org/issues/show_bug.cgi?id=25 ? Cool, done!
Django’s Cache Framework
Hi all, I thought this was interesting, and potentially relevant to Restlet and how it does caching. Ryan Tomayko linked to: http://docs.djangoproject.com/en/dev/topics/cache/ with the note: All frameworks should approach caching the way Django does. The core app/origin framework does no real caching but provides utility/helper methods for setting standard RFC 2616 cache related headers on the response easily and correctly. A completely separate set of caching goo ("middleware") sits between your app and performs the actual caching based purely on the headers set by the origin. The benefit to this approach is that caching is totally independent from the app framework and can be swapped out for a true gateway ("reverse proxy") cache at any time. here: http://tomayko.com/linkings/ (no direct link) -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Restlet 1.1.1 released
On Fri, Oct 31, 2008 at 13:08, Stephan Koops <[EMAIL PROTECTED]> wrote: > one the download site Restlet 1.1.1 is marked as testing. Is this planned? > I was just wondering this myself. Shouldn't 1.0.11 be relabeled as an "archived" version at this point, and 1.1.X as "stable"?
Enhancement for Router to ignore double slashes?
Hi everyone! Currently, if one creates a route like this: router.attach("books/{book}", BookResource.class); and then sends a request like this: GET books//some_book the response is a 404; the Router, Route, and Template classes consult each other and determine that the requested path is not defined, because of the double slashes. This behaviour makes sense, but I'm interested in a way to put the Router or the Route into a mode wherein they would ignore the double slashes somehow, or collapse them together into a single slash. I tried to follow the Routing code but I couldn't figure it out. So my question: would there be interest in an enhancement such as this? Or does anyone have a suggestion on how to achieve this via filters or services or something like that? Thanks! -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Enhancement for Router to ignore double slashes?
On Mon, Nov 3, 2008 at 19:09, Avi Flax <[EMAIL PROTECTED]> wrote: > ...I'm interested in a way to put the > Router or the Route into a mode wherein they would ignore the double > slashes somehow, or collapse them together into a single slash. I > tried to follow the Routing code but I couldn't figure it out. > > So my question: would there be interest in an enhancement such as > this? Or does anyone have a suggestion on how to achieve this via > filters or services or something like that? Not much interest in this, apparently, which is fine, but I'm still interested, so I'll keep going. I've figured out how to have a Filter, placed in the chain before a Router, remove double-slashes: @Override protected int beforeHandle(Request request, Response response) { Reference ref = request.getResourceRef(); String originalPath = ref.getPath(); if (originalPath.contains("//")) { String newPath = originalPath.replaceAll("//", "/"); ref.setPath(newPath); } return Filter.CONTINUE; } This works just fine. (I know the regex should probably be more sophisticated, but this is more about a proof of concept than production-ready code.) But I'd be interested in having this functionality be built into the framework; using a syntax something like: router.setIgnoreDoubleSlashes(true); or maybe: router.setIgnoreCommonTypos(true); So I'll ask one more time: would anyone else like to see this feature make it into the API? -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Enhancement for Router to ignore double slashes?
On Wed, Nov 5, 2008 at 15:42, Rob Heittman <[EMAIL PROTECTED]> wrote: > I use Reference.getTargetRef() a lot for normalization purposes ... and if > it doesn't already do so, there has at least been discussion of making > getTargetRef() elide stuff like /foo/../bar to /bar, /foo/./bar to /foo/bar, > or /foo//bar to /foo/bar. I think the API feature that might make sense is > one that uses getTargetRef() to normalize all such things to a canonical > reference before routing -- not just //. Makes sense to me! But do Router/Route/Template currently use Reference.getTargetRef() as part of their normal operation, when trying to match a request URL to a Route? If not, that might be a pretty significant change to some core code.
Re: Restlet MVC
Bravo, Rob! I agree 100%! FYI, the FAQ has an entry on MVC: http://www.restlet.org/documentation/1.1/faq#10 Not sure who wrote the answer, but if you do decide to follow MVC, I think the approach presented in the answer makes a lot of sense. Avi -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Restlet MVC
On Fri, Nov 21, 2008 at 09:44, Tim Peierls <[EMAIL PROTECTED]> wrote: > Maybe the first line of that FAQ answer should be modified to avoid the word > "implementation", e.g., "There is a rough correspondence between the MVC > pattern [cite?] and the Restlet framework:" I think we can just change the word "implementing" to "following". But I like the sentence you've proposed; I think we could just add that to the answer, as the first sentence, like so: "There is only a rough correspondence between the http://en.wikipedia.org/wiki/Model-view-controller";>MVC pattern and the Restlet framework; some http://n2.nabble.com/Restlet-MVC-tp1560691p1561792.html";>debate exists as to whether it should be employed at all. For those who wish to follow the MVC pattern with Restlet, here is the basic proposition:" How's that? Jerome, maybe it's time to move the FAQ to the Wiki so it can be more readily edited!
Re: Distributed Caching solution.
On Mon, Nov 24, 2008 at 09:03, Rob Heittman <[EMAIL PROTECTED]> wrote: > I'm not qualified to say which one is "best" as I haven't used Memcache much, > but I can say that I've used EHCache quite a lot within Restlet applications > and am very happy with it. Likewise, but the converse: we use Memcached extensively and we're very pleased with it, but I don't think we've used EHCache. That said, I don't know if either one would be better than the other specifically for a RESTful application; I don't know why an application being RESTful would make a difference. I'd think that what an application does and what sort of data it maintains, and which use cases it's focused on, would matter far more. A quick Google search finds many pages discussing the question of EHCache vs Memcached; this one looks pretty good: http://www.hugotroche.com/my_weblog/2008/06/ehcache-vs-memc.html -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: contributing - areas of interest
On Mon, Dec 8, 2008 at 03:04, Raif S. Naffah <[EMAIL PROTECTED]>wrote: > i'd like to contribute to this project in my free time. > Raif, that's great! Can I suggest RFE 658, Add support for JSecurity? http://restlet.tigris.org/issues/show_bug.cgi?id=658 Since you're interested in security, this might be interesting to you. I'd love to see this one make progress! Thanks, Avi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981192
Re: contributing - areas of interest
On Mon, Dec 8, 2008 at 11:55, Xavier Méhaut <[EMAIL PROTECTED]> wrote: > I didn't know JSecurity before the previous email... It seems quite powerful > and interesting? I actually hadn't known about it before I saw that RFE either, and I had the same impression. (As an aside: this is an aspect of the Restlet project which I really appreciate... I was new to Java when I started using it - in fact, I learned Java so I could use Restlet - and I didn't know anything about the various libraries in the Java ecosystem/community - I didn't know which libraries existed, and which had a good reputation, etc. I've since found that the various libraries which are included with the Restlet distribution tend to be best-in-class, or top-of-class, and it's been very useful that Restlet has introduced them to me. I'm specifically thinking of Jetty, FreeMarker, db4o, apache commons.) > has someone already tried it practically? The RFE mentions: "Tamás Cservenák has sucessfully integrated it with Restlet in Servlet deployment mode: http://restlet.tigris.org/servlets/ReadMsg?list=discuss&msgNo=6834 " - beyond that, I don't know. You may want to search the mailing list. > What would be the the bottlenecks or redundencies while integrating > JSecurity with restlets? I don't know, actually, figuring that out might be the first step in working on this! Are you possibly interested in working with Raif on it? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981205
Re: POST/PUT requests take more than 2 seconds
And which HTTP server connector are you using? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026632
Warning and SocketException when using 1.1.2, built-in server, and FreeMarker
Hello all, When I start up my app, and make the first request to it, I'm seeing this in my console: Feb 19, 2009 10:37:40 PM com.noelios.restlet.http.StreamServerCall complete WARNING: Unable to shutdown server socket java.net.SocketException: Socket is not connected at sun.nio.ch.SocketChannelImpl.shutdown(Native Method) at sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:583) at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360) at com.noelios.restlet.http.StreamServerCall.complete(StreamServerCall.java:102) at com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java:414) at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:148) at com.noelios.restlet.http.StreamServerHelper$ConnectionHandler.run(StreamServerHelper.java:86) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:613) I've confirmed that this only occurs when using the built-in server and returning a TemplateRepresentation. When I return a StringRepresentation the warning does not occur. When I switch to Jetty the warning does not occur. And again, this only occurs for the first request. Subsequent requests do not cause a warning to occur. Here's the Groovy test case I've got it boiled down to: class HelloNameRestlet extends Restlet { public void handle(Request request, Response response) { def data = ["name":"world"] response.entity = new TemplateRepresentation('hello_name.txt.fm', new Configuration(), data, MediaType.TEXT_PLAIN) } } new Server(Protocol.HTTP, 3000, new HelloNameRestlet()).start() Not sure if it matters, but I'm running my tests on an Intel Mac running OS X 10.5.6 and all updates. I've duplicated this issue with Java 1.5/32 and 1.6/64, and with Groovy 1.5.6 and 1.6.0. I'm thinking this might be pointing to a minor bug somewhere, but I couldn't begin to pinpoint where. I'm hoping someone else can! Thanks, Avi -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1196234
Re: Warning and SocketException when using 1.1.2, built-in server, and FreeMarker
On Thu, Feb 19, 2009 at 23:01, Paul Austin wrote: > I found the same issue the other day and have reported a bug. > > http://restlet.tigris.org/issues/show_bug.cgi?id=71 Paul, that's perfect! But issue 71 doesn't seem to be the right one, I think it's actually 732. I'll add my message to the issue, just in case there's something useful in it. Thanks, Avi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1196297
Invalid Success Status When No Client Connector Available?
Hi all! Test case: * Using Restlet 1.1.3, with Groovy 1.6.0 and Java 1.5.0_16 on Mac OS X 10.5.6 on an Intel Mac * I have the two main Restlet JARs in my Groovy lib folder I run this Groovy script: BEGIN CODE import org.restlet.* import org.restlet.data.* url = 'https://www.paypal.com/' println 'Sending GET to ' + url response = new Client(Protocol.HTTPS).get(url) println 'Response: ' + response.status if (response.isEntityAvailable()) println response.entity.text else println 'No Entity Available' END CODE I get this result: BEGIN RESULT --- Sending GET to https://www.paypal.com/ Mar 12, 2009 5:49:16 PM com.noelios.restlet.Engine createHelper WARNING: No available client connector supports the required protocols: 'HTTPS' . Please add the JAR of a matching connector to your classpath. Response: OK (200) - The request has succeeded No Entity Available END RESULT I totally understand why this request didn't work, and why that warning came up - because I don't have a HTTP connector available on my classpath. But the status code of the response is troubling. 200! Shouldn't it be something like 1000 or 1001, a connector error? 200 doesn't seem correct. -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1314505
Re: Tunneling Flex
On Thu, May 14, 2009 at 17:21, William Pietri wrote: > >- Although the APIs might suggest otherwise, the Flex HTTP library is >not very REST-friendly. > > To put it more bluntly, Flex has awful, horribly crippled, support for HTTP. We've worked around it in many hackish ways. At this point, I prefer Javascript for "rich" UIs. -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2352648
Trouble Setting Jetty Parameters with Restlet 1.0
Hi, I'm using Restlet 1.0.10, and I'm having trouble setting the Jetty parameters — specifically, "maxThreads", to limit the number of threads that Jetty uses. Here's what I'm doing: - Server server = comp.getServers().add(Protocol.HTTP, 3000); // The Restlet docs say the param is named "maxThread", but they're wrong server.getContext().getParameters().add("maxThreads", 40); comp.start(); - >From what I can tell from the docs and from reading the source, this looks like it should work. But it isn't. Anyone have any suggestions? Thanks, Avi -- Avi Flax » Partner » Arc90 » http://arc90.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2362672
Checking for Request Entity
Hi all, quick question: I'm using Restlet 1.1.5 to write a quick API stub. I want a resource to allow POST only, and to request that a request entity be sent. The thing that's odd is, when I use curl to test a request without an entity, like so: curl -v -X POST http://localhost:3000/path/to/resource then in my Resource subclass, when I call getRequest().isEntityAvailable() it returns true! This isn't what I expected. Can someone explain why isEntityAvailable() is returning true in this case, and/or suggest a different way to check whether a request entity has been sent? Thanks! Avi -- Avi Flax » Partner » Arc90 » http://arc90.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2376034
Re: Checking for Request Entity
On Tue, Jul 28, 2009 at 05:34, 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=4447&dsMessageId=2380138
Re: Trouble Setting Jetty Parameters with Restlet 1.0
On Wed, Jun 17, 2009 at 02:34, Jerome Louvel wrote: > Sorry, but we don't maintain Restlet 1.0 anymore except within our > professional support plans... Is it possible for you to upgrade to Restlet > 1.1? Maybe you should try updating the Jetty JARs as well. > Hi Jerome, I understand about discontinuing support for Restlet 1.0. However, I'm now experiencing this problem with version 1.1.5 — and I'm using the 1.1.5 Jetty extension, and the bundled version of Jetty. Should I enter this as an issue? Thanks, Avi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2400025
Re: Trouble Setting Jetty Parameters with Restlet 1.0
Never mind, one of my co-workers figured out that I was doing it wrong. Apparently the parameter needs to be in the Server's context *before* it is created. We could use better documentation for this. -- Avi Flax » Partner » Arc90 » http://arc90.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402644
Re: Trouble Setting Jetty Parameters with Restlet 1.0
On Fri, Oct 2, 2009 at 04:22, Jerome Louvel wrote: > This looks like a bug to me. It was actually fixed in Restlet 2.0 trunk, so I > have just ported it back to Restlet 1.1. Ahh, that makes sense. Good news, thanks! > Thanks for the report! My pleasure! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402920
Re: Trouble Setting Jetty Parameters with Restlet 1.0
On Fri, Oct 2, 2009 at 04:22, Jerome Louvel wrote: > This looks like a bug to me. It was actually fixed in Restlet 2.0 trunk, so > I have just ported it back to Restlet 1.1. Thanks for the report! One last thought… I don't know if I'm unique in this or not, but this seems to me like a fairly major bug. While there is a workaround, any app which is coded in the "correct" way will be affected by the bug, which could possibly lock up or crash production services. So, even though 1.1.6 was released only a few days ago, I'd encourage you to consider releasing 1.1.7 sooner rather than later. Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402922
Re: Restlet 1.1.6 released
On Mon, Sep 28, 2009 at 11:42, Thierry Boileau wrote: > Restlet 1.1.6 has just been released. > 12 bugs have been fixed and some libraries have been upgraded. Thanks Thierry, it's good to see 1.1 get better and better. One thought: it would be helpful if these updates were announced on the blog. That way I'd see them in my feed reader. Unfortunately, I don't often have time to peruse the list. Thanks, Avi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402925
Re: Restlet 1.1.6 released
On Fri, Oct 2, 2009 at 09:54, Jerome Louvel wrote: > Good idea. At least we'll try to give notice of 1.1 releases in the blog at > least when it is released in sync with a 2.0 version (which is mostly always > the case). Great, thanks! A thought: I know the focus is 2.0 these days, but as I see it, 1.1 is the "production" version. So I personally would think that broadly announcing bug fixes to 1.1 would be more important than 2.0 updates — or at least, important enough to deserve their own announcement, whether 2.0 is updated or not. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402934
Re: Trouble Setting Jetty Parameters with Restlet 1.0
On Fri, Oct 2, 2009 at 09:50, Jerome Louvel wrote: > This only affect the Jetty connector, but this is annoying indeed. Note that > we do fallback on the default (255) value in this case. Thanks for taking this seriously. I actually think it's more than annoying — 255 threads might be OK for an app running on a dedicated 8-core machine, but many apps run on shared servers, with only 1-4 cores. And of course it depends greatly on what those requests are doing. If handling them requires any lengthy and/or intensive work, handling 255 requests simultaneously could hang or crash the service, or maybe even the entire machine, or at least lock it up for a long time, similar to a DOS situation. This is actually occurring for me in one of my important production apps, but I can't blame it on the bug exactly — I just forgot to set the parameter in my code! Still, the situation I'm experiencing makes clear, to me, the severity of this bug. > I'm currently planning on releasing 1.1.7 in sync with Restlet 2.0 M6, in > about one month. I'd like to fix a couple more bugs pending on 1.1 branch: > http://www.restlet.org/about/roadmap Sounds good! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402938
Re: Restlet 2.0 M6 and 1.1.7 released
On Fri, Nov 20, 2009 at 14:45, Jerome Louvel wrote: > Thierry and I worked hard over the past weeks to deliver our last milestone > before 2.0 feature freeze. We received a lot of contributions as well, which > was a great source of motivation. > > In addition, we are also released 1.1.7, a bug fixing version of our stable > branch. Both releases look great — congrats! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2422967
Re: Restlet 2.0 Best Practices
On Mon, Nov 23, 2009 at 14:58, wrote: > I am evaluating Restlet 2.0 vs. Spring 3.0 for a new project that is starting > soon. I have done a lot of reading on the website and have written a couple > of small programs with Restlet 2.0M6 to get the feel for it. I am looking to > hear from people who have been using it into production about their > configuration choices. We're running 1.1, but my answers might still be helpful. We have 5 complex apps in production. > 1) What connector are you using with Restlet in production? We've been using the Jetty connector for a few years now, and we're very happy with it. > I very much like the idea of not having to run inside of a web container, but > I am not sure from the list of available connectors which are the best for > production, and what are the pros and con's of each connector. Any advice > from the community on this is appreciated. We run our apps as standalone apps — no servlet container — and I'm very happy with this approach. We use the Tanuki Service Wrapper to run them as Windows services. > 2) How are you dealing with Caching on the server side? Mostly Memcache, some OSCache. I prefer Memcache, and after trying out EHCache, I think it's better than OSCache. > 3) Are you finding that the Services / Data Access Layers in Standard Web > Apps don’t apply in the Restlet World? I didn't have a lot of experience with Java web development before I started using Restlet, so I'm not sure what a "Service" is in a "Standard" web app. But I have used a Data Access Object in one of my Restlet apps, and that's worked out just fine. > Given that we are exposing resources and no longer exposing services and > functionality, do you find that the need for Data Access Objects is gone? As > i think about what the app will do, I keep noticing that it is easier to put > the data access for a resource into the Restlet instead of making a Data > Access Object. After all PUT, POST, and DELETE will do something to the > persistent state of the resource and GET will just query it. Thoughts about > this from the community are highly appreciated. This is highly specific to your application. > 4) What does your Restlet production setup look like? Can you elaborate? What kind of information are you looking for? -- Avi Flax » Partner » Arc90 » http://arc90.com ➙ Have you tried Kindling‽ http://kindlingapp.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2424007
[JOB] Developer Needed in New York
Hi all, I hope no one minds me posting this here. We're a web application design and development firm in New York, and we've got some big new opportunities coming up in 2010. We're looking for experienced, dynamic, creative generalists, with a strong background in web application development, particularly with Restlet, to start soon. Please note: this is an on-site, full-time, long-term position. If you're interested, please see our job posting here: http://jobs.37signals.com/jobs/5891 and send me a SHORT note introducing yourself and describing how you'd be a good fit for the position. PLEASE don't reply to the list, unless it's to lambast me for spamming. Thanks, and Happy Hanukkah, Merry Christmas, Happy Winter, etc! Avi -- Avi Flax » Partner » Arc90 » http://arc90.com ➙ Have you tried Kindling‽ http://kindlingapp.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2431516
Simplest way to return an error message?
Hi all, I'm finally writing some code after way too long of a hiatus, and I'm of course getting hung up on some simple things. With 2.0, what's the simplest way to return an error message? I thought it was by throwing a ResourceException, like so: @Post("form") public void accept(Form form) throws ResourceException { throw new ResourceException(Status.CLIENT_ERROR_BAD_REQUEST, "That's not right!"); } But apparently the default StatusFilter doesn't use the "description" field of the status. So my error response is very generic. The status line is "HTTP/1.1 400 Bad Request" and the HTML representation only includes the status name "Bad Request". I know I can subclass StatusFilter and/or StatusService, but I'd be surprised if the framework didn't provide a simple way to return an error message without having to create custom classes. I know I can create my own error representation right in my method, but that also seems like a lot of boilerplate code just to send a simple error message. I know it's only 2 lines of code: getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST); return new StringRepresentation("That's not right!"); But it still seems like a lot — especially if I want to return an HTML document containing the message. So am I missing something? If not, maybe StatusFilter should be updated to include the Status description? Thanks! Avi Avi Flax » Partner » Arc90 » http://arc90.com Kindling: Innovation through Collaboration » http://kindlingapp.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2649905
405 on unsupported media type
Hi all, I'm using 2.0 jse. I've got a method that has this signature: @Post("form") public Representation accept(Form form) throws ResourceException { Everything generally works fine, but when I send a request with an unsupported Content-Type — text/plain, say — the service returns 405 Method Not Allowed. This seems a little off to me — the method I sent was POST, which IS allowed. What's not supported is the content type. I'd prefer the Status Code in this situation to be 400 Bad Request, and for the default error message to explain that the supplied representation is not a supported Content Type. I think that'd be more semantically correct. Does this make sense? I personally would like to see this change made. Thanks, Avi Avi Flax » Partner » Arc90 » http://arc90.com Kindling: Innovation through Collaboration » http://kindlingapp.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2652158
Re: 405 on unsupported media type
Ah, yes, definitely. My bad, thanks. On Fri, Aug 27, 2010 at 16:27, Jonathan Hall wrote: > I believe that's a 415. > > Jon > > On 27/08/10 19:33, Avi Flax wrote: >> Hi all, >> >> I'm using 2.0 jse. I've got a method that has this signature: >> >> @Post("form") >> public Representation accept(Form form) throws ResourceException { >> >> Everything generally works fine, but when I send a request with an >> unsupported Content-Type — text/plain, say — the service returns 405 >> Method Not Allowed. This seems a little off to me — the method I sent >> was POST, which IS allowed. What's not supported is the content type. >> I'd prefer the Status Code in this situation to be 400 Bad Request, >> and for the default error message to explain that the supplied >> representation is not a supported Content Type. I think that'd be more >> semantically correct. >> >> Does this make sense? I personally would like to see this change made. >> >> Thanks, >> Avi >> >> Avi Flax » Partner » Arc90 » http://arc90.com >> Kindling: Innovation through Collaboration » http://kindlingapp.com >> >> -- >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2652158 >> > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2652174 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2652175
NPE in the HttpClient Extension
Hi all, has anyone reported an occasionally NPE in the HttpClient extension, with Restlet 2.0.3? Here's what I'm seeing: INFO: Error while handling an HTTP client call java.lang.NullPointerException at org.restlet.ext.httpclient.internal.HttpMethodCall.sendRequest(HttpMethodCall.java:331) at org.restlet.engine.http.adapter.ClientAdapter.commit(ClientAdapter.java:112) at org.restlet.engine.http.HttpClientHelper.handle(HttpClientHelper.java:110) at org.restlet.Client.handle(Client.java:177) at org.restlet.Client.handle(Client.java:168) Oddly, I only see this on maybe ¼ of my test runs. It seems like it might have something to do with the timing of when my app starts up — I'm really not sure. In my case, I have a Groovy app, my Client is initialized like so: private static final Client client = new Client(new Context(), [Protocol.HTTP, Protocol.HTTPS]) Surprisingly to me, I was getting all sorts of errors until I added this to my main(): component.clients.add Protocol.HTTP (that's Groovy syntax BTW) I was surprised because I thought my Component and my Client were completely isolated from each other. Anyway, I'd appreciate any pointers! Thanks, Avi Avi Flax » Partner » Arc90 » http://arc90.com Kindling: Innovation through Collaboration » http://kindlingapp.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2690543
Setting timeout on built-in client connector of 2.0
Hi all, I’ve been digging through the docs but I can’t figure this out. I’m trying to set the timeout used by an instance of ClientResource. I figured I could do that by setting a parameter of the ClientResource’s Context before making any requests. However, I can’t seem to identify any parameter which would set the timeout for the built-in client connector, even when using the Client class directly. I’d appreciate any pointers on this! Thanks, Avi Avi Flax » Partner » Arc90 » http://arc90.com Readability » Enjoy Reading, Support Writing » http://readability.com Kindling » Innovation through Collaboration » http://kindlingapp.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2713284
Documentation on Component-based Client reuse
I’ve always had a vague awareness that when an application used a Component, somehow instances of Client would be reused, somehow automatically behind the scenes. Is this still the case with 2.0 and/or 2.1? If so, can anyone point me to some documentation on how this works? Thanks! Avi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2876178
Re: Using MetadataService to specify the default media type
On Thu, Jan 19, 2012 at 05:20, Jerome Louvel wrote: > The proper/standard way in HTTP to do this is to correctly set the > preferences of your clients (via the “Accept” header typically)… Otherwise, > the order of the annotated methods declaration might be taken into account > by Restlet when deciding how to dispatch the method call, but I wouldn’t say > it is a safe bet to solely rely on this default behavior. > > You could customize the ConnegService attached to your parent application to > force the variant when client preferences are not explicitly given > (MediaType.ALL), or plug a custom filter in the routing chain to enforce > your policy. Jerome, I’m using 2.0, and I need a way to set the default variant of my resources. I’m frustrated because I’d think this’d be a common need and it really should be easier and clearer how to do this. I need to support requests which don’t include an Accept header, and I need to be able to set the default variant concisely on a resource-by-resource basis — not in a centralized Service or Filter. With the resource I’m working on now, I first tried to just use a single annotation: @Get(“html|xhtml”) public Representation getRep(Variant variant) { … } I assumed that when a request didn’t include an Accept header, the conneg algorithm would take into account the order specified and use html as the default. Unfortunately it does not — for some reason, xhtml is chosen as the default. Unsurprisingly, the same is true if I use two separate methods: @Get(“html”) public Representation getHtml() { … } @Get(“xhtml”) public Representation getXhtml() { … } IIRC, in Restlet 1 this was fully supported — the first variant passed to getVariants().add() was considered the default. I still need this functionality. I don’t know if it’s too late to change this for 2.0 (I’d love to submit a patch…) but I’d at least like to see this improved for 2.1 — I think the order specified in the annotation parameter should be significant, with the first one specified used as the default. For now, I’m not even sure how I’m going to make this work in the resource I’m working on today — I might just do something hacky like this: if (acceptHeader != null && acceptHeader.contains("application/xhtml+xml") && ! acceptHeader.contains("text/html")) representation.setMediaType(MediaType.APPLICATION_XHTML); Thanks, Avi Avi Flax » Arc90 » http://arc90.com Kindling » Innovation through Collaboration » http://kindlingapp.com Readability » Enjoy Reading, Support Writing » http://readability.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2916957
Re: Using MetadataService to specify the default media type
Ping? On Wed, Feb 1, 2012 at 12:05, Avi Flax wrote: > Jerome, > > I’m using 2.0, and I need a way to set the default variant of my > resources. I’m frustrated because I’d think this’d be a common need > and it really should be easier and clearer how to do this. I need to > support requests which don’t include an Accept header, and I need to > be able to set the default variant concisely on a resource-by-resource > basis — not in a centralized Service or Filter. > > With the resource I’m working on now, I first tried to just use a > single annotation: > > @Get(“html|xhtml”) > public Representation getRep(Variant variant) { … } > > I assumed that when a request didn’t include an Accept header, the > conneg algorithm would take into account the order specified and use > html as the default. Unfortunately it does not — for some reason, > xhtml is chosen as the default. > > Unsurprisingly, the same is true if I use two separate methods: > > @Get(“html”) > public Representation getHtml() { … } > > @Get(“xhtml”) > public Representation getXhtml() { … } > > IIRC, in Restlet 1 this was fully supported — the first variant passed > to getVariants().add() was considered the default. I still need this > functionality. > > I don’t know if it’s too late to change this for 2.0 (I’d love to > submit a patch…) but I’d at least like to see this improved for 2.1 — > I think the order specified in the annotation parameter should be > significant, with the first one specified used as the default. > > For now, I’m not even sure how I’m going to make this work in the > resource I’m working on today — I might just do something hacky like > this: > > if (acceptHeader != null && > acceptHeader.contains("application/xhtml+xml") && ! > acceptHeader.contains("text/html")) > representation.setMediaType(MediaType.APPLICATION_XHTML); > > Thanks, > Avi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2922447
Re: Using MetadataService to specify the default media type
On Wed, Feb 22, 2012 at 05:48, Thierry Boileau wrote: > I've made some tests using Restlet 2.0 and 2.1. From what I notice, in this > case, the order is not significant. > I get the "xhtml" representation instead of the "html" one in both cases : > @Get(“html|xhtml”) and @Get(“xhtml|html”) > > Here is my explanation : "html" is a shortcut for "text/html" and "xhtml" > stands for "application/xhtml+xml". > When the client provides no preference, then the default one set on the > MetadataService is applied : by default "application/octet-stream". > The curent score algorithm gives a better affinity between > "application/xhtml+xml" and "application/octet-stream" than between > "text/html" and "application/octet-stream", because of "application/"... The > scores are very low : 0.0006 and 0.0003 but the difference is real. > > Good news anyway, you can set the default media type of the application's > MetadataService to a neutral one : "*/*" : > getMetadataService().setDefaultMediaType(MediaType.ALL); > > In this case, the order is significant, once again. Thanks Thierry, this is very very helpful, I appreciate you looking into this. First: I suggest we make MediaType.ALL the default in 2.1 and 2.2. Second: I’ve made this change in my application, and it seemed to work at first — but it turns out that the behavior of my resource, when I don’t send an Accept header, has become unpredictable. I have these two methods in my resource class: @Get("html|xhtml") public Representation getHtml(Variant variant) and: @Get("json") public Representation getJson() now that I’ve made this change, most of the time when I run my app and make a request for this resource without the Accept header, I get back a response with the Content-Type being text/html, which is what I want and expect. However, sometimes when I start my app and make the request, I get back a JSON response. This is of course not acceptable; I need the behavior of my app to be predictable and consistent. Unfortunately I can’t give you statistics on how often this occurs; my app takes a long time to start up. Off the top of my head, it seems to be around 20% of the time. Can you suggest any theories for why this might be happening, and some possible ways to prevent this from happening? Thanks! Avi Avi Flax » Arc90 » http://arc90.com Kindling » Innovation through Collaboration » http://kindlingapp.com Readability » Enjoy Reading, Support Writing » http://readability.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2936716