On Tue, Apr 22, 2008 at 7:12 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Tom,
>
> The default behavior of the TunnelService in 1.1 is to remove the trailing
> extensions matching known metadata (via the MetadataService). It replaces
> the extensions by updating the client's metadata,
> "ClientInfo.acceptedMediaTypes" for example.
>
> Now, I'm wondering why your application breaks when this feature is enabled.
> Are your routers trying to match those extensions explicitly? Are you using
> a Directory to handle the request?
>
> Thanks for sharing those details, that will help us tune the feature if
> necessary.
I feel like I should be wacking the TunnelService with a rolled up
newspaper. No
cookie for you, TunnelService! :)
I just ran into this myself and wasted a bunch of time figuring out
that I needed
to turn the tunnel service *OFF*.
It seems to me that the tunnel service shouldn't mess with the
resource reference.
I my case it replaced the return of getRemainingPart() with the same path minus
the final extension. I had a GET request on an XML document and it
not only called
"setExtensions()" along the way but seem to get that wrong in that a call to
getExtensions() returns null. Where did that original extension information go?
This change will also seriously break Atomojo (which uses Restlet).
Good thing that
I know about it and can turn off the TunnelService's want to break my resource
references by :
getTunnelService().setPreferencesTunnel(false);
It seems to me that a service such as this:
* should be *OFF* by default
* shouldn't mess with the original information (e.g. leave the last
segment alone)
* should provide its information as an optional augmentation of the request.
--Alex Milowski
