Restlet Framework 2.0 RC1 released

[Jerome Louvel]

Hi all,

The first 2.0 release candidate is finally ready. Please help us with bugs
reports, patches and wiki contributions, to ship a rock solid 2.0.0 version!
http://blog.noelios.com/2010/03/15/restlet-framework-2-0-rc1-released/

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460201

Content type negotiation with annotations

[Bruno Harbulot]

Hi,


Firstly, I'd like to write a ServerResource that uses @Get("xml") and 
@Get("html") for content negotiation on GET but not on POST (where it 
would return a different content-type depending on what the method does, 
or do the negotiation internally).
Secondly, I'd like to be able to post some 
"application/x-www-form-urlencoded" content and get another type in return.


public class MyResource extends
ServerResource {
@Override
protected void doInit() throws ResourceException {
super.doInit();
setNegotiated(true);
getVariants().add(new Variant(MediaType.TEXT_HTML));
getVariants().add(new Variant(MediaType.APPLICATION_XHTML));
getVariants().add(new Variant(MediaType.APPLICATION_RDF_XML));
}

@Get("html")
public Representation toHtml() throws ResourceException {
   ...
}

@Get("xml")
public Representation toXml() throws ResourceException {
...
}

@Post
public Representation accept(Representation entity) throws 
ResourceException {
...
}
}


At the moment, if I turn off the content-type negotiation 
(setNegotiated(false)), then 'accept' is being called up receiving a 
POST request. If content-negotiation is on (setNegotiated(true)), I get 
a 405 (method not allowed) error.
It looks like this is due to the logic in doNegotiatedHandle(), which 
I'd rather not override.


I'm not entirely sure it's because of the content-type negotiation on 
the returned type, but it might be due to the input type too. (Hence the 
second part of this problem.)

I've tried this @Post("html"), @Post("xml") and @Post("html|xml"), but 
they're never called anyway, so it doesn't seem to have much to do with 
the negotiated return type (the browser accepts "*/*" by the way).

