cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Comments on Resource Management in C2
Date Mon, 05 Jun 2000 18:48:04 GMT
Giacomo Pati wrote:
> 
> Hi all
> 
> I thought to write this proposal in response to the discussion of using
> Context.getResource/getRealPath and alike for locating resources in
> Cocoon2. Any comments are very welcome.
> 
> Preliminary notes:
> A lot of ideas come from Stefanos sitemap-working-draft and I wouldn't
> sell'em as my own ideas. I only tried to collect those thoughts together
> in one place for discussion. The current sitemap proposal could be found
> in the C2 CVS
> under xdocs/sitemap-working-draft.xml.
> 
> 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.

To me, it's important to keep all the informations in one place, but at
the same time, I like the idea of having the possibility to override the
default behavior from special needs (like output XML as text/plain to
show the source and not the structure).

So, +1 to <read ... mime-type=""/>, but if not specified we should use
the servlet API to find out... this means, no general mime-type
configurations for Cocoon.
 
> Proposal:
> The Cocoon 2 system should comply to the servlet spec 2.2. As for that
> it should be able to be deployed easily as a war file. The sitemap
> configuration file will be made available to the Cocoon 2 system with a
> definition of
> 
>   <init-param>
>    <param-name>configurations</param-name>
>    <param-value>/cocoon.xconf</param-value>
>   </init-param>
> 
> in the deployment descriptor. The path to the configuration file will be
> relative to the ContextPath of the Cocoon 2 servlet. It should be
> received by Context.getResource("/cocoon.xconf") (using the example
> above). The path to the configuration file becomes the root of all the
> resources mentioned in the sitemap. It is like a initial <mount uri="/*"
> src:file="/Context-Path/Path-To-Sitemap-File/*"/>. 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")

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

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message