Re: [gatein-dev] Issues with static resources
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
Any other suggestions for this?
Marek
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev