On Mon, May 19, 2008 at 1:31 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > 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).
I understand this is a good feature but many applications may find intruding on the resource reference a problem. That is, what if the "media" query parameter is already used. Now, if you want such a feature... having to just make a single call to turn it on is probably really useful. > 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. In atomojo, the extension is a choice made by the user using the atom publishing protocol. They send a "slug" header to control the actual file name. As such, the extension could be ".foo" or ".myrandomxmldocument" for text/xml and not ".xml". That means that I need to honor the original requested file name in the last segment and attempt to find it in the storage. I have all the requested information for formulating the response and setting the media type in an database external to the actual storage vehicle. In the case of the tunnel service, what doesn't make sense to me is that it seems like the extension information just disappeared. It wasn't that it was placed in another facet of the Reference instance and I had to get at it using getExtensions(). It just completely vanished. As such, I could not reconstruct the original last segment. > 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. As a policy, I turn off the TunnelService explicitly in all my applications because what tasks it performs do not help me. > 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. No need to apologize. I was very surprised and frustrated with what seemed like a very fundamental change. In this case, I do rely upon getResourceRef() related processing. I do want getRemainingPart() to give me the matching portion minus the path that go to my application via routing. It is just that the tunnel service gets inserted automatically that was surprising to me. --Alex Milowski
