Fallback routing

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

Re: Jackson extension added (Was: suggest jsonRepresentation update)

I knew this would finally happen. :) After evaluating the many JSON solutions out there, I also find Jackson to be the best. Cheers! -Tal On 11/25/2009 04:39 AM, Jerome Louvel wrote: Hi Ben, JSON-Simple looks fine as well, but lacks an automatic Object- JSON mapping mechanism. JSON-lib

REST talk in Chicago, Nov 12

Hi Restlet, For those in Chicago next Thursday, you are welcome to come to a free talk I will be giving about REST and the RESTful open-source platform, Prudence, which relies on Restlet. The talk is jointly organized by the Association for Computing Machinery (ACM) and Loyola University. For

Re: logging framework for restlet

Small mistake in the wiki: It says: org.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLogFacade But it should be: org.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLoggerFacade Jerome, this is a small but very considerate addition to Restlet. It's always good to

Re: logging framework for restlet

I use slf4j in my Restlet applications with much success. It will likely not be added to Restlet's distribution, but there's no reason why you can't do it on your own. Perhaps someone can write a recipe for how to do this on the Restlet wiki? No, I'm not volunteering myself. :) -Tal On

Re: CPU at 100%

One more thing to add -- While I still recommend my fix (it abides strictly by the usage of FilterInputStream and guarantees no evil thread thrashing), I do recommend a more thorough look at the whole RangeInputStream class. It seems to me that there are a few places that could use some more

Re: CPU at 100%

