StatusService getRepresentation and Variant
Would anyone be able to recommend the correct way to determine what the preferred Variant was for the requested Resource from the StatusService.getRepresentation() method? I would like to return different representations of error messages based on the Variant requested for the original resource. I am currently using Restlet 1.1.3. Thanks, Tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1277561
Servlet container's filters, getParameters() and POSTing www-form-urlencoded data
Dear all, this is a quite known issue[1][2] but I am wondering if you already have a solution to the following problem: Suppose you have a servlet filter that uses one of the getParameter*() method in order to get some data from the request. What happens is that if the request is a POST+www-form-urlencoded data this method consumes the body and when the request reaches Restlet, its body appears to be empty (i.e., subsequent calls to getInputStream() return and empty stream). Do you know a workaround to circumvent this behavior (except not using getParameter*() in the filter)? RequestWrappers don't work very well [1] Thank you for your answer. Cheers, Fabio [1] http://mail-archives.apache.org/mod_mbox/tomcat-users/200505.mbox/%3c428afc4b.2060...@softwareag.com%3e [2] http://markmail.org/message/hk3i7fak2hfxjbna#query:getinputstream%20post%20form%20urlencoded%20filter%20getparameters+page:1+mid:xwyf3dorrbqcdq6v+state:results -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1277500
RE: DirectoryResource, the clap://class/ scheme, and custom Classloaders - doesn't work? (OSGi- related)
Hi David, I now consider this issue fixed. See my comments in the issue opened by Thierry for details. 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 : Thierry Boileau [mailto:thierry.boil...@noelios.com] Envoyé : jeudi 26 février 2009 12:39 À : discuss@restlet.tigris.org Objet : Re: DirectoryResource, the clap://class/ scheme, and custom Classloaders - doesn't work? (OSGi- related) Hi Davd, nice shoot again :) I've entered a new RFC for that = http://restlet.tigris.org/issues/show_bug.cgi?id=740 best regards, Thierry Boileau We tried to configure a Directory instance to serve out static resources from a particular classloader (in our case we must do this to access the resource files stored inside an OSGi bundle, each bundle has it's own classloader). We set the directory's root reference to be something like clap://class/path/to/resource, following the instructions in the Restlet docs. Additionally, we made sure to set the custom class loader Request attribtue, also as documented: request.getAttributes().put(org.restlet.clap.classloader, bundleClassLoader); However the Directory failed to serve out resources from the custom classloader, and instead served resources from the classloader which was providing the restlet classes. In looking at the code, it seems that the org.restlet.engine.local.DirectoryResource class is the culprit. It ignores everything in the incoming Request object except for the target URI of the resource, and passes that URI to a call to getClientDispatcher.get(targetURI). Therefor the request attribute for org.restlet.clap.classloader is ignored, and the ClapClientHelper code never sees it. As a work-around, we created a Directory subclass which uses the clap://thread/path/to/resource strategy, and, on each request, stores the current Thread's context class loader, replaces it with the bundleClassLoader, and calls super.handle(), and then finally replaces the original context class loader. any thoughts? -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId =1231570 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12325 59 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278011
RE: Re: Managing a JPA/Hibernate session
Hi Paul, You made a good point regarding the afterSend and beforeSend method. So, I decided to change their behavior. Those methods are now invoked all the time, even if there is no entity sent (null will be passed). Changes in SVN trunk. 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 : blackh...@collab.net [mailto:blackh...@collab.net] Envoyé : jeudi 26 février 2009 17:31 À : discuss@restlet.tigris.org Objet : RE: Re: Managing a JPA/Hibernate session I have been looking more into the issue and have found some more additional issues. 1. As you suggested filters do not work as they are completed before the response is sent to the client. 2. The ConnectorService also does not work as the afterSend method is only called if there was an entity and there were no IO exceptions in streaming the result to the client. The result of this that you will have dangling EntityManagers as they are not closed. What is required is an interceptor/filter which can wrap the entire call to the restlet chain which wraps the handle and commit calls. This would allow you to do setup before the restlet calls and cleanup after the response has been committed. The developer then can include a finally block so that the cleanup is also performed after any exceptions. Paul -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12337 13 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278438
Re: Managing a JPA/Hibernate session
Jerome, Thanks, did you add it in a finally block so that it always gets executed even if there is an exception. Paul On 6-Mar-09, at 10:36 AM, Jerome Louvel wrote: Hi Paul, You made a good point regarding the afterSend and beforeSend method. So, I decided to change their behavior. Those methods are now invoked all the time, even if there is no entity sent (null will be passed). Changes in SVN trunk. 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 : blackh...@collab.net [mailto:blackh...@collab.net] Envoyé : jeudi 26 février 2009 17:31 À : discuss@restlet.tigris.org Objet : RE: Re: Managing a JPA/Hibernate session I have been looking more into the issue and have found some more additional issues. 1. As you suggested filters do not work as they are completed before the response is sent to the client. 2. The ConnectorService also does not work as the afterSend method is only called if there was an entity and there were no IO exceptions in streaming the result to the client. The result of this that you will have dangling EntityManagers as they are not closed. What is required is an interceptor/filter which can wrap the entire call to the restlet chain which wraps the handle and commit calls. This would allow you to do setup before the restlet calls and cleanup after the response has been committed. The developer then can include a finally block so that the cleanup is also performed after any exceptions. Paul -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12337 13 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278438 Paul Austin President/CEO Revolution Systems Inc. +1 (604) 288-4304 x201 www.revolsys.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278453
RE: Managing a JPA/Hibernate session
Paul, Yes I did! :) Cheers, Jerome -Message d'origine- De : Paul Austin [mailto:paul.aus...@revolsys.com] Envoyé : vendredi 6 mars 2009 19:41 À : discuss@restlet.tigris.org Objet : Re: Managing a JPA/Hibernate session Jerome, Thanks, did you add it in a finally block so that it always gets executed even if there is an exception. Paul On 6-Mar-09, at 10:36 AM, Jerome Louvel wrote: Hi Paul, You made a good point regarding the afterSend and beforeSend method. So, I decided to change their behavior. Those methods are now invoked all the time, even if there is no entity sent (null will be passed). Changes in SVN trunk. 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 : blackh...@collab.net [mailto:blackh...@collab.net] Envoyé : jeudi 26 février 2009 17:31 À : discuss@restlet.tigris.org Objet : RE: Re: Managing a JPA/Hibernate session I have been looking more into the issue and have found some more additional issues. 1. As you suggested filters do not work as they are completed before the response is sent to the client. 2. The ConnectorService also does not work as the afterSend method is only called if there was an entity and there were no IO exceptions in streaming the result to the client. The result of this that you will have dangling EntityManagers as they are not closed. What is required is an interceptor/filter which can wrap the entire call to the restlet chain which wraps the handle and commit calls. This would allow you to do setup before the restlet calls and cleanup after the response has been committed. The developer then can include a finally block so that the cleanup is also performed after any exceptions. Paul -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId =12337 13 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId =1278438 Paul Austin President/CEO Revolution Systems Inc. +1 (604) 288-4304 x201 www.revolsys.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12784 53 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278478
RE: detecting that client aborted or timed out
Hi Luis, Just a suggestion: you could provide client kits in various languages to your users, like large web services are doing. 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 : Luis Saenz [mailto:lsa...@taxcient.com] Envoyé : jeudi 26 février 2009 19:54 À : discuss@restlet.tigris.org Objet : RE: detecting that client aborted or timed out Sorry! non-blocking should have been blocking -- correction: (John) The separation of the client with the post/redirect/get pattern just changes the *client* to a non-blocking 'future'-ish model. I.e., if you use a thread pool model with a thread dedicated to processing the entire set of checks and behaviors to handle the POSTed data vs. if that's split out ala a SEDA approach, for example. (Lu) Exactly -- that's what I'm hoping to avoid, even though I agree it is a better design. The reason I want to avoid it is because I expect a non-trivial percentage of my clients not to have the skill to write a client like this. So I want to support a very simple REST client like curl, and provide a simple, ** blocking ** API spec. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12343 44 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278544
RE: Re: Why does the Restlet class have lifecycle methods?
Hi David, I think you put the finger on a serious issue here... We need to make this behavior more predictable and consistent. I suggest that we systematically propagate the start/stop actions to attached Restlets: - 'next' Restlet for a Filter - 'root' Restlet for an Application - 'routes' Filters for a Router - etc. This will also remove the current lazy start behavior, but this should be mostly backward compatible. Any opinion before I change the code in SVN trunk? 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 : David Fogel [mailto:carrotsa...@gmail.com] Envoyé : jeudi 26 février 2009 20:45 À : discuss@restlet.tigris.org Objet : RE: Re: Why does the Restlet class have lifecycle methods? Hi Stephen- Well, I'm not sure I understand what it means to be correctly integrated- we're creating Restlet subclasses and adding them to Routers, VirtualHosts, Filters, etc. Is there something else we need to do to register them somehow? Looking at the source code in Router, Filter, Application, VirtualHosts (this is in 1.2M1), I don't find any code which propagates calls to stop() to the children of the restlets. Could this be because there isn't a strict parent-child relationship in restlet? I suppose a single restlet instance could be attached to multiple parent Routers, which I suppose might make it unclear specifically whose responsibility it is to call stop() on the Restlet. Still, it seems to me that if the Restlet API is going to have these lifecycle methods on what is effectively the base class for all request-routing entities, that there should be some specific contract as to when these methods get called. Otherwise maybe they belong in a separate interface? As an aside, I'm also not a big fan of having the Restlet.handle() method lazily call start() on itself. This provides a very unreliable lifecycle for a component. I think it might make more sense to have the parent of the restlet call start() on it, either when it itself is started, or when the child is attached/added/set, etc. But this too has its own drawbacks. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12345 18 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278610
Integrating WADL and Spring
Hi All, I've been playing around with Restlet for some projects I'm working on and have really enjoyed the platform. I'm wondering if there is a way to define your service in a WADL document but still use Spring to configure all your applications Resources, etc. In the abstract what I would like to do is is define a WADL but instead of using ID's which map to Java classes, map them to Spring bean ids, essentially use WADL as a replacement for SpringRouter. Any suggestions? Is this an RFE? Thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278554
Re: Integrating WADL and Spring
Hi Dave, On Mar 6, 2009, at 1:08 PM, David Bordoley wrote: I've been playing around with Restlet for some projects I'm working on and have really enjoyed the platform. I'm wondering if there is a way to define your service in a WADL document but still use Spring to configure all your applications Resources, etc. In the abstract what I would like to do is is define a WADL but instead of using ID's which map to Java classes, map them to Spring bean ids, essentially use WADL as a replacement for SpringRouter. Any suggestions? Is this an RFE? This would be an RFE (at least, I'm not aware of any way to get it to work currently). I'm curious about how you would tie the resources in your application context to the WADL. Would you add a custom attribute for the spring bean id? Is there a WADL feature which would help with this? I'm not that familiar with it. Rhett -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278642
Re: JAX-RS and per methods security
Alexander J. Perez Tchernov schrieb:
Hello. Is it possible to ship an example how to operate with security
in JAX-RS for the following problem.
I want to specify that certain users may perform GET operation against
a certain resource, and only subset of them can perform PUT /POST
operation. The rest of resources don't need any authorization at all.
I want to implement this common task using JAX-RS.
I see that I need to create Guard to ask clients (via HTTP_DIGEST /
BASIC) to provide me trust username (principals)
// create a Guard
final Guard guard = new Guard(application.getContext(),
ChallengeScheme.HTTP_BASIC, JAX-RS example);
// set valid users and thier passwords.
guard.getSecrets().put(admin, adminPW.toCharArray());
I see that I need to create a RoleChecker that will perform the
certain validation if the certain user (principals) belongs to certain
role.
1) How can I specify that given operation against given resource is
permitted only for the following ROLE
@GET
@Path(...)
public Response get(@Context SecurityContext securityContext, ...)
{
if(!securityContext.isUserInRole(ROLE))
throw new WebApplicationException(403);
...
}
For the other resources you do not implement the role check.
2) How can I transfer the invocation context (resource uri) to
RoleChecker to let him, for example, check that given user is really
in AUTHOR ROLE of the resource
In the method you have to check, if the user is in a role, as in the
example above. You need a role where only the subset of users are in.
3) Does this schema (with Guard / RoleChecker) work even in standalone
mode, since it seems common to specify some of the parameters in
web.xml / specific.xml when deploy the application.
The Servlet security is not yet intergrated into the security system of
the Restlet JAX-RS extension, because I've had not enough time for it.
best regards
Stephan
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1279338
Upload to Directory
Hi,
I simply wanna upload a File to the org.restlet.Directory. But all I
get is:
See Other (303) - The metadata are not consistent with the URI
I don't know what that means, or what I can do against it.
On the Server Side i do:
Application application = new Application() {
@Override
public Restlet createRoot() {
Directory dir = new Directory(getContext(), ROOT_URI);
dir.setModifiable(true);
dir.setDeeplyAccessible(true);
return dir;
}
};
return application;
And the client which is uploading a file looks:
Client client = new Client(Protocol.HTTP);
Representation rep = new FileRepresentation(fileOpt.getValue(),
MediaType.ALL);
Response response = client.put(reference, rep);
Any suggestions?
Thx,
christian
--
Christian Haintz
Student of Software Development and Business Management
Graz, University of Technology
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1279726
Re: Integrating WADL and Spring
On Fri, Mar 6, 2009 at 11:32 AM, Rhett Sutphin rh...@detailedbalance.net wrote: This would be an RFE (at least, I'm not aware of any way to get it to work currently). I'm curious about how you would tie the resources in your application context to the WADL. Would you add a custom attribute for the spring bean id? Is there a WADL feature which would help with this? I'm not that familiar with it. Rhett Hi, The current way WADL works in Restlet is to require implementors to specify the class of the resource you want to map a WADL resource to using the resource's id attribute. You then pass the the WADL xml as a constructor argument to a WadlComponent or WadlApplication. You can see an example of this in org.restlet.test.YahooSearch.wadl (omitting the details in the example below): application resources base=http://api.search.yahoo.com/NewsSearchService/V1/; resource id=org.restlet.test.NewsSearchResource path=newsSearch /resource /resources /application It would be cool if you could do something similar but instead of passing a Resource class (and be stuck using the default constructor etc.), instead use a Spring Bean id as the resource id in WADL, and have restlet use spring to wire all the resources together, thus getting all the benefits of IOC, while also being able to more explicitly state your resource interface in a standard method. Anyway i can open an RFE if necessary, but I wanted to ask on the list first. thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1279214
Re: Upload to Directory
Hello Christian,
there is a mechanism based on the MetadaService [1] that checks the
media type of the uploaded file with the one deduced from the URI of the
resource.
For instance, you put a file with mediatype */* on a URI such as
http://www.example.com/fille.txt.
Based on the metadata service, the media type of the resource is
text/plain.
The rule is : if */* is not included into text/plain then, reject the
uploaded representation. it avoid to send a binary file when a text file
is expected.
Having said that, this mechanism could be optional, it isn't.
best regards,
Thierry Boileau
Hi,
I simply wanna upload a File to the org.restlet.Directory. But all I
get is:
See Other (303) - The metadata are not consistent with the URI
I don't know what that means, or what I can do against it.
On the Server Side i do:
Application application = new Application() {
@Override
public Restlet createRoot() {
Directory dir = new Directory(getContext(), ROOT_URI);
dir.setModifiable(true);
dir.setDeeplyAccessible(true);
return dir;
}
};
return application;
And the client which is uploading a file looks:
Client client = new Client(Protocol.HTTP);
Representation rep = new FileRepresentation(fileOpt.getValue(),
MediaType.ALL);
Response response = client.put(reference, rep);
Any suggestions?
Thx,
christian
--
Christian Haintz
Student of Software Development and Business Management
Graz, University of Technology
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1279726
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1281460
