Hi all,
I prefer leaving the "originalRef" absolutely untouched by the routing
process and therefore not setting/syncing its "baseRef" property. I think it
will help to separate its role relatively to "resourceRef".
Here are the new Javadocs for the Request#getResourceRef() method:
/**
* Returns the reference of the target resource. This reference is
especially
* important during routing, dispatching and resource finding. During
such
* processing, its base reference is constantly updated to reflect the
* reference of the parent Restlet or resource and the remaining part of
the
* URI that must be routed or analyzed.
*
* If you need to get the URI reference originally requested by the
client,
* then you should use the [EMAIL PROTECTED] #getOriginalRef()} method
instead.
Also,
* note that beside the update of its base property, the resource
reference
* can be modified during the request processing.
*
* For example, the [EMAIL PROTECTED] TunnelService} associated to an
application
can
* extract some special extensions or query parameters and replace them
by
* semantically equivalent properties on the request object. Therefore,
the
* resource reference can become different from the original reference.
*
* Finally, when sending out requests via a dispatcher such as
* [EMAIL PROTECTED] Context#getClientDispatcher()} or
* [EMAIL PROTECTED] Context#getServerDispatcher()}, if the reference
contains URI
* template variables, those variables are automatically resolved using
the
* request's attributes.
*
* @return The reference of the target resource.
* @see #getOriginalRef()
*/
Changes committed in SVN trunk.
Best regards,
Jerome
-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 21 mai 2008 22:32
À : [email protected]
Objet : Re: Disabling the TunnelService
Hi,
Alex Milowski wrote:
> Would Request.originalRef still have getRemainingPart() returning
> the unmatched portion?
For this I propose to create a new Reference instance for every call
with the baseRef of the updated reference. So they are ever syncronized.
best regards
Stephan