On Fri, 1 Mar 2002, Ugo Cei wrote:
> giacomo wrote:
>
> >>>For 1: The Deploying Engine (Cocoon.java today) needs to directly use
> >>>some kind of URI-Matcher to mount the sub-sitemap of an Application. It
> >>>could done by dynamically add those mounts to the root sitemap when
> >>>using the interpreted sitemap treeprocessor. there will also be a method
> >>>of dynamically specify the deployment (i.e. looking into the webapps
> >>>context directory for newly added Cocoon Application Component archives
> >>>or the technologically more advanced 'net deployment' procedure).
> >>>
> >>Isn't this what the "mount" mechanism is about?
> >>
> >
> > I don't understand what you are asking for.
>
> I am asking: doesn't the existing mount mechanism already address your
> point?
No and yes. The mount mechanism is an element of the sitemap syntax.
What we need is something like a "deploymet mechanism" which is able to
dynamically generate
<map:match pattern="URI-a-newly-deployed-cac-will-be-mounted">
<map:mount ..../>
</map:match>
into a root-sitemap (or even a component above that) to enable
deployment of new cocoon application components on the fly and over the
net.
> > If you use Apache virtual hosts you should also use Apache
> > mod_rewrite/mod_proxy for that and your scenario is easy possible with
> > only one Cocoon instance.
>
> I am using simple redirects. Probably I should be using mod_rewrite, but
> having fought with it in the past, I am a little intimidated by its
> complexity :)
We have the following snipped in the httpd.conf for each virt host:
RewriteRule ^/theurl/(.*)$ http://tomcat:8080/cocoon/theurl/$1 [P,L]
ProxyPassReverse /theurl/ http://tomcat:8080/cocoon/admin/
this works as long as you are not doing load balancing stuff.
>
> > You simply need a test environment which reflects your production
> > environment.
>
> I do have a test environment, of course, but should a new cocoon.jar
> breaks all the existing applications,
Depends on the version ;) but we cannot garantee all versions will be
backward compatible but we will give strong attention on it as long as
possible.
> I would have to chase down the
> bugs and fix them on the test env, before going production. Like they
> say: if it ain't broke, don't fix it ;).
In fact you should do that with every new software you base your
application upon (even new versions of your preferred operating system).
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
