Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jersey-dev] Sharing/caching object in request scope

Thanks, good to know.

I inject ContainerRequestContext the same way as with HttpServletRequest:

public class ApplicationFactory implements Factory<Application>
{

    @Context ContainerRequestContext crc;


and it seems to work :) Registered like that:

register(new AbstractBinder()
{
    @Override
    protected void configure()
    {
        bindFactory(ApplicationFactory.class).to(Application.class).
        proxy(true).proxyForSameScope(false).
        in(RequestScoped.class);
    }
});

On Wed, Apr 22, 2020 at 9:04 PM Jan Supol <jan.supol@xxxxxxxxxx> wrote:
>
> 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
> _______________________________________________
> 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