cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <>
Subject Re: [design] Cocoon Blocks 1.2 - Glorified Mount
Date Sat, 09 Nov 2002 05:20:33 GMT

Along the way of following this discussion, I came up with the following

First of all, this is a good page:
It is the kind of HOWTO doc we need in the main docs.

                -====[  Extending <map:mount/>  ]====-

| Part I - the "jar" protocol  |

Let's set the base line with the following popular automount example:

<map:match pattern="auto/*/**">
   <map:mount uri-prefix="auto/{1}/"

How about allowing the following alternatives for src (partially borrowed
from Tomcat):


The jar protocol is of course the one handled by the standard JDK net

Just like JBoss reads EARs from such urls and looks up META-INF/... and
Tomcat reads WARs then looks up WEB-INF/..., we can write in the
specification how Cocoon will read COBs and will look up BLOCK-INF/... (lib,
classes, .xconf, etc.)

This will possibly allow us to borrow a lot from the J2EE specs in terms of
class loading, security, signatures, deployment, life cycle and other


| Part II - the "service" protocol  |

Now, we can also merge the WebServiceProxyGenerator and <map:mount/> into
something like:

<map:match pattern="auto/*/**">
   <map:mount uri-prefix="auto/{1}/"

Where the src is prefixed with a service protocol, which implies that
requests which
match pattern="auto/*/**" will be forwarded(proxied) to the URL after
service: and the
output will be available to the parent sitemap, just like with regular

This will allow remote hosting of services/blocks, while to the users of the
current applications it will appear like everything is served by it
To clarify, as far as the service protocol is concerned, it doesn't matter
what runs the remote site.
It can be any web server, including Cocoon. See the following demo for
example of remote service hosted by Amazon and OpenWiki:

With this in place we can get rid of the current WebServiceProxyGenerator
and replace it with a simple file generator, which uses the cocoon protocol.
In other words, what used to be:

<map:match ...
  <map:generate type="wsproxy" src=http://host123/some/service...

will become:

  <map:generate src="cocoon:some/service"

<map:match "some/service"
  <map:mount src="service:http://host123/some/service/...

In addition to sitemap simplicity, the offered approach will also allow the
remote call to return any content type, not necessarily XML. Therefore it
would be possible to refer to it from readers and any other component which
uses the Avalon source resolver.

One more added value is that a site can start simple by using remote
services and then as user demand increases, it will be able to move a Cocoon
block locally by making one simple change, which is replacing the mount src
from service:... to jar:... .

One apparent difficulty with the service protocol is propagating all the
sitemap information normally available to locally mounted sitemaps.
I think that this information should be generally unavailable to remote
However explicit parameters could be passed on. For example:

<map:match "some/service"
  <map:mount src="service:http://host123/some/service/...
    <map:parameter name="request-parameter-to-service-1"
    <map:parameter name="request-parameter-to-service-2"


                         -===[ End of Proposal ]===-



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

View raw message