Hi Alex, Like Thierry, I have just checked the code again and in trunk the extensions tunnel feature is now off by default.
The idea behind this feature is to have a very simple way for a user to specify, for any resource hosted within an application, which representation he wants. The standard way is to use the "Accept" header (hard with browsers and not very intuitive), the other way is to use the "?media=xml" query parameter which is processed by the TunnelService by default and converted into the equivalent "Accept" header info (the query parameter is then removed from the 'resourceRef' to make this feature transparent to the application resources). Now with the extensions tunneling, the user can just append ".xml" to the last segment and have an effect similar to using an "Accept: text/xml" header, with no change to the application logic. I would be interested to understand why/how it breaks your URI processing logic, but my feeling is that in 90% of cases, it will be a very convenient feature. BTW, we already support something similar for the Directory class. Also, if you want to have a common configuration policy across all your applications (for example to disable all services and associated filters), then I suggest that you use a BaseApplication class extending o.r.Application. I do feel your pain regarding the unexpected changes to your URIs and logic, and I apologize for the time lost in figuring out what happened. I think that Rob's proposition to add a "requestedRef" property and to clarify "resourceRef" Javadocs is a good way to clarify the actual intent. Best regards, Jerome -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Alex Milowski Envoyé : vendredi 16 mai 2008 21:49 À : [email protected] Objet : Disabling the TunnelService I now strongly believe that the TunnelService needs to be off by default. I've had to go into *every* single class that extends Application and add this line to my constructor: getTunnelService().setEnabled(false); All of my code is now breaking wherever there is a resource with an extension because getRemainingPart() now returns the path minus the extension in the last segment. This "magic" mucking around with the resource reference has cause me no end of troubles. I'm not really certain why this service needs to be on by default but I can say with 100% certainty that I don't need it on for *any* of my applications that use Restlet. I just want the resource reference as requested by the client. If we apply the "policy of least surprise" to this, you would think that advanced features for variants/etc. would need to be enabled so that, at minimum, without changing any settings, you just get the URL path for the resource upon which the request was made. That dictates that: * unnecessary "filters" should be off by default * features like the tunnel service should be required to be turned on * the resource reference should remain the same regardless of whether such filters are enabled. --Alex Milowski
