Hi Thierry and Richard,
>from what I understand, the main aim of the JaxRs extension is to be able >to host a JaxRs based application inside a Restlet based application. ... >In this use case, the "classic JaxRs annotated resources" are considered to >be plain old Java objects, it does not address the special case of Restlet >ServerResource. I has assume that the classes *had* to extent ServerResource and I had thought that using a ServerResource in a JaxRs application would be the best of both worlds! But I see your point. In fact in terms of making my application more portable, removing the dependence on Restlet specific classes is probably a good idea. >You can still get the current request as follow : >org.restlet.Request restletReq = org.restlet.Request.getCurrent(); Great tip. >Having said that I have one general recommandation. When using Restlet >ServerResource, it's fine to get the current Request because this is >completely part of the Restlet API. But accessing the HttpServletRequest >ties your application with the special case of an application hosted by a >servlet container and will prevent you to host your application using the >Simple extension, for example. This is also a great point - JAX-RS itself gives me other ways to access parts the the request via annotations and it's probably in my interest to use those over both the Restlet API and the Servlet API. > I guess that we can enhance the current behaviour and take into account the > case of JaxRs annotated instances of ServerResource. I've entered an issue : > https://github.com/restlet/restlet-framework-java/issues/610 Yes - maybe handy that if the POJO is an instance of UniformResource then call the init method there - allows a JaxRs / Restlet hybrid model that adds some flexibility. Regards, Carl pritchett ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2972981