of times to see if this is a temporary issue of not. What do you think? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Tal Liron [mailto:tal.li

Re: CPU at 100%

So, I'd like to recommend my fix be merged. It seems to have done the trick. After three days of running, FilterInputStream.skip() returned zero only once, and my fix prevented a thrashing loop. I also have some more insight into what may cause this. This particular application is running on

Re: CPU at 100%

/2009 08:14 AM, Tal Liron wrote: Unfortunately, the thread thrashing re-appears even with the latest version of Sun's JDK6. So, I'm considering this a Restlet bug and will continue investigating. Using a recent Restlet svn build (a few days after 2.0M4). Here is the stack trace of the evil

Re: CPU at 100%

. - R On Wed, Aug 12, 2009 at 3:03 PM, Tal Liron tal.li...@threecrickets.com mailto:tal.li...@threecrickets.com wrote: This is a very useful thread! So, when you listed the problems with OpenJDK6 on Hardy and Jaunty, does this mean you didn't see the same problems using

Re: CPU at 100%

I have been running on an updated Jaunty, and yet still got the bug. Since there have been anecdotal reports on the net of having seen it recently, I assumed it might still be around. However... you brought me to double check, and it looks like the particular distribution of mine that has been

Re: CPU at 100%

This is a very useful thread! So, when you listed the problems with OpenJDK6 on Hardy and Jaunty, does this mean you didn't see the same problems using Sun's JDK6 on those platforms? -Tal --

Re: CPU at 100%

Sigh! Unfortunately, it took a bit longer (a few days), but sure enough, the thread thrashing returned. I've thus had to switch entirely to blocking IO (type=3 for Jetty). I'll keep you posted, and will also update the Tigris issue. -Tal On 08/11/2009 03:01 AM, Thierry Boileau wrote: Hi Tal,

Re: CPU at 100%

It can affect any user of java.nio, unless that user implements a rather dumb workaround involving constantly destroying and recreating the selector, which obviously creates a performance hit. As I understand it, this workaround has been introduced into Grizzly 2.0, but I don't know about

RE: CPU at 100%

I have new information about this bug, and a workaround. So, this is a known and multi-year issue with java.nio in Java 6 on Linux that has affected many nio projects, including Grizzly, Jetty and Netty. It's been fixed only relatively recently for Java 7 and recent builds of Java 6. Major

CPU at 100%

Before I open a Tigris issue on this, I want to make sure I'm not crazy. I'm getting 100% CPU utilization, and it seems to be done here: org.restlet.engine.application.RangeInputStream.read This is on Linux, JDK6 using both Grizzly and Jetty connectors (with the latest versions of both).

Route to TemplateRoute

Hi Jerome/Thierry, As usual, I'm on the cutting edge of Subversion snapshots. I've seen Route has been deprecated for a while in favor of TemplateRoute. Is there information available on how to migrate code, or what the new strategy is? Congrats on getting the edition builds up and running.

Re: Restlet 2.0 M3 released

at 2:30 PM, Tal Liron tal.li...@threecrickets.com mailto:tal.li...@threecrickets.com wrote: 1. Routing: Routing seems to be being reworked. I'm not sure how it will look for the final release as of yet, but the RFEs point to some very useful abilities. 2. High-level HTTP

Re: Restlet 2.0 M3 released

: Hi Tal, This should now be fixed in SVN trunk. Could you confirm? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Tal Liron [mailto:tal.li

Re: Restlet 2.0 M3 released

To add to this -- It seems that something changed with how negotiated mode is handled. It's breaking not just Directory, but also some of my other ServerResources. With my resources, I found that setNegotiated(false) fixed the problem, so I'm guessing that the bug introduced is somewhere

Re: GSON

? Than I like one of them to be integrated. If someone wants to write the MessageBodyWriter and Reader, or shows me, how to use GSON and/or Jackson, than let me know best regards Stephan Tal Liron schrieb: For what it's worth -- I've moved all my applications to use Jackson

Chicago, Scripting, Restlet

If anyone is in Chicago on Thursday, you can come see me present at the Chicago Python group on using Python to write a RESTful application (via Restoration, Scripturian, Jython, Restlet and Grizzly). For more information: http://www.chipy.org/ -Tal

Upstream IP address

Hi all, I'm having trouble with ClientInfo.getUpstreamAddress(). My setup is an Apache server with ProxyPass to my Restlet(svn)/Grizzly connector. This seems to always return 127.0.0.1, rather than the true upstream address. Any ideas? As far as I can tell, Apache is correctly setting the

Scripted Restlet - Demo Distribution

Hello Restleteers, The scripted edition of Restlet is ready for demoing and testing. I'm including a link to download a distribution that should run immediately on any Java 5 compatible machine. I hope you'd give it a spin! Scripted Restlet is development platform that lets you use

Scripted Restlet - Demo Distribution

Hello Restleteers, The scripted edition of Restlet is ready for demoing and testing. I'm including a link to download a distribution that should run immediately on any Java 5 compatible machine. I hope you'd give it a spin! Scripted Restlet is development platform that lets you use

Re: ServerResource is currently incompatible with OSGi

think just having an AnnotationUtils.clearCache method would work well. Call it whenever an Application stops, say. It's worth a little redundant computation to avoid having to deal with shared locks and liveness. --tim On Thu, Apr 9, 2009 at 2:22 PM, Tal Liron tal.li

Re: Annotations and Restlet's future

Hi Jerome, How about instead of calling setAnnotated(false), there would be an annotation to turn annotation on? Since this doesn't seem like behavior you'd want to turn on or off during the life of the resource instance, it seems like it should be defined at the class level, not in the

Re: ServerResource conditional mode

by the ServerResource#handle() method. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder~ http://www.noelios.com De: Tal Liron [mailto:tal.li...@threecrickets.com] Envoy: jeudi 9 avril 2009

Re: ServerResource conditional mode

developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder~ http://www.noelios.com De: Tal Liron [mailto:tal.li...@threecrickets.com] Envoy: vendredi 10 avril 2009 20:09 : discuss@restlet.tigris.org Objet: Re: ServerResource conditional mode Pretty good... except

YAJSW as a replacement for Tanuki's Java Service Wrapper

If, like me, you have been disappointed by Tanuki's moving from LGPL to GPL, coupled with their charging very, very high prices for commercial licenses, then I strongly recommend you look at YAJSW: http://yajsw.sourceforge.net/ The product is still in alpha, but it's very promising, and

Re: Annotations and Restlet's future

It seems like I'm the only one here working with non-annotated ServerResources right now, so I'd chime in and add that you actually need to override more than method for each REST method as it stands. There's get(), get(variant), post(entity), post(entity, variant), put(entity), put(entity,

Re: ServerResource is currently incompatible with OSGi

is likely to be a performance bottleneck: every request has to grab a global lock. --tim On Wed, Apr 8, 2009 at 2:06 PM, Tal Liron tal.li...@threecrickets.com wrote: Hmm. I disagree that this has nothing to do with the Application. For example, if an Application is unloaded, t

Re: Restlet 1.2 M2 released [throw previous email away]

addExtension("wav", MediaType.AUDIO_WAV);     addExtension("wrl", MediaType.MODEL_VRML);     addExtension("xht", MediaType.APPLICATION_XHTML);     addExtension("xhtml", MediaType.APPLICATION_XHTML);     addExtension("xls&q

Re: DirectoryResource throws/logs useless exceptions for CLAP protocol

This is something that concerns me, too, as I'd much rather have my applications purely in the Restlet API without reverting specifically to the connector. I've been using Directory, too, in production and without any issue except my uneasiness about performance. I have not dared use it (yet)

Re: Restlet 1.2 M2 released [throw previous email away]

.org Noelios Technologies ~ Co-founder~ http://www.noelios.com De: Tal Liron [mailto:tal.li...@threecrickets.com] Envoy: mardi 7 avril 2009 20:35 : discuss@restlet.tigris.org Objet: Re: Restlet 1.2 M2 released [throw previous email away] I like the idea of havin

Re: ServerResource is currently incompatible with OSGi

--tim On Tue, Apr 7, 2009 at 1:20 PM, Tal Liron tal.li...@threecrickets.com wrote: Ah, I can see your point now. I would recommend, then, that a Context would have two separate ConcurrentHashMaps, something like this: 1. Context.getConfiguration() -- this would be for

Re: ServerResource conditional mode

clarifies. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder~ http://www.noelios.com De: Tal Liron [mailto:tal.li...@threecrickets.com] Envoy: jeudi 2 avril 2009 23:20 : discuss@restlet.

Re: ServerResource conditional mode

Jerome, regarding exceptions caught -- You've implemented this only for when users override methods in non-annotated mode. In annotated mode, exceptions are still not allowed. This leads to different ways of doing things if you're in annotated or non-annotated mode. Personally, I think that

Re: Annotations and Restlet's future

Nicely put, Rob. I have to agree in the general sense. I'd even add that annotations are one of the most abused features in Java, and I often regret their introduction into the language. For every problem solved elegantly with an annotation, you'd find ten solutions made worse. Sometimes, I

Re: ServerResource is currently incompatible with OSGi

Ah, I can see your point now. I would recommend, then, that a Context would have two separate ConcurrentHashMaps, something like this: 1. Context.getConfiguration() -- this would be for the user 2. Context.getImplementationCache() -- this would be for things like AnnotationUtils, and the

Re: Resource factories

will give you a chance to play with the new resource API and provide feed-back. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com De : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : jeudi

Re: Restlet 1.2 M2 released [throw previous email away]

loper ~ http://www.restlet.org Noelios Technologies ~ Co-founder~ http://www.noelios.com De: Tal Liron [mailto:tal.li...@threecrickets.com] Envoy: vendredi 3 avril 2009 07:46 : discuss@restlet.tigris.org Objet: Re: Restlet 1.2 M2 released [throw previous email away]

Re: Restlet 1.2 M2 released [throw previous email away]

tion value string with proper warning message. So your concern will definitely be addressed! Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder~ http://www.noelios.com De: Tal Liron

Re: ServerResource is currently incompatible with OSGi

I've noticed this, too, but couldn't immediately think of an application where this would be a problem... thanks for bringing up OSGi. An immediate solution could be to append the class's ClassLoader instance into the key: org.restlet.resource.ServerResource.annotations.classloader

Re: ServerResource conditional mode

David, The MediaType extension as an argument for the @Get, @Post, @Put and @Delete annotation is always for the returned representation, not for the entity sent from the client. Restlet does not do anything with what the client sends you -- it's up to you to process the entity, support

Re: ServerResource conditional mode

You don't need to put a media type if you're using void (although, you could potentially have more than one @Post handler, for several media types, to be used depending on the expectation of a media type from the client...). But, you do need to disable conditional mode: @Post public void

Re: Restlet 1.2 M2 released [throw previous email away]

The MetadataService is what you're talking about. It translates between strings and other useful dimensions (in this case, MediaType instances). Right now, though, it only supports "extensions" as the strings, which mean to be filename extensions. So that's why we have "txt" as the shorthand

ServerResource conditional mode

Hi, Does someone have a grasp on what conditional mode is for and how it used? It's enabled by default, but I had to disable it for one of my resources to work with PUT and POST. The issue is that it always calls doGetInfo first, which for my particular resource will fail, and so calls to

Re: Restlet 1.2 M2 released [throw previous email away]

Hi David, I agree that filename extensions are not the best way to go here, but I see nothing wrong with supporting them in addition to MIME types. As for supporting MIME types, it seems we already have a facility in Restlet via MediaType.valueOf():

Re: CSS and HTTPS problem ...

To add to Rob's hunch -- My guess is that you are using a relative URL to access the CSS, and that you don't have a trailing slash after your base URL. For example, your base URL might be: http://localhost:8080/myapplication/main While your CSS link would be: link href="my.css"

Re: Resource factories

Thanks to all who replied on this. After a discussion on the code list, it became clear that the Restlety solution to configuring resources is to use the Context. The Context has a ConcurrentMap of attributes, described as so: "This is a convenient mean[s] to provide common objects to all the

Re: Resource factories

of this in a (Restlet) Context somehow, and looking that up at ScriptResource construction time? --tim On Mon, Mar 23, 2009 at 9:18 PM, Tal Liron tal.li...@threecrickets.com wrote: ... Specifically, I would be very happy if you and others could take a look at the script

Re: Resource factories

Thanks, Tim. This is a reasonable workaround -- creating a factory where one isn't there. And Guice adds some elegance to your solution. Another solution is simply to rewrite Finder entirely to use factories. This isn't hard. But it also goes against Restlet's current design. One of the very

Re: Resource factories

Good point, Rhett. Well, let me put it this way -- do you think the current Finder design encourages bad practices for Restlet users? -Tal Rhett Sutphin wrote: I don't think that subclassing Finder to be more factory-like goes against Restlet's design. The default finder is a

Re: Resource factories

ce object hierarchies. I don't think these are mutually exclusive. On Mon, Mar 23, 2009 at 2:34 PM, Tal Liron tal.li...@threecrickets.com wrote: Good point, Rhett. Well, let me put it this way -- do you think the current Finder design encourages bad practices for Restlet users? -Tal

Re: Resource factories

Thanks, Rob! I value your gut instinct in this. Perhaps, then, we can indeed move this over the code review side. Specifically, I would be very happy if you and others could take a look at the script extension I am working on in Restlet svn. It has two Resource-based classes that currently

Resource factories

Hey Restleters, Sorry if this question has been answered before -- I'm rather new to the community, even though I've been a heavy Restlet user for a while. I understand and agree with abstract class design used by Restlet, as is detailed by the wiki:

<    1   2