RE: ZipException with Restet 2.1 RC6
Hi Tal, I've added the ability to override the accept-encoding header. It is based on the tunnel service (turn the userAgentTunnel proprty to true). By default, it will replace the accept-encoding header value for msie, only if its curent value is deflate, have a look at the modules/org.restlet/src/org/restlet/service/accept-encoding.properties. I think you will understand it quickly. If not, please tell me. By the way, you can also tell me what could the default value for the msie browser. Cheers. Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068557
Re: GWT with Restlet JSE examples
Hello Guillaume, I've seen the missing file, I try to recover it ( https://github.com/restlet/restlet-framework-java/issues/796). Just a few words about GWT. There are two modes. The first is the development mode, then the runtime mode. In runtime mode, you get simple static files (html bootstraps files, and gwt javascript code, images, css, etc) generated by GWT compilation, and a REST api based on the Restlet framework. Statics files and API can both be handled by the JSE edition of Restlet (or a servlet container). In development mode, you have a GWT project that aims at developing the client application, using the GWT edition of Restlet. This edition is a port of the client API of Restlet for GWT (of course, there is no server available in the browser). The GWT edition is composed of the port of the core module which is sufficient, and facultative extensions (for json, and xml handling). On the server side, there is a restlet-based application, using either the jse or jee, or gae edition. The jse, jee, gae editions are shipped with a GWT extension: this extension gives the ability to Restlet-based APIs to communicate with a GWT-based client, using the GWT serialization/deserialization format. By doing so, your API can communicate with a GWT client application, or any other kind of client, at the time with the same resources. Best regards, Thierry Boileau 2013/11/14 Guillaume Pelletier tig...@perlhive.com Hi everyone, I've been investigating the restlet framework for several service based projects which I may inherit and I've been looking for examples of deployment outside of any Servlet Container. I ended up here: http://restlet.org/learn/guide/2.1/editions/gwt/examplesbut the download link leads to nothing. I'm wondering if it's doable. I currently have a little Guice + Restlet integration which works well enough. Everything is built through Guice modules and I start restlet with a Component class in a runner using the jetty connector. (attached) If I wanted to do similar for a GWT deployment of a setup application (as proof of concept), could I use the same approach or would I need to modify how everything is bootstrapped? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068495 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068561
bug with SpringFinder?
Hi, I believe I may have found a bug with the way SpringFinder works in Restlet 2.1.4. I have two Application subclasses, each with one Router. Call them app1 and app2, mapped in my servlet-based web app to /app1 and /app2. Both apps define a template /metadata mapped to their own private Resource subclasses (Metadata1Resource and Metadata2Resource). app2 happens to be initialized after app1. I find that invoking /app_1_/metadata instantiates a Metadata_2_Resource. Looking into how this happens, I believe the problem is that SpringFinder is a singleton, and therefore gets attached to both Routers in order of initialization. Since app2 was initialized later, it wins, and the /metadata is looked up relative to that Router. The bit of Spring context for app1 looks like this: bean id=router1 class=org.restlet.ext.spring.SpringRouter property name=attachments map entry key=/metadata !-- GET -- bean class=org.restlet.ext.spring.SpringFinder lookup-method name=create bean=metadataResource / /bean /entry ... /bean bean id=metadataResource class=...Metadata1Resource scope=prototype / and similarly for app2. Both apps are loaded into the same Spring context. If I'm understanding things correctly, this is a fundamental issue in using SpringFinder with multiple Routers. Can anyone give me workaround? I absolutely need my Resource instances to be created by Spring so they get autowired. Thanks, Sean -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068568
Re: bug with SpringFinder?
Hi Sean, thanks for submitting this question: I've entered an issue for that point: https://github.com/restlet/restlet-framework-java/issues/797 best regards, Thierry Boileau 2013/11/15 Sean Hogan s...@clixtec.ca Hi, I believe I may have found a bug with the way SpringFinder works in Restlet 2.1.4. I have two Application subclasses, each with one Router. Call them app1 and app2, mapped in my servlet-based web app to /app1 and /app2. Both apps define a template /metadata mapped to their own private Resource subclasses (Metadata1Resource and Metadata2Resource). app2 happens to be initialized after app1. I find that invoking /app*1*/metadata instantiates a Metadata*2*Resource. Looking into how this happens, I believe the problem is that SpringFinder is a singleton, and therefore gets attached to both Routers in order of initialization. Since app2 was initialized later, it wins, and the /metadata is looked up relative to that Router. The bit of Spring context for app1 looks like this: bean id=router1 class=org.restlet.ext.spring.SpringRouter property name=attachments map entry key=/metadata!-- GET -- bean class=org.restlet.ext.spring.SpringFinder lookup-method name=create bean=metadataResource / /bean /entry ... /bean bean id=metadataResource class=...Metadata1Resource scope=prototype / and similarly for app2. Both apps are loaded into the same Spring context. If I'm understanding things correctly, this is a fundamental issue in using SpringFinder with multiple Routers. Can anyone give me workaround? I absolutely need my Resource instances to be created by Spring so they get autowired. Thanks, Sean -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068569
Re: bug with SpringFinder?
Never mind. Like an idiot I had two beans named metadataResource. I thought Spring would whine about that, but apparently not. :-( (There may still be an issue with SpringFinder, but not from my flawed analysis.) Thanks, Sean On 13-11-15 01:31 PM, Sean Hogan wrote: Hi, I believe I may have found a bug with the way SpringFinder works in Restlet 2.1.4. I have two Application subclasses, each with one Router. Call them app1 and app2, mapped in my servlet-based web app to /app1 and /app2. Both apps define a template /metadata mapped to their own private Resource subclasses (Metadata1Resource and Metadata2Resource). app2 happens to be initialized after app1. I find that invoking /app_1_/metadata instantiates a Metadata_2_Resource. Looking into how this happens, I believe the problem is that SpringFinder is a singleton, and therefore gets attached to both Routers in order of initialization. Since app2 was initialized later, it wins, and the /metadata is looked up relative to that Router. The bit of Spring context for app1 looks like this: bean id=router1 class=org.restlet.ext.spring.SpringRouter property name=attachments map entry key=/metadata !-- GET -- bean class=org.restlet.ext.spring.SpringFinder lookup-method name=create bean=metadataResource / /bean /entry ... /bean bean id=metadataResource class=...Metadata1Resource scope=prototype / and similarly for app2. Both apps are loaded into the same Spring context. If I'm understanding things correctly, this is a fundamental issue in using SpringFinder with multiple Routers. Can anyone give me workaround? I absolutely need my Resource instances to be created by Spring so they get autowired. Thanks, Sean -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068571
Re: bug with SpringFinder?
ok, thanks Sean. I close the issue. Best regards, Thierry Boileau 2013/11/15 Sean Hogan s...@clixtec.ca Never mind. Like an idiot I had two beans named metadataResource. I thought Spring would whine about that, but apparently not. :-( (There may still be an issue with SpringFinder, but not from my flawed analysis.) Thanks, Sean On 13-11-15 01:31 PM, Sean Hogan wrote: Hi, I believe I may have found a bug with the way SpringFinder works in Restlet 2.1.4. I have two Application subclasses, each with one Router. Call them app1 and app2, mapped in my servlet-based web app to /app1 and /app2. Both apps define a template /metadata mapped to their own private Resource subclasses (Metadata1Resource and Metadata2Resource). app2 happens to be initialized after app1. I find that invoking /app*1*/metadata instantiates a Metadata*2*Resource. Looking into how this happens, I believe the problem is that SpringFinder is a singleton, and therefore gets attached to both Routers in order of initialization. Since app2 was initialized later, it wins, and the /metadata is looked up relative to that Router. The bit of Spring context for app1 looks like this: bean id=router1 class=org.restlet.ext.spring.SpringRouter property name=attachments map entry key=/metadata!-- GET -- bean class=org.restlet.ext.spring.SpringFinder lookup-method name=create bean=metadataResource / /bean /entry ... /bean bean id=metadataResource class=...Metadata1Resource scope=prototype / and similarly for app2. Both apps are loaded into the same Spring context. If I'm understanding things correctly, this is a fundamental issue in using SpringFinder with multiple Routers. Can anyone give me workaround? I absolutely need my Resource instances to be created by Spring so they get autowired. Thanks, Sean -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068572
