You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Leigh Dodds <ld...@ingenta.com> on 2002/08/05 17:59:31 UTC
Virtual Hosts/Mounts (was RE: Newbie questions)
Hi,
>>Michele Neylon
>> 1. I would like to be able to offer it to a couple of virtual hosts on
>> my server and was wondering what was the best method.
>Vadim Gritsenko
> There are couple of ways:
>
> 1. Have single Cocoon instance serving requests to all virtual hosts.
> Use host matchers/selectors to select resource to serve.
>
> 2. Have single Cocoon instance with sub-sitemap for every host. Put
> apache in front of Cocoon with rewrite module.
>
> Sorry, don't have configuration examples - didn't had need for multiple
> hosts.
Here's a document that I've been working on which should help you
ought with how to do sub-sitemaps. The additional configuration steps
will be to use the Host selector -- I believe there's an example of
this already in the Cocoon docs.
If anyone has any feedback on the following please let me know, it
was quickly drafted on a train journey so hasn't been thoroughly
proof-read. (Also forgive the scraps of Wiki markup, it's extracted
from my personal wiki site, and the cross-posting -- hoping
for sanity checks from the developers also)
btw, was a separate mailing list for Cocoon documentation ever
created? IIRC there as a proposal to do so recently?
-------------------------------------------------------------------
!!Understanding Cocoon Mounts
!The Root Sitemap
The default Cocoon web application reads the sitemap.xmap file
in the $webapp_home directory for instructions about how to
process incoming requests.
This means that if the Cocoon web application is installed in
$TOMCAT_HOME/cocoon
Then all requests with the base URL of:
http://localhost:8080/cocoon/...
will be serviced by asking this sitemap for a suitable pipeline.
The matchers defined in that sitemap can allow for arbitrary
amounts of additional path information, but it is this initial
root 'mount point' that determines basic request processing.
So for example a pipeline with:
<map:match pattern="my/long/url/path/*.html"/>
Will match:
http://localhost:8080/cocoon/my/long/url/path/doc.html
So while the Cocoon web application is mounted at /cocoon
in the servlet container. The pipelines are mounted from
/cocoon/
However placing all pipeline and component configurations in
a single sitemap can be unwieldy, it's better to partition up the
web application. This can be done by creating additional sitemaps
which contain related functionality. E.g. all form processing
relating to registration, searching, etc.
!Mounting Sub-Sitemaps
Partitioning a sitemap in this way involves use of the <map:mount/>
element. This indicates that a second sitemap should be processed,
and includes the location of that sitemap.
E.g.
<map:match pattern="my/long/url/path/*.html">
<map:mount src="my/long/dir/structure/sitemap.xmap"/>
</map:match>
Will cause the sitemap in $TOMCAT_HOME/cocoon/my/long/dir/structure/
to be queried for pipelines that can process this request. The second
sitemap is referred to as a ''sub-sitemap''. It inherits all component
declarations from it's parent, so there is no need for them to be redeclared.
However the empty container elements (e.g. <map:generators/>) must
still be provided for the sitemap to be parsed correctly. These elements
can indicate the name of the default component as usual.
However, any matchers in this sitemap would still have to
use the full request path for their match to work as expected
I couldn't do:
<map:match pattern="*.html"/>
As this actually matches
http://localhost:8080/cocoon/*.html.
To enable additional unwanted path information to be ignored,
we need to add an additional uri-prefix attribute to the <map:mount>
element, as follows:
<map:match pattern="my/long/url/path/*.html">
<map:mount src="my/long/dir/structure/sitemap.xmap"
uri-prefix="my/long/url/path/"/>
</map:match>
Which means that a matcher with the pattern *.html in
$TOMCAT_HOME/cocoon/my/long/dir/structure/sitemap.xmap will
match:
http://localhost:8080/cocoon/my/long/url/path/doc.html
but not
http://localhost:8080/cocoon/*.html
The other additional parameter to the mount element is check-reload
which can have the value yes or no. This indicates whether the mounted
sitemap should be reloaded if it changes.
!Location Independence
Note also that the sitemap location is completely separate to the
path info in the URL. I can maintain my sitemap.xmap file anywhere
on the file system that can be read by Cocoon. As is usual in Cocoon
pipelines, it's the matching components that dictate how a request
path is tied to a sequence of processing.
!Partitioning Options
The above example have assumed that the Cocoon application has
been partitioned into a collection of sub-sitemaps according to
the request path.
However it's perfectly acceptable to partition an application based
on any criteria. In fact any selector or matcher component can be
used as the means to delegate processing to a sub-sitemap.
So, for example I could use the HostSelector to select an alternate
sitemap based on the host name used in the request. Or I could
use the BrowserSelector to separate processing based on user-agents.
The ParameterMatcher could select sub-sitemaps based on request
parameters, and so on.
!Auto-Mounting
Extending this facility to its natural conclusion, we can use the
power of the WildcardMatcher component and the <map:mount/>
element to create an 'auto-mount' feature that will allow sitemaps
underneath a given directory structure to be automatically loaded
by Cocoon.
We can achieve this with the following:
<map:match pattern="auto/*/**">
<map:mount uri-prefix="auto/{1} src="auto/{1}"/>
</map:match>
This uses wildcard, and sitemap parameters to automatically match
a base request url, in this case:
http://localhost:8080/cocoon/auto/...
The first path element is matched and stored in {1}. This is
then used as the name of the directory from which to load
the sitemap. In this case a request for
http://localhost:8080/cocoon/auto/foo/bar.html
Will cause the sitemap in:
$TOMCAT_HOME/cocoon/auto/foo
to be loaded and the prefix /auto/foo/ automatically
stripped.
Auto-mounting can use the flexibility required earlier to auto-mount
sitemaps based on request parameters, and a whole range of
other options. However doing so using a correlated request-path
and directory structure makes the functionality more intuitive.
!Auto-Mounting and Users
Auto-mounting is a good way to allow multiple users to share a
Cocoon instance. Their public_html directories can be symbolically
linked to the 'auto' directory, and they can then operated independently
of one another.
!Sub-Sitemaps and Components
Since Cocoon 2.0.X it has been possible to include additional cocoon.xconf
files in sub-directories. These will be automatically processed by Cocoon,
allowing the declaration and use of additional components, JDBC connections,
etc. Again this enables multiple users to more easily share a single
Cocoon instance.
It also provides a fairly clean way to package a Cocoon application for
sharing with others: create a directory complete with sitemap.xmap, cocoon.xconf
if required, and all additional supporting files. This package can then be passed
on to others who can install it by simply unpacking it into their file-system
and adding the appropriate mount elements into their root sitemap (or one of
it's sub-sitemaps).
In this way, a service provider can also choose to host Cocoon applications
for others.
-------------------------------------------------------------------
Cheers,
L.
--
Leigh Dodds
http://weblogs.userland.com/eclectic
"Pluralitas non est ponenda sine necessitate" -- William of Ockham
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
How to translate?
Posted by Albert Cervera Areny <in...@sedifa.com>.
Hi,
I've been looking at the i18n transformer in the documentation web page,
however I can't see how it works in production. I got the idea that it
works let's say like gettext as you mark which parts you want to translate
and generate a file with those messages.... if so... how can I do that
easily? I've been looking throw those convert and merge xsl files but they
don't seem to generate it. I was able to create a file to translate into
one new language from the simple_dict.xml example but how may I create it
from scratch?
These two files, messages and dictionary, are the ones that make me not to
understand the hole process.
Could someone clarify those aspects or point me to a better resource?
Thanks in advance!
--
Albert Cervera Areny
Dept. Informàtica Sedifa, S.L.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Virtual Hosts/Mounts (was RE: Newbie questions)
Posted by Leigh Dodds <ld...@ingenta.com>.
> I´ve got a question concering 'multiple users sharing a single cocoon
> instance'...
>
> We can seperate the workspaces and sitemaps of all users with a subsitemap
> mounting.... but how can i keep the libs and classes seperated (without
> enforcing a pre-package name like our.customer.classes.*) ?
> So... is there a way to say to cocoon (or to tomcat)... "there, there and
> there are libs/classes you have to search for at each reload of the
> webapp"... (e.g. one "classes" and one "lib" dir for each cocoon user)
I don't believe there is (although I'm not 100% sure -- I'm still investigating
this area), so I should qualify my statements about multiple users sharing
a single instance to say that they're also sharing the same versions of
the same classes.
So this configuration is probably of most interest to people putting together
applications (i.e. sitemap configuration, XSLT transforms, etc) rather than
application development.
I've amended my article, which is now in the CocoDocoWiki:
http://outerthought.net/wiki/Wiki.jsp?page=UnderstandingCocoonMounts
Cheers,
L.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: content management systems?
Posted by Michael Wechner <mi...@wyona.org>.
peter riegersperger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi all!
>
> i'm looking for a content management system that works with/is based
> on cocoon. so far, i've found wyona (www.wyona.org). the
> project-links page of cocoon
> (http://xml.apache.org/cocoon/link/projects.html) didn't shed much
> light on this, and a search in the mailing list archive just brought
> up wyona again.
>
> is there anything else out there that i should look at?
>
> i know that the term 'content management system' is very vague, but
> right now, i'm in a research phase, and any pointer to a system that
> allows to create, change, delete and structure content on a
> cocoon-based website is valuable to me.
>
> hints and comments (even some experience to share?) would be great.
> if there's interest, i can sum up my findings and report back.
Take a look at DBPrism, WebEditor, CocoBlog.
More Cocoon related Application are summarized at
http://xml.apache.org/cocoon/link/projects.html
More general info on Open Source Content Management can be found
at http://www.oscom.org and http://www.cmsinfo.org
All the best
Michael
>
> thanks,
>
> rick
>
> |-
> | peter riegersperger <ri...@subnet.at>
> |-
> | subnet
> | platform for media art and experimental technologies
> |-
> | http://www.subnet.at/
> |-
> | muehlbacherhofweg 5 // 5020 salzburg // austria
> |-
> | fon/fax +43/662/842 897
> |-
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
> Comment: public key available at http://home.subnet.at/rick/pgp/
>
> iQA/AwUBPU/WuiDD9/SWDsvSEQIwtwCgshki26D8iZqyr5T+LJMbd8YigOMAn3QB
> NhhfzVx7yRQs7tbpI6zBqA5n
> =kwza
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
content management systems?
Posted by peter riegersperger <ri...@subnet.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi all!
i'm looking for a content management system that works with/is based
on cocoon. so far, i've found wyona (www.wyona.org). the
project-links page of cocoon
(http://xml.apache.org/cocoon/link/projects.html) didn't shed much
light on this, and a search in the mailing list archive just brought
up wyona again.
is there anything else out there that i should look at?
i know that the term 'content management system' is very vague, but
right now, i'm in a research phase, and any pointer to a system that
allows to create, change, delete and structure content on a
cocoon-based website is valuable to me.
hints and comments (even some experience to share?) would be great.
if there's interest, i can sum up my findings and report back.
thanks,
rick
|-
| peter riegersperger <ri...@subnet.at>
|-
| subnet
| platform for media art and experimental technologies
|-
| http://www.subnet.at/
|-
| muehlbacherhofweg 5 // 5020 salzburg // austria
|-
| fon/fax +43/662/842 897
|-
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: public key available at http://home.subnet.at/rick/pgp/
iQA/AwUBPU/WuiDD9/SWDsvSEQIwtwCgshki26D8iZqyr5T+LJMbd8YigOMAn3QB
NhhfzVx7yRQs7tbpI6zBqA5n
=kwza
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Virtual Hosts/Mounts (was RE: Newbie questions)
Posted by Michael Mangeng <mi...@ideefix.net>.
Hi
I´ve got a question concering 'multiple users sharing a single cocoon
instance'...
We can seperate the workspaces and sitemaps of all users with a subsitemap
mounting.... but how can i keep the libs and classes seperated (without
enforcing a pre-package name like our.customer.classes.*) ?
So... is there a way to say to cocoon (or to tomcat)... "there, there and
there are libs/classes you have to search for at each reload of the
webapp"... (e.g. one "classes" and one "lib" dir for each cocoon user)
greetings
mike
----- Original Message -----
From: "Leszek Gawron" <ou...@kompuart.pl>
To: <co...@xml.apache.org>
Sent: Tuesday, August 06, 2002 2:56 PM
Subject: Re: Virtual Hosts/Mounts (was RE: Newbie questions)
> >
> > Since Cocoon 2.0.X it has been possible to include additional
cocoon.xconf
> > files in sub-directories. These will be automatically processed by
Cocoon,
> > allowing the declaration and use of additional components, JDBC
connections,
> > etc. Again this enables multiple users to more easily share a single
> > Cocoon instance.
> What MUST be included in such cocoon.xconf file ?
> Is it enough:
>
> <cocoon version="2.0">
> <datasources>
> <jdbc name="foo><!-- datasource definition here --></jdbc>
> </datasources>
> </cocoon>
>
> and that is all ? Furthermore: Is it possible to omit the jdbc driver
preload
> entry in web-inf/web.xml and put it somewhere else so I do not need to
enter
> it once again when I reinstall cocoon?
> ouzo
> --
> __
> | / \ | Leszek Gawron // \\
> \_\\ //_/ ouzo@vip.net.pl _\\()//_
> .'/()\'. Phone: +48(600)341118 / // \\ \
> \\ // recursive: adj; see recursive | \__/ |
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Virtual Hosts/Mounts (was RE: Newbie questions)
Posted by Leszek Gawron <ou...@kompuart.pl>.
>
> Since Cocoon 2.0.X it has been possible to include additional cocoon.xconf
> files in sub-directories. These will be automatically processed by Cocoon,
> allowing the declaration and use of additional components, JDBC connections,
> etc. Again this enables multiple users to more easily share a single
> Cocoon instance.
What MUST be included in such cocoon.xconf file ?
Is it enough:
<cocoon version="2.0">
<datasources>
<jdbc name="foo><!-- datasource definition here --></jdbc>
</datasources>
</cocoon>
and that is all ? Furthermore: Is it possible to omit the jdbc driver preload
entry in web-inf/web.xml and put it somewhere else so I do not need to enter
it once again when I reinstall cocoon?
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@vip.net.pl _\\()//_
.'/()\'. Phone: +48(600)341118 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>