Re: Router swallowing exceptions
Hello Cliff,
I get an Instantiation exception with a warning trace when running with
the current trunk.
ATTENTION: Exception while instantiating the target handler.
java.lang.InstantiationException
at
sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.restlet.Finder.createTarget(Finder.java:186)
[...]
What release of Restlet are you using?
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
http://www.noelios.com/
I unfortunately accidentally discovered that if a Resource is not
instantiable (e.g., the class is abstract, constructor is protected,
etc.), the router---which is unable to complete its work---does
nothing and doesn't log anything either
It would be most appreciated if it would log a (probably SEVERE) error
if it was unable to instantiate the Resource.
For example, if you have this:
attach(router, /not-instantiable,
com.example.resource.MyAbstractResource.class);
and of course:
package com.example.resource;
public abstract class MyAbstractResource
extends Resource {
...
}
Thanks much,
Cliff Binstock
Coyote Reporting
Content negotiation with browsers - advice sought
Hi all, I am using Restlet to create a simple data server. I'm currently wrestling with content negotiation (conneg), which is handled very nicely by Restlet, but not by user agents, particularly web browsers. I'd like to be able to serve representations of my resources in a number of formats, including HTML, Google Earth KML and a special XML format called CSML (http://csml.badc.rl.ac.uk/). I have set up my Resource object to support a number of Variants: getVariants().add(new Variant(MediaType.TEXT_HTML)); // for web browsers getVariants().add(new Variant(CSML_MEDIA_TYPE)); // for special clients that understand CSML getVariants().add(new Variant(MediaType.IMAGE_PNG)); // image representation of the resource getVariants().add(new Variant(KML_MEDIA_TYPE)); // for clients that understand KML getVariants().add(new Variant(MediaType.APPLICATION_XML)); // for general clients that understand XML but not CSML I had naively assumed that web browsers would automatically ask for and get the TEXT_HTML representation. But no, I tested Firefox, IE7 and Chrome and got very different results: Firefox 3: Accept header is text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Hence text/html is used, as expected. Chrome 0.2.149.30: Accept header is text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5. So Chrome prefers application/xml to text/html and hence gets an XML representation by default. Seems odd. IE7: Accept header does not include text/html, image/png or application/xml (!!) but does include */* (yuck) so IE gets the variant that happens to be first in the Resource's list. With the above code this just happens to be text/html. So conneg doesn't really happen here at all. I didn't test Safari, Opera or anything else. So the question is, how can arrange things so that web browsers get HTML representations? I can only see one workaround for this, which is to use file extensions on my resource URLs to determine the media type (e.g. .html, .png, .kml etc). This is not RESTful (from my understanding of REST) but seems to be a common workaround (e.g. in Ruby on Rails). Is there a way to do this easily in Restlet or is this practice discouraged? Or is there a better alternative? Best wishes, Jon -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 [EMAIL PROTECTED] http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm
Re: Content negotiation with browsers - advice sought
Hi Jon, in the TunnelService in Restlet 1.1 there is a solution for exactly this problem. Try Application.getTunnelService().setUserAgentTunnel(true). Your proposed workaround with file extensions is also available: Try Application.getTunnelService().setExtensionsTunnel(true). But the first solution is IMO better. best regards Stephan -Ursprüngliche Nachricht- Von: Jon Blower [EMAIL PROTECTED] Gesendet: 28.10.08 12:34:26 An: Restlet discussion mailing list discuss@restlet.tigris.org Betreff: Content negotiation with browsers - advice sought Hi all, I am using Restlet to create a simple data server. I'm currently wrestling with content negotiation (conneg), which is handled very nicely by Restlet, but not by user agents, particularly web browsers. I'd like to be able to serve representations of my resources in a number of formats, including HTML, Google Earth KML and a special XML format called CSML (http://csml.badc.rl.ac.uk/). I have set up my Resource object to support a number of Variants: getVariants().add(new Variant(MediaType.TEXT_HTML)); // for web browsers getVariants().add(new Variant(CSML_MEDIA_TYPE)); // for special clients that understand CSML getVariants().add(new Variant(MediaType.IMAGE_PNG)); // image representation of the resource getVariants().add(new Variant(KML_MEDIA_TYPE)); // for clients that understand KML getVariants().add(new Variant(MediaType.APPLICATION_XML)); // for general clients that understand XML but not CSML I had naively assumed that web browsers would automatically ask for and get the TEXT_HTML representation. But no, I tested Firefox, IE7 and Chrome and got very different results: Firefox 3: Accept header is text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Hence text/html is used, as expected. Chrome 0.2.149.30: Accept header is text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5. So Chrome prefers application/xml to text/html and hence gets an XML representation by default. Seems odd. IE7: Accept header does not include text/html, image/png or application/xml (!!) but does include */* (yuck) so IE gets the variant that happens to be first in the Resource's list. With the above code this just happens to be text/html. So conneg doesn't really happen here at all. I didn't test Safari, Opera or anything else. So the question is, how can arrange things so that web browsers get HTML representations? I can only see one workaround for this, which is to use file extensions on my resource URLs to determine the media type (e.g. .html, .png, .kml etc). This is not RESTful (from my understanding of REST) but seems to be a common workaround (e.g. in Ruby on Rails). Is there a way to do this easily in Restlet or is this practice discouraged? Or is there a better alternative? Best wishes, Jon _ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
Re: Content negotiation with browsers - advice sought
Hi Stephan, Great, thanks very much. Just a few questions ;-) (I've looked in the docs but apologies if I've missed anything) 1) Is the TunnelService essentially a filter that can modify HTTP headers (possibly other things too) before they reach my Resource class? 2) Why do you consider the userAgentTunnel better than file extensions? Is it simply closer to the REST model? 3) If I use a userAgentTunnel how can I distinguish between web page requests (which probably require text/html) and requests from img tags (which probably require image/*)? 4) What's the best documentation to read to learn how to use and configure the TunnelService? I can probably figure things out from the javadoc, but would appreciate some other docs if they exist. Thanks, Jon On Tue, Oct 28, 2008 at 11:51 AM, Stephan Koops [EMAIL PROTECTED] wrote: Hi Jon, in the TunnelService in Restlet 1.1 there is a solution for exactly this problem. Try Application.getTunnelService().setUserAgentTunnel(true). Your proposed workaround with file extensions is also available: Try Application.getTunnelService().setExtensionsTunnel(true). But the first solution is IMO better. best regards Stephan -Ursprüngliche Nachricht- Von: Jon Blower [EMAIL PROTECTED] Gesendet: 28.10.08 12:34:26 An: Restlet discussion mailing list discuss@restlet.tigris.org Betreff: Content negotiation with browsers - advice sought Hi all, I am using Restlet to create a simple data server. I'm currently wrestling with content negotiation (conneg), which is handled very nicely by Restlet, but not by user agents, particularly web browsers. I'd like to be able to serve representations of my resources in a number of formats, including HTML, Google Earth KML and a special XML format called CSML (http://csml.badc.rl.ac.uk/). I have set up my Resource object to support a number of Variants: getVariants().add(new Variant(MediaType.TEXT_HTML)); // for web browsers getVariants().add(new Variant(CSML_MEDIA_TYPE)); // for special clients that understand CSML getVariants().add(new Variant(MediaType.IMAGE_PNG)); // image representation of the resource getVariants().add(new Variant(KML_MEDIA_TYPE)); // for clients that understand KML getVariants().add(new Variant(MediaType.APPLICATION_XML)); // for general clients that understand XML but not CSML I had naively assumed that web browsers would automatically ask for and get the TEXT_HTML representation. But no, I tested Firefox, IE7 and Chrome and got very different results: Firefox 3: Accept header is text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Hence text/html is used, as expected. Chrome 0.2.149.30: Accept header is text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5. So Chrome prefers application/xml to text/html and hence gets an XML representation by default. Seems odd. IE7: Accept header does not include text/html, image/png or application/xml (!!) but does include */* (yuck) so IE gets the variant that happens to be first in the Resource's list. With the above code this just happens to be text/html. So conneg doesn't really happen here at all. I didn't test Safari, Opera or anything else. So the question is, how can arrange things so that web browsers get HTML representations? I can only see one workaround for this, which is to use file extensions on my resource URLs to determine the media type (e.g. .html, .png, .kml etc). This is not RESTful (from my understanding of REST) but seems to be a common workaround (e.g. in Ruby on Rails). Is there a way to do this easily in Restlet or is this practice discouraged? Or is there a better alternative? Best wishes, Jon _ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114 -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 [EMAIL PROTECTED] http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm
Force Media Type
Hi there, I thought once upon a time you could force the media-type by specifying ?media-type=XXX in the URL. Is this still true? Thanks, Dustin -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | [EMAIL PROTECTED] facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada
RE: Force Media Type
Hi Dustin, Try just ?media=gif instead. See the TunnelService Javadocs for details. Best regards, Jérôme Louvel -- Noelios Technologies http://www.noelios.com tel / fax : +33 1 47 57 30 53 mob : +33 6 85 14 21 12 -Message d'origine- De : Dustin N. Jenkins [mailto:[EMAIL PROTECTED] Envoyé : mardi 28 octobre 2008 17:52 À : Restlet Users Group Objet : Force Media Type Hi there, I thought once upon a time you could force the media-type by specifying ?media-type=XXX in the URL. Is this still true? Thanks, Dustin -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | [EMAIL PROTECTED] facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada
RE: Router swallowing exceptions
I am using V1.1 RC2
Cliff Binstock
_
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2008 2:33 AM
To: discuss@restlet.tigris.org
Subject: Re: Router swallowing exceptions
Hello Cliff,
I get an Instantiation exception with a warning trace when running with the
current trunk.
ATTENTION: Exception while instantiating the target handler.
java.lang.InstantiationException
at
sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(Instan
tiationExceptionConstructorAccessorImpl.java:30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.restlet.Finder.createTarget(Finder.java:186)
[...]
What release of Restlet are you using?
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
http://www.noelios.com/
I unfortunately accidentally discovered that if a Resource is not
instantiable (e.g., the class is abstract, constructor is protected, etc.),
the router-which is unable to complete its work-does nothing and doesn't
log anything either
It would be most appreciated if it would log a (probably SEVERE) error if it
was unable to instantiate the Resource.
For example, if you have this:
attach(router, /not-instantiable,
com.example.resource.MyAbstractResource.class);
and of course:
package com.example.resource;
public abstract class MyAbstractResource
extends Resource {
.
}
Thanks much,
Cliff Binstock
Coyote Reporting
Restlet 1.1.0 released!
Hi all, Thanks to all of you who helped us getting there: we have just pushed Restlet 1.1.0 out of the door!! The release process is just starting, now we need to get the word out now. If you can help us spreading the good news that would be great. Below is the announce text from http://blog.noelios.com --- Since the launch of Restlet 1.0 in April 2007, we have been working hard to prepare this new version. To protect your investment in existing code, we have maintained the initial API design, extending it where necessary and always ensuring a direct if not transparent migration path. Here is a selection of the most exciting new features: * Broader and deeper HTTP support with features such as partial downloads, resumable uploads or content integrity validation. * Best support for the WADL specification in the industry, allowing an automatic and always in sync documentation of your REST APIs. WADL documents can be generated in XML or converted on the fly to HTML using the popular stylesheet from Yahoo! * One of the first and most complete implementations of the new JAX-RS 1.0 specification provided for those preferring an annotation-oriented approach. * New Restlet-GWT module provided, porting the client-side of the Restlet API to the popular Google Web Toolkit 1.5 JavaScript platform, allowing you to invoke RESTful applications right from your Web browser. * New extensions for easier integration with the JAXB 2.1, JiBX 1.1, Spring 2.5, OAuth, OSGi, Oracle XDB and SSL technologies. * Improved support for Atom Syndication XML format and for Atom Publishing Protocol. Both formatting and parsing are now available. * New POP3 connector based on JavaMail to access RESTfully to remote mail boxes. * New Grizzly HTTP server connector, first to fully leverage the NIO support in the Restlet API, leading to new levels of scalability and performance. * New internal HTTP client and server connectors to simplify development phases (zero configuration necessary) and allow very small footprint deployments. http://www.restlet.org/ Direct contributors: * Aaron Crow * Aaron Roberts * Adam Harris * Bruce Lee * Diego Ballve * Erik Beeson * Jérôme Bernard * Kevin Conaway * Richard Hoberman * Tim Peierls In addition, we have significantly expanded our documentation http://www.restlet.org/documentation/1.1/ with a 150 pages long Restlet User Guide, a screencast and first steps tutorials. We have also added new licensing options: LGPL 3.0 and transferable commercial licences (OEM). You just need to download Restlet http://www.restlet.org/downloads/ 1.1.0 to enjoy those new features ! Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com
Re: Restlet 1.1.0 released!
Congratulations on the release! I'm very excited to see where Restlet goes. --Erik On Tue, Oct 28, 2008 at 10:57 AM, Jerome Louvel [EMAIL PROTECTED]wrote: Hi all, Thanks to all of you who helped us getting there: we have just pushed Restlet 1.1.0 out of the door!! The release process is just starting, now we need to get the word out now. If you can help us spreading the good news that would be great. Below is the announce text from http://blog.noelios.com --- Since the launch of Restlet 1.0 in April 2007, we have been working hard to prepare this new version. To protect your investment in existing code, we have maintained the initial API design, extending it where necessary and always ensuring a direct if not transparent migration path. Here is a selection of the most exciting new features: - Broader and deeper HTTP support with features such as partial downloads, resumable uploads or content integrity validation. - Best support for the WADL specification in the industry, allowing an automatic and always in sync documentation of your REST APIs. WADL documents can be generated in XML or converted on the fly to HTML using the popular stylesheet from Yahoo! - One of the first and most complete implementations of the new JAX-RS 1.0 specification provided for those preferring an annotation-oriented approach. - New Restlet-GWT module provided, porting the client-side of the Restlet API to the popular Google Web Toolkit 1.5 JavaScript platform, allowing you to invoke RESTful applications right from your Web browser. - New extensions for easier integration with the JAXB 2.1, JiBX 1.1, Spring 2.5, OAuth, OSGi, Oracle XDB and SSL technologies. - Improved support for Atom Syndication XML format and for Atom Publishing Protocol. Both formatting and parsing are now available. - New POP3 connector based on JavaMail to access RESTfully to remote mail boxes. - New Grizzly HTTP server connector, first to fully leverage the NIO support in the Restlet API, leading to new levels of scalability and performance. - New internal HTTP client and server connectors to simplify development phases (zero configuration necessary) and allow very small footprint deployments. http://www.restlet.org/ Direct contributors: - Aaron Crow - Aaron Roberts - Adam Harris - Bruce Lee - Diego Ballve - Erik Beeson - Jérôme Bernard - Kevin Conaway - Richard Hoberman - Tim Peierls In addition, we have significantly expanded our documentationhttp://www.restlet.org/documentation/1.1/with a 150 pages long Restlet User Guide, a screencast and first steps tutorials. We have also added new licensing options: LGPL 3.0 and transferable commercial licences (OEM). You just need to download Restlet 1.1.0http://www.restlet.org/downloads/to enjoy those new features ! Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Re: Force Media Type
Perfect, thank you! Dustin Jerome Louvel wrote: Hi Dustin, Try just ?media=gif instead. See the TunnelService Javadocs for details. Best regards, Jérôme Louvel -- Noelios Technologies http://www.noelios.com tel / fax : +33 1 47 57 30 53 mob : +33 6 85 14 21 12 -Message d'origine- De : Dustin N. Jenkins [mailto:[EMAIL PROTECTED] Envoyé : mardi 28 octobre 2008 17:52 À : Restlet Users Group Objet : Force Media Type Hi there, I thought once upon a time you could force the media-type by specifying ?media-type=XXX in the URL. Is this still true? Thanks, Dustin -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | [EMAIL PROTECTED] facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada
Re: Restlet 1.1.0 released!
we have just pushed Restlet 1.1.0 out of the door!! Darn, there goes our excuse for postponing the update from 1.0.7! Congrats to the team. I'm looking forward to playing with the new features. -vincent.
Re: Restlet 1.1.0 released!
Cheers all On Tue, Oct 28, 2008 at 2:17 PM, Erik Beeson [EMAIL PROTECTED] wrote: Congratulations on the release! I'm very excited to see where Restlet goes. --Erik On Tue, Oct 28, 2008 at 10:57 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi all, Thanks to all of you who helped us getting there: we have just pushed Restlet 1.1.0 out of the door!! The release process is just starting, now we need to get the word out now. If you can help us spreading the good news that would be great. Below is the announce text from http://blog.noelios.com --- Since the launch of Restlet 1.0 in April 2007, we have been working hard to prepare this new version. To protect your investment in existing code, we have maintained the initial API design, extending it where necessary and always ensuring a direct if not transparent migration path. Here is a selection of the most exciting new features: - Broader and deeper HTTP support with features such as partial downloads, resumable uploads or content integrity validation. - Best support for the WADL specification in the industry, allowing an automatic and always in sync documentation of your REST APIs. WADL documents can be generated in XML or converted on the fly to HTML using the popular stylesheet from Yahoo! - One of the first and most complete implementations of the new JAX-RS 1.0 specification provided for those preferring an annotation-oriented approach. - New Restlet-GWT module provided, porting the client-side of the Restlet API to the popular Google Web Toolkit 1.5 JavaScript platform, allowing you to invoke RESTful applications right from your Web browser. - New extensions for easier integration with the JAXB 2.1, JiBX 1.1, Spring 2.5, OAuth, OSGi, Oracle XDB and SSL technologies. - Improved support for Atom Syndication XML format and for Atom Publishing Protocol. Both formatting and parsing are now available. - New POP3 connector based on JavaMail to access RESTfully to remote mail boxes. - New Grizzly HTTP server connector, first to fully leverage the NIO support in the Restlet API, leading to new levels of scalability and performance. - New internal HTTP client and server connectors to simplify development phases (zero configuration necessary) and allow very small footprint deployments. http://www.restlet.org/ Direct contributors: - Aaron Crow - Aaron Roberts - Adam Harris - Bruce Lee - Diego Ballve - Erik Beeson - Jérôme Bernard - Kevin Conaway - Richard Hoberman - Tim Peierls In addition, we have significantly expanded our documentationhttp://www.restlet.org/documentation/1.1/with a 150 pages long Restlet User Guide, a screencast and first steps tutorials. We have also added new licensing options: LGPL 3.0 and transferable commercial licences (OEM). You just need to download Restlet 1.1.0http://www.restlet.org/downloads/to enjoy those new features ! Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Re: Content negotiation with browsers - advice sought
Hi Jon 1) Is the TunnelService essentially a filter that can modify HTTP headers (possibly other things too) before they reach my Resource class? The Restlet Engine uses the data from the TunnelService to initialize the TunnelFilter (part of the engine), which does the work, as you described. As every filter, it could change everything in the request. 2) Why do you consider the userAgentTunnel better than file extensions? Is it simply closer to the REST model? The user agnet filter allow the content negotiation as it is planned, because you are not required to add extensions to your URIs. On the other hand with the extension mapping you have the possibility to request every media type with every client. You could also combine both possibilities. To the closeness to REST: While defining the JAX-RS-API we had a discussion about exactly this feature. Roy Fielding pointed out (see https://jsr311.dev.java.net/servlets/ReadMsg?list=devmsgNo=1458, full thread: https://jsr311.dev.java.net/servlets/BrowseList?listName=devfrom=1196535to=1196535count=31by=threadpaged=false) , that he URI http://abc.de/fgh.html is not the same resource as http://abc.de/fgh, and he is right. These URIs describe two resources, which could (should, ...) point to the same entity (the same business object, see http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1 for details). With reading it is not a big problem, but with modifying: if you edit ./fgh.html (e.g. PUT or DELETE), than this request (from the REST point of view) will not change/delete /fgh.xml, but this is the result, intended by the developer and the client. So the user agent filter is indeed closer to REST. The Restlet filter will evaulate the extension only for GET (and HEAD) requests. But I think, that both are useful. IMO: Use both. If the link is .../fgh (without extension), you get, what your client like (HTML for browser etc, XML or JSON for a web servcie etc.), and if you want a special media type, you could explict use the URI ./fgh.gif 3) If I use a userAgentTunnel how can I distinguish between web page requests (which probably require text/html) and requests from img tags (which probably require image/*)? See above. 4) What's the best documentation to read to learn how to use and configure the TunnelService? I can probably figure things out from the javadoc, but would appreciate some other docs if they exist. I don't knoiw, that there is more documentation. You just need to set the booleans to true. The Restlet Engine should do the rest. It includes a lot of mappings for file extensions (see org.restlet.service.MetadataService.getMetaData(), accessible via Application.getMetadataService()). It also includes a basic configuration for the user agent mapping. There is a propertiy file for it, but I don't know where. Perhaps useragents.properties or something like this. If you have more questions, there is thsi mailing list :-) Perhaps you give good input for more javadoc or something like this. best regards Stephan On Tue, Oct 28, 2008 at 11:51 AM, Stephan Koops [EMAIL PROTECTED] wrote: Hi Jon, in the TunnelService in Restlet 1.1 there is a solution for exactly this problem. Try Application.getTunnelService().setUserAgentTunnel(true). Your proposed workaround with file extensions is also available: Try Application.getTunnelService().setExtensionsTunnel(true). But the first solution is IMO better. best regards Stephan -Ursprüngliche Nachricht- Von: Jon Blower [EMAIL PROTECTED] Gesendet: 28.10.08 12:34:26 An: Restlet discussion mailing list discuss@restlet.tigris.org Betreff: Content negotiation with browsers - advice sought Hi all, I am using Restlet to create a simple data server. I'm currently wrestling with content negotiation (conneg), which is handled very nicely by Restlet, but not by user agents, particularly web browsers. I'd like to be able to serve representations of my resources in a number of formats, including HTML, Google Earth KML and a special XML format called CSML (http://csml.badc.rl.ac.uk/). I have set up my Resource object to support a number of Variants: getVariants().add(new Variant(MediaType.TEXT_HTML)); // for web browsers getVariants().add(new Variant(CSML_MEDIA_TYPE)); // for special clients that understand CSML getVariants().add(new Variant(MediaType.IMAGE_PNG)); // image representation of the resource getVariants().add(new Variant(KML_MEDIA_TYPE)); // for clients that understand KML getVariants().add(new Variant(MediaType.APPLICATION_XML)); // for general clients that understand XML but not CSML I had naively assumed that web browsers would automatically ask for and get the TEXT_HTML representation. But no, I tested Firefox, IE7 and Chrome and got very different results: Firefox 3: Accept header is
1.1.0 maven
Hello, I don't see the 1.1.0 version in the maven repository. Should we be using the SNAPSHOR version? Also, why are the poms no longer part of the distribution? Thanks, -Vincent.
RE: serving static files from servlet WAR with Directory class: index.html not served automatically
Thanks!
Is this change included in the new Restlet 1.1.0 release?
- Lu
-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2008 2:26 AM
To: discuss@restlet.tigris.org
Subject: Re: serving static files from servlet WAR with Directory class:
index.html not served automatically
Hello Luis,
we have reconsidered the question.
The WAR client connector supports the content negotiation feature.
The fix is available in the svn repository and in the last snapshot.
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Original Message-
Hello Luis,
Just to satisfy my curiosity, would you mind answering these questions for
me?
Of source not!
1. Why does content negotiation have to be disabled for this to work?
In order to anwser exactly to your question, I've just made a test, and it
is not necessary to turn off the content negotiation at the level of the
directory.
However, I would like to add a few words.
Our implementation of the content negotiation relies on the ability to look
for the entire list of files that share the same base name (e.g.
{index.html.en, index.txt, etc} when index.html is requested). Thus,
you can confront the client preferences and the listed files in order to
find the best representation of the resource.
This is possible when you are relying on a directory (something pointed by
file:///), but WAR files does not provide easy and sure way to look for
the content of a directory inside a WAR file. Thus, we decided to make
such low level connectors unable to support content negotiation. If you want
a file in a war, you need to provide its exact path and name.
In your case, you wanted to get the index file when requesting for a
directory. Therefore, we can play with the index property of Directory
Restlet and give it the exact name of your index files.
2. Are there any other side-effects due to disabling content negotiation?
Disabling content negotiation should have as only consequence to let the
client request for the exact URI of the resource.
3. What is the difference between /doc and /doc/ in the URI template
parsing logic?
Good question. This point was the main cause of your problem.
If you request for http://abc.com.mywar/doc; though your application is
routed to http://abc.com.mywar/doc/;, the routing logic can not infer that
you are actually looking for a directory identified
http://abc.com.mywar/doc/;.
Actually, /doc and /doc/ are not equivalent. The latter clearly
identifies the root of a hierarchy, in your case, a directory. But /doc
does not. It can be a resource.
Having said that, our implementation of the Directory Restlet is able to
know if you are really requesting the doc directory. If the target Uri
does not end with a /, it asks the client to make another request to the
/doc/ URI.
You can try to request http://www.restlet.org/documentation/1.1;, you will
see that you are redirected to http://www.restlet.org/documentation/1.1/;
I hope I answer to your questions.
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Thanks again,
- Lu
-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Monday, October 13, 2008 2:01 AM
To: discuss@restlet.tigris.org
Subject: Re: serving static files from servlet WAR with Directory class:
index.html not served automatically
Hi Luis,
it should work if you attach the directory like this (please note the
removes trailing /):
Directory docsDir = new Directory(getContext(), war:///doc);
docsDir.setNegotiateContent(false);
docsDir.setIndexName(index.html);
router.attach(/doc, docsDir);
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Original Message-
Hi Jerome,
Thanks for the suggestion.
I tried it, but unfortunately that didn't work either. The explicit URL
still works, but the index file is still not served when you access the
parent URL.
Let me know if you have any other ideas or if you think this is due to a
bug. Thanks again!
- Lu
-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 2:03 AM
To: discuss@restlet.tigris.org
Subject: RE: serving static files from servlet WAR with Directory class:
index.html not served automatically
Hi Luis,
This is due to the fact that directory listing isn't possible with the
war:// client connector, as opposed to the file:// client.
However, could you try this:
// expose static API docs
Directory docsDir = new Directory(getContext(), war:///doc);
docsDir.setNegotiateContent(false);
docsDir.setIndexName(index.html);
router.attach(/doc/, docsDir);
Let us know if this doesn't solve your issue and we'll
