RE: PUT and entity
Hi all, After reading the REST discussion thread again, here is a summary of the various arguments given by participants: - Use zero-length entities instead. (Jon Hanna) - Maybe an indication that another resource/representation design is preferable (Bruno Harbulot) - It seems harder to be consistent in modeling the application state by interpreting the meaning of a non-existing resource (Bruno Harbulot) - Mapping 200 OK = allow and 404 Not Found = deny is an abuse of HTTP response codes (Brian Smith) - The absence of a resource is explicitly devoid of meaning in HTTP (Aristotle Pagaltzis) For the last point, an alternative would be to use a Boolean value/representation to represent the presence or absence of the right, instead of relying on HTTP status codes. My conclusion is that the support of PUT with no entity is not necessary for now in Restlet. Any other opinion? Best regards, Jerome -Message d'origine- De : Jerome Louvel [mailto:[EMAIL PROTECTED] Envoye : jeudi 29 mai 2008 11:20 A : discuss@restlet.tigris.org Objet : RE: PUT and entity Hi Jim, I have just sent an email to the REST discuss list. Let's see what comes out of it to decide what to do: http://thread.gmane.org/gmane.comp.web.services.rest/8046 If no one says it is forbidden, we'll allow it technically in the framework. Best regards, Jerome -Message d'origine- De : Jim Alateras [mailto:[EMAIL PROTECTED] Envoye : jeudi 29 mai 2008 00:04 A : discuss@restlet.tigris.org Objet : Re: PUT and entity Rhett, Yes, forgot i asked this question before. IMHO i wouldn't encode the 'put MUST have a non-null entity) policy in the framework. If you do then you should provide for a mechanism to override it (allowNullEntity or something). From my reading of the HTTP spec doesn't specify that a PUT *MUST* have an entity although i agree that in most cases that would be the case. In my particular case the URL includes all the information required to create the resource but i have to stick in a non-null entity body to get this to work with the framework cheers /jima On 27/05/2008, at 12:37 PM, Rhett Sutphin wrote: Hi Jim, On May 26, 2008, at 7:09 PM, Jim Alateras wrote: Any reason why, i nthe restlet framework, a PUT expects to have an entity. When i issue a PUT with an empty entity i get a 400 response. Last time you asked this question ( http://restlet.tigris.org/servlets/ReadMsg?list=discussmsgNo=5132 ), I pointed you to an earlier discussion ( http://restlet.tigris.org/servlets/ReadMsg?listName=discussmsgNo=3902 ). The summary is: the HTTP spec is vague, but most implementations expect PUTs to have an entity. For more details, read that second-linked thread. Is there something in particular that was unclear or that you disagreed with? Rhett cheers /jima
RE: Restlet causing JVM crashes
Hi Mark, As it is a JVM bug, it seems natural to expect it to be fixed by Sun. If in the long run, the bug stays around and no satisfactory workaround is given, we could try to tweak the Restlet implementation to prevent it. Feel free to enter an issue in the tracker if necessary. Best regards, Jerome _ De : Mark Derricutt [mailto:[EMAIL PROTECTED] Envoyé : mardi 10 juin 2008 00:40 À : discuss@restlet.tigris.org Objet : Re: Restlet causing JVM crashes Interesting - was this ever entered as a bug to be fixed at all? Or did it just get lost in the mailing list? Mark On Tue, Jun 10, 2008 at 12:12 AM, Kevin Conaway [EMAIL PROTECTED] wrote: Hi Mark, I had the same problem as you. I tweaked some lines of code in that class and recompiled and the issue went away. It feels like a bug in the JVM because the error is happening when Hotspot decides to recompile the class. I never did figure out what was causing it. I had posted to [EMAIL PROTECTED] back in April: http://restlet.tigris.org/servlets/ReadMsg?list=code http://restlet.tigris.org/servlets/ReadMsg?list=codemsgNo=139 msgNo=139 Kevin On Wed, Jun 4, 2008 at 12:37 AM, Rob Heittman [EMAIL PROTECTED] wrote: That's a new one on me, but Hardy has been the locus of a bunch of new JVM crash issues, mainly with Athlon processors. Also there have been some similar issues with 64-bit under Red Hat and Fedora. This is the Sun JVM I get installing sun-java6-jdk from multiverse, and I don't get JVM crashes on P4, Centrino, or Core Duo. java version 1.6.0_06 Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Where did you get yours from? Direct Sun download? Hardy tries very hard to use OpenJDK, which also doesn't crash for me on P4, Centrino, or Core Duo. - Rob -- It is easier to optimize correct code than to correct optimized code. -- Bill Harlan
RE: Restlet JAX-RS extension
Hi Stephan,
Great summary email! I'd like to take this opportunity to congratulate you
for the huge amount of work that you have put into this JAX-RS extension
effort so far and into the numerous discussions with the JSR-311 EG.
I feel like we now have a strong JAX-RS implementation that will become more
and more important in the future as many developers will discover REST for
Java through the official JAX-RS API. This provides us a nice way to get
those users discovering the larger Restlet framework and use the best of
both worlds (annotation-based JAX-RS API and class-based Restlet API).
Regarding version 0.8, I agree about the renaming. Could you take care of it
directly? Otherwise, let me know when you are done with your commits so I or
Thierry can do it.
Best regards,
Jerome
_
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 6 juin 2008 22:05
À : discuss@restlet.tigris.org
Objet : Restlet JAX-RS extension
Hi JAX-RS interested people,
for my master thesis I will refer to JAX-RS 0.8, which is the public review
draft (see https://jsr311.dev.java.net). I will hand out the thesis by the
10th of July the latest. Before this date I think I have no time to update
to another JAX-RS version. And between the first Restlet 1.1 Release
Candidate and the final 1.1 release I think it is not useful to change
something here.
Jerome, if you want to rename the projects in the repository from *_0.9 to
*_0.8 (* = org.restet.ext.jaxrs and javax.ws.rs), please ask me before, if I
have uncommited changes.
As additional feature to the official API, you could use
org.restlet.data.Representation and its subclasses as entity without the
need of an entity provider for this. You could return every Representation
subclass as entity. If you want to get a Representation subclass as entity
into a resource method, this class must have a constructor with:
* a Representation as the one and only argument
* a Representation and a class as only arguments, where the class is
the generic type of the Representation subclass, e.g. the JibxRepresentation
There are some small things that are not (yet) supported by the JAX-RS
extension:
* The change of headers and the throwing of WebAppicationExceptions in
a message body writer could not work (IMO :-) ), because the Restlet Engine
first sends all headers and than start to write the message body. Here the
MessageBodyWriter is started, when the headers and the empty line is already
send. So headers could not be changed (because also send) or add (because
new line is already send). The same is valid for the WebApplicationException
with its status.
* @PathParam PathSegment do not work yet. There are some discussions
in the expert group now, so I could not finish the full requirements for the
matching. As workaround you could use @Context PathParam, to get the latest
matched path segment.
* This will work in a later version of this extension
* All other things defined with @PathParam in the spec should work
now.
* @Path(limited=false) is not fully restricted: Now also
@Path(value=ab{CDE}fg, limited=false) is also matched, if CDE matches
multiple path segments.
* This will also work in a later version of the extension.
* Because the setting of cache options is not supported by the Restlet
API until now, it is also not supported in this extension for now.
* This will also work in a later version of the extension.
* Authentication is only supported, if a Guard is used. The user name
detected by the Servlet container (or other connectors) is not available
yet; the same is valid for the role check. The reason is, that there is some
refactoring planned in the JAX-RS authentication. I think, after that
refactoring, this is also available
* If you need the role check, you could implement the interface
RoleChecker and add its instance to the JaxRsApplication.
* the de/encoding is only nearly full supported.
I hope I forgot nothing.
If you have used this extension already, something is missing or you
otherwise have comments, let me know. If told me bugs or something else
before the release, we could include fixes ...
best regards
Stephan
Re: Restlet JAX-RS extension
Hi Jerome, Regarding version 0.8, I agree about the renaming. Could you take care of it directly? Ok. Done. I've renamed the directories with subversion, renamed the new imported projects in Eclipse and checked in to the repository. I hope I forget nothing. best regards Stehan
RE: from the org.restlet.data.Request, get the HttpServletRequest
Hi Rob, There is already this method available (added recently): http://www.restlet.org/documentation/snapshot/ext/com/noelios/restlet/ext/se rvlet/ServletCall.html#getRequest(org.restlet.data.Request) It only retrieves the Servlet request if the Restlet request comes from a Servlet adapter. It misses the logic that you suggested for standalone deployment. Also, feel free to move the method into a new utility class if that can make usage more intuitive. IMO, no need to create another extension, the existing Servlet one can contain several features: - the Servlet adapter/connector - utility classes - etc. Best regards, Jerome _ De : Rob Heittman [mailto:[EMAIL PROTECTED] Envoyé : mardi 10 juin 2008 14:16 À : discuss@restlet.tigris.org Objet : Re: from the org.restlet.data.Request, get the HttpServletRequest Not a bad idea. I'm wondering how we could name it so as not to confuse people about the servlet extension vs. the servlet wrapper. I had thought of putting it the servlet extension because that is the only piece of Restlet that already depends on the servlet API, but that might cause some unintended drama with service discovery, as you point out! Definitely this calls for Jerome's wisdom. On Tue, Jun 10, 2008 at 5:01 AM, Bruno Harbulot [EMAIL PROTECTED] wrote: Very good points. Just a small comment: isn't the Servlet extension what allows Restlets to be wrapped into a Servlet environment (I don't actually use it)? I think perhaps this utility should be in a separate extension, since it would make it possible to use Servlet-based code from Restlet, but might not require Restlet to use the Servlet connector.
RE: Guards and authentication mechanisms
Hi Bruno, This looks like a killer post :-) I've added a comment about it in the RFE and will come back to it later (too busy to thoroughly read and comment it now). Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot Envoyé : mardi 10 juin 2008 10:45 À : discuss@restlet.tigris.org Objet : Re: Guards and authentication mechanisms Hi, Perhaps this can help, I've made a (long) list of authentication mechanisms (about as many as I could find and I've tried most): http://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechan isms-and-how-they-could-work-in-Restlet I was looking into which authentication information could be obtained from the server (in the sense of what can then be used for making an authorisation decision). Best wishes, Bruno. Jerome Louvel wrote: Hi Bruno, That sounds good, that for continuing the thinking. For SPNEGO, feel free to post comments on the RFE: Support SPNEGO authentication http://restlet.tigris.org/issues/show_bug.cgi?id=444 Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot Envoyé : dimanche 1 juin 2008 23:50 À : discuss@restlet.tigris.org Objet : Re: Guards and authentication mechanisms Hi all, Jerome Louvel wrote: Hi all, Thanks Bruno for the nice synthesis, that definitely helps moving forward. I have entered a new RFE to consolidate your comments and other ones from Stephan: Refactor authentication and authorization http://restlet.tigris.org/issues/show_bug.cgi?id=505 Stephan, I agree that this will take some time to properly refactor and take all aspects into account. I've listed 13 (!) related issues that I added in the blocks field. I don't think it would be wise to rush changes into 1.1 so I have set the milestone to 1.2 M1. Yes, I agree, no rush. Those of us who actually need such Guards in practice can more or less implement them in 1.1 as plain Filters or subclasses of Guard. I'll try to think of more esoteric authnz mechanisms (for example Shibboleth, which we use in parts of the project I work on). I've actually just had a rather successful go at implementing a SPNEGO Filter using the JAAS/GSS mechanism of Java 6, based on Kerberos. It's just a proof of concept and the code isn't very clean (I've cut a few corners when implementing my own ChallengeScheme and AuthenticationHelper), but it seems to work. (At least to test, being able to write the 'WWW-Authenticate' headers directly or at having something a bit simpler than AuthenticationHelper.formatParameters(...) would have made it a bit easier.) I can't guarantee if and how much time I can spend on this, but I'll try to give more details sometime soon. Best wishes, Bruno.
Re: PUT and entity
On Wednesday 2008.06.11, at 01:11 , Jerome Louvel wrote: [...] My conclusion is that the support of PUT with no entity is not necessary for now in Restlet. Any other opinion? I concur. It's totally nonsensical to have no entity at all for a put. That's like trying to put a null into a collection. The semantics are clear for an attempt to delete and for the put all empty values cases so there's no need at all. Take care, John
Vote SOON for Restlet in SourceForge's Community Choice Awards!
SourceForge is sponsoring its third annual Community Choice Awards: http://sourceforge.net/community/cca08 This year, for the first time, any open source project is eligible, not just those hosted on SourceForge.net. So you can vote for Restlet and any other of your favorite projects. *** Nominations close in just a few days, in mid-June *** so you're encouraged to vote right away. You can cast one vote for each award category, so can nominate Restlet in multiple categories, if you wish. To vote: 1. Visit the Restlet home page: http://www.restlet.org/ 2. Click the Nominate This Project button at the very bottom of the home page. NOTE: As I write this, SourceForge is currently down for scheduled maintenance. They expect to be back online at or around 12:00 pm Pacific Daylight Time Wednesday, June 11, 2000 ... 3:00 pm Eastern time in the US and Canada, 9:00 pm in many parts of Western Europe (2008-06-11T21:00:00Z), etc. :-) Aron Roberts
How to run JAX-RS application in a Servlet container
I would like to know how to deploy a JAX-RS application in a Servlet container.
I built a resource and MyAppConfig for testing and I don't know how to deploy it
a servlet container (similar to a servlet example in quick start).
public class MyAppConfig extends ApplicationConfig
{
@Override
public SetClass? getResourceClasses()
{
SetClass? rcs = new HashSetClass?();
rcs.add(HelloResource.class);
return rcs;
}
}
Thanks
cURL PUT with data?
Hey all, I did research into Restlet at the beginning of this year and really liked it. It tought me a lot about REST in general, but my boss decided that for the mean time we would implement our REST services in PHP, and slowly migrate modules across to Java at a later date. Regardless, I figured that this forum would be a good place to ask the following question: I have encountered an issue with using cURL and issuing PUT HTTP requests to perform update REST calls. It seems as if you can only upload whole files using this method. When using POST, data can be passed in. Unfortunately I seem to be left with no option other than to use a POST HTTP verb with a queryString flag saying something like 'reallyAPut=true' so that i can then retrieve the data and act on it in an 'update' way rather than a 'create' way. Has anyone else noticed this 'problem' with cURL? How does Restlet handle this again (memory is fading now)? Thanks guys, Marcus.
Re: cURL PUT with data?
I did a quick test, and formatted up my own HTTP request manually. I put in the PUT verb and the resource URI, the headers, and the data. Apache doesn't provide the data in the post data. It does pass these in when i change the verb to POST. Could this be an Apache thing? This is making the implementation of true REST calls very difficult for me. Marcus [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hey all, I did research into Restlet at the beginning of this year and really liked it. It tought me a lot about REST in general, but my boss decided that for the mean time we would implement our REST services in PHP, and slowly migrate modules across to Java at a later date. Regardless, I figured that this forum would be a good place to ask the following question: I have encountered an issue with using cURL and issuing PUT HTTP requests to perform update REST calls. It seems as if you can only upload whole files using this method. When using POST, data can be passed in. Unfortunately I seem to be left with no option other than to use a POST HTTP verb with a queryString flag saying something like 'reallyAPut=true' so that i can then retrieve the data and act on it in an 'update' way rather than a 'create' way. Has anyone else noticed this 'problem' with cURL? How does Restlet handle this again (memory is fading now)? Thanks guys, Marcus.
