[
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