cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [patch] current HEAD branch does not cache anything
Date Thu, 08 Nov 2001 14:58:51 GMT
Sylvain Wallez wrote:
> 
> Torsten Curdt a écrit :
> >
> > I notice the that the current HEAD branch does cache any events
> > or streams no matter which pipeline components are defined in the
> > conf.
> >
> > This seems to happen because of the new sitemap component uses it's
> > own role manager. Anyway as a quick fix I changed the default
> > pipelines from NonCacheable to Cacheable.
> > --
> > Torsten
> 
> Fixed. This required to copy some of the roles in sitemap.roles to
> cocoon.roles.
> 
> This was effectively caused by component management (CM), but not
> exactly as you state : the sitemap always had its own role manager (RM).
> Here is the detailed explanation, for confirmed avaloners :)
> 
> Before componentization, the sitemap received the global "cocoon"
> configuration object and thus was able to identify "stream-pipeline" and
> "event-pipeline" roles against its own RM.
> 
> With the componentization, it receives only the "sitemap" configuration
> object and thus "stream-pipeline" and "event-pipeline" configurations
> are resolved by the main Cocoon CM. This one having no role definition
> for these, we went back to the sitemap CM to instanciate the default
> classes defined in "sitemap.roles".

Good summary.  The ComponentManagers are hierarchical.  That way, each
Sitemap can resolve the Components it needs differently, and default to
the parent Sitemap if the Component is not defined in this component.

> By copying the pipeline roles (and required sitemap components
> selectors) to "cocoon.roles", the main CM knows about them and can
> properly create them when the sitemap CM asks its parent CM.

I thought the pipeline roles were in the main CM.  The reason being
is that there are types of components that are not sitemap specific
which have to access the Pipeline Components.

Therefore, the Pipeline Components have to be in the same CM or a
parent CM.  You can't resolve against a child CM.  This is by design.

> The other working solution is to move pipeline configurations _inside_
> the "sitemap" element in cocoon.xconf, because this one is now the input
> for component definitions of the sitemap CM. But this would have broken
> compatibility with existing cocoon.xconf files.

Another solution that I prefer is to do away with sitemap specific components,
and have ALL components declared in the Cocoon.xconf file.  This has the
added benefit of controlling the allowed components throughout an entire
installation.  That way if you mount user directories in your Sitemap,
you will never be worried about a user installing a trojan component
in the sitemap.

It would be good if the Interpretted Sitemap that is being worked on
would be able to allow component declaration in the Sitemap or deny
component declaration--depending on the site policy.  As it is now,
it is too easy to kill Cocoon:

All you have to do is to mount a sitemap that contains a MemoryEaterGenerator:

class MemoryEaterGenerator implements Generator {
   // ....... skip all other stuff

   void generate() {
      while (true) {
          new int[1000][1000];
      }
   }
}

If this generator is installed and called, the entire VM will die a horrid
death due to OutOfMemmoryErrors, etc.

That is why I advocate more control over the Component declarations
As it is now, there is little to no control over that senario, provided
there is a sitemap rule like this (which is legal):

<map:match pattern="~*/**">
  <map:mount src="file:/home/{1}/web/sitemap.xmap" uri-prefix="{1}" check-reload="yes"/>
</map:match>

By removing the ability to decare components in subsitemaps, it places more
responsibility on the Cocoon Webapp Manager to verify new components, etc.

> 
> Hope this was clear, and thanks for reporting.
> Sylvain.
> 
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


-- 

"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message