You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Thorsten Scherler <th...@juntadeandalucia.es> on 2009/03/02 09:22:37 UTC
Block resources and proxying
Hi all,
we have developed a block to add a new section to our page.
http://juntadeandalucia.es/28f2009/index.html
This section is independent from the rest of the portal. Since we are
using Apache httpd to serve all images, css and js we had to implement a
rewrite rule to the work dir of tomcat.
Something like:
RewriteRule "^/themes/images/28f2009/(.*)\.(gif|jpg|jpeg|ico)$"
"$PORTAL/work/blocks/conectorEspeciales/themer/themes/common/images/$1.$2" [L]
We cannot do this anymore out of constraints from our production
department and are looking into ways to link to the resources in the
block lib not pointing into the work dir of tomcat.
How do other solve this issue?
Is there a a way to tell the block to deploy to another path then the
work dir of tomcat?
I see different solutions:
1) Link into the jar via httpd directly (not sure whether httpd can do
that and whether that brings any drawbacks).
2) Use block deployer from cocoon (if exists) that extract the jar to
certain configurable path.
3) Tell production that they need to unzip the block.jar into a certain
path themselves.
Any ideas and thoughts welcome.
TIA
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
Open Source Java <consulting, training and solutions>
Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)
Re: Block resources and proxying
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Mon, 2009-03-02 at 14:41 +0100, Andreas Hartmann wrote:
> Grzegorz Kossakowski schrieb:
> > Reinhard Pötz pisze:
> >> We usually use httpd mod_cache for static resources in our projects but
> >> some sysadmins don't like it (don't ask me why).
> >>
> >
> > Too bad, I would be very curious to hear why it's a bad idea.
> >
> > I can say why configuring httpd to access some resources directly is a bad idea. It's simply mixing of layers that
> > sooner or later will introduce some headaches (think of SSF for e.g.) or will limit application developer in artificial way.
>
> I totally agree. Using mod_cache instead of directly exposing files to
> HTTPD already saved me a lot of deployment hassle.
Thanks all for your replies!
Will now present the following solutions to our production:
1) Use mod_cache for all static resources and read it once from cocoon
2) Write a listener that uses DeploymentUtil.deployBlockArtifacts(...)
on a path they want
3) Let them extract the jar.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
Open Source Java <consulting, training and solutions>
Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)
Re: Block resources and proxying
Posted by Andreas Hartmann <an...@apache.org>.
Grzegorz Kossakowski schrieb:
> Reinhard Pötz pisze:
>> We usually use httpd mod_cache for static resources in our projects but
>> some sysadmins don't like it (don't ask me why).
>>
>
> Too bad, I would be very curious to hear why it's a bad idea.
>
> I can say why configuring httpd to access some resources directly is a bad idea. It's simply mixing of layers that
> sooner or later will introduce some headaches (think of SSF for e.g.) or will limit application developer in artificial way.
I totally agree. Using mod_cache instead of directly exposing files to
HTTPD already saved me a lot of deployment hassle.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: Block resources and proxying
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
> We usually use httpd mod_cache for static resources in our projects but
> some sysadmins don't like it (don't ask me why).
>
Too bad, I would be very curious to hear why it's a bad idea.
I can say why configuring httpd to access some resources directly is a bad idea. It's simply mixing of layers that
sooner or later will introduce some headaches (think of SSF for e.g.) or will limit application developer in artificial way.
--
Best regards,
Grzegorz Kossakowski
Re: Block resources and proxying
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>>> Any ideas and thoughts welcome.
>> Another idea is to use mod_cache of httpd.
>
> +1 for this one.
>
> Cocoon by default sets all caching-related HTTP headers for static
> resources. Thus httpd should just act as a simple proxy in front of
> Cocoon instance.
We usually use httpd mod_cache for static resources in our projects but
some sysadmins don't like it (don't ask me why).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: Block resources and proxying
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
>
>> Any ideas and thoughts welcome.
>
> Another idea is to use mod_cache of httpd.
+1 for this one.
Cocoon by default sets all caching-related HTTP headers for static resources. Thus httpd should just act as a simple
proxy in front of Cocoon instance.
--
Best regards,
Grzegorz Kossakowski
Re: Block resources and proxying
Posted by Reinhard Pötz <re...@apache.org>.
Thorsten Scherler wrote:
> Hi all,
>
> we have developed a block to add a new section to our page.
>
> http://juntadeandalucia.es/28f2009/index.html
>
> This section is independent from the rest of the portal. Since we are
> using Apache httpd to serve all images, css and js we had to implement a
> rewrite rule to the work dir of tomcat.
>
> Something like:
> RewriteRule "^/themes/images/28f2009/(.*)\.(gif|jpg|jpeg|ico)$"
> "$PORTAL/work/blocks/conectorEspeciales/themer/themes/common/images/$1.$2" [L]
>
> We cannot do this anymore out of constraints from our production
> department and are looking into ways to link to the resources in the
> block lib not pointing into the work dir of tomcat.
>
> How do other solve this issue?
>
> Is there a a way to tell the block to deploy to another path then the
> work dir of tomcat?
>
> I see different solutions:
>
> 1) Link into the jar via httpd directly (not sure whether httpd can do
> that and whether that brings any drawbacks).
> 2) Use block deployer from cocoon (if exists) that extract the jar to
> certain configurable path.
Have a look at the cocoon-block-deployment subproject. It contains a
servlet listener (BlockDeploymentServletContextListener) that extracts
all blocks into the work directory.
You could write an additional listener for you purpose which should be
fairly easy because DeploymentUtil.deployBlockArtifacts(File f) does
everything that you need.
The only problem that we would have to solve is how we make this
configurable. We can't use the Spring configurator for that purpose
because it is not initialized when the listener is called.
After writing this I think that you could also write an initializable
Spring bean that calls DeploymentUtil.deployBlockArtifacts(File f) which
would solve the configuration problem.
> 3) Tell production that they need to unzip the block.jar into a certain
> path themselves.
Of course possible but clumsy IMO.
> Any ideas and thoughts welcome.
Another idea is to use mod_cache of httpd.
HTH
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________