Re: Restlet 1.1 M2 released
great! I translated it in Chinese:http://www.matrix.org.cn/resource/news/e2dda96c-e908-11dc-91da-b599c3ba16ef.html On Fri, Feb 29, 2008 at 11:29 PM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi again! After two months of intense work we are finally releasing our next milestone. In addition to the numerous bug fixes and API enhancements, we would like to underline the following features: * Addition of a HTTP server based on the Grizzly NIO framework. This connector is the first to provide end-to-end NIO support, for example with direct transfer from file to socket for static files. * Support for HTTP DIGEST authentication (client and server side) and refactoring of engine to support pluggable authentication. * Addition of new Spring NRE extension providing even more integration possibilities with the Servlets and Restlets at the same time. The existing Spring API extension has also been extended and improved based on users feed-back and contributions. * Addition of JiBX extension, providing an efficient and flexible alternative to JAXB for XML to Object serialization. * Configuration of a Component based on a XML document is now directly supported. * Update of the Atom extension to conform to the latest APP specifications. The extension currently allows to retrieve an APP Service Document and Atom Feeds. * Sorting of directory indexes is now based on the Alpha-numerical algorithm based on David Koelle's original idea. * Refactoring and enhancement of the WADL extension to support more use cases and nested resources are now supported. We have also updated several dependencies: * Spring to version 2.5 * db4o to version 7.0 * FreeMarker to version 2.3.12 * Grizzly to version 1.7.2 Thanks also to the direct contributors: * Alex Milowski * Avi Flax * Davide Angelocola * Derek Chiles * Evgeny K. Shepelyuk * Florian Schwarz * Garriot Zhang * Iestyn Evans * Jason Terhune * Kevin Conaway * Marc Portier * Michael Makunas * Paul J. Lucas * Ray Waldin * Rhett Sutphin * Rob Heittman * Sean Landis * Simon Olofsson * Stephan Koops * Tim Peierls * Todd Nguyen * William Pietri Changes log: http://www.restlet.org/documentation/1.1/changes Download links: http://www.restlet.org/downloads/1.1/restlet-1.1m2.zip http://www.restlet.org/downloads/1.1/restlet-1.1m2.exe Maven repositories: http://maven.restlet.org (open) will be updated on 02/01 http://maven.noelios.com (restricted) has the new artifacts Best regards, Jerome Louvel Thierry Boileau -- cleverpig Location: Beijing Address: Room 4018,No.A2 South Avenue Fuxingmen Beijing,P.R.China Zipcode: 100031 Phone: 010-66415588-1113 MSN: [EMAIL PROTECTED] QQ: 149291732 Skepe: cleverpigatmatrix My Facebook ID:cleverpig My Blog: hihere.sohu.com My Tags: del.icio.us/cleverpig My Twitter: twitter.com/cleverpig My Organization: www.beijing-open-party.org 一些值得关注的唧歪: http://jiwai.de/t/jmatrix/ http://jiwai.de/t/db4o/ http://jiwai.de/t/matrix-community/
Issue 376
Hello, I'm interested in trying to contribute to solve issue 376: http://restlet.tigris.org/issues/show_bug.cgi?id=376 There are in fact two sub-problems in this issue: (1) exposing javax.servlet.request.X509Certificate and (2) defining something that would provide the equivalent of javax.servlet.http.HttpServletRequest.getRemoteUser(). Is someone already working on it? I wouldn't mind having a go at this, but I'm not sure if this would conflict with some other work. Best wishes, Bruno.
Re: Problems extracting a POST request's entity
Hi, Thanks Mitch and Bruno for your answers. Bruno, I was using Restlet 1.1M1 and the problem was the same that yours. The resolution of the POST method took a long time and the returned entity's value was null (either using getText() or using streams). I returned to Restlet 1.07 and now the problem is gone. Regards, Sergio. -- Sergio Saugar García Área de Ciencias de la Computación e Inteligencia Artificial Departamento de Ciencias de la Computación Edificio Departamental II - Despacho 053 Escuela Técnica Superior de Ingeniería Informática Universidad Rey Juan Carlos Móstoles (MADRID) Clave PGP: http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xADFA3433 signature.asc Description: OpenPGP digital signature
RE: Issue 376
Hi Bruno, Thanks for proposing to help on this front Bruno. I've reassigned the RFE to you. Note that in 1.1 M2, the Guard is automatically adding a Principal instance to the request attributes upon successful authentication. Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot Envoyé : lundi 3 mars 2008 12:43 À : discuss@restlet.tigris.org Objet : Issue 376 Hello, I'm interested in trying to contribute to solve issue 376: http://restlet.tigris.org/issues/show_bug.cgi?id=376 There are in fact two sub-problems in this issue: (1) exposing javax.servlet.request.X509Certificate and (2) defining something that would provide the equivalent of javax.servlet.http.HttpServletRequest.getRemoteUser(). Is someone already working on it? I wouldn't mind having a go at this, but I'm not sure if this would conflict with some other work. Best wishes, Bruno.
Re: 1.1-M2 maven dependency error for artifact 'com.noelios.restlet.ext.spring'
Rasmus Agerholm rasmus at agerholm.org writes: HiThe pom file for the 'com.noelios.restlet.ext.spring' artifact found at the 'maven.restlet.org' repository, http://maven.restlet.org/com/noelios/restlet/com.noelios.restlet.ext.servlet/1.1-M2/com.noelios.restlet.ext.servlet-1.1-M2.pom defines the 'com.noelios.restlet.ext.servlet' dependency like this: dependency groupIdcom.noelios.restlet.ext.servlet/groupId artifactIdcom.noelios.restlet.ext.servlet/artifactId version1.1-M/version /dependencyI believe the groupId should be 'com.noelios.restlet' and the version should be '1.1-M2', right?The groupId issue also goes for the 1.1-SNAPSHOT pom.Best Regards, and thanks for a very good framework Rasmus Agerholm Hi there, another error in both 1.1-M2 and 1.1-SNAPSHOT like at http://maven.restlet.org/org/restlet/org.restlet.ext.spring/1.1-SNAPSHOT/org.restlet.ext.spring-1.1-SNAPSHOT.pom is the non-replaced spring framework dependency version variable @lib-spring-version@, resulting in non-valid deps in maven. /peter dependency groupIdorg.springframework/groupId artifactIdspring-core/artifactId version@lib-spring-version@/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version@lib-spring-version@/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-beans/artifactId version@lib-spring-version@/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-web/artifactId version@lib-spring-version@/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version@lib-spring-version@/version /dependency
Understanding Restlet's Threading Model?
I'd like to understand the threading model used by my basic Restlet app. I have a standalone app that uses Application and Component, and attaches subclasses of Restlet to the router. I am using the reference implementation provided by noelios. (Many, many thanks to Jerome for all of this!) So, what rules should I expect this app to follow as far as how many threads get created when requests come in, and how many threads are allowed to run concurrently? I've looked at the behaviour empirically and I'm a little confused: 1) When I insert test code that sometimes has a handlers sleep before finishing the request, and I then manually hit that handler through my browser with multiple requests, I seem to be observing purely synchronous behaviour. I do see that new threads are created for each request, however I also see that all requests coming in are forced to wait if a previous request triggered the handler to sleep. Then when the sleep is done, all requests seem to complete synchronously. Shouldn't I expect that the sleeping request handler would not cause any non-sleeping handlers to block? Or I'm missing something obvious? 2) When I run load tests against the app, generating dozens or more of simultaneous requests, I *do* observe asynchronous processing of those requests. (I conclude this from the fact that file output from my handler to a specific file ends up interlaced, or if I try using locking I may get OverlappingFileLockException). I've reviewed the docs on restlet.org and I haven't been able to find a basic overview of the strategy being used here. Many many thanks to anyone who can enlighten me or point me to relevant docs! 8-] All the best, Aaron
Re: HTML with REST
Hello,
as discussed two weeks ago, some browsers (e.g. Internet Explorer 7.0
and Firefox 2.0) sends as accepted media type XML with a higher quality
than HTML. The consequence is, that a HTTP server sends XML instead of
HTML, if it could produce XML.
For this problem I've created a Filter (named HtmlPreferer now), that
will increase the qualities for HTML media types (text/html and
application/xhtml+xml) higher than both XML types (text/xml and
application/xml), if at least one of both is available in a request.
Now it is available in the JAX-RS extension. What do you think about
make it available for all developers in the main project? I put the
actual source and a test case as attachment.
Jerome or Thierry: If you want to integrate the class in the main
package or where ever, use the file of the JAX-RS; perhaps I continue
developing or something like this.
best regards
Stephan
Rob Heittman schrieb:
This legacy browser behavior is frustrating in the extreme. Why in
heaven's name would a tool meant primarily for viewing HTML, request
XML as a higher quality representation? Just goes to show how
uber-excited everybody was about XML once upon a time. You know,
because in the future, all web pages will someday be XML with a
reference to an XSL stylesheet, not HTML.
Choosing a different MediaType for your XML, that the browser doesn't
ask for, is the usual solution.
Another workable solution I have found -- if you are using XML and
will get criticized for making up MIME types -- is to expose the
browser-friendly HTML variant by itself on a distinct URI (e.g.
person.html). That's sloppy too, just in a different way.
Now, packaging your data with JSON instead of XML will avoid the issue
altogether, without making up MIME types =)
- R
On 2/18/08, *Stephan Koops* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
if a browser requests to a REST server, some browsers (Firefox and IE
for example, Opera not) requests text/xml and application/xml with a
higher quality than text/html.
/*
* Copyright 2005-2008 Noelios Consulting.
*
* The contents of this file are subject to the terms of the Common Development
* and Distribution License (the License). You may not use this file except in
* compliance with the License.
*
* You can obtain a copy of the license at
* http://www.opensource.org/licenses/cddl1.txt See the License for the specific
* language governing permissions and limitations under the License.
*
* When distributing Covered Code, include this CDDL HEADER in each file and
* include the License file at http://www.opensource.org/licenses/cddl1.txt If
* applicable, add the following below this CDDL HEADER, with the fields
* enclosed by brackets [] replaced with your own identifying information:
* Portions Copyright [] [name of copyright owner]
*/
package org.restlet.ext.jaxrs;
import java.util.List;
import java.util.Map;
import org.restlet.Context;
import org.restlet.Filter;
import org.restlet.Restlet;
import org.restlet.data.MediaType;
import org.restlet.data.Preference;
import org.restlet.data.Request;
import org.restlet.data.Response;
/**
* p
* Some browsers (e.g. Internet Explorer 7.0 and Firefox 2.0) sends as accepted
* media type XML with a higher quality than html. The consequence is, that a
* HTTP server sends XML instead of HTML, if it could produce XML. To avoid
* this, you can use this filter.
* /p
* p
* This Filter will increase the qualities for HTML media types (text/html and
* application/xhtml+xml) higher than both XML types (text/xml and
* application/xml), if at least one of both is available in a request. The
* check is implemented in method [EMAIL PROTECTED]
#shouldChangeToPrefereHtml(Request)}.
* br
* Requests that not are not effected.
* /p
* p
* You may alter the test if the filter should change the request by subclass
* this Filter and overrider method [EMAIL PROTECTED]
#shouldChangeToPrefereHtml(Request)}.
* /p
*
* @author Stephan Koops
*/
public class HtmlPreferer extends Filter {
private static final int MT_PREF_APP_XHTML = 1;
private static final int MT_PREF_APP_XML = 3;
private static final int MT_PREF_TEXT_HTML = 0;
private static final int MT_PREF_TEXT_XML = 2;
private static final String MT_QUALITY_ARRAY =
org.restlet.HtmlPreferer.qualities;
/**
* Creates a new [EMAIL PROTECTED] HtmlPreferer}. You should use constructor
* [EMAIL PROTECTED] #HtmlPreferer(Context)} or [EMAIL PROTECTED]
#HtmlPreferer(Context, Restlet)}.
*/
@Deprecated
public HtmlPreferer() {
super();
}
/**
* Creates a new [EMAIL PROTECTED] HtmlPreferer}. You can give also the
next restlet
* by using constructor [EMAIL PROTECTED] #HtmlPreferer(Context, Restlet)}.
*
* @param context
*the context from the parent
*/
public HtmlPreferer(Context context) {
super(context);
}
/**
Re: Understanding Restlet's Threading Model?
The mapping of incoming network connections to threads is very dependent on the HTTP/HTTPS connector/server in use. Restlet, as far as I know, does not do anything to attenuate the native behavior of the server with regard to creating threads for incoming network connections. Which server environment were you looking at when you tested? On Mon, Mar 3, 2008 at 2:43 PM, Aaron Crow [EMAIL PROTECTED] wrote: I'd like to understand the threading model used by my basic Restlet app. I have a standalone app that uses Application and Component, and attaches subclasses of Restlet to the router. I am using the reference implementation provided by noelios. (Many, many thanks to Jerome for all of this!)
Re: HTML with REST
Another workable solution I have found -- if you are using XML and will get criticized for making up MIME types -- is to expose the browser-friendly HTML variant by itself on a distinct URI (e.g. person.html). That's sloppy too, just in a different way. I think this might be a better and clear way than specifying content type in the HTTP header. The book Restful web service also recommends doing this. It is both friendly to browser client and programmatic client. On Tue, Feb 19, 2008 at 12:41 AM, Rob Heittman [EMAIL PROTECTED] wrote: This legacy browser behavior is frustrating in the extreme. Why in heaven's name would a tool meant primarily for viewing HTML, request XML as a higher quality representation? Just goes to show how uber-excited everybody was about XML once upon a time. You know, because in the future, all web pages will someday be XML with a reference to an XSL stylesheet, not HTML. Choosing a different MediaType for your XML, that the browser doesn't ask for, is the usual solution. Now, packaging your data with JSON instead of XML will avoid the issue altogether, without making up MIME types =) - R On 2/18/08, Stephan Koops [EMAIL PROTECTED] wrote: if a browser requests to a REST server, some browsers (Firefox and IE for example, Opera not) requests text/xml and application/xml with a higher quality than text/html. -- Cheers, Keke - We paranoid love life
Re: HTML with REST
On Mon, Mar 3, 2008 at 6:00 PM, keke [EMAIL PROTECTED] wrote: [...] Another workable solution I have found -- if you are using XML and will get criticized for making up MIME types -- is to expose the browser-friendly HTML variant by itself on a distinct URI (e.g. person.html). That's sloppy too, just in a different way. I think this might be a better and clear way than specifying content type in the HTTP header. The book Restful web service also recommends doing this. It is both friendly to browser client and programmatic client. It's easy enough to support both approaches in the Resources' code. I.e., it doesn't have to be an either/or dichotomy. Take care, John
