Re: [jersey-dev] Sharing/caching object in request scope

[Jan Supol <jan.supol@xxxxxxxxxx>]

Yes, getProperty/setProperty is meant to be used for passing the objects 
between various filters, but I was unsure the ApplicationFactory of 
yours has it available.

If you can live without HttpServletRequest, it is good you removed it. 
In pure Java SE environment you may be fine with Jersey, but there is no 
Servlet at all.

-- Jan

On 22.04.2020 20:15, Martynas Jusevičius wrote:

> I have replaced usages of HttpServletRequest.set/getAttribute() with 
> ContainerRequestContext.set/getProperty() and now it works as expected.
>
> Can you confirm this is the right approach when injecting “expensive” 
> objects?
> If, say, the Factory has to do an HTTP request or some other expensive 
> operation in order to construct the object, which may be injected 
> multiple times within the scope of a single request.
>
> On Wed, 22 Apr 2020 at 16.01, Martynas Jusevičius 
> <martynas@xxxxxxxxxxxxx <mailto:martynas@xxxxxxxxxxxxx>> wrote:
>
>     I cannot explain it. The injection was done like this in all 3
>     classes:
>
>     @Context HttpServletRequest httpServletRequest;
>
>     I've tried reproducing it using JerseyTest, but no luck... I'm getting
>     httpServletRequest as null instead.
>
>     On Wed, Apr 22, 2020 at 2:10 PM Jan Supol <jan.supol@xxxxxxxxxx
>     <mailto:jan.supol@xxxxxxxxxx>> wrote:
>     >
>     > Hi,
>     >
>     > It's odd you have injected the
>     > org.glassfish.jersey.server.ContainerRequest, since it does not
>     inherit
>     > from HttpServletRequest.
>     >
>     > --Jan
>     >
>     > On 20.04.2020 22:45, Martynas Jusevičius wrote:
>     > > Hi,
>     > >
>     > > I'm porting 1.19 code to 2.30.1 which stores objects as
>     > > HttpServletRequest attributes.
>     > >
>     > > This was done to improve performance - if injection providers were
>     > > called multiple times, we didn't want to do expensive processing
>     > > multiple times to get the injectable object. A request filter
>     would
>     > > get the object, store it HttpServletRequest, and providers would
>     > > simply take it from the attribute:
>     > >
>     > > public class ApplicationFactory
>     > > {
>     > >      public Application provide()
>     > >      {
>     > >          return
>     (Application)httpServletRequest.getAttribute(LAPP.Application.getURI());
>     > >      }
>     > > ...
>     > >
>     > > I wonder if there's a better approach?
>     > >
>     > > In any case, this kind of code does not seem to work anymore.
>     So far
>     > > it seems that the request filters get injected one
>     HttpServletRequest
>     > > instance while a factory gets a different one:
>     > > ApplicationFilter:
>     org.glassfish.jersey.server.ContainerRequest@7a11342
>     > > AuthFilter: org.glassfish.jersey.server.ContainerRequest@7a11342
>     > > ApplicationFactory:
>     org.apache.catalina.connector.RequestFacade@3515d98a
>     > >
>     > > ApplicationFilter sets Application object as a HttpServletRequest
>     > > attribute, ApplicationFactory is supposed to retrieve it and
>     inject it
>     > > into AuthFilter.
>     > >
>     > > But if they don't share HttpServletRequest, they don't share the
>     > > attributes and our approach breaks down.
>     > >
>     > > Any suggestions? Thanks.
>     > >
>     > > Martynas
>     > > _______________________________________________
>     > > 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
>     > _______________________________________________
>     > 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
>
>
> _______________________________________________
> jersey-dev mailing list
> jersey-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev