On Aug 18, 2010, at 11:34 AM, Daniel Larsson wrote:
> Logged as https://jersey.dev.java.net/issues/show_bug.cgi?id=572
>
> Attached the small change I made (as a proper diff).
>
Thanks!
Paul.
> On Wed, Aug 18, 2010 at 11:03 AM, Paul Sandoz  
> <Paul.Sandoz_at_oracle.com> wrote:
> Hi Daniel,
>
> I think it is an oversight. I don't think it has any bad side- 
> effects in this regard. Can you log an issue?
>
> One general problem when making re-invocations is that i was not  
> sure what information i should copy from the original request. You  
> notice the set of request headers from the original is not copied.  
> Because we never invoke a resource method for this feature. It is  
> not catastrophic but there could be resources that look at this  
> information in constructors, or sub-resource locators. Note that i  
> also chose an internal HTTP method to utilize as well, this is a bit  
> of a hack so i know when to terminate the lookup process so that  
> resource methods are not invoked (it could be done by other means if  
> we want to retain the same HTTP method as the original request).
>
> I'm not sure the HTTP method should be relevant. Feels weird,  
> without having thought too much about it. This is pretty much an  
> internal GET of the passed along URI, regardless of the original  
> request.
>
>
> Thanks.
>
> On Aug 17, 2010, at 6:04 PM, Daniel Larsson wrote:
>
>> Sorry for following up on myself, but I checked out the 1.3 tag  
>> from jersey svn, and made the following change:
>>
>>         ...
>>         final ContainerRequest _request = new ContainerRequest(app,
>>                 HTTP_METHOD_MATCH_RESOURCE,
>>                 base, u,
>>                 new InBoundHeaders(), null);
>>
>>         _request.setSecurityContext(request); // <--- CHANGE: Set  
>> original request as security context
>>
>>         final ContainerResponse _response = new  
>> ContainerResponse(app,
>>                 _request, null);
>>         return new WebApplicationContext(app,
>>                 _request,
>>                 _response);
>>         ...
>>
>> I can now translate the URI into a resource instance. No idea what  
>> kind of nasty side effects this may cause though...
>>
>> On Tue, Aug 17, 2010 at 4:37 PM, Daniel Larsson <daniel.j.larsson_at_gmail.com 
>> > wrote:
>> Very nice feature, Paul,
>>
>> However, it seems the security context isn't passed along from the  
>> original request to the constructed request inside matchResource  
>> (WebApplicationContext.java:createMatchResourceContext). One of my  
>> subresource locator methods are annotated with @RolesAllowed, and  
>> I'm getting a java.lang.UnsupportedOperation exception thrown when  
>> trying to resolve an URI. The original user has the appropriate  
>> role, and the request URI passes another subresource locator with  
>> the same @RolesAllowed annotation.
>>
>> Are there any other potential problems with copying the security  
>> context along, or is this just an oversight?
>>
>>
>> On Wed, Jun 2, 2010 at 4:25 PM, Paul Sandoz <Paul.Sandoz_at_sun.com>  
>> wrote:
>> Hi,
>>
>> I have fixed issue 436:
>>
>> https://jersey.dev.java.net/issues/show_bug.cgi?id=436
>>
>> So it is now possible to match a URI to a resource. See end of  
>> email for JavaDoc.
>>
>> There are some possible side-effects depending on how your  
>> application is constructed. Matching will share the scope of the  
>> HTTP request. Resources will be constructed if references are not  
>> already in scope. Sub-resource locator methods may be invoked.
>>
>> Paul.
>>
>> /**
>>  * The resource context provides access to instances of resource  
>> classes.
>>  * <p>
>>  * This interface can be injected using the {_at_link Context}  
>> annotation.
>>  * <p>
>>  * The resource context can be utilized when instances of managed  
>> resource
>>  * classes are to be returned by sub-resource locator methods. Such  
>> instances
>>  * will be injected and managed within the declared scope just like  
>> instances
>>  * of root resource classes.
>>  * <p>
>>  * The resource context can be utilized when matching of URIs are
>>  * required, for example when validating URIs sent in a request  
>> entity.
>>  * Note that application functionality may be affected as the  
>> matching
>>  * process will result in the construction or sharing of previously  
>> constructed
>>  * resource classes that are in scope of the HTTP request, and the  
>> invocation of
>>  * matching sub-resource locator methods. No resource methods wll  
>> be invoked.
>>  *
>>  * @author <a href="mailto:martin.grotzke_at_freiheit.com">Martin  
>> Grotzke</a>
>>  * @author Paul.Sandoz_at_Sun.Com
>>  */
>> public interface ResourceContext {
>>
>>    /**
>>     * Match a URI to URI information.
>>     * <p>
>>     * If the URI is relative then the base URI of the application  
>> will be
>>     * used to resolve the relative URI to an absolute URI.
>>     * If the URI is absolute then it must be relative to the base  
>> URI of the
>>     * application.
>>     *
>>     * @param u the URI.
>>     * @return the URI information, otherwise null if the URI cannot  
>> be matched.
>>     * @throws ContainerException if there is an error when matching.
>>     */
>>    ExtendedUriInfo matchUriInfo(URI u) throws ContainerException;
>>
>>    /**
>>     * Match a URI to a resource instance.
>>     * <p>
>>     * If the URI is relative then the base URI of the application  
>> will be
>>     * used to resolve the relative URI to an absolute URI.
>>     * If the URI is absolute then it must be relative to the base  
>> URI of the
>>     * application.
>>     *
>>     * @param u the URI.
>>     * @return the resource instance, otherwise null if the URI  
>> cannot be
>>     *         matched.
>>     * @throws ContainerException if there is an error when matching.
>>     */
>>    Object matchResource(URI u) throws ContainerException;
>>
>>    /**
>>     * Match a URI to a resource instance.
>>     * <p>
>>     * If the URI is relative then the base URI of the application  
>> will be
>>     * used to resolve the relative URI to an absolute URI.
>>     * If the URI is absolute then it must be relative to the base  
>> URI of the
>>     * application.
>>     *
>>     * @param <T> the type of the resource.
>>     * @param u the URI.
>>     * @param c the resource class.
>>     * @return the resource instance, otherwise null if the URI  
>> cannot be
>>     *         matched.
>>     * @throws ContainerException if there is an error when matching.
>>     * @throws ClassCastException if the resource instance cannot be  
>> cast to
>>     *         <code>c</code>.
>>     */
>>    <T> T matchResource(URI u, Class<T> c) throws  
>> ContainerException, ClassCastException;
>>
>>    /**
>>     * Provides an instance of the given resource class.
>>     *
>>     * @param <T> the type of the resource class
>>     * @param c the resource class
>>     * @return an instance if it could be resolved, otherwise null.
>>     * @throws com.sun.jersey.api.container.ContainerException if  
>> the resource
>>     *         class cannot be found.
>>     */
>>    <T> T getResource(Class<T> c) throws ContainerException;
>> }
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>
>