cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Comments on Resource Management in C2
Date Mon, 05 Jun 2000 19:35:37 GMT
Stefano Mazzocchi wrote:
> Giacomo Pati wrote:
> >
> > I will also propose to add a attribute "mime-type" to the <read> tag to
> > make it a real binary generator/serializer to serve _any_ data directly
> > to the client browser from a resource. Or make it a reader component
> > which can be
> > parametrized with a reference to a mime-type definition file (somthing
> > like Tomcats main web.xml file).
> can we use getMimeType() from the Servlet API directly and let Tomcat
> handle it? it could be possible, given a better AJP protocol, to go back
> to Apache and let him handle the MIME type.

Right, I've overlooked that, sorry. So we should have access to the
ServletContext in the <read> tag.

> > The name of the
> > sitemap (cocoon.xconf in this example) will be used for all sitemaps
> > that gets mounted by the <mount> tag.
> what about
>  <mount uri="/"
> src:file="/Context-Path/Path-to-Sitemap-File/sitemap.xml"/>


> I think we should remove the use of matching from the "mount" element
> since this is just like partition mounting for FS. It's implicitly
> matching all the subrequests and with this you can specify how you name
> the sitemap. (if the file is not present, I say we default to
> "cocoon.sitemap")

You mean hard code it to String sitemapName = "cocoon.sitemap"? What
against using the name of the "root" sitemap?

> > The <mount> tag describes a path to a "cascading" site in his "uri"
> > attribute and thus is _not_ rooted at the path of the sitemap containing
> > the <mount> tag (except if the "local" loader is used, see next
> > paragraph). If there is a sitemap found at the path the "uri" attribute
> > of the <mount> tag points to, it inherits all definitions (?or should we
> > only inherit components?) of the sitemap the <mount> tag was in.
> > Consider this as a recursive process.
> Right.

Should we inherit all definitions or only the components?

> > As mentioned in the sitemap-working-draft.xml a concept of loaders for
> > different protocols (src:jar, src:file:, src:class) will be introduced
> > to load resources needed by the sitemap components. The "local" loader
> > is initialized with the root path to the sitemap it belongs to. All
> > other loaders have their own method to localize the resources they will
> > deliver.
> >
> > Thus, if you look at these note it is not relevant (and I think not even
> > recomended) to use Context.getResource() in the loaders because it could
> > only be used for resources the "local" loader of the "root" sitemap will
> > deliver.
> You are right, I overlooked that.
> But for the "local" loader, we should use getResource() anyway.

Where does a "local" loader of a cascaded sitemap points to? Into the
ContextPath or into the mounted path?


PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7           
CH-8166 Niederweningen                    Web:

View raw message