What's posted is of type "application/x-www-form-urlencoded". It looks 
like the @Post annotation make the negotiation on the input type too.
If I tweak client to send the same content as "text/html", the 
@Post("html") is called. This seems a bit wrong (posting 
x-www-form-urlencoded forms and getting HTML in return seems quite 
common, and that doesn't seem feasible if content-type negotiation is on).
Did I miss something? Any workarounds?


Best wishes,

Bruno.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460162

Re: A GET with query parameters?

[Thierry Boileau]

Hi,

just in order to get a little bit shorter:

Form queryParams = getReference().getQueryAsForm();
String size = queryParams.getFirstValue("size");


You can also use the "new Form(String)" constructor.

Best regards,
Thierry Boileau

> Hi,
>
> Any specific reason why you don't want to use a "normal" query like this?
> http://mysite.com/farms?size=n
>
> You could then get the query parameters with:
> Form queryParams = getRequest().getResourceRef().getQueryAsForm();
> String size = queryParams.getFirstValue("size");
>
> Best wishes,
>
> Bruno.
>
> dj wrote:
>
>> Hi,
>>
>> I'm using restlet with google app engine, but think this is just a general 
>> restlet question.
>>
>> I want to support a GET method where the user can supply some query 
>> parameters like:
>>
>>http://mysite.com/farms/size=n
>>
>> so the user can do a GET on the farms list but only return a list of farms 
>> that have a size of N. What's the proper way to do this with restlet?
>>
>> I've got this:
>>
>>router.attach("/farms/{size}", Farm.class);
>>
>>public class Farm extends ServerResource {
>>
>>  @Get
>>  public String represent() {
>>Request request = getRequest();
>>String params = getRequest().getAttributes().get("size");
>>  }
>>}
>>
>> that works, I'll get "size=12" etc. Is this the right way to do it, or is 
>> there some more structured approach to parameters? If I have like 12 
>> parameters, I have to explode the string etc etc to get the param names and 
>> their values and all that fun stuff. No big deal, just want to know if this 
>> is the right way to go.
>>
>> Thanks
>>
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460126
>>
>>  
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460147
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460151

Re: A GET with query parameters?

[Bruno Harbulot]

Hi,

Any specific reason why you don't want to use a "normal" query like this?
   http://mysite.com/farms?size=n

You could then get the query parameters with:
   Form queryParams = getRequest().getResourceRef().getQueryAsForm();
   String size = queryParams.getFirstValue("size");

Best wishes,

Bruno.

dj wrote:
> Hi,
> 
> I'm using restlet with google app engine, but think this is just a general 
> restlet question.
> 
> I want to support a GET method where the user can supply some query 
> parameters like:
> 
>   http://mysite.com/farms/size=n
> 
> so the user can do a GET on the farms list but only return a list of farms 
> that have a size of N. What's the proper way to do this with restlet?
> 
> I've got this:
> 
>   router.attach("/farms/{size}", Farm.class);
> 
>   public class Farm extends ServerResource {
> 
> @Get
> public String represent() {
>   Request request = getRequest();
>   String params = getRequest().getAttributes().get("size");
> }
>   }
> 
> that works, I'll get "size=12" etc. Is this the right way to do it, or is 
> there some more structured approach to parameters? If I have like 12 
> parameters, I have to explode the string etc etc to get the param names and 
> their values and all that fun stuff. No big deal, just want to know if this 
> is the right way to go.
> 
> Thanks
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460126
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460147

A GET with query parameters?

[dj]

Hi,

I'm using restlet with google app engine, but think this is just a general 
restlet question.

I want to support a GET method where the user can supply some query parameters 
like:

  http://mysite.com/farms/size=n

so the user can do a GET on the farms list but only return a list of farms that 
have a size of N. What's the proper way to do this with restlet?

I've got this:

  router.attach("/farms/{size}", Farm.class);

  public class Farm extends ServerResource {

@Get
public String represent() {
  Request request = getRequest();
  String params = getRequest().getAttributes().get("size");
}
  }

that works, I'll get "size=12" etc. Is this the right way to do it, or is there 
some more structured approach to parameters? If I have like 12 parameters, I 
have to explode the string etc etc to get the param names and their values and 
all that fun stuff. No big deal, just want to know if this is the right way to 
go.

Thanks

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460126

Strange problem with redirection

[Mathias]

Gentlemen,

first of all: congratulations to the restlet team for making available such an 
excellent framework! Restlet is true fun to work with!
Still, I currently have a strange problem that someone might be able to give me 
a hint for:

I'm running restlet 2.0M7 JavaSE edition directly with the internal web server.
I am creating a standard Engine with a simple Component containing a very 
simple Application whose inboundRoot is a Router with a route mapping "/" to a 
Redirector to "file://c/xyz/home.html".

When I access the root URL I get a "port out of range" exception because for 
some reason the redirector redirects to an HTTP client instead of a FILE client.
This is my log (on level FINE):

18:26:55.648 [main] DEBUG o.r.e.c.ComponentClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.648 [main] DEBUG o.r.e.c.ComponentServerDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.648 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.664 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.664 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.664 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.664 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.679 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.679 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.679 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.695 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has 
been instantiated without any protocol.
18:26:55.695 [main] INFO  o.r.PricingEngineComponent.Client - Starting the 
default HTTP client
18:26:55.961 [main] INFO  o.r.PricingEngineComponent.Server - Starting the 
default HTTP server
18:26:55.992 [main] DEBUG org.restlet.PricingEngineApplication - The connector 
has been instantiated without any protocol.
18:26:55.992 [main] DEBUG org.restlet.PricingEngineApplication - The connector 
has been instantiated without any protocol.
18:26:55.992 [main] INFO  com.xyz.tariffs.PricingEngine - PricingEngine SERVER 
ONLINE after 1.391 sec
18:26:59.320 [Restlet-213274] DEBUG o.r.PricingEngineComponent.LogFilter - The 
connector has been instantiated without any protocol.
18:26:59.320 [Restlet-213274] DEBUG o.r.P.ServerRouter - The default host was 
selected.
18:26:59.320 [Restlet-213274] DEBUG o.r.P.ServerRouter - New base URI: 
http://coxxp:8182
18:26:59.320 [Restlet-213274] DEBUG o.r.P.ServerRouter - New remaining part: /
18:26:59.320 [Restlet-213274] DEBUG org.restlet.VirtualHost - This route was 
selected: "" -> com.discovergy.tariffs.pricingengineapplicat...@8e32e7
18:26:59.320 [Restlet-213274] DEBUG org.restlet.VirtualHost - New base URI: 
http://coxxp:8182
18:26:59.320 [Restlet-213274] DEBUG org.restlet.VirtualHost - New remaining 
part: /
18:26:59.320 [Restlet-213274] DEBUG org.restlet.VirtualHost - Delegating the 
call to the target Restlet
18:26:59.320 [Restlet-213274] DEBUG org.restlet.PricingEngineApplication - This 
route was selected: "/" -> org.restlet.routing.redirec...@1d62270
18:26:59.320 [Restlet-213274] DEBUG org.restlet.PricingEngineApplication - New 
base URI: http://coxxp:8182/
18:26:59.320 [Restlet-213274] DEBUG org.restlet.PricingEngineApplication - New 
remaining part: 
18:26:59.320 [Restlet-213274] DEBUG org.restlet.PricingEngineApplication - 
Delegating the call to the target Restlet
18:26:59.320 [Restlet-213274] INFO  org.restlet.PricingEngineApplication - 
Redirecting via client dispatcher to: file://c/xyz/home.html
18:26:59.320 [Restlet-213274] DEBUG o.r.P.ClientRouter - This client was 
selected: "[HTTP]"
18:26:59.320 [Restlet-213274] DEBUG o.r.P.ClientRouter - New base URI: 
18:26:59.320 [Restlet-213274] DEBUG o.r.P.ClientRouter - New remaining part: 
file://c/xyz/home.html
18:26:59.320 [Restlet-213274] DEBUG o.r.P.ClientRouter - Delegating the call to 
the target Restlet
18:26:59.398 [Restlet-1152907] ERROR o.r.PricingEngineComponent.Client - 
Thread: Restlet-1152907 terminated with exception: port out of range:-1
java.lang.IllegalArgumentException: port out of range:-1
at java.net.InetSocketAddress.(InetSocketAddress.java:118) 
[na:1.6.0_14]
at 
org.restlet.engine.http.connector.BaseClientHelper.handleOutbound(BaseClientHelper.java:547)
 [org.restlet.jar:na]
at 
org.restlet.engine.http.connector.ControllerTask$4.run(ControllerTask.java:139) 
[org.restlet.jar:na]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 [na:1.6.0_14]
at 
jav

Re: How to write an Universal redirector

[asdfasdf]

Hi Gentlemen,

Was it possible to find out why a Tomcat deployed application redirects
differently then the from Eclipse run GWT application?
I have uploaded my (simple) Eclipse project with this behavior 
http://www.kybernetika.de/tmp/TestRestlet.zip here . 
(The Google classes have been removed from the WEB-INF/lib directory) 

Best regards,

ab



Thierry Boileau wrote:
> 
> Hi ab,
> 
>  >Another problem is when I deploy the application to Tomcat. The
> Redirects do not work at all.
> what do you mean?
> Do you declare the required client connectors in the web.xml file?
> 

-- 
View this message in context: 
http://n2.nabble.com/How-to-write-an-Universal-redirector-tp4620578p4737021.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2459976

Re: Access to HttpSession from Restlet ...

[Jerome Louvel]

FYI, Bruno's patch has just been applied to SVN trunk.

Best regards,
Jerome


Le 03/03/2010 12:27, Bruno Harbulot a écrit :
> Hi,
>
> I've just submitted a patch:
> http://restlet.tigris.org/issues/show_bug.cgi?id=1050
>
> It can be useful for some applications to have access to the TLS session
> ID. (This could possibly be used by some ongoing FOAF+SSL work for example.)
>
>
> Regarding the use of SSL session ID for maintaining session, this
> discussion should be of interest:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=22679
>
>
> Basically, nothing even guarantees that the same session ID will be used
> for multiple requests (it's not just about those 10-15 minutes).
>
> In addition, what RFC2818  says
> about (TLS) sessions is:
> - "Note that an implementation which does this MAY choose to reuse the
> session. [...]"
> - "It MAY resume a TLS session closed in this fashion."
> - "Servers SHOULD be willing to resume TLS sessions closed in this
> fashion."
> - "As specified in [RFC2246], any implementation which receives a
> connection close without first receiving a valid closure alert (a
> "premature close") MUST NOT reuse that session."
>
> It's quoted out of context, but they're all MAYs and SHOULDs (except
> about invalidating the session), which implies very little in terms of
> what can be expected from the session ID, regarding application session
> management.
>
>
> Best wishes,
>
> Bruno.
>
>
> Stefan Meissner wrote:
>> Ok Bruno, thanks for your assessement.
>>
>> I'll forward your expert's opinion to the architect who gave me this task :)
>>
>> But generally 10-15 minutes life-time of the session would be sufficient for 
>> my use-case.
>>
>> best regards
>> Stefan
>>
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2452215
>>
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2454411
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2459829

Re: SESSIONS.ser error in tomcat 6.0 with restlet 2.0

[Thierry Boileau]

Hello Iván,

it seems this is a configuration issue with Tomcat about "persistent 
connections" (see here [0], for example). A Restlet based application is 
totally unaware of such feature.

Best regards,
Thierry Boileau

[0] http://wiki.webratio.com/index.php/Avoiding_Persistent_Tomcat_Sessions

> Hello,
>
> I have a problem with a very simple application when I deploy it in tomcat 
> 6.0.
> The deploy process is right and the application is working, but sometime 
> after the application has been deployed  it doesn't work anymore.
> The application is the following:
>
> public class MMApplication extends Application {
>   
>public MMApplication() {
>}
>
>public MMApplication(Context parentContext) {
>super(parentContext);
>}
>
>@Override
>public synchronized Restlet createInboundRoot() {
>
>Router router = new Router(getContext());
>
>router.attach("/users/{username}", UserResource.class);
>router.attach("/messages", MessagesResource.class);
>
>return router;
> }
>
>
> In tomcat log I can see the following error:
>
> INFO: Repliegue (undeploy) de la aplicación web que tiene como trayectoria 
> de contexto /MM
> 13-mar-2010 9:54:22 org.apache.catalina.session.StandardManager doUnload
> GRAVE: IOException al salvar sesiones persistidas: 
> java.io.FileNotFoundException: 
> /home/foss/apache-tomcat-6.0.20/work/Catalina/localhost/MM/SESSIONS.ser (No 
> such file or directory)
> java.io.FileNotFoundException: 
> /home/foss/apache-tomcat-6.0.20/work/Catalina/localhost/MM/SESSIONS.ser (No 
> such file or directory)
>  at java.io.FileOutputStream.open(Native Method)
>  at java.io.FileOutputStream.(FileOutputStream.java:179)
>  at java.io.FileOutputStream.(FileOutputStream.java:70)
>  at 
> org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:489)
>  at 
> org.apache.catalina.session.StandardManager.unload(StandardManager.java:463)
>  at 
> org.apache.catalina.session.StandardManager.stop(StandardManager.java:667)
>  at 
> org.apache.catalina.core.StandardContext.stop(StandardContext.java:4573)
>  at 
> org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:924)
>  at 
> org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1103)
>  at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1271)
>  at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296)
>  at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>  at 
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
>  at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
>  at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
>  at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
>  at java.lang.Thread.run(Thread.java:619)
> 13-mar-2010 9:54:22 org.apache.catalina.session.StandardManager stop
> GRAVE: Excepción descargando sesiones a almacenamiento persistente
> java.io.FileNotFoundException: 
> /home/foss/apache-tomcat-6.0.20/work/Catalina/localhost/MM/SESSIONS.ser (No 
> such file or directory)
>  at java.io.FileOutputStream.open(Native Method)
>  at java.io.FileOutputStream.(FileOutputStream.java:179)
>  at java.io.FileOutputStream.(FileOutputStream.java:70)
>  at 
> org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:489)
>  at 
> org.apache.catalina.session.StandardManager.unload(StandardManager.java:463)
>  at 
> org.apache.catalina.session.StandardManager.stop(StandardManager.java:667)
>  at 
> org.apache.catalina.core.StandardContext.stop(StandardContext.java:4573)
>  at 
> org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:924)
>  at 
> org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1103)
>  at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1271)
>  at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296)
>  at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>  at 
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
>  at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
>  at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
>  at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
>  at java.lang.Thread.run(Thread.java:619)
>
>
> The web.xml file is:
> 
> http://www.w3.o