cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [patch] current HEAD branch does not cache anything
Date Thu, 08 Nov 2001 17:09:09 GMT

Berin Loritsch a écrit :
> 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.

Ah, forgot about that ! I found SitemapSource. Is it the only one ?

> 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.

We have to distinguish here between components specific to the engine
and specific to a given sitemap.xmap. An engine for a particular xxxmap
language may require components that aren't declared in the main CM
(e.g. MatcherSelector which is of no use outside the sitemap). These
engine components should be configurable in the main cocoon.xconf,
inside the <sitemap> element.

> 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.

Poor VM, what a terrible end ;)

You'll also have to disable XSP/JSP/Script generators which allow the
above more easily than a MemoryEaterGenerator that has to be put in the

And what about infinite recursions and Java extensions in XSL ?

> 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.

A new attribute to <map:mount> could control this. But we'll also have
to control which components of a sitemap are inherited by subsitemaps
(see the XSP/JSP/Script point above). SitemapSelector could handle a
special "inherit" attribute on component definitions.

But let's keep that for later and finish the reimplementation of the
current language :)


Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

View raw message