Jetty 9.3 connector
Please help me test it! Especially exciting is support for HTTP/2. Available here: https://github.com/tliron/restlet-jetty9 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3128986
Two new beta products for Restlet
After many dev releases, I'm happy to announce the betas for two new products of interest to Restlet users. Both of these products require JVM 6+, but also make use of the new Nashorn engine when run on JVM 8. SINCERITY This is a package/bootstrapping manager for the JVM. It comes with skeletons for many platforms and frameworks, among them Restlet. Using the Restlet skeleton, you can quickly and easily install Restlet and its extensions into a container, and write simple JavaScript code to bootstrap your component, connectors, virtual hosts, and applications. http://threecrickets.com/sincerity/ecosystem/skeletons/#restlet-skeleton Easy-to-install and easy-to-use Sincerity plugins include support for high-performance logging (based on Log4j 2.0), and Tanuki service wrapper. No need to keep reinventing wheels for every new Restlet project! With Sincerity, you can thus focus on writing your Restlet resources instead of assembling a component. Sincerity will download/upgrade packages from any Maven-type repository, but additionally supports very useful extended features. Three Crickets now maintains a free online repository with Sincerity-empowered packages. PRUDENCE 2.0 This is a complete re-imagining of the web page and web API platform since version 1.1. As before, it comes with state-of-the-art scalability features (integrated caching, clustering), but now features vastly easier configuration and deployment, and a simplified and enriched API. The documentation is especially comprehensive and friendly. Prudence 2.0 was is designed on top of Sincerity, indeed as an extension of the Restlet skeleton mentioned above. (Sincerity was, in fact, was originally designed for deploying Prudence, but has proved generally effective.) http://threecrickets.com/prudence/ Prudence lets you write RESTful resources and web pages in JavaScript, Python, Ruby, PHP, Lua, Groovy or Clojure. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3071732
RE: Re: Re: Re: Re: Re: Jetty 9?
Great! I agree with this new direction. Well, for now I will implement your requested feature. Hi Tal, In RF 3.0, we should really give more precise control regarding extensions -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3070826
RE: Re: Re: Re: Re: Jetty 9?
Actually, it's a feature I would like to see with *all* Restlet extensions: it would be nice for users to be able select which extensions they want to use, rather than configure it solely via the classpath. Possibly with Java properties? I can imagine every extension class having an enabled property. Thanks Tal, this looks great. We might want to add parameters to disable/enable the client/server connector from the extension as a second step to allow mixing of several connector extensions. I've added a note about this to the matching ticket: https://github.com/restlet/restlet-framework-java/issues/512 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3069272
RE: Re: Re: Re: Jetty 9?
I went ahead and also added a Jetty 9 client connector: https://github.com/tliron/restlet-jetty9 Note that if you add the Jar to your classpath, both the server and client connectors will be activated. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3069061
RE: Re: Re: Jetty 9?
Binaries and API documentation are now available via the GitHub project site. Enjoy! https://github.com/tliron/restlet-jetty9 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068157
RE: Re: Re: Re: Jetty 9?
Excellent. If anyone has comments, here is the GitHub issue: https://github.com/restlet/restlet-framework-java/issues/793 That's fine Tal, whatever works best for you. Merging by hand won't be a big issue anyway. You might want to enter an issue in RF repo to let people discover this support and let us communicate over it. Best regards, Jerome -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068106
RE: Re: Jetty 9?
So, I went ahead and created a Jetty 9 extension for Restlet 2.2: https://github.com/tliron/restlet-jetty9 It's not much tested (especially SSL), but it does work! There are also 2 helper parameters that I still haven't found how to duplicate on Jetty 9, so they are just be ignored. Actually, I would prefer a more major refactor, because Jetty 9 is different enough that it would demand a different set of parameters. Jetty 9 is a major overhaul of the API: it was naïve of me to think it could just be a drop-in replacement. :) Obviously, you need at least JVM 7 to use Jetty 9. As I said, would prefer to contribute this to Restlet, but the JVM 7 requirement makes it awkward. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068074
RE: Re: Re: Jetty 9?
Thanks, Jerome. I picked the Apache License 2.0, and am hosting it as a separate project. I'm assigning joint copyright on it to Restlet S.A.S, per the contributor agreement, so you are free to merge it should you ever wish to do so: https://github.com/tliron/restlet-jetty9 Rather than a branch, it's its own tiny repository. I know you've made many efforts to make things easier for contributers, but alas it's still too cumbersome for me. The Restlet repository is enormous and unwieldy, and in fact I haven't been able to build it at all. It's just too much effort over no clear gain to be part of the incubator at this point. Maven builds, especially, make it trivial to use the Restlet binaries without having to be part of the git tree. Just treat the project as an incubator if you like! I suggest that you create a new /restlet-framework-java/master/incubator/org.restlet.ext.jetty9 extension by copying then adapting the o.r.e.jetty extension. You can always have you own branch in GitHub and then merge it back when master becomes ready for RF 3.0 (Java 7), but from a licensing point of view you can't offer all the available open source licenses and would need to pick one (I suggest Apache license). Best regards, Jerome -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068100
Jetty 9?
Can Restlet 2.2 work use Jetty 9 as its connector? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3067974
RE: Jetty 9?
The answer, unfortunately, is no: Restlet uses AJP to connect to Jetty, which is unfortunate because it's not a recommended protocol, and has been dropped in Jetty 9. Would it be possible to change the Jetty connector so that it would work with either Jetty 8 or 9? It's very unfortunate that Restlet is always behind on the latest releases of Jetty, -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3067981
RE: Re: Jetty 9?
The API has indeed subtly changed, so that throwing in the Jars will not work. And though Restlet doesn't use AJP to communicate with Jetty, it does try to initialize AJP support, and those classes no longer exist in Jetty 9, thus another kind of failure. Bottom line, it won't work. Jerome, Jetty 9 is an important feature for me, but I understand that it would be difficult to include this support in the Restlet main code base, because it would indeed require JVM 7 to compile. What is your opinion about me forking and hosting a jetty9 extension separately from the Restlet tree? I would be happy to keep the same multiple licenses. And eventually, when Restlet becomes ready for JVM 7, it could be merged into the main tree. Another idea is to create yet another repository within Restlet for contrib extensions from the community. They could be included in the Restlet distribution, each with its own documentation and possible quirks, clearly demarcated from the core extensions. -Tal Restlet integration with Jetty (the org.restlet.ext.jetty extension) isn't based on AJP but on core Jetty APIs, enable support of HTTP/HTTPS and AJP. I haven't tried but dropping new Jetty JARs might just do it, but likely they have changed their internal API here and there and some patches will be required. Anyone want to have a look? The main issue I see for Jetty 9 in RF 2.2 is their requirement on Java 7... It seems like the official support should come instead in RF 3.0. Jerome 2013/11/6 Bryan Hunt bhunt at mac dot com You can always use the servlet extension with Jetty. Bryan On Nov 06, 2013, at 08:45 AM, Tal Liron tal dot liron at threecrickets dot com wrote: The answer, unfortunately, is no: Restlet uses AJP to connect to Jetty, which is unfortunate because it's not a recommended protocol, and has been dropped in Jetty 9. Would it be possible to change the Jetty connector so that it would work with either Jetty 8 or 9? It's very unfortunate that Restlet is always behind on the latest releases of Jetty, -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3067981 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068043
Restlet 2.2
Any idea or plan on when 2.2 will be released? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3066202
VirtualHost configuration
I use virtual hosts a lot, but I almost always use setResourcePort so that applications can work on different ports. I'm wondering: 1) What is setServerPort for? 2) What is setHostPort for? Setting either of these seems to make no different in routing incoming requests. The JavaDocs for VirtualHost are very lean, and could definitely use some more detail! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3047996
RE: ZipException with Restet 2.1 RC6
The DEFLATE issues: https://github.com/restlet/restlet-framework-java/issues/653 https://github.com/restlet/restlet-framework-java/issues/654 The decoding/encoding issue is trickier, and may require some discussion: https://github.com/restlet/restlet-framework-java/issues/655 I'm copy-pasting my suggested solution here, in case the mailing list would like to chime in with ideas: For chunking, it is necessary for the channel to decode the entity and re-encode the separate chunks. However, a much more optimal situation would be for this extra decoding/re-encoding not to occur. I can think of two possible solutions: 1. If Restlet knows that it will have to re-encode the entity, it should set the preferred Encoding to null for downstream, while storing a flag (request attribute?) telling it to encode on the way back. This way a ServerResource would know to provide an un-encoded entity and let ReadableChunkingChannel handle all the encoding. The advantage of this solution is that it's entirely transparent and would work for existing code. Unfortunately, if the ServerResource supports caching of any kind, it would not be able to cache encoded chunked representations. 2. It may be possible for ServerResource to detect that chunking is happening, in which case there may be a way to create a special kind of Representation (ChunkedRepresentation?) that encodes each chunks separately. The advantage of this solution is in the ability for caching optimization: the ServerResource would be able to cache ChunkedRepresentations according to chunk size and avoid unnecessary encoding. Ideally, Restlet would support both! However, I imagine that option #1 would be best as the default mode, with an API allowing a ServerResource to handle chunking via option #2. +++ I should note that as Prudence developer, I would strongly suggest that option #2 exist. Prudence does aggressive caching, and separately caches entities in all encoded variations, guaranteeing that encoding only ever happens once for cached entities. Unfortunately, option #1 would break this optimization and introduce encoding. (It's much worst at the moment, because Restlet will decode and re-encode.) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3005684
RE: ZipException with Restet 2.1 RC6
OK, I now understand what is causing these exception and would like to suggest a solution in Restlet. The issue is in Restlet's ReadableChunkingChannel. In order to chunk an existing representation, it needs to first decode it if it's encoded. In the case of Encoding.DEFLATE, it would thus use an InflaterInputStream instance. Unfortunately, there are two incompatible versions of the DEFLATE algorithm. The default in the JVM is to use wrap mode, but you can explicitly set nowrap mode like so: new InflaterInputStream(stream, new Inflater(true)) Even more unfortunately, certain versions of Microsoft's Internet Explorer only support the nowrap mode. So, you absolutely *must* set the nowrap flag if you want to support IE when generating your own encoded Restlet representations. So, what can Restlet do about this? There can be two Encoding constants, one for each supported mode. The usual DEFLATE, and perhaps DEFLATE_NOWRAP. In terms of outgoing HTTP headers, they should be identical, but the Restlet stack should be able to maintain the correct version of algorithm throughout, for example in ReadableChunkingChannel. (It must also re-encode the chunk in the correct version of the algorithm.) A simpler solution may be to simply use nowrap always in Restlet. I've done this in my pre-2.1 Restlet applications in order to support IE properly. But, there are advantages to allowing developers some control over this. A related side question: Is there be a way to avoid the decoding-re-encoding done by ReadableChunkingChannel? Specifically, is there a way to send the representation already chunked from the ServerResource? -Tal I'm getting these exceptions occasionally on a few specific resources, not sure yet how to reproduce. Has anyone else seen them and have any information? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3005128
RE: ZipException with Restet 2.1 RC6
I'll just quickly point out there is *another* bug here. Because Restlet's EncodeRepresentation class does not use nowrap encoding, DEFLATE encoding will be broken for certain versions of Internet Explorer. This bug may well very have existed in Restlet for a long time. -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3005141
ZipException with Restet 2.1 RC6
I'm getting these exceptions occasionally on a few specific resources, not sure yet how to reproduce. Has anyone else seen them and have any information? I'm getting them both the internal connector and with Jetty. Stack trace example: 2012-08-28 22:23:19,233: WARN [org.restlet.Component.InternalRouter.Server] Unable to read the entity java.util.zip.ZipException: incorrect header check at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164) at org.restlet.engine.io.InputStreamChannel.read(InputStreamChannel.java:156) at org.restlet.engine.io.InputStreamChannel.read(InputStreamChannel.java:136) at org.restlet.engine.io.ReadableChunkingChannel.read(ReadableChunkingChannel.java:137) at org.restlet.engine.io.Buffer.fill(Buffer.java:395) at org.restlet.engine.connector.OutboundWay.onFill(OutboundWay.java:345) at org.restlet.engine.io.Buffer.process(Buffer.java:601) at org.restlet.engine.connector.Way.processIoBuffer(Way.java:477) at org.restlet.engine.connector.OutboundWay.processIoBuffer(OutboundWay.java:420) at org.restlet.engine.connector.Way.onSelected(Way.java:430) at org.restlet.util.SelectionRegistration.onSelected(SelectionRegistration.java:325) at org.restlet.engine.connector.Connection.onSelected(Connection.java:611) at org.restlet.util.SelectionRegistration.onSelected(SelectionRegistration.java:325) at org.restlet.engine.connector.ConnectionController.onSelected(ConnectionController.java:208) at org.restlet.engine.connector.ServerConnectionController.onSelected(ServerConnectionController.java:99) at org.restlet.engine.connector.ConnectionController.selectKeys(ConnectionController.java:294) at org.restlet.engine.connector.ConnectionController.doRun(ConnectionController.java:162) at org.restlet.engine.connector.Controller.run(Controller.java:159) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3001770
RE: Restlet Framework 2.1 RC6 and 2.0.15 released
I've been experimenting with 2.1 for a while with a few big Restlet applications. I want to point out that 2.1-RC6 is the first version of Restlet (including all the 2.0 line!) in which I could use Directory over the internal connector without any response hangs. Hooray, it may be possible to finally remove my dependency on Jetty! (In 2.0, I used Grizzly for a comparable workaround.) I know I should have opened a bug on this in the past, but it's just been so persistent for so many versions, and there was a simple enough workaround. Nevertheless, I would sometimes remove Jetty just to see how the internal connector was behaving... and it looks good. Good job, bug reporters and bug fixers! -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3000664
RE: Restlet 2.1 to use jetty 8?
I was about to do this myself, but thanks very much. :) :) Why not have 2.1 use Jetty 8? Related: I recommend updating the Jackson plugin to use the 2.0 line. The API is the same, but there is a namespace change. If you update it, it would allow users to upgrade the jar without problems. Otherwise, they will be stuck in 1.0. Hi Tal, Good news, I updated the 2.1 branch today with Jetty 7.6.5 version and 2.2/master with Jetty 8.1.5 ! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2992264
RE: Restlet 2.1 to use jetty 8?
To add information from my testing: Restlet 2.1rc5 seems to work fine with Jetty 7.5.4, so I imagine it would be trivial to update Jetty to that. However, it does not work with Jetty 7.6 nor Jetty 8. There are likely API updates necessary. I hope Restlet 2.1 can be released with support for the latest Jetty version. -Tal Restlet 2.1rc5 ships with Jetty 7.4, but the Jetty 7 line is already at 7.6.4. Will this be updated for the final release? Also, will it be possible to use the Jetty 8 line, which supports the servlet 3 API? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2989686
Patched Restlet in Nexus?
Would anybody on the list happen to know the story behind the patched version of Restlet 1.1.6 that's included in Nexus 2.0.2? It is marked version 1.1.6-SONATYPE-5348-V4. From what I can tell, they were trying to solve a problem with the Apache HTTP Client extension (they patched that library, too). Are there missing features them from upgrading to Restlet 2.0/2.1? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2938009
RE: Re: Re: Re: Status of Asynchronous Support
Jerome, You make a lot of sense. I agree with you that Jetty's solution is complicated, but I was 1) hoping we could do it more straightforwardly in Restlet (possibly a naive hope), and 2) a graph (and other) solutions would have their own complexity. There's really no simple way out of this. That said, the graph approach is programatically more comprehensible, and also more idiomatic to Java, than simulating continuations. (I'd also add that functional languages would make this problem much more comprehensible, but I'm afraid that Tim would bite my head off, so I won't...) I was also thinking of the problem in a far more local sense -- a single thread committing -- rather than the more complex scenarios you've listed, of chunked responses, which I imagine would be extremely useful in the new streaming applications to which Restlet is being applied, with Noelios' terrific new partnerships. So, yes, I'm fully in agreement with the graph approach, it is comprehensive and can potentially address all needs. So, it'll be ready next week? ;) Happy new year! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2903175
RE: Re: Re: Status of Asynchronous Support
I see. Well, how about this: Perhaps setAutoCommit(false) might be the wrong approach. If anybody else along the chain tries to commit, it should fail somehow. How, then, would response.commit() know when it's time to really, truly commit? My idea is to make a commitment to commit (ha!) via a kind of token, which would identify the committer. The flow would be something like this: Object token = response.deferCommit(); ... From now on, the response has a flag telling it that commitment is deferred, and it will fail on all commit() calls, unless the token is provided. ... Later, on some other thread: ... response.commit(token); ... The above will actually commit, because the token was provided. Hopefully my test code can be turned into a unit test for whatever solution is found (though reliable unit tests for race conditions are notoriously hard to get right). My understanding of Jerome's e-mail of 2010-Aug-30 (has it really been that long?) is that it's not sufficient to unwind the stack, whether by exception or by testing response state. The main problem is arranging for the calls to afterHandle to occur in a different thread. These are calls that would have been executed on a committed response as part of the normal stack unwind. While it *might *be a reasonable implementation choice to use an exception internally, it's not a real exception that can be allowed to propagate arbitrarily, because it's OK, not exceptional, for the original thread to return without a committed response. This is a tough problem. --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2899593
RE: Re: Re: Re: Status of Asynchronous Support
I would have two answers: 1) Isn't that the price to pay for asynchronicity, and the desire of the user? The whole point is to implicate a different set of threads into communication with the client. Of course, hybrid thread-pool-plus-event-driven servers come to mind, which queue up event responses but handle them on a single thread pool. There are advantages to that, but it didn't seem to be the design goal for Restlet. 2) It could be handled by the application's TaskService. Still, I would imagine that the user would not always want that. How about this: response.commit(token) ...to commit in the current thread, and... response.commitLater(token) ...to commit in the TaskService. But doesn't that still leave the problem of arranging for all the afterHandle calls to happen in the thread that does that commit? That's what scares me. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2899780
RE: Re: Status of Asynchronous Support
Jerome, What about my idea of throwing a special exception, something like ResponseCommitDeferredException? Exceptions are an easy and natural way in the JVM to unwind a call stack. The exception would go up to the lowest possible level, where it explicitly caught and set to wait. Nothing along the way would have to know any specific about it. Hi Tim, Yes, this is a good summary of the API refactoring intent. Actually it would be a bit simpler as the stack would only contain Restlet instances part of the processing chain, not lower level Java methods. Another key aspect is that a call to Restlet#handle() would not take care itself of invoking the next Restlet in the chain otherwise the stack wouldnt be properly populated. Maybe the next Restlet should be the result of the call to Restlet#handle() . handle the call at your level and then return the control to the caller by indicating the next Restlet if any, and let the caller invoke this next Restlet after updating the Restlet stack. Best regards, Jerome -- http://www.restlet.org/ http://www.restlet.org http://twitter.com/#!/jlouvel http://twitter.com/#!/jlouvel De : tpeierls at gmail dot com [mailto:tpeierls at gmail dot com] De la part de Tim Peierls Envoyé : jeudi 22 décembre 2011 19:01 À : discuss at restlet dot tigris dot org Objet : Re: Re: Status of Asynchronous Support Jerome said earlier in this conversation: The only way I see to solve this issue for now (2.1) would be to maintain a custom Restlet call stack containing the list of Filters that intercepted the inbound call and make sure that their afterHandle() method is invoked by the asynchronous response thread. Trying to flesh this out in my head: So the same logic that calls beforeHandle would push the corresponding afterHandle call onto a stack associated with the response; setting committed false would prevent the normal afterHandle machinery from executing, and the commit() machinery would be given access to the stack so it could pop those afterHandles and call them? Afaict, this isn't in yet, so I think it would be safer to say that asynch I/O is still in preview mode for 2.1. Am I being too pessimistic? --tim On Thu, Dec 22, 2011 at 12:56 AM, Tal Liron tal dot liron at threecrickets dot com wrote: I have created the simplest example I could to prove my point, and hopefully to help find a solution to this important problem: https://github.com/tliron/restlet-async-test The current code works as expected -- but only because AsyncResource.delay is non-zero. If you set the value to zero, then the Restlet chain will do its work before the AsyncResource commits, and then the resource will not return the entity. No exceptions get thrown -- the code is thread safe -- but it still shows that it's impossible to reliably handle async responses. I hope other people can take a look and let me know if I missed something important. Jerome, even though setCommitted(false) gets called, there still the usual processing of handle() in the entire restlet chain (the Finder, delegating to the UniformResource, etc.). Within these routines, the return values from various callbacks are handled. Stuff that happens there on the response can override work being done in another thread. The response is thread safe, but it's still not the intended result. I don't have a test case right now, but it would be easy to produce: simply call setCommitted(false) in a ServerResource annotated @Get implementation, and immediately move processing to a thread, where commit() is eventually called. The worker handler thread would overlap with the work done in the regular Restlet handling thread and you would get weird statuses and response entities. The reason I suggest an exception (and I share Tim's unease with it) is that it's a way to stop the handling chain in the regular thread, so that only the new handler thread would have free reign on the response. But it doesn't have to be an exception. Another solution would be for ServerResource, UniformResource and Finder to be refactored specifically to handle the committed=false case. I worry, though, that future work or custom implementations would not handle the case properly. -Tal On Sun, Jul 11, 2010 at 9:00 PM, Jerome Louvel jerome dot louvel at noelios dot comwrote: Hi Tal and Tim, There is a way to signal an asynchronous response on a per-call basis, calling Response#setCommitted(false). Then, if you call Response#commit() before the initial request thread reaches back the connector, this should work fine as well. Im not sure yet how it could get corrupted. Do you have a precise scenario? Note that the NIO version of the asynchronous internal connector has been moved
RE: Restlet with Apache HTTP Client does not deal well with followingRedirects
Has this issue ever been resolved? Should I open a bug for it? Sigh, it's been a long two days. The bottom line is that if you use Client or ClientResource over the Apache HTTP Client, you better not use followingRedirect=true, or else you'll get hanging threads due to connections not being returned to the Apache Client's connection pool. The issue is that Restlet (2.0.7) executes an additional GET request for the redirect, but does not release the representation for the first GET that contains the redirect response. You can reproduce this easily by trying more than 10 GET requests to http://google.com/; (which will redirect you to http://www.google.com/; and return an entity). After 10 requests, your Restlet Client class will hang. :/ I hope this gets fixed and can be merged into the 2.0 branch! My deployments are not yet ready to shift to 2.1. In the meantime, use my simple (if annoying) workaround: setFollowingRedirect(false). You will have to handle redirects via your own logic. (After a few wild goose chases, I now know far, far more than I ever wanted to know about the internals of the Apache HTTP Client. Its architecture is actually similar to Restlet's in many ways!) And ... you're welcome. -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2899007
Asynchronous support in 2.1
html style=direction: ltr;
head
meta http-equiv=content-type content=text/html;
charset=ISO-8859-1stylebody
p { margin-bottom: 0cm; margin-top: 0pt; } /style
/head
body style=direction: ltr;
bidimailui-detected-decoding-type=latin-charset bgcolor=#FF
text=#00
pHi,/p
pI would like to resurrect a very old thread, from more than a
year ago:/p
pa class=moz-txt-link-freetext
href=http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447amp;dsMessageId=2612147;http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447amp;dsMessageId=2612147/a/p
pLooking at the state of Restlet 2.1, I can't seem to find a
solution to the old problem, which implies asynchronous support is
still broken./p
pTo rehash the problem:/p
pEven if I set autoCommitting to false, parts of the Restlet
framework upstream will modify the Response (there is nothing to
stop them, since they have no idea about autoCommit downstream).
Their actions can easily interfere with my own comitter code,
which may be trying to modify the response at the same time. So,
the commit as a whole ends up being non-atomic and prone to race
conditions./p
pMy suggestion back then was to throw a special exception class
that would force upstream Restlets to avoid any kind of messing
with the response. We don't like adding more exceptions, but in
this case there is an obvious advantage of using the exception
unrolling feature of the JVM to elegantly send messages upstream.
(Another solution would be to set a special flag in the response,
but this would require all upstream restlets to explicitly check
for this flag.)br
/p
pSo, I'm wondering what's the status of this now! This is a
feature I've been wanting to see in Restlet for years. The
potential is there (the concurrency stuff is well handled), but
there is still this missing piece of the mechanism.br
/p
p-Talbr
/p
/body
/html
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2848707
RE: Prudence 1.1.1 released
I apologize, Jerome. I thought it would be interesting for Restlet users to see how Prudence was progressing. There is not a lot of traffic on the mailing list these days, so I thought some news would be nice! I will refrain from posting about minor releases. -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2827342
Prudence 1.1.1 released
This is a maintenance release that mostly involves upgrading a few dependencies and improving various pain points in the distributions (many of those are thanks to enthusiastic feedback from Beth Marston). It should now be easier than ever before to hit the ground rolling with Prudence. This release does not fix any major bug and it is not necessary to upgrade if none of the issues listed below affects you. Ubuntu repository users will be upgraded automatically. There is also a revised download page that will hopefully reduce the chance of confusion for new users: http://threecrickets.com/prudence/download/ Note that the Savory JavaScript flavor is now recommended for beginners. (The Kitchen Sink edition is a poor choice for beginners, due to the requirement of also having to install Quercus.) Revision 1064: * Distribution: archives now preserve executable permission in Unix-like systems (including OS X) (issue #9) * Distribution: archives now include a root directory (issue #10) * Distribution: an informative readme.txt is now included, with instructions on installation and troubleshooting (issue #11) * Distribution: make sure all text files are in Windows-friendly format (CR-LF line ending) * Distribution: cleaner packaging of jQuery, now also including the license * Stickstick: fixed for newer versions of WebKit browsers (Safari, Chrome) via upgrading jQuery * Dependency bumps: Restlet 2.0.9, H2 1.3.156, MongoDB Driver 2.6.5, Hazelcast 1.9.3.4, JRuby 1.6.3, Groovy 1.8.1, jQuery 1.6.2, jQuery UI 1.8.16 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2827087
RE: Re: Prudence 1.1 and the Savory Framework for MongoDB
It's a standard Subversion repo on Google Code, so I think it should work with Beanstalk! (I've been considering switching to Mercurial, but I think Subversion serves the most important needs for now.) I'm not married to MongoDB, but we are having a sordid love affair. :) The NoSQL database are all quite different from each other in terms of features and performance characteristics, and I strongly believe Mongo offers the best choices for most web developers. Savory very much embraces MongoDB and uses many of its atomic update features to the max. This does not mean that it's impossible to adapt many of the features for other databases. In many cases, all you need to do is extend a class and provide your own implementation. It can also make sense to mix MongoDB with other databases. There's been a lot of interest in integrating Savory with neo4j. We'll see how things progress! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2783443
Prudence 1.1 and the Savory Framework for MongoDB
of Prudence and MongoDB can take your backend very, very far. And Savory makes it even tastier. Our web development framework tastes better than yours. Yours, Tal Liron, Three Crickets LLC -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2781974
RE: Prudence 1.1 and the Savory Framework for MongoDB
If you live in Chicago, come to the July 6 2011 MongoDB meetup, where I will be presenting Savory, and showing some wild Ext JS and Sencha Touch tricks: http://www.meetup.com/Chicago-MongoDB-User-Group/events/21369271/ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2781977
RE: Re: Different deployment schemes for the same Restlet-based Application
Fabian, This is the $1,000,000 question, quite literally. I happen to think that deployment -- a term often considered by engineers only at the very end of their project -- is more likely close to 50% of their work effort. I've never seen any real-life project for real people (other than some open source library released to a few geeks) that doesn't have serious and expensive deployment challenges. Though Tim is apologizing for his elaborate answer, if anything it's too simplistic: this is an enormous challenge that can't be solved in a simple email. If you wait for Jerome's Restlet book, it will offer you quite a bit of advice on deployment! From what I read in the early version, it's not a small chapter, and it still only scraped the surface. JEE is one way to go: there are big, complicated products out there (JBoss) that implement deployment standards in complex ways that have proven themselves in many enterprises. People also seem to like adding Maven, OSGi and other technologies in their deployments, trying to integrate development with deployment. Perhaps a developer's pipe dream? I'm a consultant who has left the enterprise behind, and see a lot of my clients are trying to move away from this old, heavy term and think in more agile ways. I love Restlet and can't think of a better way to develop internet/intranet applications right now, in any language and on any platform. Which is why I decided to develop a container for Restlet applications that is based on Restlet and not JEE, and is more oriented towards agile than the enterprise: http://threecrickets.com/prudence/ It started pretty much like Tim: I was rolling my own until I realized that I can't keep rolling my own for every new client without exhausting myself, and that other people could benefit and help me in my work. Viva open source! -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2747769
Restlet with Apache HTTP Client does not deal well with followingRedirects
Sigh, it's been a long two days. The bottom line is that if you use Client or ClientResource over the Apache HTTP Client, you better not use followingRedirect=true, or else you'll get hanging threads due to connections not being returned to the Apache Client's connection pool. The issue is that Restlet (2.0.7) executes an additional GET request for the redirect, but does not release the representation for the first GET that contains the redirect response. You can reproduce this easily by trying more than 10 GET requests to http://google.com/; (which will redirect you to http://www.google.com/; and return an entity). After 10 requests, your Restlet Client class will hang. :/ I hope this gets fixed and can be merged into the 2.0 branch! My deployments are not yet ready to shift to 2.1. In the meantime, use my simple (if annoying) workaround: setFollowingRedirect(false). You will have to handle redirects via your own logic. (After a few wild goose chases, I now know far, far more than I ever wanted to know about the internals of the Apache HTTP Client. Its architecture is actually similar to Restlet's in many ways!) And ... you're welcome. -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2738502
Re: Setting the keystore password for SSL
I can confirm that this is also true for Restlet 2.0.6. The blog announcement indicated that Jetty was upgraded, but I guess this happened only in the 2.1 branch. Jetty 7.3 does not work in Restlet 2.0. -Tal On 03/18/2011 03:09 PM, John Karp wrote: I found the problem. Apparently restlet-jse-2.0.5 does not work with jetty-7.3.1. I had to downgrade jetty to version 7.2.2, and then SSL worked. Should I file a bug? -John -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2712441 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2715690
Re: Examples of Tanuki wrapper usage with a Restlet application
You can check out the daemon support page for Prudence (which is based on Restlet): http://threecrickets.com/prudence/manual/daemon/ Prudence comes with working configuration files for Tanuki's Wrapper and for YAJSW. It comes with Apache Commons Daemon ready to run, with a rather sophisticated bash and Windows script. -Tal On 03/31/2011 01:53 PM, Fabian Mandelbaum wrote: Hello, I'd like to know if there's some examples (and where are them, of course) on using Tanuki's wrapper to 'control' (startup, shutdown) a Restlet application. I'm currently using a 'main' class which sets my Application instance, starts needed services, and starts the Application, together with a shutdown hook to shut itself down when: 1) the user hits Ctrl+C on the console where my app is running; or 2) a POST is gotten on /system/control/shutdown and am having problems with dangling Java processes left around and not really 'clean' shutdown. I'm using the Jetty server connector. Any ideas/help is appreciated. Thanks in advance. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2715784
Re: Launching TipTheWeb, a new service built on Restlet
This looks terrific, Dave! Congratulations -- it's always a great feeling to finally get a big project out the door. I am especially interested in how you used OSGi for deployment. I'm still torn about the costs vs. the benefits. The idea seems great in theory, but it seems to me to have arrived too late in the JVM scene, and too many libraries are difficult to integrate. Even Restlet has a ways to go -- it would be great if individual applications could become OSGi bundles, but it's not entirely clear what the best architecture would be. If you write a nice blog post about it, I will tip you. ;) Kudos on embracing MongoDB. I have my own announcement regarding MongoDB and Restlet coming soon... -Tal On 03/28/2011 03:13 PM, David Fogel wrote: Hello All- We've been using Restlet for the last few years in developing our recently-launched consumer Web service called TipTheWeb, and I thought that people on this list might be interested in hearing about it. TipTheWeb.org is a new service that lets you directly support your favorite web content by tipping it- for instance, you might like a blog post and tip it 25 cents. The goal is to make possible what we call community-supported Web publishing, where we can all participate in building a better Internet by supporting the publishers that create great stuff, whether it's writing, photographs, videos, open-source software, or almost anything else published online that is free to access. Here's the site: http://tiptheweb.org/ And here's our recent blog post announcing our recent release: http://blog.tiptheweb.org/post/4052890190/building-a-better-web-together We use Restlet as the core of our HTTP infrastructure, both for more standard JSON web service type resources as well as our human-facing web site and application (for which we built a thin framework on top of Restlet). We develop and deploy all our code within an OSGi runtime, which, among other things, gives us the ability to break up our software into modules and hot-deploy new code without taking down the main java process. So we have a pretty non-traditional technology stack (which I describe in slightly more detail here http://tiptheweb.org/technology/ ), and which I'd be happy to discuss further on this list. Using Restlet has worked out pretty well for us, and we'd like to thank Jerome, Thierry, and all the other contributors and helpful folks us this list for Restlet and it's supportive community. And I'd like to point out that supporting open-source software like Restlet is a major goal of TipTheWeb, so consider using our new service to tip http://www.restlet.org/ ! Dave Fogel TipTheWeb Foundation -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2714832 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2714836
Re: Deploying restlets on a commercial hosting service?
There are no real limitations. Using Apache as a reverse proxy in front of Restlet should work just fine, actually better than having Restlet answer internet requests directly. Restlet does tend to be stricter about HTTP header formats than most HTTP servers. Things that Apache's mod_php would handle happily may not be OK with Restlet. But this is a good thing: the internet is a wild place full of bizarre robots, spiders from Mars, and other junk that will start hitting your server almost as soon as you open it to the world... The bottom line is that Restlet is recommended for commercial, internet-public sites. -Tal On 03/24/2011 09:52 AM, Robert P Futrelle wrote: I work in Java for servers and clients. They all work fine on my local machine (most of the time ;-). Is anyone familiar with the issues (limitations?) that could arise in attempting to create a java restlet server and then deploying it/them on a commercial hosting site? They all have Apache available, but I'm not familiar enough with web software architecture to know what can be put behind Apache. - Bob Futrelle BioNLP.org Northeastern University View this message in context: Deploying restlets on a commercial hosting service? http://restlet-discuss.1400322.n2.nabble.com/Deploying-restlets-on-a-commercial-hosting-service-tp6204385p6204385.html Sent from the Restlet Discuss mailing list archive http://restlet-discuss.1400322.n2.nabble.com/ at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2713904
'Invalid tag format detected' with Apache HTTP Client
Hmm, I'm having some more issues with the Apache HTTP client. This is a URL that works fine with other HTTP clients. Restlet 2.0.4 SE. Here's the relevant stack trace. Any ideas? 2011-01-31 03:45:49,553: WARN [org.restlet.Component.Client] Invalid tag format detected: m1SbCDHPwgmhtnASxZWgcA 2011-01-31 03:45:49,554: INFO [org.restlet.Component.Client] Error while handling an HTTP client call java.lang.ArrayIndexOutOfBoundsException: 22 at org.restlet.engine.util.Base64.decode(Base64.java:114) at org.restlet.engine.util.Base64.decode(Base64.java:163) at org.restlet.engine.http.header.HeaderUtils.extractEntityHeaders(HeaderUtils.java:723) at org.restlet.engine.http.ClientCall.getResponseEntity(ClientCall.java:204) at org.restlet.engine.http.adapter.ClientAdapter.updateResponse(ClientAdapter.java:200) 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.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:203) at org.restlet.routing.Router.doHandle(Router.java:497) at org.restlet.routing.Router.handle(Router.java:737) at org.restlet.engine.component.ComponentClientDispatcher.doHandle(ComponentClientDispatcher.java:130) at org.restlet.engine.TemplateDispatcher.handle(TemplateDispatcher.java:121) at org.restlet.engine.component.ChildClientDispatcher.parentHandle(ChildClientDispatcher.java:139) at org.restlet.engine.component.ChildClientDispatcher.doHandle(ChildClientDispatcher.java:114) at org.restlet.engine.TemplateDispatcher.handle(TemplateDispatcher.java:121) at org.restlet.engine.component.ChildClientDispatcher.parentHandle(ChildClientDispatcher.java:139) at org.restlet.engine.component.ChildClientDispatcher.doHandle(ChildClientDispatcher.java:114) at org.restlet.engine.TemplateDispatcher.handle(TemplateDispatcher.java:121) at org.restlet.resource.ClientResource.handle(ClientResource.java:928) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2701625
'hostname in certificate didn't match' with Apache HTTP client
I'm getting a lot of these exceptions when accessing perfectly happy internet sites, such as Yahoo! and LiveJournal. It seems that various people on the net have problems with similar problems with Apache HTTP Client on Android, but in this case I'm using Restlet 2.0 JSE. Any ideas or suggestions for workarounds? Here is a relevant stack trace: 2011-01-30 00:54:08,358: WARN [org.restlet.Component.Client] An error occurred during the communication with the remote HTTP server. javax.net.ssl.SSLException: hostname in certificate didn't match: openid.yahoo.com != open.login.yahoo.com at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:220) at org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54) at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149) at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130) at org.apache.http.conn.ssl.SSLSocketFactory.createSocket(SSLSocketFactory.java:399) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:143) at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149) at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554) 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) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2701493
Re: Inefficient parsing of date header clientresource 2.0.3
SimpleDateFormat is not thread-safe -- you have no choice but to 1) re-create it per request, or 2) use thread-locals. -Tal On 01/24/2011 09:05 AM, Chris Davis wrote: Hello, I have been profiling my android app that uses android restlet client 2.0.3. I can see from the profile (image attached see the cornflower blue section on the right hand side of the restlet thread) and subsequent tracing that when DateUtils is used to parse the date header it creates a new SimpleDateFormat object that then has to load all the timezone names from android. This loading takes considerable time and uses a lot of memory and as far as I can tell is done each time a client resource is handled. At first I thought that the client should cache the dateformat object but that too would hold onto memory (unless it held a weak reference?) but I also see from DateUtils that if the format is RFC 3339 then an InternetDateFormat parser is used which I'm guessing wont need to load the timezone names as the timezone is specified in hours So I am wondering that if I can configure my server resources to return the date header in a format that required less processing? We are using restlet 1.1.9 (I know we need to upgrade, we will get around to it eventually) on the server side can I force it to use RFC 3339? kind regards Chris -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2700256
Prudence 1.0 officially released
After 4 months of release candidates, we are happy to announce that Prudence is production-worthy. We've been using it very successfully with numerous in-house projects and for several clients. Prudence provides Restlet developers with a complete, Restlet-centric deployment container, as an alternative to deploying via JEE containers such as Tomcat. As a container, Prudence also allows JSP-like scriptlet programming, albeit based on Restlet and with many sophisticated caching features. For more information on using Prudence as a container: http://threecrickets.com/prudence/manual/restlet-container/ Moreover, Prudence can provide Restlet programmers with an alternative programming environment, based on one of six JVM languages: Python, Ruby, Clojure, JavaScript, PHP or Groovy. Use the full power of Restlet without writing a single line of Java code! This is useful not only for quick prototyping of REST resources, but also works very well for full-blown products. For example, we've had unprecedented success working and deploying with the LEMP stack: Linux, Ext-JS, MongoDB, and Prudence for JavaScript. Using JavaScript on the server, client and database allows us to stay within the same coding paradigm throughout the RESTful project and encourages cooperation within our development teams. We've never been able to complete projects which such speed before, while having complete confidence in the products' ability to scale and grow. I'd like to personally thank Jerome, Thierry and everyone who assisted on the Restlet mailing list during development! It's been a wonderful journey. And now, it's time to think of Prudence 1.1... Sincerely, Tal Liron and Three Crickets -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2699853
Re: mongodb inside jse restlets...
I have been developing regularly using Restlet (via Prudence for JavaScript) and MongoDB for a while, and strongly recommend it. Check out the MongoVision project as an example. The server-side code is ridiculously simple: http://code.google.com/p/mongo-vision/ (For web development, the combination of JavaScript on the server, client and database is a magic bullet! Note that Prudence can also use MongoDB as its cache backend.) MongoDB also has a RESTful layer, which means you would be able to access it via Restlet's ClientResource. Though, I'd say you're better off using the standard Java driver. (Even though it, too, could be better.) Otherwise, there are no problems storing the Mongo instance in the Context. That's its natural place. (I sometimes store it in the Component's context if I need it shared between a few Restlet Applications.) -Tal On 01/20/2011 08:37 PM, darrylwest wrote: hi all, I am interested in your thoughts on implementing mongodb inside a standard jse restlet app. My current implementation uses a context attribute to store the reference to the mongo connection pool but was interested in any other ideas. my implementation uses restlets 2.0.4 and is slated to replace our current tomcat/mysql implementation that supports about 2000 concurrent users (500 tx/second) on a small cluster. my initial mongo tests have been great, and the restlets project looks promising, but I would feel much more comfortable with feedback from larger implementations. thanks, darryl... -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2699516
Re: Restlet + Clojure = Prudence: Talk in Chicago, December 15th
This talk has been postponed to next Wednesday, Jan 19th. If you're in the Chicago area and are interested in using Restlet with Clojure, join us! http://www.meetup.com/Chicago-Clojure/calendar/15911747/http://www.meetup.com/Chicago-Clojure/calendar/15623004/ On Thu, Dec 2, 2010 at 5:10 PM, Tal Liron tal.li...@threecrickets.comwrote: In case you're interested, I'll be giving a talk on December 15th (Wednesday) at 6pm, at ThoughtWorks (200 E. Randolph). The Clojure edition is Prudence's most exciting: the combination of Prudence's high-concurrency Restlet container and Clojure's persistent data structure promises very robust, scalable web applications. http://www.meetup.com/Chicago-Clojure/calendar/15623004/ If you've never used a Lisp before, don't be too intimidated: the Clojure meetup crowd always includes a mix of old hands and parentheses noobs. (defn signature [salutation] (sign salutation Sincerely 'Tal)) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2697036
Re: Restlet + Clojure = Prudence: Talk in Chicago, December 15th
Chicago is the Paris of the Midwest. :) On Mon, Jan 10, 2011 at 1:15 PM, Thierry Boileau thierry.boil...@noelios.com wrote: Hello Tal, unfortunately, we won't be there as we are quite busy busy in France. Hope you will enjoy this meeting!! :) Best regards, Thierry Boileau This talk has been postponed to next Wednesday, Jan 19th. If you're in the Chicago area and are interested in using Restlet with Clojure, join us! http://www.meetup.com/Chicago-Clojure/calendar/15911747/http://www.meetup.com/Chicago-Clojure/calendar/15623004/ On Thu, Dec 2, 2010 at 5:10 PM, Tal Liron tal.li...@threecrickets.comwrote: In case you're interested, I'll be giving a talk on December 15th (Wednesday) at 6pm, at ThoughtWorks (200 E. Randolph). The Clojure edition is Prudence's most exciting: the combination of Prudence's high-concurrency Restlet container and Clojure's persistent data structure promises very robust, scalable web applications. http://www.meetup.com/Chicago-Clojure/calendar/15623004/ If you've never used a Lisp before, don't be too intimidated: the Clojure meetup crowd always includes a mix of old hands and parentheses noobs. (defn signature [salutation] (sign salutation Sincerely 'Tal)) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2697080
Re: response.release() versus response.exhaust() in 2.0
So, what do you think about this pseudo-code to demonstrate the use of
ClientResource? (My experience has shown this to hang applications...)
function getText(url) {
var resource = new ClientResource(url)
var representation = resource.get()
if (representation) {
var text;
try {
text = representation.getText()
}
finally {
representation.exhaust()
}
return text
}
}
On Sun, Jan 2, 2011 at 3:29 PM, Jerome Louvel jerome.lou...@noelios.comwrote:
After further investigation of the source code, I rediscovered the main
intent behind the Representation#release() method which is to provide a
callback from the connectors to the representation that can be called when
it has been fully written out, therefore allowing the release of associated
resources such as database connections.
Representations provided by the connectors themselves apparently don't rely
on this method to be called as long as the content is fully read or
exhausted, but it shouldn't hurt to call it systematically.
I've revised the wiki page again as well as the Representation#release()
Javadocs to further clarify those points.
Best regards,
Jerome
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2695526
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2695534
Re: response.release() versus response.exhaust() in 2.0
I am a still unclear as to the best practice.
In the example you give on the wiki, you call stop() on the resource,
and there is no try/catch, but you do not mention whether using stop()
is a good idea.
In relation to the last paragraph -- my experience has shown that
exhaust() is not good enough (Restlet 2.0.x, Apache HTTP Client), and
still leads to hanging threads. Even calling release() on the
representation is not good enough. I found that the only way to avoid
hangs is a complete release() of the *response*, and I found this out
only through searching in the mailing list. While this does avoid
hanging my application, it seems like this is not recommended. Can you
clarify?
-Tal
On 12/31/2010 03:39 AM, Jerome Louvel wrote:
Hi all,
I've updated the wiki to clarify this best practice, see the last section:
http://wiki.restlet.org/docs_2.0/285-restlet.html
The Javadocs have also been previously clarified before, saying that
release() should rarely be called:
http://www.restlet.org/documentation/2.0/jee/api/org/restlet/representation/Representation.html#release%28%29
I've clarified this even further in SVN (2.0 and trunk) by adding this
paragraph:
* Note that calling this method will likely prevent the reuse of the
* underlying persistent connection and therefore should only be called
when
* exhausting the content with {...@link #exhaust()} is too costly or
when
* further calls from the client are not welcome.
Hope this clarifies. We can update the wiki/javadocs further based on your
experienced. If one connector such as Apache HTTP Client 4 doesn't work
consistently with this description, we can try to fix it.
Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com
-Message d'origine-
De : Rickard Öberg [mailto:rickardob...@gmail.com]
Envoyé : vendredi 31 décembre 2010 03:18
À : discuss@restlet.tigris.org
Objet : Re: response.release() versus response.exhaust() in 2.0
On 2010-12-31 05.55, Tal Liron wrote:
pool.) It's probably best to employ a try-finally paradigm, where the
try clause contains as little code as possible, and the finally clause
releases the response. See the example below.
var fixture
var resource =
document.external('file:///myfiles/fixture.json','application/json')
try {
fixture = resource.get().text
}
finally {
resource.response.release()
}
So this, combined with Jerome's reply:
1) release() has the effect of closing the underlying TCP
socket, preventing persistent connection reuse. So it can't be
recommended to systematically call it.
basically means that we can't have persistent connection reuse on the client.
Correct or not?
/Rickard
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2695100
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2695151
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2695206
Re: response.release() versus response.exhaust() in 2.0
I took me a while to debug this problem, and I agree it could be made
clearer. Here's what I wrote in the Prudence documentation, and would be
happy if anyone could correct me if I'm wrong:
Important: The semantics of ClientResource require you to explicitly release
the response as soon as you're done using it, which will in turn release the
thread used to stream the response to you. (Though these threads might
eventually be reclaimed by a built-in garbage collection mechanism, leaving
them hanging could lead to starvation, such that further uses of
document.external will block until threads return to the pool.) It's
probably best to employ a try-finally paradigm, where the try clause
contains as little code as possible, and the finally clause releases the
response. See the example below.
var fixture
var resource = document.external('file:///myfiles/fixture.json',
'application/json')
try {
fixture = resource.get().text
}
finally {
resource.response.release()
}
On Thu, Dec 30, 2010 at 11:48 AM, David Fogel carrotsa...@gmail.com wrote:
Like Rickard, we also have started to call release() in a finally
block for client and clientresource code, since it seemed, according
to previous posts, that that was a necessary best practice, especially
when using the Httpclient4 extension, where we'd seen situations where
threads weren't getting released properly. So, it'd be great to see
an official client-code best practice example that includes calls to
exhaust() and release().
-Dave
On Thu, Dec 30, 2010 at 1:45 AM, Rickard Öberg rickardob...@gmail.com
wrote:
On 2010-12-30 07.34, Jerome Louvel wrote:
Hi Marc,
I don't know if you still experiment issues with this, but here are a
couple of clarifications:
1) release() has the effect of closing the underlying TCP socket,
preventing persistent connection reuse. So it can't be recommended to
systematically call it.
2) exhaust() does ensure a proper consumption of the entity and enable
reuse of the connection. If you don't systematically consume the entity via
other means (actually reading it), then calling exhaust() is the way to go.
Is there any difference between best practices of how a client vs a
server should handle this? Right now we have our clients do
response.release() in a finally block. Does your response imply that
this messes up persistent connections from the clients point of view?
/Rickard
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2694744
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2695029
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2695067
Re: Proper handling of / at the end of the requested URI
Like David, I also recommend requiring trailing slashes for *everything*. In
fact, I'm annoyed that the URI spec lets you get away without using them...
it's a recipe for so much confusion, especially in relative paths
(HTML/CSS). This is a vestige from the days in which filesystems were mapped
directly to URI-space, and you had files and directories in it.
The method I use is a bit different -- I simply add Redirectors directly to
the Router for all the URIs without the trailing slash. Pseudocode example:
router.attach(workspaces/{w}/, workspacesClass);
router.attach(workspaces/{w}, new Redirector(context, workspaces/{w}/);
It could be possible to write a utility method that goes over the RouteList
and does this for you.
-Tal
On Thu, Dec 9, 2010 at 1:10 PM, David Fogel carrotsa...@gmail.com wrote:
Hi Fabián-
In our development, we did a lot of thinking about how we wanted to
structure our URL-space, especially regarding directory paths and
the issue of optional slashes, and how to best implement these things
in Restlet. What we came up with might be too much work to do by hand
(we've built a thin framework on top of Restlet, which includes this
optional-slash support), but here's how we do it:
In general, we prefer directory-like paths to always end in /. We
also prefer most HTML pages served to a browser to have a url that
ends in / as well, for a variety of reasons (including making
relative resources work consistently).
However, since our app is a web app with human users, we make sure to
support optional / for any URL that a user is likely to type by
hand.
When we attach resources to our Router, we do so through custom
methods that allow us to specify whether we want to support an
optional slash on the pattern. If so, we actually attach _two_
resources: the first is the original target resource, which we attach
to the specified pattern like normal. The second is a singleton
instance of a Restlet we wrote which we call OptionSlashRedirect,
which we attach to a path which is the original path plus-or-minus the
slash. Our OptionalSlashRedirect restlet responds to any request by
sending a permanent redirect to the other path. Here is the code to
our OptionalSlashRedirect:
protected static class OptionalSlashRedirect extends Restlet {
public OptionalSlashRedirect(Context context) {
super(context);
}
public OptionalSlashRedirect() {}
public void handle(Request request, Response response) {
super.handle(request, response);
Method m = request.getMethod();
if (m.equals(Method.GET) || m.equals(Method.HEAD)) {
Reference ref =
request.getOriginalRef().getTargetRef();
String path = ref.getPath();
if (path.endsWith(/))
path = path.substring(0,
path.length() - 1);
else
path = path + /;
ref.setPath(path);
response.redirectPermanent(ref);
} else {
response.setStatus(Status.CLIENT_ERROR_NOT_FOUND);
}
}
}
So, in your case I think you should consider making the official
directory paths end in a /, and then using a technique like this to
make sure it's effectively optional for human users. An alternative
would be to attach the same resource twice (or some other template
pattern / regex way of achieving the same thing). In general though,
we think that a resource should generally only have one canonical
path, and so serving it out at two similar paths is less desirable.
Hope this helps,
-Dave Fogel
On Thu, Dec 9, 2010 at 12:54 PM, Fabian Mandelbaum
fmandelb...@gmail.com wrote:
Hello there, sorry if this has been asked a zillion times (kindly
point me to the relevant answers if so) already.
Whenever a WebDAV request is performed, I don't know why (maybe it's
somewhere in the DAV specs, and I didn't read/understand that part),
the client seems to 'climb up' the requested URI, making some requests
(mostly OPTIONS, but I remember seeing some PROPFIND too...) on those
partial URIs too, for example:
Dec 9, 2010 2:31:29 PM org.restlet.engine.log.LogFilter afterHandle
INFO: 2010-12-0914:31:29127.0.0.1
ad...@calenco.com 127.0.0.1 9000OPTIONS
/workspaces/W1/content - 200 0 035
http://localhost:9000 gvfs/1.6.1 -
Dec 9, 2010 2:31:29 PM org.restlet.engine.log.LogFilter afterHandle
INFO: 2010-12-0914:31:29127.0.0.1
ad...@calenco.com 127.0.0.1 9000PROPFIND
/workspaces/W1/content - 207-124 186
http://localhost:9000 gvfs/1.6.1
Re: RIAP cannot handle binary streams
Anybody? I sometimes think I'm the only Restlet user who pushes RIAP to these extremes... :) On Sun, Nov 21, 2010 at 11:24 PM, Tal Liron tal.li...@threecrickets.comwrote: I have an representation that writes binary data. It works fine in HTTP, but in RIAP I get this exception when I try to exhaust the stream (Restlet 2.0.2): java.io.IOException: Timeout while reading from the queue-based input stream at org.restlet.engine.io.PipeStream$1.read(PipeStream.java:78) at java.io.InputStream.read(InputStream.java:171) at java.io.InputStream.read(InputStream.java:102) at org.restlet.engine.io.BioUtils.exhaust(BioUtils.java:220) at org.restlet.representation.Representation.exhaust(Representation.java:322) Is this a bug, or am I doing something unsupported? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2688559
Restlet + Clojure = Prudence: Talk in Chicago, December 15th
In case you're interested, I'll be giving a talk on December 15th (Wednesday) at 6pm, at ThoughtWorks (200 E. Randolph). The Clojure edition is Prudence's most exciting: the combination of Prudence's high-concurrency Restlet container and Clojure's persistent data structure promises very robust, scalable web applications. http://www.meetup.com/Chicago-Clojure/calendar/15623004/ If you've never used a Lisp before, don't be too intimidated: the Clojure meetup crowd always includes a mix of old hands and parentheses noobs. (defn signature [salutation] (sign salutation Sincerely 'Tal)) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2687409
Re: Child URI's
This is a useful discussion! I think newcomers to REST, especially those
trained in RPC thinking, find the URI space paradigm to baffling.
Unlike pros like us who swim gracefully in its waters. :)
That's a good point. Per-resource docs won't scale, or at least not
without some tool to extract those docs into a single or hyperlinked
document. Maybe javadoc would be up to it, but that sounds
complicated. I'm still feeling my way here.
I've given up on JavaDoc entirely for such uses. Java is
object-oriented, a paradigm that does not cleanly map to a
resource-oriented URI space except in naive examples. (I actually find
OO to be a tired paradigm in general.)
A wiki is too free in form, though -- I wonder if someone knows of a
tool better suited to documenting a URI space?
I also tend to use class inheritance a lot in Restlet... so, it
ends up that the code is pretty scattered. (In my Prudence apps,
there's always a routing.* file with everything concentrated there.)
What does your routing.* file look like? Is it Java source? Free-form
text?
It is bootstrapping code in one of six languages: routing.js,
routing.py, routing.rb, routing,gv., routing.php or routing.clj. The
point of the file is to map URIs to the code that would handle them
(resources, pages, generic handlers, etc.). It is really standard
Restlet routing, with a wee bit of sugar for common use cases.
I'm still wondering if there's a clean way to do this in pure Java
taking advantage of dependency injection. (I use Guice, but the
following applies to any JSR-330-compliant DI.)
I like this line of thinking. In fact, I've hit limitations of Restlet's
Template class a few times, and wonder if it can be rewritten to allow
for application-specific casting and parsing of templates. Perhaps an
overridable TemplatingService that would allow not only injection of
{variables} but also hierarchical building of URIs.
(By the way, URI hierarchies are significant in the HTTP 1.1 spec (see
PUT and DELETE), and are perhaps the only REST concept not addressed by
Restlet.)
-Tal
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2686744
Re: Child URI's
I can't find any mention of this in the HTTP/1.1 spec under PUT and DELETE. What am I missing? Hm, I remembered that the requirement for both was that the parent URI exist. For example, that you can't PUT to /items/box/ unless /items/ exists. But, a quick look at the spec now and I can't find this requirement. I might have picked this up from one of the many (wrong) interpretations of HTTP out there. HTTP is a complex protocol! I'm glad Restlet exists. :) -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2686833
Re: Child URI's
Ah, I assumed the Restlet client would be using them, but I guess it
does make sense that certain server resources could share these constants.
My personal style in documentation has always been to have a wiki page
with a description of the URI space, organized by hierarchy, with notes
for representation structures and HTTP verb support where appropriate.
The thing about documenting them at the resource level in Restlet is
that routing can be pretty complex, and one ServerResource class can
also server various URI patterns. I also tend to use class inheritance a
lot in Restlet... so, it ends up that the code is pretty scattered. (In
my Prudence apps, there's always a routing.* file with everything
concentrated there.)
-Tal
On 11/27/2010 09:11 AM, Tim Peierls wrote:
Regarding the need to document URIs/APIs for humans rather than
automatically exposing them to machine clients, I totally agree.
I think you misunderstood me, though. I was only advocating the use of
String constants, Templates, etc. as a way to avoid having two places
on the *server side* that need updating when the URI structure changes
-- during development, say. I'm the kind of person who might change
the router.attach(...) code without changing the corresponding code to
generate hyperlinks in my representations, and not detect my mistake
right away. This way I cut down on the risk of that.
I hadn't thought of this at all as a way of documenting/exposing the
URI structure to clients. I've been assuming that *if* I ever wanted
to do something like that, I would just inherit from WadlApplication
(as a first cut). But now that you mention it :-) I suppose the first
place I would go to write up the URI space / API in prose would be the
resource classes -- I could more or less read the API right out of there.
--tim
On Fri, Nov 26, 2010 at 4:37 PM, Tal Liron
tal.li...@threecrickets.com mailto:tal.li...@threecrickets.com wrote:
Nice write up!
But one problem I see in this is that it's a bit like IDL and the like
in SOAP and other RPC protocols. You end up having to share some
kind of
interface descriptor (or load/interpret it at runtime) between the
server and the client. REST requires a well-documented URI space, as
well as well-documented representation structures, but
documentation !=
IDL. A human looking up an API signature and making sure he's
following
the spec makes much more sense to me than having arbitrary clients
arbitrarily talking to arbitrary servers via arbitrary protocols.
:) At
best, IDL-like mechanisms provide some type safety. Although, even
then,
they only provide runtime safety and can't help you during compile- or
link- time.
The bottom line is that you always need to document your URI (and API)
space well, whether you share such specs between client server or not.
Which, to me means that I'd rather not spend too much time
creating spec
sharing mechanisms. I'd rather spend more time making sure my
documentation is concise, so that other programmers (or me!) will
understand the URI space in the future.
(For what it's worth, if you work a lot of dynamic languages with
dynamic and duck types, you get used to not having any compile-time
signature safety, and always rely on documentation anyway.)
Tangent: I would add that it's good practice to always think of
URIs as
ending in trailing slashes. If you decide on using relative URIs, it
makes your URI space more consistent:
/user/liron/projects/
/user/liron/project/123/items/
../
(I'm also a fan of the plural vs. singular noun form URI space)
-Tal
On 11/26/2010 02:06 PM, Tim Peierls wrote:
I'm interested in hearing other answers to this, too, but the first
thing that occurs to me about your example is that the recipient of
this representation would probably find an absolute URI more useful
than a relative one. So at the very least you'd want something
like this:
String userProjects = /user/ + user.getId() + /projects;
Reference userProjectsRef = new Reference(getRootRef(),
userProjects);
jr.put(projects, userProjectsRef.getTargetRef().toString());
Furthermore, you can use a Template to regularize the
construction of
the userProjects string:
// Static fields of the user resource class.
public static final String USER_PROJECTS_PATH =
/user/{id}/projects;
private static final Template userProjectsTemplate = new
Template(USER_PROJECTS_PATH);
When building the representation, you provide values to this
template.
MapString, String userValues = new HashMapString, String();
userValues.put(id, abc123);
String userProjects = userProjectsTemplate.format(userValues
Re: Child URI's
Nice write up!
But one problem I see in this is that it's a bit like IDL and the like
in SOAP and other RPC protocols. You end up having to share some kind of
interface descriptor (or load/interpret it at runtime) between the
server and the client. REST requires a well-documented URI space, as
well as well-documented representation structures, but documentation !=
IDL. A human looking up an API signature and making sure he's following
the spec makes much more sense to me than having arbitrary clients
arbitrarily talking to arbitrary servers via arbitrary protocols. :) At
best, IDL-like mechanisms provide some type safety. Although, even then,
they only provide runtime safety and can't help you during compile- or
link- time.
The bottom line is that you always need to document your URI (and API)
space well, whether you share such specs between client server or not.
Which, to me means that I'd rather not spend too much time creating spec
sharing mechanisms. I'd rather spend more time making sure my
documentation is concise, so that other programmers (or me!) will
understand the URI space in the future.
(For what it's worth, if you work a lot of dynamic languages with
dynamic and duck types, you get used to not having any compile-time
signature safety, and always rely on documentation anyway.)
Tangent: I would add that it's good practice to always think of URIs as
ending in trailing slashes. If you decide on using relative URIs, it
makes your URI space more consistent:
/user/liron/projects/
/user/liron/project/123/items/
../
(I'm also a fan of the plural vs. singular noun form URI space)
-Tal
On 11/26/2010 02:06 PM, Tim Peierls wrote:
I'm interested in hearing other answers to this, too, but the first
thing that occurs to me about your example is that the recipient of
this representation would probably find an absolute URI more useful
than a relative one. So at the very least you'd want something like this:
String userProjects = /user/ + user.getId() + /projects;
Reference userProjectsRef = new Reference(getRootRef(),
userProjects);
jr.put(projects, userProjectsRef.getTargetRef().toString());
Furthermore, you can use a Template to regularize the construction of
the userProjects string:
// Static fields of the user resource class.
public static final String USER_PROJECTS_PATH = /user/{id}/projects;
private static final Template userProjectsTemplate = new
Template(USER_PROJECTS_PATH);
When building the representation, you provide values to this template.
MapString, String userValues = new HashMapString, String();
userValues.put(id, abc123);
String userProjects = userProjectsTemplate.format(userValues);
// ... as above ...
And you can make this even simpler if you write a resolver for your
user resource class.
class UserResolver extends ResolverString {
UserResolver(User user) { this.user = user; }
// Crude implementation - could do better using reflection.
public String resolve(String name) {
if (name.equals(id)) return user.getId();
// ... other possibilities ...
throw new RuntimeException(can't resolve name for user:
+ name);
}
private final User user;
}
Then instead of creating a Map from the names in the template to
string values, you can provide a resolver instance.
Resolver userResolver = new UserResolver(user);
String userProjects = userProjectsTemplate.format(userResolver);
Finally, to avoid replicating the knowledge of an application's URI
structure between the resource classes and the application class, you
can change the routing in the application to refer to the strings used
to construct the templates. In other words, instead of this line in
your Application's createInboundRoot() method:
router.attach(/user/{id}/projects, UserResource.class);
you can say this:
import static com.example.myapp.UserServerResource.USER_PROJECTS_PATH;
...
router.attach(USER_PROJECTS_PATH, UserResource.class);
This way if the routing changes, you only have to update the ..._PATH
constants.
Thanks for asking the question -- I learned a lot writing up my answer!
--tim
On Fri, Nov 26, 2010 at 2:14 AM, Marty La Jeunesse
marty.lajeune...@gmail.com mailto:marty.lajeune...@gmail.com wrote:
I've a User object with a name and a List of Project objects. When
I represent with, for example, a JsonRepresentation, I do
jr.put(lastName, user.getLastName());
jr.put(projects, user/+user.getId()+/projects);
return jr;
The 'projects uri construction seems a little naive.
Any suggestions?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2685953
RIAP cannot handle binary streams
I have an representation that writes binary data. It works fine in HTTP, but in RIAP I get this exception when I try to exhaust the stream (Restlet 2.0.2): java.io.IOException: Timeout while reading from the queue-based input stream at org.restlet.engine.io.PipeStream$1.read(PipeStream.java:78) at java.io.InputStream.read(InputStream.java:171) at java.io.InputStream.read(InputStream.java:102) at org.restlet.engine.io.BioUtils.exhaust(BioUtils.java:220) at org.restlet.representation.Representation.exhaust(Representation.java:322) Is this a bug, or am I doing something unsupported? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2684217
Re: Adding sessions to a REST(let) application
There's nothing in REST for or against sessions -- that's not its domain. Your higher level app can definitely have sessions. I do not recommend renewing your cookie for every request to keep the session from expiring. Instead, have your cookie store a session ID, and maintain a session table on your server (via a memory DB or persistent, as you prefer). You can update the session expiration per hit you get on resources within the session. This is standard practice for web applications: even if they are not overtly RESTful, then need to use HTTP. :) Where this can affect REST is your URI space: sessions end up being resources. For example, you might allow a superuser access to a resource which lets them list all open sessions, and then perhaps query session data (GET) and logging out sessions (DELETE). It's quite rare for me to write a RESTful service that does not have some kind of sessions. -Tal On 11/19/2010 10:53 AM, Fabian Mandelbaum wrote: Hello there, We're currently facing a dillema with our REST application. Since we sell accounts for this application, we'd need a way to limit the concurrent number of users using an account. It happens that we sell one account and have many users use the authentication credentials of that account. Now, REST principles state that the server must not store any application state (for example, user sessions), so this seems to contradict our (commercially-motivated, agreed) needs. We thought about having the client send a cookie (I'm cookie-ignorant) with each request, and have the resources check that cookie, which would 'expire' after a given ammount of time, or when the user explicitly states so (there's a Logout button on our UI, which just works on IE and FF for now, using a REST-based logout technique: basically it sends bogus authentication credentials invalidating the browser's cached ones). Cookies seem to be accepted as a RESTful way of exchanging such state information. This of course, posses another issue, how does the user renew the cookie when the session is nearing expiration? Is this handled automatically? As I've mentionned above, I'm cookie-ignorant, forgive me if I ask nonsense. How did you solve this issue on your REST(let) applications? Any examples I can take a look at? Thanks in advance for your answers. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2683498
Re: BufferOverflowException when response size exceeds 8192 bytes
Would this bug affect the 2.0 branch at all? On 11/17/2010 05:33 AM, Thierry Boileau wrote: Hello Tom, thanks a lot for your help, the fix is available in the svn repository. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682439 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682556
Re: Data loss between HTTP client and restlet server, errors writing to non-blocking channel
My problem ended up being Grizzly (version 1.9.21). Switching to Jetty made the problem disappear, at least for the past 24 hours. Will keep you posted. I don't know if the issue is Grizzly itself or the Restlet connector, but this is a production system I can't play around with and test. Also, now that the Grizzly connector is being deprecated for Restlet 2.1, it seems wise for all of us to move away from Grizzly. -Tal On 11/15/2010 08:12 AM, Carles Barrobés wrote: Ok, problem solved. It was not a server issue after all, sorry for the noise. (It was due to creating multipart requests with HttpClient, where the file to upload was not yet completely written to disk.) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682098
Re: newbie question
Absolutely, and it works great! Though I do recommend using the Apache HTTP client connector for good performance and secure connection support. There are a few library dependencies to get it to work, so make sure you get them. -Tal On 11/07/2010 01:19 PM, deuce4 wrote: I am wondering of the capabilities of the client side of Restlet. There are a lot of data cloud libraries out there, like AWS Simple DB, and soon, the Google Big Query, which are RESTful. Can RESTlet be used as a general purpose Rest client? I have not seen any information on hooking up Restlet to Amazon Web Services, so I wonder why it hasn't been documented/implemented. For example, to hook up AWS to GAE requires a big workaround. Could RESTlet (in client mode) be used in a GAE servlet to access data in Amazon Simple DB? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2679787
Re: Using a REST layer for UI and services
I'll only say that without caching somewhere along the line, making any
kind of front-facing UIs with Restlet is going to be painful. When this
comes (Restlet 2.1?), the proper Restlety route for this may suggest
itself. fetchCalendar may cache, but does wrapIfHtml cache?
Though, I do like the basic approach -- I did something similar and
simpler with my pure-Java Restlet applications that speak to Ext-JS
REST-aware widgets. I just had to return JSON, but very specific JSON.
I think you can improve your own idea by automatically handling etags or
modification dates in wrapIfHtml, perhaps storing a timestamp in the
calendar data itself. If you can't cache, at least conditionalize the HTTP.
-Tal
On 10/20/2010 07:58 AM, Tim Peierls wrote:
I went ahead and did this as I outlined (see quoted message below),
for Freemarker and Jackson only, no Atom. there were several issues
along the way.
I had to replace the built-in ConverterHelpers that come with the
Restlet extensions with my own subclasses of those ConverterHelpers.
(The JacksonConverter is fine, except I needed to provide a custom
ObjectMapper to use materialized beans) That meant running through
the list of registered converters looking for one of the right type
and removing it, then adding my own.
I have to return different objects depending on whether the client is
expecting HTML or JSON. For JSON, I just return the plain domain
object. For HTML, I wrap the domain object with a dynamic proxy that
adds support for a special interface that names a Freemarker template
-- this interface is detected by my custom FreemarkerConverter and
used to produce the TemplateRepresentation by combining the template
with the domain object data model.
Since I have to use that wrapping logic in every resource
implementation that supports HTML representations, I bundled it into a
method, wrapIfHtml, of a common superclass that extends
ServerResource. Now my @Get method can look like this:
// Request URI is something like /calendar/{calendar} --
fetchCalendar does the heavy lifting.
@Get(html|json) public Calendar getCalendar() {
String id = (String) getRequest().getAttributes().get(calendar);
Calendar calendar = fetchCalendar(id); // throws 404
ResourceException if id not found
return wrapIfHtml(calendar, Calendar.class, Calendar.html);
}
You might think I could just wrap _always_, even for JSON, but it
turns out that the Jackson materialized bean logic doesn't work on
dynamic proxies. I want to use the materialized bean stuff because it
saves me having to write and expose implementations for my domain
interfaces.
But two of my questions remain: Is there (or will there soon be) a
better way? (Tal, aren't you going to mention Prudence? ;-)) Am I
going against the Restlet grain?
--tim
On Thu, Oct 14, 2010 at 10:07 PM, Tim Peierls t...@peierls.net
mailto:t...@peierls.net wrote:
On Sat, Sep 11, 2010 at 11:47 AM, Jerome Louvel
jerome.lou...@noelios.com mailto:jerome.lou...@noelios.com wrote:
Good news, is that we are planning to simplify this binding in
version 2.1 but associating the template files with
representation beans based on the bean qualified class name.
The converter service would allow the developer to indicate
where the template lives, for example in the classpath next to
the bean class or in a separate directory.
That sounds great. I'm impatient, though, and I want to implement
my own version of this in 2.0.x, with some additional design
constraints:
I want to write resource interfaces like this:
public interface CalendarResource {
@Get(html|atom|json) Calendar getCalendar();
@Post(form|atom|json:html|atom|json) Event addEvent(Event
event);
}
where Calendar is a domain-level interface with some associated
mechanisms for converting a Calendar instance into a
(Freemarker) TemplateRepresentation (looking up the template file
based on the class name, as Jerome describes), Feed,
or JacksonRepresentation; and Event is a domain-level interface
with some associated mechanisms for converting from a Form, Entry,
or JacksonRepresentation to an Event instance and from an Event
instance to a TemplateRepresentation, Entry, or JacksonRepresentation.
I want to implement CalendarResource on the server side with:
public class CalendarServerResource extends ServerResource
implements CalendarResource {
public Calendar getCalendar() {
Calendar calendar = lookupCalendar(getRequest()); //
actual domain logic in here
return calendar;
}
public Event addEvent(Event event) {
Calendar calendar = lookupCalendar(getRequest());
Event event = addNewEventToCalendar(calendar, event); //
actual domain logic
Re: Best way to deal with bot attacks and vulnerability searches using Restlet for a public webs site.
Exactly. You would still want two layers for everyday production applications, even if you have just one Restlet node. Upgrading your app, for example -- you have Varnish show a under maintenance screen while you swap out your Restlet nodes. Perhaps it looks appealing to have both layers in the JVM. Couldn't your your load balancer be written in Java? Perlbal is written in Perl, after all. Wouldn't a Java house want everything in Java? Well, fact is, for simple products like load balancers, that aim for maximum scalability, the JVM isn't quite there yet. Perhaps Java 7's NIO would be better. Using Perl directly over Linux async IO is far more efficient. Likewise, a caching tool like Varnish is a masterpiece of efficient use of direct memory paging under Linux. No way you could do the same with the JVM. By the way -- I don't necessarily recomend using Varnish, Squid, Pound, etc. I see upstream caching as a patchy solution from a previous LAMP era. Modern applications, especially on the JVM, should be able to handle caching on their own, and do it smartly. But, it's good to know that there are products there in case you need them. Since Restlet lets you so easily set the HTTP caching headers, Varnish, upstream, would know exactly what to do with your representations. I address this in more depth in my article about scaling: http://threecrickets.com/prudence/scaling/#toc-Subsubsection-135 My current favorite deployment is Perlbal+Prudence (which is Restlet over Grizzly). I find Perlbal deliciously minimal and reliable: all it does is forward to my application nodes, and handle SSL for me. This minimalism forces the application developers to be smart, and not rely on any upstream features that would compartmentalize your deployment and add dependencies to your application. (Restlet/Grizzly can do SSL, but there are some thorny issues with persistent connections that are easily avoided by just handling it at the front.) -Tal On 09/24/2010 10:53 AM, jrb wrote: A 2 layer architecture for a public service is useful for a bunch of reasons- load balancing, service availability during upgrades, security, separation of concerns (e.g. segregate apps by workload, offload gzip encoding, ssl endpoint, local static asset caching). Now, I haven't tried this with restlet yet, but it looks to me like restlet could be used on both layers. That said, there is a point at which *running* a public service requires its own expertise to manage the endpoint, and typically people focused on that use those tools- HAProxy, nginx, apache, etc. And they tend to think of a jvm as opaque and hard to manage. Try telling an ops person that they have to tune GC on their load balancer and they'll probably quit. But I definitely see the appeal of having a restlet uberjar, packaging jetty and spring and a bunch of other connectors, to serve as a kind of universal REST server that could do load balancing, reverse proxy, template rendering, or whatever- expose a REST interface to a database or to other proprietary back end services- all by just swapping in and out spring bean configuration. There are still some areas of weakness- I think e.g. the slowloris DoS attack is not defensible from a JVM. But as a devops tool, it seems like it has potential. On Fri, Sep 24, 2010 at 10:56 AM, Tim Peierlst...@peierls.net wrote: I share David's frustration. One of the things that attracted me to Restlet in the first place was the hope that I could throw away all the other processes and do everything in the JVM. Why couldn't I put whatever throttling/defensive logic (that I would otherwise have to put in a separate process) right into the Restlet Component? Is a Restlet Component inherently vulnerable as Tal puts it, or is it just that no one has provided the right defensive Restlet Filter so far? --tim On Fri, Sep 24, 2010 at 2:24 AM, David Fogelcarrotsa...@gmail.com wrote: Hi Tal, William- Thanks for your feedback! Regarding putting the JVM behind Apache or some other proxy: well, we're likely to have to use a load-balancer soon, but aside from that, I find it frustrating to put something in front of the JVM- shouldn't java web servers be considered just as robust and fast as ones written in C or something else? It's not like java web servers are inefficient CGI scripts or something, yet everyone is always saying to stick things in front of them. I'm not suggesting this is wrong, just that it's frustrating :-) Wouldn't it be nice if products like Jetty, Simple, etc had appropriate built-in features to combat various misuse? It seems like if they're serious about being web servers, they should consider these features to be important. Anyhow, I'll probably try to block a few things at the Simple or Restlet Filter level, just to make myself feel better... thanks, Dave Fogel --
Re: Best way to deal with bot attacks and vulnerability searches using Restlet for a public webs site.
The Internet is a wild place. :) You will get hits from all kinds of bots, from search engines to trackers of various sorts to spies to malicious attacks. The Internet also has a long memory. Years from now, you will still get hits for pages that have been removed from your application today. You'll need to be constantly tending your application to make sure you're dealing with these efficiently. At the very least, make sure to keep your robots.txt and sitemap.xml up to date, and also use log analysis to make sure you understand the traffic. Is your JVM facing your Internet connection? I would recommend having some proxy in front of it, whether it's Apache, or a load balancer like Perlbal, or a balancer/cache like Varnish. They can filter a lot of problems before they hit your vulnerable Restlet application. Restlet/Grizzly does very well with high saturation from my experience, but you really want a mature front-facing product to make sure you're not vulnerable to DoS and other storms. I swear by Perlbal, myself. Especially if you're on EC2, you want the potential, at least, to spin up new Restlet instances behind the balancer, for redundancy if not for scalability. Perlbal's documentation is ... non existent. Here's a sample configuration I've been using for a while on production systems: http://threecrickets.com/prudence/manual/http-proxy/ -Tal On Wed, Sep 22, 2010 at 2:46 PM, David Fogel carrotsa...@gmail.com wrote: Hi All- We've been developing our new web site/service using Restlet, and we're getting very close to a full launch. In the process, we've been deploying parts of our site on publicly-accessible servers (mostly Amazon EC2 instances). In addition to the small amount of traffic we're generating ourselves, we're seeing a fairly large amount of noise requests, which mostly seem to be robots looking for vulnerabilities in common systems like PHP and apache. Below are some examples of resources being requested. These requests usually result in a 404, although some have resulted in 30x redirects, and some have caused errors / stack traces due to malformed HTTP requests. In particular, restlet threw a NullPointerException in response to a request that must have had a malformed tag or conditional request headers: WARN Exception or error caught in resource java.lang.NullPointerException org.restlet.data.Conditions.getStatus(Conditions.java:310) org.restlet.data.Conditions.getStatus(Conditions.java:366) ... Anyhow, obviously this is just part of the reality of the internet, but we're wondering how other Restlet folks deal with this. In general we would like to avoid devoting CPU or other resources (including log file space) on this crap. Ideally we would like to find a solution that not only reduces our resource utilization, but perhaps increases the attacker's cost in some manner, so they are more likely to move on and leave our servers alone. Also, we're trying to get a better grip on any potential Restlet issues that could be triggered by this stuff that would be disproportionately costly. On the one hand, it seems unlikely to us any of these attacks will be specifically written to look for Restlet (or Jetty, or Simple) vulnerabilities. On the other hand, based on looking at the discussion archive, it doesn't seem like there's been very much attention given to dealing with these attacks on a Restlet-based web stack. Any ideas/suggestions/thoughts? Thanks, Dave Fogel (Here are the examples I mentioned:) INFO GET /HTTP/1.1 = 404 INFO GET /install.txt = 404 INFO GET /cart/install.txt = 404 INFO GET /zencart/install.txt = 404 INFO GET /zen-cart/install.txt = 404 INFO GET /zen/install.txt = 404 INFO GET /shop/install.txt = 404 INFO GET /butik/install.txt = 404 INFO GET /zcart/install.txt = 404 INFO GET /shop2/install.txt = 404 INFO GET /catalog/install.txt = 404 INFO GET /boutique/install.txt = 404 INFO GET /cart/install.txt = 404 INFO GET /store/install.txt = 404 INFO GET / = 404 INFO Couldn't find the mandatory Host HTTP header. INFO GET /robots.txt = 404 INFO GET / = 301 INFO GET /w00tw00t.at.blackhats.romanian.anti-sec:) = 404 INFO GET /scripts/setup.php = 404 INFO GET /admin/scripts/setup.php = 404 INFO GET /admin/pma/scripts/setup.php = 404 INFO GET /admin/phpmyadmin/scripts/setup.php = 404 INFO GET /db/scripts/setup.php = 404 INFO GET /dbadmin/scripts/setup.php = 404 INFO GET /myadmin/scripts/setup.php = 404 INFO GET /mysql/scripts/setup.php = 404 INFO GET /mysqladmin/scripts/setup.php = 404 INFO GET /typo3/phpmyadmin/scripts/setup.php = 404 INFO GET /phpadmin/scripts/setup.php = 404 INFO GET /phpMyAdmin/scripts/setup.php = 404 INFO GET /phpmyadmin/scripts/setup.php = 404 INFO GET /phpmyadmin1/scripts/setup.php = 404 INFO GET /phpmyadmin2/scripts/setup.php = 404 INFO GET /pma/scripts/setup.php = 404 INFO GET /web/phpMyAdmin/scripts/setup.php = 404 INFO GET
Re: Prudence 1.0 RC1
Thanks, Vincent! I agree that Groovy is a great choice for a more Java-centric Restlet project. I always have fun working with Groovy. (Though my personal favorite flavor of Prudence is Clojure...) Your suggestions for documentation are interesting, because they are so different from what my approach was. :) I was thinking that someone with a large Java/Restlet application would not look to rewrite things with Prudence, but instead look to Prudence, perhaps, as a container to replace JEE. I'm thinking, though, that you are right and it's worth looking at two new aspects: 1) migrating parts of an existing Java/Restlet app to Prudence, specifically component/application/routing configuration, and 2) hybrid mixes of made-in-Java Restlet resources with Prudence resource and pages. I've actually done both of these things with my production applications. I've actually never tried to use the Velocity/Freemarker Restlet extensions as a view layer, so I'm not even sure how migrating the code would work! But, Velocity is very naturally and easily supported in Prudence, and it even comes with example code that shows you how to share state between your Velocity template and your other code. -Tal On Mon, Sep 13, 2010 at 3:44 AM, Vincent Nonnenmacher vincent.nonnenmac...@agentspace.com wrote: On 12/09/10 02:39, Tal Liron wrote: I'm very happy to announce the first public release candidate of Prudence, an open source web development platform based on Restlet 2.0. http://threecrickets.com/prudence/ Prudence comes with a comprehensive 100-page manual, a complete example application and an extensive online reference. It's been in development for more than a year and has undergone a lot of testing in live production environments. Great work ! I tried it over this weekend and it sound like I could migrate back from an external ruby/sinatra for the UI computation part to prudence. Especialy the fact that with groovy support its far more easier to do some Restlet Ressource inner integration on the view side with very powerfull routings. If you've depended on JEE containers such as Tomcat or JBoss to deploy your Restlet apps, you might be happy to replace them with Prudence. Prudence acts as a Restlet-centric container, The documentation is very nice and the tutorial a breeze to play with ;-) Perhaps one area to document would be for Reslet developers showing them how they can enrich there own routing/mapping of ressources to view delivery with prudence with a scripting level layer of their choice. I feel it could solve some of my problems but with contrained time it somewhat scary to adopt on a latter stage something that taken from the outside look like an 'other radical choice for a latter projet', when there is perhaps small steps to follow to convert let say a freemaker/velocity view kind of mapping to a Prudence app. From that some parrallel side by side description on how to do things by hands with Restlet and doing the same with prudence would bring you some converts ;-) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2658657 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2659767
Re: Using a REST layer for UI and services
Vincent, This is handled in Prudence using capturing: http://threecrickets.com/prudence/manual/routing/#toc-Subsubsection-93 Note that the capturing API, like all other Restlet sugar, is available in the tiny standalone Prudence jar. -Tal On Fri, Sep 10, 2010 at 7:54 AM, Vincent Nonnenmacher vincent.nonnenmac...@telnowedge.fr wrote: On 10/09/10 09:15, Marc Portier wrote: 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 to UI transition we're wrapping up a 0.4 release in the near future Hi mark, I admit I have looked at Kauri but some time ago and lack of documentation (and time to try) make me not considering it. I see that you have made lots of improvements on the doc side the mavenization is also nice, I will give it a try, thanks for the update ;-) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2657525 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2659769
Prudence 1.0 RC1
I'm very happy to announce the first public release candidate of Prudence, an open source web development platform based on Restlet 2.0. http://threecrickets.com/prudence/ Prudence comes with a comprehensive 100-page manual, a complete example application and an extensive online reference. It's been in development for more than a year and has undergone a lot of testing in live production environments. If you've depended on JEE containers such as Tomcat or JBoss to deploy your Restlet apps, you might be happy to replace them with Prudence. Prudence acts as a Restlet-centric container, fully supporting advanced Restlet features such as virtual hosts and routing, while also providing you with a live administration application, pre-configured just works logging, configuration files for daemons/services, debugging information, and deployment by zip file (just like WAR files in JEE). Furthermore, much of the Prudence documentation could be helpful to newcomers to Restlet. See the special page for Restlet users: http://threecrickets.com/prudence/manual/restlet-container/ Beyond functioning as a mere container, Prudence provides a JSP-like view environment, with what might be the most sophisticated caching system you've seen in a web platform, and allows easy prototyping of your Restlet resources and filters. You can do all of this in your choice of six dynamic languages: Python, Ruby, JavaScript, PHP, Clojure and Groovy. Velocity and Succinct templating is also included. Enjoy! And please join the Prudence community: http://groups.google.com/group/prudence-community Special thanks go to Noelios, and especially Jérôme, for cultivating such a vibrant community around Restlet. It's a solid foundation. -Tal Liron -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2657949
Re: Using a REST layer for UI and services
Kauri is impressive! Also check out Prudence. If all goes well, we will have a 1.0 release candidate this weekend. :) http://threecrickets.com/prudence/ On 09/10/2010 02:15 AM, Marc Portier wrote: 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 to UI transition we're wrapping up a 0.4 release in the near future -marc= On 09/06/2010 01:26 PM, webp...@tigris.org wrote: Hi everyone, I have a web app who is divided into a web services and a ui front end. Actually the ui is made from servlets who call a business services layers and my web services use the same business layer. But I wonder if it is a way to write a set of REST services for replacing the old web services and using these REST for the ui too. Does someone have some usefull tips or experience about that ? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2655998 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2657442 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2657629
Re: Restlet Framework 2.0.1released
Just a quick note on changed behavior I noticed in 2.0.1 -- If you throw a ResourceException that has a cause, the cause is now sent to the status service for processing into a new status. If you don't have explicit support for this, you'll likely get a 500 error, thus overriding whatever status you set in the ResourceException (say, 404). I'm not sure if this a regression or intended new behavior... but it did break a few of my applications. -Tal On 09/08/2010 12:30 PM, Thierry Boileau wrote: Hello all, The version 2.0.1 of the Restlet framework has been released and can be downloaded at this uri: http://www.restlet.org/downloads/. The list of bugs fixed and changes is available here: http://www.restlet.org/documentation/2.0/jse/changes. We would like to thank all the people who contributed to this release. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2657215
Re: Best way to get automatic JavaScript minification in Restlet
I agree that this is important! It's also quite a challenge to do caching right. In particular, you want to make sure that you are providing enough transparency to developers, choosing the right cache key per circumstance, etc. Most server frameworks that do dare to integrate caching do a poor job at it. From my experience, I would suggest to set a more cautious roadmap: perhaps a certain set of caching features for 2.1, with an eye towards more sophistication in a future version of Restlet. I would prefer that instead of configurable automation, we allow for a way for users to programatically cache, and just make sure that Restlet stays out of the way. I'll give an example: I've recently implemented caching of compressed (gzipped) output. I did not want to use the EncoderRepresentation, because it would encode per request. To accomplish my goal, I had to create a new kind of representation (ByteArrayRepresentation) that would allow the compressed data to pass through Restlet. It works great, but it's all a bit awkward, because I'm dealing with multiple representation classes. And so, I'm wondering if anyone has an idea for a representation API that would let me and other devs do the caching while maintaining more coherence. One thought -- A RepresentationIdentifier class, sitting between RepresentationInfo and Representation. What it adds to RepesentationInfo is some metadata about caching: cache keys, groups, partitions, backends, etc. I would then be able to return a RepresentationIdentifier from a @get method instead of a full-blown Representation, which would cause the CachingService to replace it with a real Representation, perhaps by calling another callback in my resource. If the cache entry is somehow invalid, a different route would have to happen to force my @get to generate a full Representation. I see the whole process working a little bit like negotiation (with getInfo and get). -Tal On 08/31/2010 05:35 AM, Jerome Louvel wrote: Hi all, This is a great use case that could be nicely solved by a combination of the TunnelService indeed, to define an encoding preference via a “min” extension, associated to an Encoding.JAVASCRIPT_MINIFICATION. This would update the Request#clientInfo#acceptedEncodings property. Then, the upcoming EncoderService could automatically wrap the response entity to minify if needed the JavaScript representations, using the EncoderFilter. To facilite the support of new encodings, we should support pluggable EncodingHelper that would allow new extensions to be discovered (YCompressor, JSMin, Zip, etc). I’ve added notes to this RFE: “Add EncoderService (similar to DecoderService)” http://restlet.tigris.org/issues/show_bug.cgi?id=208 Regarding caching, I think this should be treated as an orthogonal aspect across the board, based on response entities’ caching properties. The CachingService would have a pluggable storages, ideally the most requested entities should stay in memory while the less requested ones could land in a static directory, all configurable of course. “Add caching support” http://restlet.tigris.org/issues/show_bug.cgi?id=25 “Add caching support to Filter according to incoming Tag” http://restlet.tigris.org/issues/show_bug.cgi?id=772 All those features look really important to me at this point, so I’ve targeted them for 2.1 M1 and 2.1 M2. Best regards, Jerome -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.o rg http://www.restlet.org/ Noelios Technologies ~ http://www.noelios.com http://www.noelios.com/ *De :* Thierry Boileau [mailto:thierry.boileau.noel...@gmail.com] *Envoyé :* vendredi 27 août 2010 16:21 *À :* discuss@restlet.tigris.org *Objet :* Re: Best way to get automatic JavaScript minification in Restlet Hello Tim, I'm sorry for my very late answer. You can also wrap the response's representation into a custom one that aims at applying the minification process. You can have a look at the Encoder filter, especially in the encode method which uses an EncodeRepresentation. Best regards, Thierry Boileau Perfect, thanks! --tim On Wed, Jul 28, 2010 at 7:43 PM, Tal Liron tal.li...@threecrickets.com mailto:tal.li...@threecrickets.com wrote: I've handled it differently for Prudence: I create static unified/minifed files on-the-fly to be served via a Directory. If you request all.min.js, all .js files in that directory are unified (in alphabetical order) and minifed. The filter can detect if any of the source files has been updated, and the interval between such tests can be configured. This seems to me the best way to go because the case for serving static files has already been optimized. (Other static web servers/CDNs can easily be used instead of Restlet's Directory.) See the code in JavaScriptUnifyMinifyFilter (LGPL): http://code.google.com/p
Re: concept of REST and HTTP itself
Here's an article I wrote as an introduction to REST: http://threecrickets.com/prudence/rest/ -Tal On 08/13/2010 12:47 AM, sic wrote: I hope to understand not the restlet but the concept of REST itself, sorry for that. What's the meaning of the REST compared with HTTP using commonly all around the world? Easily, we can already access any data via HTTP web browser and get data from them. through the HTTP protocol, it is already possible to take some resources from somewhere, which is the new main architecture of REST, so irony. Even though I try to read some documents and toturial related to the REST and consider them deeply, It's so hard for me to find out the meaning of the REST. Can anyone give me some advice for that whatever you know? regards, sic -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2646579
Re: Best way to get automatic JavaScript minification in Restlet
I've handled it differently for Prudence: I create static unified/minifed files on-the-fly to be served via a Directory. If you request all.min.js, all .js files in that directory are unified (in alphabetical order) and minifed. The filter can detect if any of the source files has been updated, and the interval between such tests can be configured. This seems to me the best way to go because the case for serving static files has already been optimized. (Other static web servers/CDNs can easily be used instead of Restlet's Directory.) See the code in JavaScriptUnifyMinifyFilter (LGPL): http://code.google.com/p/prudence/source/browse/#svn/trunk/java/com.threecrickets.prudence/src/com/threecrickets/prudence/util%3Fstate%3Dclosed There's also a similar class for CSS. (There might be an issue with method and concurrent file locking on certain operating systems -- haven't done a lot of testing yet, but I'm sure that case would be easy to fix.) -Tal On 07/28/2010 05:27 PM, Tim Peierls wrote: I wrote a Restlet Filter to minify application/x-javascript resources in afterHandle (using JSMin now, but I'll probably switch to YUI Compressor). But is that all I can do with it? It feels as though this should be plugged into the TunnelService, with ways to take requests for foo.min.js, say, and return a minified foo.js, with caching and all those goodies, yet still return plain, unminified foo.js when it's requested. Feels like this must have been done already, but I can't find anything. Pointers? Advice? --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2639913
Missing root reference
I've noticed that Request.getRootRef() returns null in Restlet 2.0.0. I haven't been able to find out what triggers this, but will try to dig more... -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2637021
Re: Missing root reference
I've managed to trace this -- the effect is specific to the RIAP protocol. Could this be intentional or is it a bug? On 07/22/2010 02:10 PM, Tal Liron wrote: I've noticed that Request.getRootRef() returns null in Restlet 2.0.0. I haven't been able to find out what triggers this, but will try to dig more... -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2637023
Re: Status of Asynchronous Support
Jerome, even though setCommitted(false) gets called, there still the usual processing of handle() in the entire restlet chain (the Finder, delegating to the UniformResource, etc.). Within these routines, the return values from various callbacks are handled. Stuff that happens there on the response can override work being done in another thread. The response is thread safe, but it's still not the intended result. I don't have a test case right now, but it would be easy to produce: simply call setCommitted(false) in a ServerResource annotated @Get implementation, and immediately move processing to a thread, where commit() is eventually called. The worker handler thread would overlap with the work done in the regular Restlet handling thread and you would get weird statuses and response entities. The reason I suggest an exception (and I share Tim's unease with it) is that it's a way to stop the handling chain in the regular thread, so that only the new handler thread would have free reign on the response. But it doesn't have to be an exception. Another solution would be for ServerResource, UniformResource and Finder to be refactored specifically to handle the committed=false case. I worry, though, that future work or custom implementations would not handle the case properly. -Tal On Sun, Jul 11, 2010 at 9:00 PM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Tal and Tim, There is a way to signal an asynchronous response on a per-call basis, calling Response#setCommitted(false). Then, if you call Response#commit() before the initial request thread reaches back the connector, this should work fine as well. I’m not sure yet how it could get ‘corrupted’. Do you have a precise scenario? Note that the NIO version of the asynchronous internal connector has been moved to version 2.1. This feature should indeed be considered as preview feature for 2.0. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com *De :* tpeie...@gmail.com [mailto:tpeie...@gmail.com] *De la part de* Tim Peierls *Envoyé :* vendredi 18 juin 2010 13:51 *À :* discuss@restlet.tigris.org *Objet :* Re: Status of Asynchronous Support I never saw a response to this, but it does seem like a problem. I don't love the idea of a special exception used purely to handle control flow, but I can't think of anything better off-hand. --tim On Sat, May 22, 2010 at 8:05 PM, Tal Liron tal.li...@threecrickets.com wrote: Hi Jerome, 2. There is a TaskService associated to your application that you could leverage. It separates threads usage from tasks to process (such as committing responses). I've tried this, but there is a concurrency problem with this pattern in ServerResource -- If I set autoCommiting to false during a ServerResource.get() and put my task on a separate thread pool, then my own task might try to update the response at the same time as the upper parts of the call stack (Finder.handle(), for example) also try to update the response according to my return value from get(). Both threads might be doing it at the same time, and the response ends up corrupted (no concurrency exceptions, but it's mismatched status/entity, for example). What would be the correct way to defer a response from within a ServerResource? My thought is that there should be a way to return from get() while signaling to the rest of the call stack that I am handling the response. A null won't work, because it internally signifies an unavailable entity. Perhaps a new kind of ResourceException? DefferedResponseResourceException? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2612147 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2632674
Re: RFC - Restlet edition for JavaScript
Great stuff, Eric. I will experiment with this. I would love for Prudence to have a matching client-side API. By the way, take a look at Ext-JS -- recent versions have really well thought-out RESTful widgets. You'll need to have your Restlet resources aware of the Ext-JS requirements, but this is so easy to do that I haven't even bothered with boilerplate code. -Tal On Mon, Jul 12, 2010 at 10:42 PM, Eric Ferraiuolo eferraiu...@gmail.comwrote: This sounds like an interesting project. Currently the Ajax support in the JavaScript libraries lack a full-fledged REST model/support; although they are very simple to use in the basic use-cases. I work with YUI 3 and we use Restlet in our server-side stack. YUI 3 has a Y.io static class/object to make Ajax requests; the features of this utility module weren't up to par with what I wanted, and I wanted to make complex client-server interactions easier for me. I decided to wrap Y.io with my REST Resource class, Y.Resource, to make a more RESTful client API for me to communicate with the server. REST Resource YUI 3 Module: http://yuilibrary.com/gallery/show/resource Code on GitHub: http://github.com/ericf/yui3-gallery/blob/master/src/gallery-resource/js/resource.js This is definitely not anything close to a full-fledged Restlet JavaScript client, but the features I added to YUI 3's Ajax support were inspired by Restlet. Eric On Jul 8, 2010, at 9:30 AM, Jerome Louvel wrote: Hi all, Following a recent customer project experience involving GXT + GWT + Restlet/GWT + Restlet/JEE and discussions about the interest of scripting languages as opposed to a statically type language with Jean-Paul Figer [1], I reconsidered an idea initially suggested by Yuri de Wit [2] to add a pure JavaScript edition of Restlet. Due to the emergence of HTML 5 on all sorts of browser platforms (mobile), the improvement of JavaScript engines such as Chrome V8 and the overall convergence with REST and Restlet/Java on the server-side, it seems like a good time to push for a more RESTful JavaScript client API, reusing the Restlet API semantics in pure JavaScript. Eclipse 3.6 also improved its support for JavaScript developments Of course, we already have the GWT edition of Restlet which provides a nice solution, but there seems to be room for a more hypermedia driven/document oriented solution, combining AJAX and UI libraries such as jQuery, Ext JS, YUI to name a few popular ones. I’ve collected my thoughts on this wiki page and look forward to reading your ideas and experiences. “JavaScript edition” http://wiki.restlet.org/developers/172-restlet/368-restlet.html Best regards, Jerome Louvel [1] REST paper in French: http://www.figer.com/publications/REST.htm [2] “Add JavaScript client”: http://restlet.tigris.org/issues/show_bug.cgi?id=129 [3] AJAX Tools Framework: http://www.eclipse.org/atf/ -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2632678
Re: RFC - Restlet edition for JavaScript
This is good news! Until this is available, I would like to suggest trying out Prudence for JavaScript. It's not intended as a Restlet edition, but instead a RESTful platform, which happens to be fueled by the real Restlet (JSE edition) for Java, via the Rhino JavaScript engine. It thus will always be based on the JVM, and not other JavaScript engines. As exciting as those are, Prudence is committed to the JVM. Other than this major difference in intent with Jerome's spec, Prudence already supports many of the features on the RFE, including a very powerful caching backend that can plug into memcached, Hazelcast and relational databases. http://threecrickets.com/prudence/ Prudence is also meant as a pure Restlet container for regular Java Restlet applications, for those who would rather not use Tomcat or J2EE containers. It allows easy deploy-by-zip similarly to using WAR files. I will posting more about this use case soon, because I feel there's a real need for this among Restlet developers who are not necessarily interested in JavaScript or other dynamic languages. I've been successfully developing and deploying applications in-house with Prudence for a year now (with a version that was too rough for me to make it public without embarrassment). JavaScript is my personal favorite Prudence flavor! (Well, I love Clojure a lot, too, but find JavaScript more immediately useful for my work. Other available flavors: PHP, Python, Ruby and Groovy, all fully supported.) In the JavaScript context, I'm working on creating a natural Rhino-based API for MongoDB, which already makes heavy use of JavaScript internally. http://code.google.com/p/mongodb-rhino/ Not a lot of code there, but works great. The combination of Prudence, JavaScript, MongoDB and Ext-JS is especially delicious. It's been a piece of cake to connect Ext-JS grids to MongoDB documents via Prudence REST resources. Yum! The Prudence 1.0 release candidate will be available in the coming weeks -- the main challenge right now is finishing up the extensive documentation. The API and feature-set are otherwise already locked. Hopefully the 1.0 release will match Restlet 2.0's schedule. It's a different kind of beast than what a JavaScript edition of Restlet would be, but could be a useful playground for those of you who want to try out some ideas. -Tal (Tim, thank you for your work on Java Concurrency in Practice. It's been a valuable handbook in working on Scripturian, Prudence's underlying execution engine.) On Thu, Jul 8, 2010 at 4:47 PM, Tim Peierls t...@peierls.net wrote: This is great news! Thanks, Jerome. --tim On Thu, Jul 8, 2010 at 9:30 AM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi all, Following a recent customer project experience involving GXT + GWT + Restlet/GWT + Restlet/JEE and discussions about the interest of scripting languages as opposed to a statically type language with Jean-Paul Figer [1], I reconsidered an idea initially suggested by Yuri de Wit [2] to add a pure JavaScript edition of Restlet. Due to the emergence of HTML 5 on all sorts of browser platforms (mobile), the improvement of JavaScript engines such as Chrome V8 and the overall convergence with REST and Restlet/Java on the server-side, it seems like a good time to push for a more RESTful JavaScript client API, reusing the Restlet API semantics in pure JavaScript. Eclipse 3.6 also improved its support for JavaScript developments Of course, we already have the GWT edition of Restlet which provides a nice solution, but there seems to be room for a more hypermedia driven/document oriented solution, combining AJAX and UI libraries such as jQuery, Ext JS, YUI to name a few popular ones. I’ve collected my thoughts on this wiki page and look forward to reading your ideas and experiences. “JavaScript edition” http://wiki.restlet.org/developers/172-restlet/368-restlet.html Best regards, Jerome Louvel [1] REST paper in French: http://www.figer.com/publications/REST.htm [2] “Add JavaScript client”: http://restlet.tigris.org/issues/show_bug.cgi?id=129 [3] AJAX Tools Framework: http://www.eclipse.org/atf/ -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2631149
Re: ClientResource leaves inactive thread
As long as you're part of the decision-making process for Restlet, then I'm OK with it. The caveat is that people don't always understand how to use the configuration parameters of ThreadPoolExecutor. There was an exchange on the concurrency-interest mailing list recently that brought this home to me. For example, it seems that a lot of people think of corePoolSize as minPoolSize, the opposite of maxPoolSize, which is the wrong way to think about it. A conservative default in Restlet is probably better than a user configuration based on a misunderstanding. --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2628698
Re: Restlet Framework 2.1 roadmap
Suitably ambitious! I'm sure we all have our little issues that we'd like to see prioritized... Mine is that I would like to see some instrumentation of the servers. My specialization is super-scalable systems (the cloud) and this would make Restlet very sweet for me: http://restlet.tigris.org/issues/show_bug.cgi?id=1117 I also feel that the asynchronous API could use some more thought (as well as extending it to all connectors). The threading model has in essence been well thought-out and solved, but I found some loopholes in its actual integration into the rest of the Restlet structure (I've wrote about it to the list). It's still not clear to me if 2.0 will have actually usable asynchronous support. -Tal On 06/06/2010 06:45 AM, Jerome Louvel wrote: Hi all, Restlet Framework 2.0.0 is now in sight; we are working on the remaining blocking bugs and plan to release it at the end of the month or early in July. That means that it’s time for us to plan for the next steps, always a great time! I have summarized our initial ideas on this wiki page: http://wiki.restlet.org/developers/175-restlet.html We look forward to reading your comments, suggestions and contributions! Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org http://www.restlet.org/ Noelios Technologies ~ http://www.noelios.com http://www.noelios.com/ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2617667
Re: Problem using RestletFileUpload for V2. RC3
I've created an extension of Form called FormWithFiles for Prudence: http://prudence.tigris.org/source/browse/prudence/trunk/java/com.threecrickets.prudence/src/com/threecrickets/prudence/util/FormWithFiles.java http://prudence.tigris.org/source/browse/prudence/trunk/java/com.threecrickets.prudence/src/com/threecrickets/prudence/util/FileParameter.java -Tal On 05/27/2010 11:22 AM, HT wrote: Additionally I have the question. For v2 RC3 do i need all *.jars as mentioned on the page http://wiki.restlet.org/docs_1.1/13-restlet/28-restlet/64-restlet.html I have installed following: - org.restlet.jar - org.restlet.ext.servlet.jar - org.restlet.ext.fileupload.jar - org.restlet.ext.fileupload - commons-fileupload-1.2.1.jar - commons-io-1.4.jar Do I need : com.noelios.restlet ? On a side note; is there an example of how to parse fields passed from a webform AND also a file attached in the multipart form ? Regards, Hideki -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2614134 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2614245
Re: Status of Asynchronous Support
Thanks for the detailed response! RFE: Expose server instrumentation http://restlet.tigris.org/issues/show_bug.cgi?id=1117 So, I guess only the internal connector will support true asynchronous handling now for 2.0. The comparison charts talk about the internal connector being suitable for development. But, what's your opinion about production environments? It seems to be much improved since the early days of Restlet. If asynchronicity is a required feature, I do not have another choice for 2.0. Or, perhaps we should consider asynchronicity as a preview feature in 2.0, and wait until 2.1 for leveraging it? I think it was wise of you not to add SSL support. It's definitely a pain to write, and there are simple solutions. (I recommend using Perlbal as your load balancer, and handling SSL there.) Have you considered, though, using code from Grizzly for SSL? -Tal On 05/21/2010 03:53 AM, Jerome Louvel wrote: Hi Tal, 1. This is a good point that needs to be explored. The current path we are following is to deal with high-load directly inside the internal connector, for example to stop accepting new connections at IO level if we are overloaded, or giving a priority of responses sending over new requests handling. You might prefer to deal with that inside resources, which could make perfect sense. We should explore this during the 2.1 development cycle. Feel free to enter a RFE in the tracker. 2. There is a TaskService associated to your application that you could leverage. It separates threads usage from tasks to process (such as committing responses). Your point about instrumentation is valid though, we need to work on that. Creating a RFE would be a good step forward. 3. abort() should now work with other connectors AFAIK (check the changes log). Regarding provisional responses and commit(), I think this will have to wait for 2.1. 4. The internal connector is described here: http://wiki.restlet.org/developers/172-restlet/354-restlet.html We are working on the NIO enhancements to it and hope to have this ready for 2.0 in order to have a scalable/asynchronous/lightweight connector. It uses a configurable thread pool, but HTTPS is not planned for 2.0 at all (too much work). We also have this page describing the various connectors available: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/325-restlet/37-restle t.html This should be improved I guess with addition details/criterias. We did cover those details in the Restlet in Action book (early access). 5. Currently, we call this default connector the internal connector. I'm not sure about having a code name for it at this point... I'd prefer people to think about it as a natural part of the Restlet engine. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -Message d'origine- De : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : jeudi 20 mai 2010 11:00 À : discuss@restlet.tigris.org Objet : Status of Asynchronous Support Thought I've followed what I could of the progress on asynchronous support, I have a few interdependent questions and suggestions. 1. On the one hand, I really like how simple asynchronicity is handled. I can defer my response to later (from another thread). But, Restlet provides no tools to help me decide if I should defer or not. What I would want to know is -- Am I under load right now, meaning high concurrency? Should I yield so that other requests can have a chance to get in? 2. A related question: If I do defer, I do not necessarily want to decide on my own when to finish the response. I might want to wait until there is a free thread that can take me. It would be great if there were 1) a callback for this, or 2) a way for me to signal that I'm ready to respond, as soon as the server is free. Or, at the very least a way to poll the server load. (To summarize these two issues: the Restlet server is very opaque right now. For truly scalable applications (cloud, cloud, cloud) we need realtime information from it so that the application can react dynamically.) 3. I know that the default connector supports commit/abort, but what about Grizzly, Jetty and Netty? If they don't support it yet, is support being planned for 2.0? This will strongly affect my deployment strategies. 4. Assuming only the default connector is asynchronous, could you provide more details about it? Until now, frankly, I've ignored it as something that just works and isn't fit for production. It seems like this connector is very capable by now, but I know nothing about how it's implemented. NIO? Thread pools? SSL? I think it would be very good if there were a wiki page with an in-depth comparison of the various available connectors, what features they provide and implementation details -- both of the servers themselves, and of the features the Restlet adapters
Re: Status of Asynchronous Support
Hi Jerome, 2. There is a TaskService associated to your application that you could leverage. It separates threads usage from tasks to process (such as committing responses). I've tried this, but there is a concurrency problem with this pattern in ServerResource -- If I set autoCommiting to false during a ServerResource.get() and put my task on a separate thread pool, then my own task might try to update the response at the same time as the upper parts of the call stack (Finder.handle(), for example) also try to update the response according to my return value from get(). Both threads might be doing it at the same time, and the response ends up corrupted (no concurrency exceptions, but it's mismatched status/entity, for example). What would be the correct way to defer a response from within a ServerResource? My thought is that there should be a way to return from get() while signaling to the rest of the call stack that I am handling the response. A null won't work, because it internally signifies an unavailable entity. Perhaps a new kind of ResourceException? DefferedResponseResourceException? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2612147
Status of Asynchronous Support
Thought I've followed what I could of the progress on asynchronous support, I have a few interdependent questions and suggestions. 1. On the one hand, I really like how simple asynchronicity is handled. I can defer my response to later (from another thread). But, Restlet provides no tools to help me decide if I should defer or not. What I would want to know is -- Am I under load right now, meaning high concurrency? Should I yield so that other requests can have a chance to get in? 2. A related question: If I do defer, I do not necessarily want to decide on my own when to finish the response. I might want to wait until there is a free thread that can take me. It would be great if there were 1) a callback for this, or 2) a way for me to signal that I'm ready to respond, as soon as the server is free. Or, at the very least a way to poll the server load. (To summarize these two issues: the Restlet server is very opaque right now. For truly scalable applications (cloud, cloud, cloud) we need realtime information from it so that the application can react dynamically.) 3. I know that the default connector supports commit/abort, but what about Grizzly, Jetty and Netty? If they don't support it yet, is support being planned for 2.0? This will strongly affect my deployment strategies. 4. Assuming only the default connector is asynchronous, could you provide more details about it? Until now, frankly, I've ignored it as something that just works and isn't fit for production. It seems like this connector is very capable by now, but I know nothing about how it's implemented. NIO? Thread pools? SSL? I think it would be very good if there were a wiki page with an in-depth comparison of the various available connectors, what features they provide and implementation details -- both of the servers themselves, and of the features the Restlet adapters leverages (or not). As it stands, it's hard for a deployer to make an informed decision on which connector to use. (For the record -- I think benchmarks are quite useless for this comparison. Performance != scalability, and in any case benchmarks are highly contextual. It's very easy to switch connectors in Restlet and for people to do their own benchmarks.) 5. Might I suggest giving the default connector a name? It seems to be a nice little engine of its own. If we're going to start comparing it to the others as a viable alternative, it might be easier to name it. My only name suggestion is Thier Engine, short for Thierry, and reminds me of tier. :) -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2611218
Re: uri reorg question
I've solved this using something I call a FallbackRouter, which internally uses a restlet I call a Fallback. It knows how to test different targets in series until it finds one that succeeds. The FallbackRouter is smart enough to know when you are attaching multiple identical paths, and the Fallback is smart enough to cache successful routes (for a defined time) so it won't have to keep trying them. The code is available in LGPL as part of Prudence: http://prudence.tigris.org/source/browse/prudence/trunk/java/com.threecrickets.prudence/src/com/threecrickets/prudence/util/ -Tal On 05/10/2010 08:08 AM, Fabian Mandelbaum wrote: Hello Peg, there is a way you can handle 'arbitrary' paths with a single rule match... (that is, to handle the / inside the variable's values), someone asked about this on this list not long ago IIRC... You are welcomed. Good luck! On Mon, May 10, 2010 at 10:01 AM, pegpeggig...@yahoo.fr wrote: it is true that knowing every directory I could map these ... but this is not really possible because web developpers are free to organize their web resources thanks anyway for your reply Peg -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/uri-reorg-question-tp5029417p5030420.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2606813 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2606980
Re: What to do about sessions?
It's hard for me to see Comet as RESTful. I would consider it a new use of HTTP that demands a new way of thinking. You'd probably want to use a lower level API than Restlet, so you can fully leverage asynchronicity. Have you considered repeat rapid polling instead of using Comet? On 04/21/2010 05:12 PM, Marc Larue wrote: Ok, I realize you are all talking mostly from a B2B perspective. I'm developing a realtime comet system for multiplayer games (Ajax, JSON, Rupy); so my perspective is a little different. Right now I'm trying to figure out how to make my XSS messaging system as cheaply scalable as possible; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Laruem...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591952 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592758
Re: HTTPS and HTTP?
A common solution I use is to have my loadbalancer (I like PerlBal) handles HTTPS divert HTTP and HTTPS to different ports, for example 80 for HTTP and 81 for HTTPS. You can run your Restlet component with two servers to answer both of these, and then test for which port requests are coming through to make decisions based on HTTP vs. HTTPS. -Tal On 04/22/2010 01:09 PM, gonzajg wrote: Hi, i'd like to know if there's a way to have on the same application running HTTPS resources and HTTP. My idea is to have a login resource via HTTPS where a session is returned if user/password are ok and then check the session in other HTTP resources (so the overload of HTTPS is saved) Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592791
Re: Re: What to do about sessions?
REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue m...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936
Re: HTTPS / SSL not working after updating to trunk
I've been following this with interest, though haven't had time to look at it... Thanks for the excellent debugging, David and Bruno! On 03/26/2010 09:16 AM, Bruno Harbulot wrote: Hi Dave, On 25/03/2010 21:47, David Fogel wrote: Hi Bruno- So, I got Jetty working as the connector, and yes, it does seem to work fine with our previously discussed HTTPS configuration. So that can hold us for now, but we do eventually want to use the Simple connector. Incidentally, based on recent postings to the simpleframework support list, it appears that Niall (the author of Simple) plans to release a bug-fix version in the next few days for some problem having to do with a potential endless loop writing to a socket. So I wonder if this could be part of the issue... I think I've tracked down the problem to be a Simple bug: the output buffer used during the TLS handshake is too small to send a big list of CA certificates (since Simple always requests a client certificate, it sends the list of CAs it's willing to accept within the TLS CertificateRequest message: this list is longer with the default trust store bundled with the JRE and used when nothing is specified). More on this here: http://sourceforge.net/mailarchive/message.php?msg_name=4BACBFF1.7090108%40manchester.ac.uk Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2465481 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2465558
Re: Redirect from HTTP to RIAP
Just letting you know all seems to work well now! Test revision 6392.
On 03/01/2010 09:48 AM, Thierry Boileau wrote:
Hello Tal,
thanks for your report. There was a bug in the Protocol class which
causes the generation of bad responses with the RIAP protocol.
This should work better now. Let us know if it still fails.
Best regards,
Thierry Boileau
OK, I managed to build it, and some things work but some don't.
My example does work. However, I cannot redirect to riap://application/
URIs. My understanding is that these are not supported by the server
dispatcher (I'm not sure why -- could it be something to do with
handling asynchronous requests?). Thing is, I cannot redirect to RIAP at
all with the client dispatcher, which as far as I know does support all
RIAP authorities. For example, the following will hang Restlet:
router.attach(/note/{id}), new Redirector(component.context,
riap://application/note, Redirector.MODE_CLIENT_DISPATCHER));
On 02/22/2010 09:07 AM, Thierry Boileau wrote:
Hello Tal,
thanks for your report. The fix is available in the svn repository.
Best regards,
Thierry Boileau
It seems like I cannot use a Redirector to an RIAP URI.
For example:
router.attach(/note/{id}), new Redirector(component.context,
riap://component/myapp/note, Redirector.MODE_SERVER_DISPATCHER));
Is this intentional? Can anyone think of a simple workaround?
The use case is to have a different internal URI space, and a different
one exposed to the world.
By the way, setting the Redirector in MODE_CLIENT_DISPATCHER in this
case causes a JVM failure...
-Tal
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2449457
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2450618
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2463480
Re: Suspended thread doing Client.put
I've been seeing hangs on GET, too. Unfortunately, can't provide debug information for this particular project ... I hacked a quick workaround to avoid it. Seems to do with the fixes Thierry made to protocol handling. On 03/03/2010 03:50 PM, webp...@tigris.org wrote: Jerome, I have the same problem and am running the 2.0m7 version. I can replicate the problem with the sample resource code, using the sample client software, with the resources hosted within a servlet container. It appears that the client hangs on the Latch on the GET directly after a PUT on the same resource. Let me know what additional information I can provide. Regards, Jon Cook -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2454626 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2454794
Re: Redirect from HTTP to RIAP
Almost there. :)
Restlet's ClientResource works fine.
With Firefox, the request does reach the target resource, but something
odd is going on with the response. Firefox just hangs waiting for the
request to close. Also, and this is probably related, rather than
getting just my string representation, I'm getting what seems to be the
HTTP headers plus my string in the response in Firefox.
If I do an HTTP redirect instead (need MODE_SERVER_INBOUND), then
Firefox works fine.
-Tal
On 03/01/2010 09:48 AM, Thierry Boileau wrote:
Hello Tal,
thanks for your report. There was a bug in the Protocol class which
causes the generation of bad responses with the RIAP protocol.
This should work better now. Let us know if it still fails.
Best regards,
Thierry Boileau
OK, I managed to build it, and some things work but some don't.
My example does work. However, I cannot redirect to riap://application/
URIs. My understanding is that these are not supported by the server
dispatcher (I'm not sure why -- could it be something to do with
handling asynchronous requests?). Thing is, I cannot redirect to RIAP at
all with the client dispatcher, which as far as I know does support all
RIAP authorities. For example, the following will hang Restlet:
router.attach(/note/{id}), new Redirector(component.context,
riap://application/note, Redirector.MODE_CLIENT_DISPATCHER));
On 02/22/2010 09:07 AM, Thierry Boileau wrote:
Hello Tal,
thanks for your report. The fix is available in the svn repository.
Best regards,
Thierry Boileau
It seems like I cannot use a Redirector to an RIAP URI.
For example:
router.attach(/note/{id}), new Redirector(component.context,
riap://component/myapp/note, Redirector.MODE_SERVER_DISPATCHER));
Is this intentional? Can anyone think of a simple workaround?
The use case is to have a different internal URI space, and a different
one exposed to the world.
By the way, setting the Redirector in MODE_CLIENT_DISPATCHER in this
case causes a JVM failure...
-Tal
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2449457
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2450618
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2453510
Re: How to write an Universal redirector
Hi Thierry --
The documentation for the URI template variables is so deeply hidden
(Resolver API doc) that I always have trouble finding it. My
recommendation is to put it somewhere much more obvious, possibly even
in the first Resource tutorials, and to document it more with
examples. It's such a powerful feature of Restlet!
-Tal
On 02/24/2010 02:32 AM, Thierry Boileau wrote:
Hello,
actually, the second parameter in the Redirector constructor is a
template using a set of known variables (see [0]).
You should be able to use the shipped Redirector, as follow (or
something similar)
new Redirector(getContext(),
http://192.168.100.1:8080/RESTfulServices{rr};,
Redirector.MODE_CLIENT_DISPATCHER));
Don't forget to declare the client HTTP connector on the component
(such redirection is seen as a new client call issued by the
Component). This is done in the web.xml file see ([1])
servlet
[...]
init-param
param-nameorg.restlet.clients/param-name
param-valueHTTP/param-value
/init-param
[...]
/servlet
[0]
http://www.restlet.org/documentation/2.0/jse/api/org/restlet/util/Resolver.html
[1]
http://www.restlet.org/documentation/2.0/jee/ext/org/restlet/ext/servlet/ServerServlet.html
Best regards,
Thierry Boileau
Hello everybody,
Could please anyone help me to write a universal redirector to match
all requests and to redirected them to a remote host?
Example:
Start: /redirect/RESTfulServices/resources/customers/pkey/2176172632
Finish:http://192.168.100.1:8080/RESTfulServices/resources/customers/pkey/2176172632
GWT Client side:
ClientResource r = new
ClientResource(/redirect/RESTfulServices/resources/customers/pkey/2176172632);
Server side class TestRestletApplication extends Application (my
web.xml was changed to forward all /redirect/* requests to
TestRestletApplication)
Router router = new Router(getContext());
router.attach(/RESTfulServices, new MyRedirector(getContext(), null));
//-- this is wrong
and MyRedirector class:
public class MyRedirector extends Redirector {
public MyRedirector(Context context, String targetTemplate) {
// By default, the mode is MODE_CLIENT_DISPATCHER
super(context, targetTemplate);
}
@Override
protected Reference getTargetRef(Request request, Response response) {
Reference ref = request.getResourceRef();
ref.setHostDomain(192.168.100.1);
ref.setHostPort(8080);
//-- here is missing something
return ref;
}
}
Thank you for helping me.
ab
View this message in context: How to write an Universal redirector
http://n2.nabble.com/How-to-write-an-Universal-redirector-tp4620578p4620578.html
Sent from the Restlet Discuss mailing list archive
http://n2.nabble.com/Restlet-Discuss-f1400322.html at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2452668
Re: Starting/stopping restlets
True. So, I guess the only way to remove turn off routes/restlets is to detach them? On Wed, Feb 24, 2010 at 2:33 PM, Stephan Koops stephan.ko...@web.de wrote: Hi Tal, you could do some initialization and finalization work in your own Restlets. best regards Stephan Tal Liron schrieb: This is a basic attribute of any Restlet, but it seems like nowhere in the framework is it used. My expectation was that routers, filters, etc., would not pass requests on to a stopped target restlet. However, it seems that stopping restlets has no effect. Is this by design? In which case, what is the purpose of starting/stopping? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2451685 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2451697
Re: Redirect from HTTP to RIAP
Thanks!
Would love to test and confirm, but Restlet won't build (revision 6159).
My error:
[javac]
/Depot/Projects/Collaborative/Restlet/build/temp/android/modules/org.restlet.ext.odata/src/org/restlet/ext/odata/internal/FeedParser.java:362:
cannot find symbol
[javac] symbol : method getNode(java.lang.String)
[javac] location: class org.restlet.ext.xml.DomRepresentation
[javac] Node node =
inlineContent.getNode(mapping.getValuePath());
On 02/22/2010 09:07 AM, Thierry Boileau wrote:
Hello Tal,
thanks for your report. The fix is available in the svn repository.
Best regards,
Thierry Boileau
It seems like I cannot use a Redirector to an RIAP URI.
For example:
router.attach(/note/{id}), new Redirector(component.context,
riap://component/myapp/note, Redirector.MODE_SERVER_DISPATCHER));
Is this intentional? Can anyone think of a simple workaround?
The use case is to have a different internal URI space, and a different
one exposed to the world.
By the way, setting the Redirector in MODE_CLIENT_DISPATCHER in this
case causes a JVM failure...
-Tal
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2449457
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2450573
Redirect from HTTP to RIAP
It seems like I cannot use a Redirector to an RIAP URI.
For example:
router.attach(/note/{id}), new Redirector(component.context,
riap://component/myapp/note, Redirector.MODE_SERVER_DISPATCHER));
Is this intentional? Can anyone think of a simple workaround?
The use case is to have a different internal URI space, and a different
one exposed to the world.
By the way, setting the Redirector in MODE_CLIENT_DISPATCHER in this
case causes a JVM failure...
-Tal
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2449457
Re: Directory returning 500 instead of 404 for missing files
Ah!
Further digging showed me that what happened was that the behavior of
catching thrown ResourceExceptions from a ServerResource has changed.
Now, if the exception has a cause, then the error always becomes 500.
This was not previously the case... If this is planned behavior, great,
but just wanted to be sure.
Here is a test case that returns a 500 error:
public class Test
{
public static class MyResource extends ServerResource
{
@Override
public Representation get() throws ResourceException
{
throw new ResourceException( Status.CLIENT_ERROR_NOT_FOUND,
new IOException( This turns into a 500 error ) );
// The following works as I expected:
//throw new ResourceException( Status.CLIENT_ERROR_NOT_FOUND );
}
}
public static void main( String arguments[] ) throws Exception
{
Component component = new Component();
try
{
component.getServers().add( Protocol.HTTP, 8080 );
Application application = new Application();
component.getDefaultHost().attach( application );
component.getInternalRouter().attach( /myapp, application
).setMatchingMode( Template.MODE_STARTS_WITH );
Router router = new Router( application.getContext() );
application.setInboundRoot( router );
router.attach( /test/, MyResource.class
).setMatchingMode( Template.MODE_STARTS_WITH );
component.start();
ClientResource client = new ClientResource(
component.getContext(), riap://component/myapp/test/ );
// ClientResource client = new ClientResource(
// http://localhost:8080/test/; );
System.out.println( GET: + client.get() );
}
catch( ResourceException x )
{
System.out.println( x.getStatus() );
}
catch( Exception x )
{
x.printStackTrace();
}
finally
{
System.exit( 0 );
}
}
}
On 02/16/2010 01:37 AM, Thierry Boileau wrote:
Hello Tal,
using a ClientResource, I get a ResourceException when the response is
not successful, and both the ResourceException and the response's
statuses are equals to 404.
Using a simple Client instance, the status of the response object is
set to 404 also. Could you explain a little bit more what happens in
your case?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2448233
Directory returning 500 instead of 404 for missing files
This seems to be true of revision 6132. Is this intentional, or a regression bug? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2447935
Re: Directory returning 500 instead of 404 for missing files
It seems to me that what's going on is that thrown ResourceExceptions are not getting their Status set to the Response. On 02/15/2010 05:58 PM, Tal Liron wrote: This seems to be true of revision 6132. Is this intentional, or a regression bug? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2447956
RE: Fallback routing
So, nobody provided a better solution, but here's mine, with source code straight out of the Prudence project! I call it a FallbackRouter, an extension of the standard Restlet router, and pretty much a drop-in replacement for it in most circumstances. Whenever you attach new targets to it, it makes sure to automatically bunch together identical routes via a Fallback restlet. The Fallback restlet goes through its targets in order, trying to find the first one that can handle the request. It thus falls back to the next target for that route. It also supports simple caching, so that the successful target can be remembered per reference, and wasteful re-attempts can be avoided in the (near) future. Detaching targets from the FallbackRouter is also done with sensitivity to un-bunching. This have proven very useful in Prudence, where we can allow serving dynamic HTML, static web files, and REST resources from the same base URI. Here is the source code from the current Prudence revision, though if you read this email later, always best to check for the freshest revision: http://prudence.tigris.org/source/browse/prudence/trunk/java/com.threecrickets.prudence/src/com/threecrickets/prudence/util/FallbackRouter.java?revision=145view=markup http://prudence.tigris.org/source/browse/prudence/trunk/java/com.threecrickets.prudence/src/com/threecrickets/prudence/util/Fallback.java?revision=145view=markup -Tal Here's my requirement: I have two restlets to attach to a router, both with the same URI template. What I want is that if the first restlet fails (specifically setting the response status to 404), then the next restlet would be tried. I'm calling this fallback routing. So far, the only thing that works well is my own custom restlet that tries these two (or more) restlets in series. But this solution is awkward and also circumvents the router. I've tried to create my own custom router with a custom routing mode, but the best this solution can offer is selection of a route. There's no simple way to fallback on the next route in line if the first one fails its handle(). I even thought to use Router's built in retry feature, but this would require runtime changing of the route list, which also seems awkward to me. Any better ideas? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2431841
Re: MIME Accept Type filter
Unfortunately, I can confirm that Andrzej's beforeSend fix is the way to
go on this one. Been doing it for a while now...
@Thierry: The dataType parameter in .ajax is just for jQuery to handle
the response. It doesn't actually do anything for jQuery's request.
An additional jQuery quirk to think about when working with Restlet is
that caching really messes things up with IE. Here's what I add every time:
$(function() {
if($.browser.msie) {
// Caching breaks Internet Explorer
$.ajaxSetup({
cache: false
});
}
}
Perhaps it's a good idea to set up a Client Quirks page on the Restlet
wiki? Obviously not Restlet's fault that clients are broken, but we need
them.
By the way, I had no issues ever with Ext-JS. The Ext-JS Core is
liberally licensed, and is almost a drop-in replacement for jQuery on
things like this.
-Tal
P.S. I really wish the browser JavaScript world would abandon the term
AJAX. It shows a lack of commitment to what these calls are really
about -- REST.
On 12/16/2009 07:58 AM, Andrzej Berico wrote:
Thierry,
1) Our JQuery Ajax call:
$.ajax({
type: 'GET',
url: myUrl,
success: onAjaxSuccess,
error: onAjaxError,
cache: false,
beforeSend :
function(xhr){xhr.setRequestHeader('Accept','application/xml')}
});
Will generate Accept header of */*, application/xml. We want
application/xml.
2) Our Restlet 1.1.5
@Override
public Restlet createRoot() {
// Create a router Restlet.
Router router = new Router(getContext());
// Attach our routers.
router.attach(/test, HelloWorldResource.class);
router.attach(/file/status, FileStatusResource.class);
return router;
}
public FileStatusResource(Context context, Request request, Response
response) {
super(context, request, response);
// Read URI query strings.
Form form = request.getOriginalRef().getQueryAsForm();
if (form != null) {
setUser(form.getFirstValue(user, isIgnoreCase()));
setOriginalUri(form.getFirstValue(originalUri,
isIgnoreCase()));
setAction(form.getFirstValue(action, isIgnoreCase()));
}
// Variants that our resource generates.
getVariants().add(new Variant(MediaType.APPLICATION_JSON));
getVariants().add(new Variant(MediaType.APPLICATION_XML));
}
@Override
public Representation represent(Variant variant) throws ResourceException {
Representation representation = null;
// Validate request
if (StringUtils.isBlank(getUser())) {
log.debug(GET FileStatusResource bad user. );
representation = representError(variant, new
ErrorMessage());
getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return representation;
}
representation = representGet(this,variant);
return representation;
}
public final Representation representGet(CoralReefResource crr, Variant
variant)
throws ResourceException {
Representation representation = null;
log.debug(HTTP GET for : + variant.getMediaType().getName());
...
Thierry Boileau wrote:
Hello Andrzej,
I wonder if the source cause if your issue is out there.
Could you tell us how are built your resources? How do you send the
request using jquery?
Best regards,
Thierry Boileau
Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A
JQuery
client, sets the Accept Type to */*, application/xml. So the Restlet
negotiates that APPLICATION_JSON should be returned as expected. However,
we
want APPLICATION_XML to be served. The problem is that we are unable to
remove the */* as the first Accept type in JQuery. JQuery seems to tack
on
the */* as an Accept Type to every request we send.
Is there an elegant way in Restlet to filter the */* values, e.g. ALL
or
APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and
re-arrange the Accept list ourselves to override the Restlet
negotiation.
We are thinking of filtering, after Restlet negotiation, based on the
User-Agent header for this particular JQuery client, so as not to break
the Restlet behaviour for other clients (which is what we expect.)
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430776
--
