On Jan 30, 2012, at 5:22 PM, Marek Posolda wrote:
> Hi,
>
> I think that it's not ideal how WebAppController processes static
> resources like images. I have 2 things to point out:
>
> 1) Today I found (and fixed) a bug that images are first processed by
> PortalRequestHandler, even if they should be processed by
> StaticResourceRequestHandler. Please look at
>
https://issues.jboss.org/browse/GTNPORTAL-2338 for more details. This is
> really not good because HTTP header "Cache-Control: no-cache" is
> returned for every image, and so web browser needs to download images
> for each HTTP request to portal. I fixed it by adding
> StaticResourceRequestHandler before PortalRequestHandler into
> navController configuration, so it should not be the issue anymore.
in StaticResourceRequestHandler the request is dispatched with the servlet API and the
"default" servlet should setup the proper headers.
could you explain me why having the StaticResourceRequestHandler after the
PortalRequestHandler prevents it ?
>
> 2) Second thing is not so bad but a bit more tricky. The piece of code
> in WebAppController:
>
> {code}
> if (!started)
> {
>
> RequestLifeCycle.begin(ExoContainerContext.getCurrentContainer());
> started = true;
> }
> .....
> processed = handler.execute(new ControllerContext(this,
> router, req, res, parameters));
> .....
> if (started)
> {
> RequestLifeCycle.end();
> }
> {code}
>
> This means that we need to start RequestLifeCycle for processing of
> every resource including static resource. And startup of some services
> is quite expensive (like startup of OrganizationService requires startup
> of Hibernate transaction). In other words, currently we are starting
> Hibernate transaction for processing images and other static resources.
>
> It's obvious that some handlers (PortalRequestHandler,
> LegacyRequestHandler and probably some others) really need to start
> RequestLifecycle, but some others like StaticResourceRequestHandler
> don't need it. So how about postponing the RequestLifecycle.begin from
> WebAppController to concrete handlers, which really need it? And use
> some ThreadLocal variable or flag "started" on ControllerContext, so
> that we can track if RequestLifeCycle.begin has been already started
> (can be useful to avoid double-start if some resource needs to be
> processed by more request handlers) ?
please make an abstract method on WebRequestHandler :
protected abstract boolean getRequiresLifeCycle() that the WebAppController can use in
the loop to replace the condition checked by
if (!started)
by the condition
if (!started && handler.getRequiresLifeCycle()) { ... }
(which requires to move this block in the
if (handler != null)
{
}
block
I just want that the whole request lifecycle stuff keeps confined in the WebAppController
class if we can, as the subclass will likely always or never need a RequestLifecyle to be
triggered.
>
> Any other suggestions for this?
>
> Marek
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/gatein-dev