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

Hmm I need to try it out. Thanks again.

On Mon, 19 Oct 2020 at 19.43, Jan Supol <jan.supol@xxxxxxxxxx> wrote:
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$
_______________________________________________
jersey-dev mailing list
jersey-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev

Back to the top