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