Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jersey-dev] Internal request with new UriInfo 
In Jersey, you can have something like:

public static class SubResource {
    private UriInfo uriInfo;
    public SubResource(@Context UriInfo info) {
        this.uriInfo = info;
    }

    @GET public String get() {
        return uriInfo.getAbsolutePath().toASCIIString();
    }
}

@Path("/")
public static class Resource {
    @Path("/sub")
    public Class<SubResource> getSub() {
        return SubResource.class;
    }
}

Would that help?

-- Jan

On 19.10.2020 18:29, Martynas Jusevičius wrote:

Thanks. Yes I instantiate Resource on my own.
It’s because in 2.x there does not seem to be any mechanism to lookup resource by URI? While in 1.x there was ResourceContext.matchResource(): https://github.com/eclipse-ee4j/jersey/issues/2444 <https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jersey/issues/2444__;!!GqivPVa7Brio!MCnZgqZ74rdUzIsS0up_Y_xaZgn3GmUi5SyIzdbytctEyUnsxO8ofcX3OkXS7ljX$> 
The issue is now 7 years old - how come it’s not implemented in 2.x?

So I need my own UriInfo implementation? Or can I reuse one somehow?
On Mon, 19 Oct 2020 at 18.16, Jan Supol <jan.supol@xxxxxxxxxx <mailto:jan.supol@xxxxxxxxxx>> wrote: 

    So you instantiate the Resource class on your own? I am afraid
    that you
    need to instantiate the correct UriInfo on your own, too.

    For the sub-resource case, JAX-RS Spec. Section 3.2 says: Objects
    returned by sub-resource locators (see Section 3.4.1) are expected
    to be
    initialized by their creator.

    Thanks,

    Jan

    On 19.10.2020 17:23, Martynas Jusevičius wrote:
    > Hi Jan,
    >
    > OK let me try to explain.
    >
    > Lets say Resource is constructed with UriInfo where
    >
    requestUri=https://urldefense.com/v3/__https://localhost/some/path__;!!GqivPVa7Brio!MS_K1k3MXtVAEn9RUvumFbiAbJ9aUw7G7CZOzleix_3dgXbCtfyJaMIXnN-hW5Em$
    >
    > But then I want to create another Resource and execute its
    methods as
    > if it was a completely new request, e.g.
    >
    requestUri=https://urldefense.com/v3/__https://localhost/another/path__;!!GqivPVa7Brio!MS_K1k3MXtVAEn9RUvumFbiAbJ9aUw7G7CZOzleix_3dgXbCtfyJaMIXnLGxbHlH$
    >
    > So the same UriInfo does not apply. Nor is this a sub-resource case.
    >
    > On Mon, Oct 19, 2020 at 5:16 PM Jan Supol <jan.supol@xxxxxxxxxx
    <mailto:jan.supol@xxxxxxxxxx>> wrote:
    >> Hi,
    >>
    >> I am not sure I follow. Unless the resource is specified as a
    singleton
    >> (either by using the @Singleton annotation) or by
    >> Application.getSingletons(), the Resource classes are
    instantiated per
    >> request, so you should have the proper UriInfo.
    >>
    >> Note that you may also inject @Context UriInfo as a post method
    argument.
    >>
    >> Thanks,
    >>
    >> Jan
    >>
    >> On 19.10.2020 16:34, Martynas Jusevičius wrote:
    >>> Hi,
    >>>
    >>> say I have a resource class with a UriInfo constructor and a
    @POST method.
    >>>
    >>> How do I call post() on a new Resource with a new UriInfo with a
    >>> different requestUri?
    >>>
    >>> public class Resource
    >>> {
    >>>
    >>>       @Inject
    >>>       public Resource(UriInfo uriInfo)
    >>>       {
    >>>           ...
    >>>       }
    >>>
    >>>       @POST
    >>>       public post(Model model)
    >>>       {
    >>>           // use getUriInfo() here
    >>>           ...
    >>>           // forward POST -- how to construct UriInfo with an
    arbitrary
    >>> requestUri?
    >>>           new Resource(???).post(newModel);
    >>>           ...
    >>>       }
    >>>
    >>> }
    >>>
    >>>
    >>> Martynas
    >>> _______________________________________________
    >>> jersey-dev mailing list
    >>> jersey-dev@xxxxxxxxxxx <mailto:jersey-dev@xxxxxxxxxxx>
    >>> To unsubscribe from this list, visit
    https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jersey-dev__;!!GqivPVa7Brio!Ll-NKpZ9Yae48eNnU-pgrlG-iFyaoR8gSuX7AC88OCuRiyVdKTD6GuxH4cVJ3nxa$
    >> _______________________________________________
    >> jersey-dev mailing list
    >> jersey-dev@xxxxxxxxxxx <mailto:jersey-dev@xxxxxxxxxxx>
    >> To unsubscribe from this list, visit
    https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jersey-dev__;!!GqivPVa7Brio!MS_K1k3MXtVAEn9RUvumFbiAbJ9aUw7G7CZOzleix_3dgXbCtfyJaMIXnPbCzE8w$
    > _______________________________________________
    > jersey-dev mailing list
    > jersey-dev@xxxxxxxxxxx <mailto:jersey-dev@xxxxxxxxxxx>
    > To unsubscribe from this list, visit
    https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jersey-dev__;!!GqivPVa7Brio!MS_K1k3MXtVAEn9RUvumFbiAbJ9aUw7G7CZOzleix_3dgXbCtfyJaMIXnPbCzE8w$
    _______________________________________________
    jersey-dev mailing list
    jersey-dev@xxxxxxxxxxx <mailto:jersey-dev@xxxxxxxxxxx>
    To unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jersey-dev
    <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jersey-dev__;!!GqivPVa7Brio!MCnZgqZ74rdUzIsS0up_Y_xaZgn3GmUi5SyIzdbytctEyUnsxO8ofcX3OjKjUKYW$>


_______________________________________________
jersey-dev mailing list
jersey-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jersey-dev__;!!GqivPVa7Brio!MCnZgqZ74rdUzIsS0up_Y_xaZgn3GmUi5SyIzdbytctEyUnsxO8ofcX3OjKjUKYW$

Back to the top