Returning data after PUT/POST
Hello everyone, I'm currently working on my first restlet application and have one big question. Typically when I want to persist some data I will not know certain information about it (i.e. the ID of the data). Instead of creating the object and searching for it I usually design my DAO to return the same object with the missing information filled in once it's been submitted to the persistence layer. I have noticed in building my restlet app that the storeRepresentation method does not return any type of data, only a status. Some of the clients that will be using the service would greatly benefit from the DAO style of data creation. So, how can I mimick this behavior in restlet so that a successful PUT returns the data back to the client as representation? Thanks for your time, Jean-Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1027657
Re: Returning data after PUT/POST
Based on the way i've currently constructed my app this may not be possible. If I want to add a resource named car I perform a PUT on a url like http://localhost/myapp/car/ instead of http://localhost/myapp/car/15. This is because I do not want the client to be responsible for managing identifiers (that is what the persistence layer is for). I think Jerome's suggestion will work more favorably here. Although perhaps there is a better way to handle this type of transaction? I've also noticed that to return a list of some data such as car the typical method is to implement a second resource cars. Perhaps its a matter of taste but I would think it would be simpler for the client user to assume if you do not enter an ID or other search parameter into the URI then it implies a "catch all". For example, GET http://localhost/myapp/car/ returns a list of all car objects GET http://localhost/myapp/car/15 returns the car object with ID 15 GET http://localhost/myapp/car/bodystyle/coupe returns all car objects with body style coupe Would not this be simpler? What are the realistic benefits to actually creating another resource cars? Lastly, is there a standard way to simplify creating resources so that performing GET on http://localhost/myapp/car/bodystyle/coupe doesn't require implementing a separate resource from http://localhost/myapp/car? Instead the /bodystyle/coupe part of the URI just becomes a search parameter of the car resource? Jean-Philippe On Fri, Jan 16, 2009 at 12:24 AM, Karel Vervaeke wrote: > I'm not sure if this will help you, but in case of a PUT, you already > know the url, issuing a GET to the same url > should (by your implementation) return the same entity body you > presented in the PUT. If you want to retrieve a 'more informative' > representation (i.e. including the 'internal' id), you could add a > query parameter to the url. > > Alternatively (more appropriate in case of a POST) you can return a > 201 Created status code [1] (with Location headers and url's in the > entity body) or a 202 Accepted status code > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2 > > HTH, > Karel > > On Fri, Jan 16, 2009 at 2:37 AM, Jean-Philippe Steinmetz > wrote: > > Hello everyone, > > > > I'm currently working on my first restlet application and have one big > > question. Typically when I want to persist some data I will not know > certain > > information about it (i.e. the ID of the data). Instead of creating the > > object and searching for it I usually design my DAO to return the same > > object with the missing information filled in once it's been submitted to > > the persistence layer. > > > > I have noticed in building my restlet app that the storeRepresentation > > method does not return any type of data, only a status. Some of the > clients > > that will be using the service would greatly benefit from the DAO style > of > > data creation. So, how can I mimick this behavior in restlet so that a > > successful PUT returns the data back to the client as representation? > > > > Thanks for your time, > > > > Jean-Philippe > > > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1038847
RESTlet + Spring
Hi All, I'm working on integrating restlet and spring for use in a web app to be run under Tomcat. After reading up on the Spring extension (thank you Jerome) I have decided to go the restlet as the main controller route. This is due to the fact that Spring is only being used as a Dao implementation layer. I came across the com.noelios.restlet.ext.spring.RestletFrameworkServlet class. Based on its description it would appear this is what I should use to properly set things up. Unfortunately I am getting crash errors when I try and access my restlet app from a browser. I am hoping someone may be able to shed some light on the situation. The error I am getting is: java.lang.IllegalArgumentException: Value does not implement specified type org.springframework.util.Assert.isTrue(Assert.java:65) org.springframework.beans.factory.support.DefaultListableBeanFactory.registerResolvableDependency(DefaultListableBeanFactory.java:325) org.springframework.web.context.support.WebApplicationContextUtils.registerWebApplicationScopes(WebApplicationContextUtils.java:129) org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.postProcessBeanFactory(AbstractRefreshableWebApplicationContext.java:143) org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:359) org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:332) org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:266) org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:236) org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:126) javax.servlet.GenericServlet.init(GenericServlet.java:212) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:857) org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565) org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509) java.lang.Thread.run(Unknown Source) Here is what my web.xml file looks like: http://java.sun.com/dtd/web-app_2_3.dtd"; > Web Service org.restlet.application webservice.RestApplication webservices com.noelios.restlet.ext.spring.RestletFrameworkServlet 1 webservices /* I also have a webservices-servlet.xml file for Spring bean definition. It looks like: http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:util="http://www.springframework.org/schema/util"; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd";> classpath:persistence.xml Any ideas what the problem is? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1038898
Re: RESTlet + Spring
I'm using maven to manage all the dependencies. It's possible something is incorrectly done in my pom. For Spring I am using 2.5.6 for spring-core, spring-context and spring-web. I am using 2.0.8 for spring-hibernate3 and spring-jpa. For restlet I am using 1.1.1 for everything. Here is my pom.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.webservice webservice war 0.3 Web Service javax.servlet servlet-api 2.5 com.noelios.restlet com.noelios.restlet 1.1.1 com.noelios.restlet com.noelios.restlet.ext.servlet 1.1.1 com.noelios.restlet com.noelios.restlet.ext.spring 1.1.1 org.restlet org.restlet 1.1.1 org.restlet org.restlet.ext.json 1.1.1 com.thoughtworks.xstream xstream 1.3 org.codehaus.jettison jettison 1.0-RC2 javax.persistence persistence-api 1.0 org.hibernate hibernate-core 3.3.1.GA mysql mysql-connector-java 5.1.6 org.springframework spring-core 2.5.6 org.springframework spring-context 2.5.6 org.springframework spring-hibernate3 2.0.8 org.springframework spring-jpa 2.0.8 org.springframework spring-web 2.5.6 ch.qos.logback logback-classic 0.9.11 org.slf4j slf4j-api 1.5.3 junit junit 3.8.1 test org.codehaus.mojo tomcat-maven-plugin LocalTomcat maven-compiler-plugin 1.5 1.5 true jboss http://repository.jboss.com/maven2 true false jboss-snapshot http://repository.jboss.org/maven2 true true restlet http://maven.restlet.org On Tue, Jan 20, 2009 at 12:34 PM, Rhett Sutphin wrote: > Hi Jean-Philippe, > > At first glance, the error seems to be a generic spring error -- that > one of the wired dependencies is of the wrong type. Looking at your > XML, I wonder if it is failing here: > > > > value="persistenceUnitManager"/> > > > > I think those should be "ref" instead of "value". I haven't seen this > particular error before, though, so I'm not sure. > > If it's not that, would you please let us know what versions of Spring > and Restlet you are using? > > Rhett > > On Jan 20, 2009, at 1:04 PM, Jean-Philippe Steinmetz wrote: > > > Hi All, > > > > I'm working on integrating restlet and spring for use in a web app > > to be run under Tomcat. After reading up on the Spring extension > > (thank you Jerome) I have decided to go the restlet as the main > > controller route. This is due to the fact that Spring is only being > > used as a Dao implementation layer. I came across the > > com.noelios.restlet.ext.spring.RestletFrameworkServlet class. Based > > on its description it would appear this is what I should use to > > properly set things up. Unfortunately I am getting crash errors when > > I try and access my restlet app from a browser. I am hoping someone > > may be able to shed some light on the situation. > > > > The error I am getting is: > > java.lang.IllegalArgumentException: Value does not implement > > specified type > > org.springframework.util.Assert.isTrue(Assert.java:65) > > > > org > > .springframework > > .beans > > .factory > > .support > > .DefaultListableBeanFactory > > .registerResolvableDependency(DefaultListableBeanFactory.java:325) > > > > > org.springframework.web.context.support.WebApplicationContextUtils.registerWebApplicationScopes > > (WebApplicationContextUtils.java:129) > > > org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.postProcessBeanFactory > > (AbstractRefreshableWebApplicationContext.java:143) > > > > > > org > > .springframework > > .context > > .support > > .AbstractApplicationContext.refresh(AbstractApplicationContext.java: >
Re: RESTlet + Spring
Ok i've changed my depedencies to use restlet 1.1-SNAPSHOT and 2.5 for spring. I am getting what looks like a running system. Is there any way to customize this page... The server has not found anything matching the request URI You can get technical details here<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5> . Please continue your visit at our home page <http://localhost:8080/>. Thanks again, Jean-Philippe On Tue, Jan 20, 2009 at 2:27 PM, Jerome Louvel wrote: > Hi Jean-Philippe, > > I've noticed that we declare a dependency on Spring 2.5 and not on the > latest 2.5.6. This may be the cause of your issue. > > I've just updated the dependency in SVN branch 1.1 and trunk. > > Best regards, > Jérôme Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > > -- > *De :* Jean-Philippe Steinmetz [mailto:caskate...@gmail.com] > *Envoyé :* mardi 20 janvier 2009 22:42 > *À :* discuss@restlet.tigris.org > *Objet :* Re: RESTlet + Spring > > I'm using maven to manage all the dependencies. It's possible something is > incorrectly done in my pom. For Spring I am using 2.5.6 for spring-core, > spring-context and spring-web. I am using 2.0.8 for spring-hibernate3 and > spring-jpa. For restlet I am using 1.1.1 for everything. > > Here is my pom.xml > > http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" > http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > com.webservice > webservice > war > 0.3 > Web Service > > > > > javax.servlet > servlet-api > 2.5 > > > com.noelios.restlet > com.noelios.restlet > 1.1.1 > > > com.noelios.restlet > com.noelios.restlet.ext.servlet > 1.1.1 > > > com.noelios.restlet > com.noelios.restlet.ext.spring > 1.1.1 > > > org.restlet > org.restlet > 1.1.1 > > > org.restlet > org.restlet.ext.json > 1.1.1 > > > > > com.thoughtworks.xstream > xstream > 1.3 > > > org.codehaus.jettison > jettison > 1.0-RC2 > > > > > javax.persistence > persistence-api > 1.0 > > > org.hibernate > hibernate-core > 3.3.1.GA > > > mysql > mysql-connector-java > 5.1.6 > > > > > org.springframework > spring-core > 2.5.6 > > > org.springframework > spring-context > 2.5.6 > > > org.springframework > spring-hibernate3 > 2.0.8 > > > org.springframework > spring-jpa > 2.0.8 > > > org.springframework > spring-web > 2.5.6 > > > > > ch.qos.logback > logback-classic > 0.9.11 > > > org.slf4j > slf4j-api > 1.5.3 > > > > > junit > junit > 3.8.1 > test > > > > > > > org.codehaus.mojo > tomcat-maven-plugin > > LocalTomcat > > > > maven-compiler-plugin > > 1.5 > 1.5 > true > > > > > > > > jboss > http://repository.jboss.com/maven2 > > true > > > false > > > > jboss-snapshot > http://repository.jboss.org/maven2 > > true > > > true > > > > restlet > http://maven.restlet.org > > > > > > On Tue, Jan 20, 2009 at 12:34 PM, Rhett Sutphin > wrote: > >> Hi Jean-Philippe, >> >> At first glance, the error seems to be a generic spring error -- that >> one of the wired dependencies is of the wrong type. Looking at your >> XML, I wonder if it is failing here: >> >> > > > value="persistenceUnitManager"/> >> > >> >> I think those shoul
Re: RESTlet + Spring
he > StatusService class and related property for your Application. > > Best regards, > Jérôme Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > -- > *De :* Jean-Philippe Steinmetz [mailto:caskate...@gmail.com] > *Envoyé :* mardi 20 janvier 2009 23:57 > *À :* discuss@restlet.tigris.org > *Objet :* Re: RESTlet + Spring > > Ok i've changed my depedencies to use restlet 1.1-SNAPSHOT and 2.5 for > spring. I am getting what looks like a running system. > > Is there any way to customize this page... > The server has not found anything matching the request URI > > You can get technical details > here<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5> > . > Please continue your visit at our home page <http://localhost:8080/>. > > Thanks again, > > Jean-Philippe > > On Tue, Jan 20, 2009 at 2:27 PM, Jerome Louvel > wrote: > >> Hi Jean-Philippe, >> >> I've noticed that we declare a dependency on Spring 2.5 and not on the >> latest 2.5.6. This may be the cause of your issue. >> >> I've just updated the dependency in SVN branch 1.1 and trunk. >> >> Best regards, >> J�r�me Louvel >> -- >> Restlet ~ Founder and Lead developer ~ >> http://www.restlet.org >> Noelios Technologies ~ Co-founder ~ http://www.noelios.com >> >> >> >> -- >> *De :* Jean-Philippe Steinmetz [mailto:caskate...@gmail.com] >> *Envoy� :* mardi 20 janvier 2009 22:42 >> >> *� :* discuss@restlet.tigris.org >> *Objet :* Re: RESTlet + Spring >> >> I'm using maven to manage all the dependencies. It's possible something >> is incorrectly done in my pom. For Spring I am using 2.5.6 for spring-core, >> spring-context and spring-web. I am using 2.0.8 for spring-hibernate3 and >> spring-jpa. For restlet I am using 1.1.1 for everything. >> >> Here is my pom.xml >> >> http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" >> http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >> http://maven.apache.org/maven-v4_0_0.xsd";> >> 4.0.0 >> com.webservice >> webservice >> war >> 0.3 >> Web Service >> >> >> >> >> javax.servlet >> servlet-api >> 2.5 >> >> >> com.noelios.restlet >> com.noelios.restlet >> 1.1.1 >> >> >> com.noelios.restlet >> com.noelios.restlet.ext.servlet >> 1.1.1 >> >> >> com.noelios.restlet >> com.noelios.restlet.ext.spring >> 1.1.1 >> >> >> org.restlet >> org.restlet >> 1.1.1 >> >> >> org.restlet >> org.restlet.ext.json >> 1.1.1 >> >> >> >> >> com.thoughtworks.xstream >> xstream >> 1.3 >> >> >> org.codehaus.jettison >> jettison >> 1.0-RC2 >> >> >> >> >> javax.persistence >> persistence-api >> 1.0 >> >> >> org.hibernate >> hibernate-core >> 3.3.1.GA >> >> >> mysql >> mysql-connector-java >> 5.1.6 >> >> >> >> >> org.springframework >> spring-core >> 2.5.6 >> >> >> org.springframework >> spring-context >> 2.5.6 >> >> >> org.springframework >> spring-hibernate3 >> 2.0.8 >> >> >> org.springframework >> spring-jpa >> 2.0.8 >> >> >> org.springframework >> spring-web >> 2.5.6 >> >> >> >> >> ch.qos.logback >> logback-classic >> 0.9.11 >> >> >> org.slf4j >> slf4j-api >> 1.5.3 >> >> >> >> >> junit >> junit >> 3.8.1 >> test >> >> >> >> >> >> >>
Auto-Attachment of Resources to Router
Hello again, Quick question about attaching URI patterns and resource classes to the router. Is there a way to make this happen more automagically with annotations or some other mechanism? Adding each one by hand will get unwieldy and requires touching the main Application class every time I want to add a new resource. I see there is some work with this with JAX-RS but I wasn't sure if this was included in restlet or not. Thanks much, Jean-Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1041869
Re: Returning data after PUT/POST
Thanks for all the help. If you are both suggesting using POST to add an entry why use PUT then? It seems to make PUT somewhat irrelevant unless performing an update. I'm going to have to do some rethinking. I'm mainly using this rest service for passing serialized objects back and forth between the service and clients. I had originally imagined that the difference between the cars and car was merely that car returned a single full car object (serialized of course) while cars returned an array or list (also full objects) but I can see where you'd think otherwise. The way you define a list below would require some extra processing that I don't necessarily do when working with serialization. Has anyone else come across this kind of a scenario? Jean-Philippe? On Tue, Jan 20, 2009 at 6:45 PM, Donald S Strong < donald.str...@transport.vic.gov.au> wrote: > Hi Jean-Philippe, > > > If I want to add a resource named car I perform a PUT on a url like > http://localhost/myapp/car/ instead of http://localhost/myapp/car/15. > > I agree with Rhett, use POST and then GET. > > POST http://localhost/myapp/car creates the car object with a new ID and > redirects to the URI > GET http://localhost/myapp/car/15 returns the car object with ID 15 > > > I've also noticed that to return a list of some data such as car the > typical method is to implement a second resource cars. > > Perhaps its a matter of taste but I would think it would be simpler for > the client user to assume if you do not enter an ID or other search > parameter into the URI then it implies a "catch all". > > Would not this be simpler? What are the realistic benefits to actually > creating another resource cars? > > A "single car" and "a list of cars" are logicaly different resources; the > structures they return are quite different. > A list of cars will probably contain many URIs, each refering to a single > car. > eg. > > > >http://localhost/myapp/vehicles returns a list of all bike, car and > truck objects. > > > Lastly, is there a standard way to simplify creating resources so that > performing GET on http://localhost/myapp/car/bodystyle/coupe doesn't > require implementing a separate resource from http://localhost/myapp/car? > Instead the /bodystyle/coupe part of the URI just becomes a search > parameter of the car resource? > > You can use the same resource implementation if it takes parameters. > Theoretically these are different resources, but in practice they can use > the same implementation class. > > GET http://localhost/myapp/cars returns a list of all car objects > GET http://localhost/myapp/cars?bodystyle=coupe returns all car objects > with body style coupe > GET http://localhost/myapp/cars?color=blue returns all blue car objects > > Regards > Donald. > > > ** > Any personal or sensitive information contained in this email and > attachments must be handled in accordance with the Victorian Information > Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988 > (Commonwealth), as applicable. > > This email, including all attachments, is confidential. If you are not the > intended recipient, you must not disclose, distribute, copy or use the > information contained in this email or attachments. Any confidentiality or > privilege is not waived or lost because this email has been sent to you in > error. If you have received it in error, please let us know by reply > email, delete it from your system and destroy any copies. > ** > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1040074 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1041749
Re: Auto-Attachment of Resources to Router
Oh I like the idea of that... i've tried setting it up but now i'm getting the following error: Jan 22, 2009 3:16:58 PM org.restlet.Filter doHandle WARNING: A filter was executed without a next Restlet attached to it. Here is my web.xml: Web Service webservices com.noelios.restlet.ext.spring.RestletFrameworkServlet 1 webservices /* And here is my applicationContext http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:util="http://www.springframework.org/schema/util"; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd";> Any ideas what could be wrong? Jean-Philippe On Wed, Jan 21, 2009 at 11:13 PM, Rhett Sutphin wrote: > Hi Jean-Philippe, > > On Jan 21, 2009, at 1:07 PM, Jean-Philippe Steinmetz wrote: > > > Quick question about attaching URI patterns and resource classes to > > the router. Is there a way to make this happen more automagically > > with annotations or some other mechanism? Adding each one by hand > > will get unwieldy and requires touching the main Application class > > every time I want to add a new resource. I see there is some work > > with this with JAX-RS but I wasn't sure if this was included in > > restlet or not. > > Since you are already using Spring, you might consider using > SpringBeanRouter: > > > http://www.restlet.org:8080/documentation/1.1/ext/org/restlet/ext/spring/SpringBeanRouter.html > > It allows you to define URI templates in your application context. It > also allows you to do Spring DI on the resource instances. > > Rhett > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1042895 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1043753
Re: Returning data after PUT/POST
Thanks again for everyone's input.
I re-read through some of the REST docs and realized my misunderstanding of
the PUT/POST methods. For simplicity I think the idea of mapping the URI
pattern /cars/{id} to the singular resource implementation and /cars to the
plural will be sufficient; with PUT supported in the singular and POST
supported in the plural. This seems to be the proper RESTful approach?
As for my lists I can definitely see the merit in including only references
to objects instead of a complete list when that collection becomes large. I
am also quite certain that my application will see an increasingly large
number of objects within it's lifetime. However, the clients utilizing this
service will be strictly machines and in some circumstances may benefit from
a complete representation list. So maybe it would be beneficial to create an
attribute called mode that could have the values "full" or "lite" that would
return a list accordingly.
I'll try and give an example of where this situation may be useful.
Unfortunately I cannot discuss the actual data we are working with (due to
confidentiality) so I will try and make the car analogy fit as well as
possible. Let's say i'm writing a visualization system where I have a car
that is composed of N number of graphical assets. My visualizer would query
the service for all assets that make up a particular car. By obtaining the
full list of assets the visualizer can immediately begin drawing the car
without having to perform a look up for each asset.
On Wed, Jan 21, 2009 at 11:38 PM, Rhett Sutphin
wrote:
> > If you are both suggesting using POST to add an entry why use PUT
> > then? It seems to make PUT somewhat irrelevant unless performing an
> > update.
>
> PUT is useful for updates. It's also useful when the client
> determines the resource's URL. This latter case is pretty common --
> some systems don't expose their internal IDs in the URI, but rather
> use an identifier which is shared between the client and the server.
> In that case, the client already knows what the URI will be, even
> before it is added to the system.
>
> E.g., in the main application I work on, one of the central concepts
> is a study template. Studies have an externally assigned identifier
> which is defined before either the server or the client has anything
> to do with the template, and can never change. We use that assigned
> identifier in the URIs. This has the benefit of making the URIs
> easier to read and allowing clients to not have to distinguish between
> creates and updates.
>
> > The way you define a list below would require some extra processing
> > that I don't necessarily do when working with serialization.
>
> I don't want to speak for Donald, but I think he was just providing an
> example representation to make his suggestions more concrete. You
> should tune your representation to the requirements of your
> application, of course.
>
> Rhett
>
> On Jan 21, 2009, at 12:56 PM, Jean-Philippe Steinmetz wrote:
>
> > Thanks for all the help.
> >
> > If you are both suggesting using POST to add an entry why use PUT
> > then? It seems to make PUT somewhat irrelevant unless performing an
> > update.
> >
> > I'm going to have to do some rethinking. I'm mainly using this rest
> > service for passing serialized objects back and forth between the
> > service and clients. I had originally imagined that the difference
> > between the cars and car was merely that car returned a single full
> > car object (serialized of course) while cars returned an array or
> > list (also full objects) but I can see where you'd think otherwise.
> > The way you define a list below would require some extra processing
> > that I don't necessarily do when working with serialization. Has
> > anyone else come across this kind of a scenario?
> >
> > Jean-Philippe?
> >
> > On Tue, Jan 20, 2009 at 6:45 PM, Donald S Strong <
> donald.str...@transport.vic.gov.au
> > > wrote:
> > Hi Jean-Philippe,
> >
> > > If I want to add a resource named car I perform a PUT on a url like
> > http://localhost/myapp/car/ instead of http://localhost/myapp/car/15.
> >
> > I agree with Rhett, use POST and then GET.
> >
> > POST http://localhost/myapp/car creates the car object with a new
> > ID and
> > redirects to the URI
> > GET http://localhost/myapp/car/15 returns the car object with ID 15
> >
> > > I've also noticed that to return a list of some data such as car the
> > typical method is to implement a second resource cars.
> > > Perhaps its a matter of taste but I would think i
Re: Auto-Attachment of Resources to Router
Excellent that works. One more quick question. I noticed that I had to remove all the original constructors for Resources that took parameters. I perform my data look up in the constructor but since Spring hasn't injected everything yet i'm getting null pointer exceptions. Is there an init function or some standard method that gets called after all Spring is finished setting things up? Jean-Philippe On Fri, Jan 23, 2009 at 8:27 AM, Rhett Sutphin wrote: > Hi Jean-Philippe, > > Your Application bean isn't connected to the router. Since you are > not using a custom Application, you could just remove the Application > bean and make the router the root (either by naming it "root" or by > setting the targetRestletBeanName parameter for > RestletFrameworkServlet to "router"). RestletFrameworkServlet will > automatically instantiate a default Application. > > If you do want to create your own application instance (e.g., because > you decide later that you want a custom version), you need to attach > the router as the root of the Application: > > > > > > Rhett > > On Jan 22, 2009, at 5:18 PM, Jean-Philippe Steinmetz wrote: > > > Oh I like the idea of that... i've tried setting it up but now i'm > > getting the following error: > > > > Jan 22, 2009 3:16:58 PM org.restlet.Filter doHandle > > WARNING: A filter was executed without a next Restlet attached to it. > > > > Here is my web.xml: > > > > Web Service > > > > > > > > webservices > >> class>com.noelios.restlet.ext.spring.RestletFrameworkServlet > servlet-class> > > 1 > > > > > > > > > > webservices > > /* > > > > > > > > And here is my applicationContext > > > > http://www.springframework.org/schema/beans"; > >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > >xmlns:util="http://www.springframework.org/schema/util"; > >xsi:schemaLocation=" > > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd > > http://www.springframework.org/schema/util > http://www.springframework.org/schema/util/spring-util-2.5.xsd > > "> > > > > > > > > > class="org.restlet.ext.spring.SpringBeanRouter"/> > > > > > > > scope="prototype" > > class="com.trilogy.engine.webservice.restlets.AssetsResource"> > > > > > > > scope="prototype" > > class="com.trilogy.engine.webservice.restlets.AssetResource"> > > > > > > > > > scope="prototype" > > > > class="com.trilogy.engine.webservice.restlets.BodyPartsResource"> > > > > > > > autowire="byName" scope="prototype" > > > > class="com.trilogy.engine.webservice.restlets.BodyPartsResource"> > > > > > > > > > > Any ideas what could be wrong? > > > > Jean-Philippe > > > > On Wed, Jan 21, 2009 at 11:13 PM, Rhett Sutphin < > rh...@detailedbalance.net > > > wrote: > > Hi Jean-Philippe, > > > > On Jan 21, 2009, at 1:07 PM, Jean-Philippe Steinmetz wrote: > > > > > Quick question about attaching URI patterns and resource classes to > > > the router. Is there a way to make this happen more automagically > > > with annotations or some other mechanism? Adding each one by hand > > > will get unwieldy and requires touching the main Application class > > > every time I want to add a new resource. I see there is some work > > > with this with JAX-RS but I wasn't sure if this was included in > > > restlet or not. > > > > Since you are already using Spring, you might consider using > > SpringBeanRouter: > > > > > http://www.restlet.org:8080/documentation/1.1/ext/org/restlet/ext/spring/SpringBeanRouter.html > > > > It allows you to define URI templates in your application context. It > > also allows you to do Spring DI on the resource instances. > > > > Rhett > > > > -- > > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1042895 > > > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1045059 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1045323
Re: Auto-Attachment of Resources to Router
I was wondering if anyone had an answer to this question yet? I created my own init function that is called once my Dao object is set. Unfortunately in trying to perform a getRequest() within that function I get a nullpointer exception thrown. There must be some way to execute a function once the bean is fully set up? On Fri, Jan 23, 2009 at 12:07 PM, Jean-Philippe Steinmetz < caskate...@gmail.com> wrote: > Excellent that works. > > One more quick question. I noticed that I had to remove all the original > constructors for Resources that took parameters. I perform my data look up > in the constructor but since Spring hasn't injected everything yet i'm > getting null pointer exceptions. Is there an init function or some standard > method that gets called after all Spring is finished setting things up? > > Jean-Philippe > > > On Fri, Jan 23, 2009 at 8:27 AM, Rhett Sutphin > wrote: > >> Hi Jean-Philippe, >> >> Your Application bean isn't connected to the router. Since you are >> not using a custom Application, you could just remove the Application >> bean and make the router the root (either by naming it "root" or by >> setting the targetRestletBeanName parameter for >> RestletFrameworkServlet to "router"). RestletFrameworkServlet will >> automatically instantiate a default Application. >> >> If you do want to create your own application instance (e.g., because >> you decide later that you want a custom version), you need to attach >> the router as the root of the Application: >> >> >> >> >> >> Rhett >> >> On Jan 22, 2009, at 5:18 PM, Jean-Philippe Steinmetz wrote: >> >> > Oh I like the idea of that... i've tried setting it up but now i'm >> > getting the following error: >> > >> > Jan 22, 2009 3:16:58 PM org.restlet.Filter doHandle >> > WARNING: A filter was executed without a next Restlet attached to it. >> > >> > Here is my web.xml: >> > >> > Web Service >> > >> > >> > >> > webservices >> > > > class>com.noelios.restlet.ext.spring.RestletFrameworkServlet> > servlet-class> >> > 1 >> > >> > >> > >> > >> > webservices >> > /* >> > >> > >> > >> > And here is my applicationContext >> > >> > http://www.springframework.org/schema/beans"; >> >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> >xmlns:util="http://www.springframework.org/schema/util"; >> >xsi:schemaLocation=" >> > http://www.springframework.org/schema/beans >> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd >> > http://www.springframework.org/schema/util >> http://www.springframework.org/schema/util/spring-util-2.5.xsd >> > "> >> > >> > >> > >> > > > class="org.restlet.ext.spring.SpringBeanRouter"/> >> > >> > >> > > > scope="prototype" >> > class="com.trilogy.engine.webservice.restlets.AssetsResource"> >> > >> > >> > > > scope="prototype" >> > class="com.trilogy.engine.webservice.restlets.AssetResource"> >> > >> > >> > >> > > > scope="prototype" >> > >> > class="com.trilogy.engine.webservice.restlets.BodyPartsResource"> >> > >> > >> > > > autowire="byName" scope="prototype" >> > >> > class="com.trilogy.engine.webservice.restlets.BodyPartsResource"> >> > >> > >> > >> > >> > Any ideas what could be wrong? >> > >> > Jean-Philippe >> > >> > On Wed, Jan 21, 2009 at 11:13 PM, Rhett Sutphin < >> rh...@detailedbalance.net >> > > wrote: >> > Hi Jean-Philippe, >> > >> > On Jan 21, 2009, at 1:07 PM, Jean-Philippe Steinmetz wrote: >> > >> > > Quick question about attaching URI patterns and resource classes to >> > > the router. Is there a way to make this happen more automagically >> > > with annotations or some other mechanism? Adding each one by hand >> > > will get unwieldy and requires touching the main Application class >> > > every time I want to add a new resource. I see there is some work >> > > with this with JAX-RS but I wasn't sure if this was included in >> > > restlet or not. >> > >> > Since you are already using Spring, you might consider using >> > SpringBeanRouter: >> > >> > >> http://www.restlet.org:8080/documentation/1.1/ext/org/restlet/ext/spring/SpringBeanRouter.html >> > >> > It allows you to define URI templates in your application context. It >> > also allows you to do Spring DI on the resource instances. >> > >> > Rhett >> > >> > -- >> > >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1042895 >> > >> >> -- >> >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1045059 >> > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1059974
Re: Accessing URI parameters
Well I was able to answer my own question. It appears reference.getQuery() is the correct way to get this information. I should really read the documentation a bit more thoroughly. Jean-Philippe On Wed, Jan 28, 2009 at 10:47 AM, Jean-Philippe Steinmetz < caskate...@gmail.com> wrote: > Hi All, > > I believe i've briefly discussed this before. I'd like to be able to pass > multiple search query information into my resources. So a typical GET URI > might look like http://localhost/myapp/resource/?field1=thing&field2=else. > > Is there a built-in mechanism in restlet for getting at the field1 and > field2 parameters? or do I have to process the request reference myself? > > Thanks, > Jean-Philippe > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1063978
Accessing URI parameters
Hi All, I believe i've briefly discussed this before. I'd like to be able to pass multiple search query information into my resources. So a typical GET URI might look like http://localhost/myapp/resource/?field1=thing&field2=else. Is there a built-in mechanism in restlet for getting at the field1 and field2 parameters? or do I have to process the request reference myself? Thanks, Jean-Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1063968
Overriding HTTP headers
Hello again, One of my REST clients will be a Flash application. As some or all of you are aware Flash's URLRequest is a bit broken in that it doesn't fully support the HTTP protocol. I have tried using arc90restlib that Jerome suggested at http://lab.arc90.com/2008/03/restservice.php but unfortunately all I get are IOErrors when a request is sent anywhere. It could be that i'm loading in a Flex library into a Flash app but it's a bit hard too difficult to debug at this point. I can only assume there is an issue with the library. Short of writing my own HTTP socket library I was given a tip on using Flash's built-in URLRequest method and utilizing override headers to perform the PUT and DELETE operations. Specifically I am adding the header X-HTTP-Method-Override with the correct action I desire. Now to the point; does RESTlet support these headers? Does anyone else have any suggestions on how to make this Flash client talk? Jean-Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1072663
Re: Overriding HTTP headers
Excellent. The current workaround should work just nicely for now. I would be more than happy to implement the header override feature if no one else is currently working on it. Jean-Philippe On Fri, Jan 30, 2009 at 12:40 AM, Jerome Louvel wrote: > Hi Jean-Philippe, > > In addition to the current workaround described by Karel, we are planning > to support the "X-HTTP-Method-Override" header in Restlet > 1.2: > > "Support method tunneling via header" > http://restlet.tigris.org/issues/show_bug.cgi?id=297 > > 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 : Karel Vervaeke [mailto:ka...@outerthought.org] > Envoye : vendredi 30 janvier 2009 09:02 > A : discuss@restlet.tigris.org > Objet : Re: Overriding HTTP headers > > Just scanning your mail diagonally I think you need to add the method > parameter to your query string (in combination with POST requests): > > http://host/path?method=PUT > http://host/path?method=DELETE > > (You should have the tunnel service enabled) > > HTH, > Karel > > On Fri, Jan 30, 2009 at 8:00 AM, Jean-Philippe Steinmetz > wrote: > > Hello again, > > > > One of my REST clients will be a Flash application. As some or all of you > > are aware Flash's URLRequest is a bit broken in that it doesn't fully > > support the HTTP protocol. I have tried using arc90restlib that Jerome > > suggested at http://lab.arc90.com/2008/03/restservice.php but > unfortunately > > all I get are IOErrors when a request is sent anywhere. It could be that > i'm > > loading in a Flex library into a Flash app but it's a bit hard too > difficult > > to debug at this point. I can only assume there is an issue with the > > library. Short of writing my own HTTP socket library I was given a tip on > > using Flash's built-in URLRequest method and utilizing override headers > to > > perform the PUT and DELETE operations. Specifically I am adding the > header > > X-HTTP-Method-Override with the correct action I desire. Now to the > point; > > does RESTlet support these headers? Does anyone else have any suggestions > on > > how to make this Flash client talk? > > > > Jean-Philippe > > > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1072845 > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1073181 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1073200
Re: Overriding HTTP headers
Ok. I've added the following to my Application's constructor. getTunnelService().setEnabled(true); But when I try and perform the following: POST http://host/resource/1?method=DELETE All it does is retrieve the resource. Am I missing something? On Fri, Jan 30, 2009 at 12:01 AM, Karel Vervaeke wrote: > Just scanning your mail diagonally I think you need to add the method > parameter to your query string (in combination with POST requests): > > http://host/path?method=PUT > http://host/path?method=DELETE > > (You should have the tunnel service enabled) > > HTH, > Karel > > On Fri, Jan 30, 2009 at 8:00 AM, Jean-Philippe Steinmetz > wrote: > > Hello again, > > > > One of my REST clients will be a Flash application. As some or all of you > > are aware Flash's URLRequest is a bit broken in that it doesn't fully > > support the HTTP protocol. I have tried using arc90restlib that Jerome > > suggested at http://lab.arc90.com/2008/03/restservice.php but > unfortunately > > all I get are IOErrors when a request is sent anywhere. It could be that > i'm > > loading in a Flex library into a Flash app but it's a bit hard too > difficult > > to debug at this point. I can only assume there is an issue with the > > library. Short of writing my own HTTP socket library I was given a tip on > > using Flash's built-in URLRequest method and utilizing override headers > to > > perform the PUT and DELETE operations. Specifically I am adding the > header > > X-HTTP-Method-Override with the correct action I desire. Now to the > point; > > does RESTlet support these headers? Does anyone else have any suggestions > on > > how to make this Flash client talk? > > > > Jean-Philippe > > > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1072845 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1077225
Re: Overriding HTTP headers
So I removed the code that initialized a new instance of the TunnelService as apparently it was enabled by default already. I have successfully tested the request POST http://host/app/resource/15?method=UPDATE. However performing a DELETE operation the same way results in a GET. The tomcat logs do not give any stack traces or other output that would indicate something is wrong. I also have logger messages set to display when the removeRepresentation method is called but am seeing nothing in the logs. Lastly, I can confirm DELETE http://host/app/resource/15 works using a restlet java client for testing. This seems quite strange. Jean-Philippe On Sat, Jan 31, 2009 at 4:27 AM, Jerome Louvel wrote: > Hello, > > This should really work... The tunnel service is enabled by default, so the > first line shouldn't even be necessary. What is displayed in the logs? If > the tunnel service works as expected, you should see DELETE as the invoked > method. > > Otherwise, I would suggest to send us a small reproducible sample or to > debug the TunnelFilter code if you are willing to dig into Restlet code :) > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > ------ > *De :* Jean-Philippe Steinmetz [mailto:caskate...@gmail.com] > *Envoyé :* samedi 31 janvier 2009 00:39 > *À :* discuss@restlet.tigris.org > *Objet :* Re: Overriding HTTP headers > > Ok. I've added the following to my Application's constructor. > > getTunnelService().setEnabled(true); > > But when I try and perform the following: > > POST http://host/resource/1?method=DELETE > > All it does is retrieve the resource. > > Am I missing something? > > On Fri, Jan 30, 2009 at 12:01 AM, Karel Vervaeke > wrote: > >> Just scanning your mail diagonally I think you need to add the method >> parameter to your query string (in combination with POST requests): >> >> http://host/path?method=PUT >> http://host/path?method=DELETE >> >> (You should have the tunnel service enabled) >> >> HTH, >> Karel >> >> On Fri, Jan 30, 2009 at 8:00 AM, Jean-Philippe Steinmetz >> wrote: >> > Hello again, >> > >> > One of my REST clients will be a Flash application. As some or all of >> you >> > are aware Flash's URLRequest is a bit broken in that it doesn't fully >> > support the HTTP protocol. I have tried using arc90restlib that Jerome >> > suggested at http://lab.arc90.com/2008/03/restservice.php but >> unfortunately >> > all I get are IOErrors when a request is sent anywhere. It could be that >> i'm >> > loading in a Flex library into a Flash app but it's a bit hard too >> difficult >> > to debug at this point. I can only assume there is an issue with the >> > library. Short of writing my own HTTP socket library I was given a tip >> on >> > using Flash's built-in URLRequest method and utilizing override headers >> to >> > perform the PUT and DELETE operations. Specifically I am adding the >> header >> > X-HTTP-Method-Override with the correct action I desire. Now to the >> point; >> > does RESTlet support these headers? Does anyone else have any >> suggestions on >> > how to make this Flash client talk? >> > >> > Jean-Philippe >> > >> >> -- >> >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1072845 >> > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1092806
Opening transactions per resource
Hello all, It's been a long time since i've last posted. Been pretty happily working with restlet 1.1 for some time now. I've come across an issue/optimization that i'm trying to solve that i'd like to get your thoughts on. We are using Spring's AOP and Transaction Management to handle a lot of our database access. This has greatly simplified our code and we're loving it. Right now we apply the @Transactional annotation for each of the functions in the resource class. Therefore the init function has it, acceptRepresentation has it and so on. The init function will initially pull the resource in one transaction and the subsequent method handlers potentially open a second transaction to further process changes. The issue for us is that we are trying to keep the original select and update calls in the same transaction to ensure transactional integrity. The only way I know of to make this work is to put the @Transactional annotation at a higher level so that the transaction is open for the entire life of the resource handler execution. Unfortunately I have been unable to find a way to do this with restlet. How can I make @Transactional to take affect at a higher level than the resource? Is there a way to override the resource router or is there some already built-in mechanism that I need to enable or set up? Thanks in advance, Jean-Philippe Steinmetz -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2429858
Re: Opening transactions per resource
Good question. We use the init to verify the resource actually exists as well as handling other bits. So the question is is mainly in interest of finding an easier way to get it done that won't cause us to redo a lot of boiler plate code all over the method handlers. On Fri, Dec 11, 2009 at 12:37 PM, Tim Peierls wrote: > Why not move the functionality that you currently have in the init method > into each of the HTTP method handlers (and remove this functionality and the > @Transactional annotation from init)? > > --tim > > > On Fri, Dec 11, 2009 at 2:57 PM, Jean-Philippe Steinmetz < > caskate...@gmail.com> wrote: > >> Hello all, >> >> It's been a long time since i've last posted. Been pretty happily working >> with restlet 1.1 for some time now. I've come across an issue/optimization >> that i'm trying to solve that i'd like to get your thoughts on. >> >> We are using Spring's AOP and Transaction Management to handle a lot of >> our database access. This has greatly simplified our code and we're loving >> it. Right now we apply the @Transactional annotation for each of the >> functions in the resource class. Therefore the init function has it, >> acceptRepresentation has it and so on. The init function will initially pull >> the resource in one transaction and the subsequent method handlers >> potentially open a second transaction to further process changes. >> >> The issue for us is that we are trying to keep the original select and >> update calls in the same transaction to ensure transactional integrity. The >> only way I know of to make this work is to put the @Transactional annotation >> at a higher level so that the transaction is open for the entire life of the >> resource handler execution. Unfortunately I have been unable to find a way >> to do this with restlet. How can I make @Transactional to take affect at a >> higher level than the resource? Is there a way to override the resource >> router or is there some already built-in mechanism that I need to enable or >> set up? >> >> Thanks in advance, >> >> Jean-Philippe Steinmetz >> > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2429873
Re: Opening transactions per resource
Like I said we could do that though it still requires more than one line of code in each function. We currently use init to determine resource available and setting the allowed actions (i.e. allowPost) in the init which as far as I know can only be done there. On Fri, Dec 11, 2009 at 1:52 PM, Tim Peierls wrote: > Wouldn't it be just a matter of calling a single private method at the top > of each of the method handlers? > > --tim > > > On Fri, Dec 11, 2009 at 4:49 PM, Jean-Philippe Steinmetz < > caskate...@gmail.com> wrote: > >> Good question. We use the init to verify the resource actually exists as >> well as handling other bits. So the question is is mainly in interest of >> finding an easier way to get it done that won't cause us to redo a lot of >> boiler plate code all over the method handlers. >> >> >> On Fri, Dec 11, 2009 at 12:37 PM, Tim Peierls wrote: >> >>> Why not move the functionality that you currently have in the init method >>> into each of the HTTP method handlers (and remove this functionality and the >>> @Transactional annotation from init)? >>> >>> --tim >>> >>> >>> On Fri, Dec 11, 2009 at 2:57 PM, Jean-Philippe Steinmetz < >>> caskate...@gmail.com> wrote: >>> >>>> Hello all, >>>> >>>> It's been a long time since i've last posted. Been pretty happily >>>> working with restlet 1.1 for some time now. I've come across an >>>> issue/optimization that i'm trying to solve that i'd like to get your >>>> thoughts on. >>>> >>>> We are using Spring's AOP and Transaction Management to handle a lot of >>>> our database access. This has greatly simplified our code and we're loving >>>> it. Right now we apply the @Transactional annotation for each of the >>>> functions in the resource class. Therefore the init function has it, >>>> acceptRepresentation has it and so on. The init function will initially >>>> pull >>>> the resource in one transaction and the subsequent method handlers >>>> potentially open a second transaction to further process changes. >>>> >>>> The issue for us is that we are trying to keep the original select and >>>> update calls in the same transaction to ensure transactional integrity. The >>>> only way I know of to make this work is to put the @Transactional >>>> annotation >>>> at a higher level so that the transaction is open for the entire life of >>>> the >>>> resource handler execution. Unfortunately I have been unable to find a way >>>> to do this with restlet. How can I make @Transactional to take affect at a >>>> higher level than the resource? Is there a way to override the resource >>>> router or is there some already built-in mechanism that I need to enable or >>>> set up? >>>> >>>> Thanks in advance, >>>> >>>> Jean-Philippe Steinmetz >>>> >>> >>> >> > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2429875
Re: Opening transactions per resource
I'll give that a shot thanks.
On Fri, Dec 11, 2009 at 2:52 PM, Tim Peierls wrote:
> I guess you could try sticking @Transactional on the handle method of the
> Finder that creates the resource. You'd have to subclass Finder:
>
> public class TransactionalFinder extends Finder {
> ...
> @Transactional public void handle(Request req, Response rsp) {
> super(req, rsp); }
> }
>
> I haven't checked to see if this really works, though.
>
> --tim
>
>
> On Fri, Dec 11, 2009 at 5:01 PM, Jean-Philippe Steinmetz <
> caskate...@gmail.com> wrote:
>
>> Like I said we could do that though it still requires more than one line
>> of code in each function. We currently use init to determine resource
>> available and setting the allowed actions (i.e. allowPost) in the init which
>> as far as I know can only be done there.
>>
>>
>> On Fri, Dec 11, 2009 at 1:52 PM, Tim Peierls wrote:
>>
>>> Wouldn't it be just a matter of calling a single private method at the
>>> top of each of the method handlers?
>>>
>>> --tim
>>>
>>>
>>> On Fri, Dec 11, 2009 at 4:49 PM, Jean-Philippe Steinmetz <
>>> caskate...@gmail.com> wrote:
>>>
>>>> Good question. We use the init to verify the resource actually exists as
>>>> well as handling other bits. So the question is is mainly in interest of
>>>> finding an easier way to get it done that won't cause us to redo a lot of
>>>> boiler plate code all over the method handlers.
>>>>
>>>>
>>>> On Fri, Dec 11, 2009 at 12:37 PM, Tim Peierls wrote:
>>>>
>>>>> Why not move the functionality that you currently have in the init
>>>>> method into each of the HTTP method handlers (and remove this
>>>>> functionality
>>>>> and the @Transactional annotation from init)?
>>>>>
>>>>> --tim
>>>>>
>>>>>
>>>>> On Fri, Dec 11, 2009 at 2:57 PM, Jean-Philippe Steinmetz <
>>>>> caskate...@gmail.com> wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> It's been a long time since i've last posted. Been pretty happily
>>>>>> working with restlet 1.1 for some time now. I've come across an
>>>>>> issue/optimization that i'm trying to solve that i'd like to get your
>>>>>> thoughts on.
>>>>>>
>>>>>> We are using Spring's AOP and Transaction Management to handle a lot
>>>>>> of our database access. This has greatly simplified our code and we're
>>>>>> loving it. Right now we apply the @Transactional annotation for each of
>>>>>> the
>>>>>> functions in the resource class. Therefore the init function has it,
>>>>>> acceptRepresentation has it and so on. The init function will initially
>>>>>> pull
>>>>>> the resource in one transaction and the subsequent method handlers
>>>>>> potentially open a second transaction to further process changes.
>>>>>>
>>>>>> The issue for us is that we are trying to keep the original select and
>>>>>> update calls in the same transaction to ensure transactional integrity.
>>>>>> The
>>>>>> only way I know of to make this work is to put the @Transactional
>>>>>> annotation
>>>>>> at a higher level so that the transaction is open for the entire life of
>>>>>> the
>>>>>> resource handler execution. Unfortunately I have been unable to find a
>>>>>> way
>>>>>> to do this with restlet. How can I make @Transactional to take affect at
>>>>>> a
>>>>>> higher level than the resource? Is there a way to override the resource
>>>>>> router or is there some already built-in mechanism that I need to enable
>>>>>> or
>>>>>> set up?
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> Jean-Philippe Steinmetz
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2429885
Re: Opening transactions per resource
That works very nicely. Thanks for the help!
On Fri, Dec 11, 2009 at 2:52 PM, Tim Peierls wrote:
> I guess you could try sticking @Transactional on the handle method of the
> Finder that creates the resource. You'd have to subclass Finder:
>
> public class TransactionalFinder extends Finder {
> ...
> @Transactional public void handle(Request req, Response rsp) {
> super(req, rsp); }
> }
>
> I haven't checked to see if this really works, though.
>
> --tim
>
>
> On Fri, Dec 11, 2009 at 5:01 PM, Jean-Philippe Steinmetz <
> caskate...@gmail.com> wrote:
>
>> Like I said we could do that though it still requires more than one line
>> of code in each function. We currently use init to determine resource
>> available and setting the allowed actions (i.e. allowPost) in the init which
>> as far as I know can only be done there.
>>
>>
>> On Fri, Dec 11, 2009 at 1:52 PM, Tim Peierls wrote:
>>
>>> Wouldn't it be just a matter of calling a single private method at the
>>> top of each of the method handlers?
>>>
>>> --tim
>>>
>>>
>>> On Fri, Dec 11, 2009 at 4:49 PM, Jean-Philippe Steinmetz <
>>> caskate...@gmail.com> wrote:
>>>
>>>> Good question. We use the init to verify the resource actually exists as
>>>> well as handling other bits. So the question is is mainly in interest of
>>>> finding an easier way to get it done that won't cause us to redo a lot of
>>>> boiler plate code all over the method handlers.
>>>>
>>>>
>>>> On Fri, Dec 11, 2009 at 12:37 PM, Tim Peierls wrote:
>>>>
>>>>> Why not move the functionality that you currently have in the init
>>>>> method into each of the HTTP method handlers (and remove this
>>>>> functionality
>>>>> and the @Transactional annotation from init)?
>>>>>
>>>>> --tim
>>>>>
>>>>>
>>>>> On Fri, Dec 11, 2009 at 2:57 PM, Jean-Philippe Steinmetz <
>>>>> caskate...@gmail.com> wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> It's been a long time since i've last posted. Been pretty happily
>>>>>> working with restlet 1.1 for some time now. I've come across an
>>>>>> issue/optimization that i'm trying to solve that i'd like to get your
>>>>>> thoughts on.
>>>>>>
>>>>>> We are using Spring's AOP and Transaction Management to handle a lot
>>>>>> of our database access. This has greatly simplified our code and we're
>>>>>> loving it. Right now we apply the @Transactional annotation for each of
>>>>>> the
>>>>>> functions in the resource class. Therefore the init function has it,
>>>>>> acceptRepresentation has it and so on. The init function will initially
>>>>>> pull
>>>>>> the resource in one transaction and the subsequent method handlers
>>>>>> potentially open a second transaction to further process changes.
>>>>>>
>>>>>> The issue for us is that we are trying to keep the original select and
>>>>>> update calls in the same transaction to ensure transactional integrity.
>>>>>> The
>>>>>> only way I know of to make this work is to put the @Transactional
>>>>>> annotation
>>>>>> at a higher level so that the transaction is open for the entire life of
>>>>>> the
>>>>>> resource handler execution. Unfortunately I have been unable to find a
>>>>>> way
>>>>>> to do this with restlet. How can I make @Transactional to take affect at
>>>>>> a
>>>>>> higher level than the resource? Is there a way to override the resource
>>>>>> router or is there some already built-in mechanism that I need to enable
>>>>>> or
>>>>>> set up?
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> Jean-Philippe Steinmetz
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2429891
Representation for multiple types?
Hello all, We're using restlet 1.1.6 and for all our resources we want to support a dynamic set of media types. We do this in our Spring configuration by setting up a list of acceptable media types. My question is if there is a Representation class I can use that will essentially accept any type of data I push into it? For instance we support HTML, XML, JSON and AMF3 therefore most of the time it's a string based representation but in the case of AMF3 it is binary (byte array). So far the only way I see it is to make a switch statement in our resource class for each media type but this pretty much defeats the purpose of specifying supported media types in the application configuration. Jean-Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441306
Re: Representation for multiple types?
Thank you for the quick reply. This certainly would resolve the issue but it
doesn't really offer the kind of solution I was hoping for. With this
solution i'd still have to do a mapping of media type to some representation
which is what I am trying to avoid. The thought was that there is a
Representation that just outputs the message body regardless of whatever
media type variant is set for it. That way I don't have to make a mapping of
media type to anything.
On Fri, Jan 22, 2010 at 1:27 PM, Matt Kennedy wrote:
> I can't remember what 1.1.6's API looks like, but I do something like this
> with the 2.0 API. Basically, in the Resource's constructor, I use someting
> like:
>
> getVariants().add(new MyXMLRepresentation(this))
> getVariants().add(new MyJSONRepresentation(this))
>
>
> Each of those My* classes are a subclass of Representation, and the write()
> method is overridden to produce the custom media type. I pass the Resource
> object to the custom representation so that I have access to the resource
> during the write method. Also important is that in the constructor, you
> call the super constructor with the MediaType and resource as arguments, ex:
>
> //Constructor
> public MyJSONRepresentation(Resource res)
> {
> super(MediaType.APPLICATION_JSON, res);
> }
>
> I know something like this can be done with the 1.1.6 API because I was
> using it before I ported to 2.0, but now I can't find the 1.1.6 code. It
> probably isn't too different.
>
> On Jan 22, 2010, at 3:50 PM, Jean-Philippe Steinmetz wrote:
>
> > Hello all,
> >
> > We're using restlet 1.1.6 and for all our resources we want to support a
> dynamic set of media types. We do this in our Spring configuration by
> setting up a list of acceptable media types. My question is if there is a
> Representation class I can use that will essentially accept any type of data
> I push into it? For instance we support HTML, XML, JSON and AMF3 therefore
> most of the time it's a string based representation but in the case of AMF3
> it is binary (byte array). So far the only way I see it is to make a switch
> statement in our resource class for each media type but this pretty much
> defeats the purpose of specifying supported media types in the application
> configuration.
> >
> > Jean-Philippe
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441312
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441339
Re: Representation for multiple types?
Sure. With our particular use case we specify a map of media types to data
serializers in spring as a hash map. We then inject this map into each
resource. When the map is set in the class we then add all the media types
specified as map keys as acceptable variants. When the represent() function
is called we use the provided media type to retrieve the associated
serializer, throwing an unsupported media type error if the variant has no
corresponding serializer. We then serialize our data and send it back to the
client. It's the sending it back to the client part is where I am stuck. As
there is no default Representation class that I can merely pass in any
object type to whether it be string, bye array, etc.
Here is an example of the Resource class.
public class MyResource extends Resource
{
public Map map;
public Representation represent(Variant variant) throws
ResourceException
{
Serializer serializer = map.get(variant.getMediaType());
if (serializer == null)
throw new
ResourceException(Status.CLIENT_ERROR_UNSUPPORTED_MEDIA_TYPE);
return new Representation(serializer.encode(data)); // ??
}
}
Here is an example of our spring applicationContext.xml.
...
...
On Fri, Jan 22, 2010 at 3:07 PM, Matt Kennedy wrote:
> I'm not a Spring user, so maybe that's why it isn't clear to me what you're
> asking. Can you try phrasing this question a different way? I think I know
> the answer to your problem because I've always had to deal with multiple
> media types for the same resource, but I'm not sure I understand the
> problem. Can you walk through a use-case?
>
>
> On Jan 22, 2010, at 6:00 PM, Jean-Philippe Steinmetz wrote:
>
> Thank you for the quick reply. This certainly would resolve the issue but
> it doesn't really offer the kind of solution I was hoping for. With this
> solution i'd still have to do a mapping of media type to some representation
> which is what I am trying to avoid. The thought was that there is a
> Representation that just outputs the message body regardless of whatever
> media type variant is set for it. That way I don't have to make a mapping of
> media type to anything.
>
> On Fri, Jan 22, 2010 at 1:27 PM, Matt Kennedy wrote:
>
>> I can't remember what 1.1.6's API looks like, but I do something like this
>> with the 2.0 API. Basically, in the Resource's constructor, I use someting
>> like:
>>
>> getVariants().add(new MyXMLRepresentation(this))
>> getVariants().add(new MyJSONRepresentation(this))
>>
>>
>> Each of those My* classes are a subclass of Representation, and the
>> write() method is overridden to produce the custom media type. I pass the
>> Resource object to the custom representation so that I have access to the
>> resource during the write method. Also important is that in the
>> constructor, you call the super constructor with the MediaType and resource
>> as arguments, ex:
>>
>> //Constructor
>> public MyJSONRepresentation(Resource res)
>> {
>> super(MediaType.APPLICATION_JSON, res);
>> }
>>
>> I know something like this can be done with the 1.1.6 API because I was
>> using it before I ported to 2.0, but now I can't find the 1.1.6 code. It
>> probably isn't too different.
>>
>> On Jan 22, 2010, at 3:50 PM, Jean-Philippe Steinmetz wrote:
>>
>> > Hello all,
>> >
>> > We're using restlet 1.1.6 and for all our resources we want to support a
>> dynamic set of media types. We do this in our Spring configuration by
>> setting up a list of acceptable media types. My question is if there is a
>> Representation class I can use that will essentially accept any type of data
>> I push into it? For instance we support HTML, XML, JSON and AMF3 therefore
>> most of the time it's a string based representation but in the case of AMF3
>> it is binary (byte array). So far the only way I see it is to make a switch
>> statement in our resource class for each media type but this pretty much
>> defeats the purpose of specifying supported media types in the application
>> configuration.
>> >
>> > Jean-Philippe
>>
>> --
>>
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441312
>>
>
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441345
Client Custom Header
Hi, I'm trying to add a custom HTTP header to outgoing requests when using the restlet client API. Ideally i'm looking for some way to implement a helper class that can inject my header into every request as they are processed. However in looking through the documentation i'm not really finding what i'm looking for. I see in the FAQ it's possible to access headers but this seems to be from the server perspective. How do I get access from a client perspective? Thanks in advance, Jean-Philippe Steinmetz -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2599941
Re: Client Custom Header
Hi Stephan,
Thank you for the response. I've implemented a filter and created one while
setting the "next" property to be my client but I am not getting any calls
to the beforeHandle function. My code looks like the following.
class MyFilter extends Filter
{
public MyFilter() { this(null);
public MyFilter(Context context) { this(context, null); }
public MyFilter(Context context, Restlet next) { super(context, next); }
public int beforeHandle(Request request, Response response)
{
System.out.println("HIT!");
return CONTINUE;
}
}
And my Spring configuration looks like this...
What am I missing? Thanks again.
Jean-Philippe
On Sat, May 1, 2010 at 3:49 AM, Stephan Koops wrote:
> Hi Jean,
>
> the access is on both sides the same. That's an advantage of Restlet.
> To add the header for every request you could create a filter. It adds
> the header. Instead of send the request directly by the Client object
> you set the Client as next Restlet in the filter and your application
> sends all request via the filter.
> (I hope that's right ...)
>
> best regards
> Stephan
>
> Jean-Philippe Steinmetz schrieb:
> > Hi,
> >
> > I'm trying to add a custom HTTP header to outgoing requests when using
> > the restlet client API. Ideally i'm looking for some way to implement
> > a helper class that can inject my header into every request as they
> > are processed. However in looking through the documentation i'm not
> > really finding what i'm looking for. I see in the FAQ it's possible to
> > access headers but this seems to be from the server perspective. How
> > do I get access from a client perspective?
> >
> > Thanks in advance,
> >
> > Jean-Philippe Steinmetz
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2600427
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2602229
Re: Client Custom Header
Since no one seems to have responded to this problem I was hoping someone
could shed some light on cookie setting. Similarly to adding my own header
to all outgoing client requests I could instead set a cookie. My one
requirement here is that I don't want to modify every outgoing request
individually. In other words, the following code *won't *work...
request.getCookies().add("myCookie", "value");
Instead I need a solution where I set the cookie for the Client instance
once and it is respected across all future connections and requests. Is this
possible? Or am I really stuck having to add it to every outgoing request?
Also please note it is *not* possible to set the cookie on the server side.
On Mon, May 3, 2010 at 5:24 PM, Jean-Philippe Steinmetz <
caskate...@gmail.com> wrote:
> Hi Stephan,
>
> Thank you for the response. I've implemented a filter and created one while
> setting the "next" property to be my client but I am not getting any calls
> to the beforeHandle function. My code looks like the following.
>
> class MyFilter extends Filter
> {
> public MyFilter() { this(null);
> public MyFilter(Context context) { this(context, null); }
> public MyFilter(Context context, Restlet next) { super(context, next);
> }
>
> public int beforeHandle(Request request, Response response)
> {
> System.out.println("HIT!");
> return CONTINUE;
> }
> }
>
> And my Spring configuration looks like this...
>
>
>
>
>
>
>
>
>
> class="com.noelios.restlet.ext.httpclient.HttpClientHelper">
>
>
>
>
>
>
> What am I missing? Thanks again.
>
> Jean-Philippe
>
>
> On Sat, May 1, 2010 at 3:49 AM, Stephan Koops wrote:
>
>> Hi Jean,
>>
>> the access is on both sides the same. That's an advantage of Restlet.
>> To add the header for every request you could create a filter. It adds
>> the header. Instead of send the request directly by the Client object
>> you set the Client as next Restlet in the filter and your application
>> sends all request via the filter.
>> (I hope that's right ...)
>>
>> best regards
>> Stephan
>>
>> Jean-Philippe Steinmetz schrieb:
>> > Hi,
>> >
>> > I'm trying to add a custom HTTP header to outgoing requests when using
>> > the restlet client API. Ideally i'm looking for some way to implement
>> > a helper class that can inject my header into every request as they
>> > are processed. However in looking through the documentation i'm not
>> > really finding what i'm looking for. I see in the FAQ it's possible to
>> > access headers but this seems to be from the server perspective. How
>> > do I get access from a client perspective?
>> >
>> > Thanks in advance,
>> >
>> > Jean-Philippe Steinmetz
>>
>> --
>>
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2600427
>>
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2603060
Re: Client Custom Header
Hi Jerome,
As I said the server side isn't an option and I need to do this
systematically. The Filter seems like the way to go. You're right that
I was sending through the client instead of the filter. However my
aplication expects a Client object and the Filter does not have the
same API. Do I need to instead extend Client instead of filter?
You may want to reconsider how Filter hooks in. It's inappropriate for
it to change the API. A Filter should really attach to an object, not
wrap it.
Jean-Philippe
On May 5, 2010, at 4:36 AM, Jerome Louvel
wrote:
> Hi Jean-Philippe,
>
>
>
> If your goal is to systematically add cookies to your client
> requests, you should definitely use the Restlet API (Request#cookies
> property) instead of setting a custom header. To set the cookies on
> the server-side, you need instead to use the Response#cookieSettings
> property. For complete mapping between Restlet API and HTTP headers,
> check this page:
>
> http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/324-restlet/130-restlet.html
>
>
>
> The Client class is a stateless connector that is not appropriate
> for cookie management. It was designed to be shared by several
> threads/applications. Even though it is possible to instantiate
> several of them in the same JVM, it is recommended to share them (of
> course based on the protocol they support, HTTP(S) in your case).
>
>
>
> I would instead suggest using a CookieFilter in front of the Client
> to systematically add the cookies (maybe based on the target URI…).
> I don’t see why this wouldn’t work as you say in your previous
> email. Note that your “clientHelper” bean doesn’t seem used nor
> useful.
>
>
>
> Are you sure that you send outgoing requests to the “myFilter”
> bean and not just to the “client” one? In order for filtering to
> happen, you need to explicitly call it. It will then forward the cal
> l to the ‘next’ Restlet attached, the “client” one in your cas
> e.
>
>
>
> Also, note that we have a RFE to provide a cookie manager filter,
> able to store cookie settings and to send them again based on target
> URI and other criteria:
>
> http://restlet.tigris.org/issues/show_bug.cgi?id=42
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
> Noelios Technologies ~ http://www.noelios.com
>
>
>
>
>
>
>
>
>
>
>
> De : Jean-Philippe Steinmetz [mailto:caskate...@gmail.com]
> Envoyé : mercredi 5 mai 2010 04:38
> À : discuss@restlet.tigris.org
> Objet : Re: Client Custom Header
>
>
>
> Since no one seems to have responded to this problem I was hoping
> someone could shed some light on cookie setting. Similarly to adding
> my own header to all outgoing client requests I could instead set a
> cookie. My one requirement here is that I don't want to modify every
> outgoing request individually. In other words, the following code
> won't work...
>
> request.getCookies().add("myCookie", "value");
>
> Instead I need a solution where I set the cookie for the Client
> instance once and it is respected across all future connections and
> requests. Is this possible? Or am I really stuck having to add it to
> every outgoing request? Also please note it is not possible to set
> the cookie on the server side.
>
> On Mon, May 3, 2010 at 5:24 PM, Jean-Philippe Steinmetz > wrote:
>
> Hi Stephan,
>
> Thank you for the response. I've implemented a filter and created
> one while setting the "next" property to be my client but I am not
> getting any calls to the beforeHandle function. My code looks like
> the following.
>
> class MyFilter extends Filter
> {
> public MyFilter() { this(null);
> public MyFilter(Context context) { this(context, null); }
> public MyFilter(Context context, Restlet next) { super(context,
> next); }
>
> public int beforeHandle(Request request, Response response)
> {
> System.out.println("HIT!");
> return CONTINUE;
> }
> }
>
> And my Spring configuration looks like this...
>
>
>
>
>
>
>
>
>
> class="com.noelios.restlet.ext.httpclient.HttpClientHelper">
>
>
>
>
>
>
> What am I missing? Thanks again.
>
> Jean-Philippe
>
>
>
> On Sat, May 1, 2010 at 3:49 AM, Stephan Koops
> wrote:
>
> Hi Jean,
>
> the access is on both sides the same. That's an advantage of Restlet.
> To add the header for every request you could create a filter. It
Retrying requests
Hello everyone,
I have a restlet resource that sometimes produces an exception during
processing. Since the exception is the fault of the server and not the fault
of the client I would like to retry the request. When an exception occurs I
get rolled back all the way to the Finder. In the Finder's handle function
i'd like to attempt to retry processing of the request when I see these
exceptions. Here's an example of the Finder I would like to implement.
@Override
public void handle(Request request, Response response)
{
int count = 0;
while (count < MAX_RETRIES)
{
try
{
super.handle(request, response);
break;
} catch (MyException e) {
count++;
}
}
}
The behavior i'm seeing, however, is that once the exception is caught the
response is immediately sent back to the client and retry processing ceases.
If this is expected behavior how would I go about making this happen?
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2603790
Re: Retrying requests
I just tested that scenario out and it works. Unfortunately though the way
it's all coded up so far requires a lot more code refactoring to edit each
resource than it would be to handle it in the Finder itself. Albeit it would
probably be more "correct." Just trying to save myself some time =)
On Wed, May 5, 2010 at 5:56 PM, Matt Kennedy wrote:
> I usually do this sort of thing in the ServerResource itself. Just wrap
> the problematic lines in the code you just provided only replace the call to
> super.handle with whatever calls throw the exception. Are you doing
> something in particular that makes this a bad strategy?
>
> -Matt
>
>
>
> On May 5, 2010, at 8:45 PM, Jean-Philippe Steinmetz wrote:
>
> Hello everyone,
>
> I have a restlet resource that sometimes produces an exception during
> processing. Since the exception is the fault of the server and not the fault
> of the client I would like to retry the request. When an exception occurs I
> get rolled back all the way to the Finder. In the Finder's handle function
> i'd like to attempt to retry processing of the request when I see these
> exceptions. Here's an example of the Finder I would like to implement.
>
> @Override
> public void handle(Request request, Response response)
> {
> int count = 0;
> while (count < MAX_RETRIES)
> {
> try
> {
> super.handle(request, response);
> break;
> } catch (MyException e) {
> count++;
> }
> }
> }
>
> The behavior i'm seeing, however, is that once the exception is caught the
> response is immediately sent back to the client and retry processing ceases.
> If this is expected behavior how would I go about making this happen?
>
> Jean-Philippe
>
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2603799
Re: Retrying requests
I'll look into that thanks.
On Wed, May 5, 2010 at 6:39 PM, Matt Kennedy wrote:
> You can probably save yourself a lot of work by inserting an extra level of
> inheritance. It is a pain to throw in try-catch blocks all over the place,
> but if you think about it you might be able to put your try loop in a new
> superclass to your resources and get the same functionality. It is usually
> fairly easy to change around your inheritance hierarchy and change some
> method names, especially if you have a nice refactoring helper like Eclipse.
>
>
> -Matt
>
>
>
> On May 5, 2010, at 9:06 PM, Jean-Philippe Steinmetz wrote:
>
> I just tested that scenario out and it works. Unfortunately though the way
> it's all coded up so far requires a lot more code refactoring to edit each
> resource than it would be to handle it in the Finder itself. Albeit it would
> probably be more "correct." Just trying to save myself some time =)
>
> On Wed, May 5, 2010 at 5:56 PM, Matt Kennedy wrote:
>
>> I usually do this sort of thing in the ServerResource itself. Just wrap
>> the problematic lines in the code you just provided only replace the call to
>> super.handle with whatever calls throw the exception. Are you doing
>> something in particular that makes this a bad strategy?
>>
>> -Matt
>>
>>
>>
>> On May 5, 2010, at 8:45 PM, Jean-Philippe Steinmetz wrote:
>>
>> Hello everyone,
>>
>> I have a restlet resource that sometimes produces an exception during
>> processing. Since the exception is the fault of the server and not the fault
>> of the client I would like to retry the request. When an exception occurs I
>> get rolled back all the way to the Finder. In the Finder's handle function
>> i'd like to attempt to retry processing of the request when I see these
>> exceptions. Here's an example of the Finder I would like to implement.
>>
>> @Override
>> public void handle(Request request, Response response)
>> {
>> int count = 0;
>> while (count < MAX_RETRIES)
>> {
>> try
>> {
>> super.handle(request, response);
>> break;
>> } catch (MyException e) {
>> count++;
>> }
>> }
>> }
>>
>> The behavior i'm seeing, however, is that once the exception is caught the
>> response is immediately sent back to the client and retry processing ceases.
>> If this is expected behavior how would I go about making this happen?
>>
>> Jean-Philippe
>>
>>
>>
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2603829
Amazon S3 Auth
Hi, I'm using Amazon S3 authentication in my web application. I'm looking to moving to restlet 2.0 from 1.1 and was wondering if there is finally a server side implementation of the authentication protocol? Jean-Philippe Steinmetz -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2605196
Re: Amazon S3 Auth
During our conversion to Restlet 2.0 i've gone ahead and implemented a SecretVerifier to be used for server side AWS authentication. I've abstracted out the common functionality into a utility class so that both the current HttpAwsS3Helper and my verifier can ensure consistency. The utility class is lifted from a submission I made to Apache's HTTPClient project (https://issues.apache.org/jira/browse/HTTPCLIENT-926) not so long ago but with changes made to conform to restlet's API. I took it over the existing functionality in restlet as it is a more complete implementation of Amazon's spec. Now that I have all the pieces i'm ready to plug it in for testing and ultimately submission to the project. I've been digging around a lot but am so far unable the location where the correct verifier is selected/instantiated for a given ChallengeScheme. Can you point me in the right direction? Ultimately it would be great if it "just worked." Any help on plugging this is would be greatly appreciated. On Sun, May 9, 2010 at 2:39 AM, Thierry Boileau wrote: > Hello Jean-Philippe, > > unfortunately the server side has been implemented for the moment. > > Best regards, > Thierry Boileau > > > Hi, > > I'm using Amazon S3 authentication in my web application. I'm looking to > moving to restlet 2.0 from 1.1 and was wondering if there is finally a > server side implementation of the authentication protocol? > > Jean-Philippe Steinmetz > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2608799
Re: Amazon S3 Auth
I'm pretty sure I understand and have it set up correctly but I am clearly
missing something.
Here's what I have.
I've implemented the HttpAwsS3Verifier which wraps a LocalVerifier similar
to the DigestVerifier. My understanding was that this is how I can hook in
the actual identifier/password list and your response appears to confirm
that. Now in my application I have everything hooked up via Spring. Here is
what my beans look like...
When my application is running and a request is sent I get the following
message...
*Challenge scheme HTTP_AWS not supported by the Restlet engine.*
I also get an authentication required required error sent back to the
client. I'm looking at the source for
org.restlet.ext.crypto.DigestAuthenticator but I do not see anything inside
that seems to set what ChallengeScheme is supported by it. I'm also
generally unclear where the mapping of ChallengeScheme to
Authenticator/Verifier occurs.
On Fri, May 14, 2010 at 6:58 AM, Thierry Boileau <
thierry.boil...@noelios.com> wrote:
> Hello Jean-Phillipe,
>
> that's a great news!
>
>
> > Now that I have all the pieces i'm ready to plug it in for testing and
> ultimately submission to the project.
> > I've been digging around a lot but am so far unable the location where
> the correct verifier is selected/instantiated for a given ChallengeScheme.
>
> Basically, a verifier is attached to an authenticator by the developer.
>
> If you have a look at the "crypto" extension, you will see a
> DigestAuthenticator that aims to handle Digest-based authentication,
> especially HTTP_DIGEST. This authenticator is aimed to be used as follow
> (see [1]):
>
> ***
>
> DigestAuthenticator guard = new DigestAuthenticator(null, "TestRealm",
> "mySecretServerKey");
>
> // Instantiates a Verifier of identifier/secret couples based on a simple
> Map.
> MapVerifier mapVerifier = new MapVerifier();
> // Load a single static login/secret pair.
> mapVerifier.getLocalSecrets().put("login", "secret".toCharArray());
> guard.setWrappedVerifier(mapVerifier);
>
> ***
>
> As you can see, a verifier is provided manually, and this verifier seems
> totally agnostic of the challenge scheme. That's true. You may have also
> noticed that this verifier is attached to the authenticator as a "wrapped"
> verifier.
> Actually, the DigestAuthenticator has its own verifier (see the
> constructor) which is an instance of DigestVerifier that wraps the user's
> one. This verifier supports a given ChallengeScheme which is HTTP_Digest.
> Here is an answer to your question.
> Another question is "why using a DigestVerifier that wraps a simple
> LocalVerifier?". The reason is that we try to support the case where the
> user's verifier leverages credentials that are already encrypted...
>
> I hope this get the things clearer, but I'm not really sure. Please let us
> know!
>
> Best regards,
> Thierry Boileau
>
> [1] http://wiki.restlet.org/docs_2.0/13-restlet/112-restlet.html
>
>
> Can you point me in the right direction? Ultimately it would be great if
> it "just worked." Any help on plugging this is would be greatly appreciated.
>
> On Sun, May 9, 2010 at 2:39 AM, Thierry Boileau <
> thierry.boil...@noelios.com> wrote:
>
>> Hello Jean-Philippe,
>>
>> unfortunately the server side has been implemented for the moment.
>>
>> Best regards,
>> Thierry Boileau
>>
>>
>> Hi,
>>
>> I'm using Amazon S3 authentication in my web application. I'm looking to
>> moving to restlet 2.0 from 1.1 and was wondering if there is finally a
>> server side implementation of the authentication protocol?
>>
>> Jean-Philippe Steinmetz
>>
>>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609206
Re: Amazon S3 Auth
Nevermind... I see my mistake now...
public DigestAuthenticator(Context context, boolean optional, String realm,
List domainRefs, String serverKey) {
super(context, optional, ChallengeScheme.HTTP_DIGEST, realm);
Time to implement the HttpAwsS3Authenticator =)
On Fri, May 14, 2010 at 11:54 AM, Jean-Philippe Steinmetz <
caskate...@gmail.com> wrote:
> I'm pretty sure I understand and have it set up correctly but I am clearly
> missing something.
>
> Here's what I have.
>
> I've implemented the HttpAwsS3Verifier which wraps a LocalVerifier similar
> to the DigestVerifier. My understanding was that this is how I can hook in
> the actual identifier/password list and your response appears to confirm
> that. Now in my application I have everything hooked up via Spring. Here is
> what my beans look like...
>
>
>
>
>
>
>
>
> static-field="org.restlet.data.ChallengeScheme.HTTP_AWS_S3"/>
>
>
>
> class="org.restlet.ext.crypto.internal.HttpAwsS3Verifier">
>
> class="com.company.restlet.security.MyLocalVerifier"/>
>
>
>
>
>
>
>
>
> When my application is running and a request is sent I get the following
> message...
>
> *Challenge scheme HTTP_AWS not supported by the Restlet engine.*
>
> I also get an authentication required required error sent back to the
> client. I'm looking at the source for
> org.restlet.ext.crypto.DigestAuthenticator but I do not see anything inside
> that seems to set what ChallengeScheme is supported by it. I'm also
> generally unclear where the mapping of ChallengeScheme to
> Authenticator/Verifier occurs.
>
>
> On Fri, May 14, 2010 at 6:58 AM, Thierry Boileau <
> thierry.boil...@noelios.com> wrote:
>
>> Hello Jean-Phillipe,
>>
>> that's a great news!
>>
>>
>> > Now that I have all the pieces i'm ready to plug it in for testing and
>> ultimately submission to the project.
>> > I've been digging around a lot but am so far unable the location where
>> the correct verifier is selected/instantiated for a given ChallengeScheme.
>>
>> Basically, a verifier is attached to an authenticator by the developer.
>>
>> If you have a look at the "crypto" extension, you will see a
>> DigestAuthenticator that aims to handle Digest-based authentication,
>> especially HTTP_DIGEST. This authenticator is aimed to be used as follow
>> (see [1]):
>>
>> ***
>>
>> DigestAuthenticator guard = new DigestAuthenticator(null, "TestRealm",
>> "mySecretServerKey");
>>
>> // Instantiates a Verifier of identifier/secret couples based on a simple
>> Map.
>> MapVerifier mapVerifier = new MapVerifier();
>> // Load a single static login/secret pair.
>> mapVerifier.getLocalSecrets().put("login", "secret".toCharArray());
>> guard.setWrappedVerifier(mapVerifier);
>>
>> ***
>>
>> As you can see, a verifier is provided manually, and this verifier seems
>> totally agnostic of the challenge scheme. That's true. You may have also
>> noticed that this verifier is attached to the authenticator as a "wrapped"
>> verifier.
>> Actually, the DigestAuthenticator has its own verifier (see the
>> constructor) which is an instance of DigestVerifier that wraps the user's
>> one. This verifier supports a given ChallengeScheme which is HTTP_Digest.
>> Here is an answer to your question.
>> Another question is "why using a DigestVerifier that wraps a simple
>> LocalVerifier?". The reason is that we try to support the case where the
>> user's verifier leverages credentials that are already encrypted...
>>
>> I hope this get the things clearer, but I'm not really sure. Please let us
>> know!
>>
>> Best regards,
>> Thierry Boileau
>>
>> [1] http://wiki.restlet.org/docs_2.0/13-restlet/112-restlet.html
>>
>>
>> Can you point me in the right direction? Ultimately it would be great if
>> it "just worked." Any help on plugging this is would be greatly appreciated.
>>
>> On Sun, May 9, 2010 at 2:39 AM, Thierry Boileau <
>> thierry.boil...@noelios.com> wrote:
>>
>>> Hello Jean-Philippe,
>>>
>>> unfortunately the server side has been implemented for the moment.
>>>
>>> Best regards,
>>> Thierry Boileau
>>>
>>>
>>> Hi,
>>>
>>> I'm using Amazon S3 authentication in my web application. I'm looking to
>>> moving to restlet 2.0 from 1.1 and was wondering if there is finally a
>>> server side implementation of the authentication protocol?
>>>
>>> Jean-Philippe Steinmetz
>>>
>>>
>>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609207
Re: Amazon S3 Auth
Ok i've created the authenticator and pass in ChallengeScheme.HTTP_AWS_S3 to
super in the constructor but i'm still getting this message from restlet
whenever I make a call...
*Challenge scheme HTTP_AWS not support by the Restlet engine.*
On Fri, May 14, 2010 at 12:04 PM, Jean-Philippe Steinmetz <
caskate...@gmail.com> wrote:
> Nevermind... I see my mistake now...
>
> public DigestAuthenticator(Context context, boolean optional, String realm,
> List domainRefs, String serverKey) {
>
>
> super(context, optional, ChallengeScheme.HTTP_DIGEST, realm);
>
> Time to implement the HttpAwsS3Authenticator =)
>
>
> On Fri, May 14, 2010 at 11:54 AM, Jean-Philippe Steinmetz <
> caskate...@gmail.com> wrote:
>
>> I'm pretty sure I understand and have it set up correctly but I am clearly
>> missing something.
>>
>> Here's what I have.
>>
>> I've implemented the HttpAwsS3Verifier which wraps a LocalVerifier similar
>> to the DigestVerifier. My understanding was that this is how I can hook in
>> the actual identifier/password list and your response appears to confirm
>> that. Now in my application I have everything hooked up via Spring. Here is
>> what my beans look like...
>>
>>
>>
>>
>>
>>
>>
>>
>> > static-field="org.restlet.data.ChallengeScheme.HTTP_AWS_S3"/>
>>
>>
>>
>> > class="org.restlet.ext.crypto.internal.HttpAwsS3Verifier">
>>
>> > class="com.company.restlet.security.MyLocalVerifier"/>
>>
>>
>>
>>
>>
>>
>>
>>
>> When my application is running and a request is sent I get the following
>> message...
>>
>> *Challenge scheme HTTP_AWS not supported by the Restlet engine.*
>>
>> I also get an authentication required required error sent back to the
>> client. I'm looking at the source for
>> org.restlet.ext.crypto.DigestAuthenticator but I do not see anything inside
>> that seems to set what ChallengeScheme is supported by it. I'm also
>> generally unclear where the mapping of ChallengeScheme to
>> Authenticator/Verifier occurs.
>>
>>
>> On Fri, May 14, 2010 at 6:58 AM, Thierry Boileau <
>> thierry.boil...@noelios.com> wrote:
>>
>>> Hello Jean-Phillipe,
>>>
>>> that's a great news!
>>>
>>>
>>> > Now that I have all the pieces i'm ready to plug it in for testing and
>>> ultimately submission to the project.
>>> > I've been digging around a lot but am so far unable the location where
>>> the correct verifier is selected/instantiated for a given ChallengeScheme.
>>>
>>> Basically, a verifier is attached to an authenticator by the developer.
>>>
>>> If you have a look at the "crypto" extension, you will see a
>>> DigestAuthenticator that aims to handle Digest-based authentication,
>>> especially HTTP_DIGEST. This authenticator is aimed to be used as follow
>>> (see [1]):
>>>
>>> ***
>>>
>>> DigestAuthenticator guard = new DigestAuthenticator(null, "TestRealm",
>>> "mySecretServerKey");
>>>
>>> // Instantiates a Verifier of identifier/secret couples based on a simple
>>> Map.
>>> MapVerifier mapVerifier = new MapVerifier();
>>> // Load a single static login/secret pair.
>>> mapVerifier.getLocalSecrets().put("login", "secret".toCharArray());
>>> guard.setWrappedVerifier(mapVerifier);
>>>
>>> ***
>>>
>>> As you can see, a verifier is provided manually, and this verifier seems
>>> totally agnostic of the challenge scheme. That's true. You may have also
>>> noticed that this verifier is attached to the authenticator as a "wrapped"
>>> verifier.
>>> Actually, the DigestAuthenticator has its own verifier (see the
>>> constructor) which is an instance of DigestVerifier that wraps the user's
>>> one. This verifier supports a given ChallengeScheme which is HTTP_Digest.
>>> Here is an answer to your question.
>>> Another question is "why using a DigestVerifier that wraps a simple
>>> L
Re: Amazon S3 Auth
Alright I was able to fix that problem. I overwrote the HttpAmsS3Helper
class so that the serverSide property is set to true. That allowed my
Verifier implementation to finally get executed. Unfortunately though i'm
seeing some behavior which feels like a bug in restlet. I've configured the
Authenticator so that authentication is optional. The behavior i'm seeing is
that if a request has missing credentials or returns invalid I get an
authentication required response. What is more strange is that if I change
the optional boolean I get the exact same results. No matter what it appears
a user must have proper credentials to be passed though. This doesn't seem
right. If authentication is optional and there is any sort of failure I
would expect the request to still be fulfilled. Is this not a correct
expectation?
On Fri, May 14, 2010 at 12:53 PM, Jean-Philippe Steinmetz <
caskate...@gmail.com> wrote:
> Ok i've created the authenticator and pass in ChallengeScheme.HTTP_AWS_S3
> to super in the constructor but i'm still getting this message from restlet
> whenever I make a call...
>
> *Challenge scheme HTTP_AWS not support by the Restlet engine.*
>
>
> On Fri, May 14, 2010 at 12:04 PM, Jean-Philippe Steinmetz <
> caskate...@gmail.com> wrote:
>
>> Nevermind... I see my mistake now...
>>
>> public DigestAuthenticator(Context context, boolean optional, String realm,
>> List domainRefs, String serverKey) {
>>
>>
>>
>> super(context, optional, ChallengeScheme.HTTP_DIGEST, realm);
>>
>> Time to implement the HttpAwsS3Authenticator =)
>>
>>
>> On Fri, May 14, 2010 at 11:54 AM, Jean-Philippe Steinmetz <
>> caskate...@gmail.com> wrote:
>>
>>> I'm pretty sure I understand and have it set up correctly but I am
>>> clearly missing something.
>>>
>>> Here's what I have.
>>>
>>> I've implemented the HttpAwsS3Verifier which wraps a LocalVerifier
>>> similar to the DigestVerifier. My understanding was that this is how I can
>>> hook in the actual identifier/password list and your response appears to
>>> confirm that. Now in my application I have everything hooked up via Spring.
>>> Here is what my beans look like...
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> >> static-field="org.restlet.data.ChallengeScheme.HTTP_AWS_S3"/>
>>>
>>>
>>>
>>> >> class="org.restlet.ext.crypto.internal.HttpAwsS3Verifier">
>>>
>>> >> class="com.company.restlet.security.MyLocalVerifier"/>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> When my application is running and a request is sent I get the following
>>> message...
>>>
>>> *Challenge scheme HTTP_AWS not supported by the Restlet engine.*
>>>
>>> I also get an authentication required required error sent back to the
>>> client. I'm looking at the source for
>>> org.restlet.ext.crypto.DigestAuthenticator but I do not see anything inside
>>> that seems to set what ChallengeScheme is supported by it. I'm also
>>> generally unclear where the mapping of ChallengeScheme to
>>> Authenticator/Verifier occurs.
>>>
>>>
>>> On Fri, May 14, 2010 at 6:58 AM, Thierry Boileau <
>>> thierry.boil...@noelios.com> wrote:
>>>
>>>> Hello Jean-Phillipe,
>>>>
>>>> that's a great news!
>>>>
>>>>
>>>> > Now that I have all the pieces i'm ready to plug it in for testing and
>>>> ultimately submission to the project.
>>>> > I've been digging around a lot but am so far unable the location where
>>>> the correct verifier is selected/instantiated for a given ChallengeScheme.
>>>>
>>>> Basically, a verifier is attached to an authenticator by the developer.
>>>>
>>>> If you have a look at the "crypto" extension, you will see a
>>>> DigestAuthenticator that aims to handle Digest-based authentication,
>>>> especially HTTP_DIGEST. This authenticator is aimed to be used as follow
>>>> (s
Content Negotiation
Hi, I've implemented a ServerResource class where I override both the *get() *and *get(Variant variant) *methods. I consider the *get(Variant variant) *method to be the primary responder for incoming requests as all content types should be negotiated and I use the basic *get() *as a fallback to call *get(Variant variant) *with a hard coded variant. Unfortunately i'm never getting a call to *get(Variant variant)* unless it is going through the basic *get()*. When I run the debugger I can see that the request has the isNegotiated flag set correctly. Therefore I never get the content type I ask for. I only get the default. I see the Accept header properly in the request attributes as well as all the supported variant types for the resource. How is this possible? Jean-Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2610062
Re: Content Negotiation
This turns out to be my fault. I am overriding the doHandle(Variant variant) function and accidentally was calling super.doHandle() instead of super.doHandle(variant). On Mon, May 17, 2010 at 12:35 PM, Jean-Philippe Steinmetz < caskate...@gmail.com> wrote: > Hi, > > I've implemented a ServerResource class where I override both the *get() *and > *get(Variant variant) *methods. I consider the *get(Variant variant) *method > to be the primary responder for incoming requests as all content types > should be negotiated and I use the basic *get() *as a fallback to call > *get(Variant > variant) *with a hard coded variant. > > Unfortunately i'm never getting a call to *get(Variant variant)* unless it > is going through the basic *get()*. When I run the debugger I can see that > the request has the isNegotiated flag set correctly. Therefore I never get > the content type I ask for. I only get the default. I see the Accept header > properly in the request attributes as well as all the supported variant > types for the resource. How is this possible? > > Jean-Philippe > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2610106
Verifying Content-MD5
Hello, I have a simple question. Does the restlet server connector verify Content-MD5 headers by default? If not, is there a setting or filter I can enable to make sure that it does? Jean-Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2610939
