cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [RT] Cocoon web applications
Date Thu, 25 Oct 2001 08:36:10 GMT
On Sat, 6 Oct 2001, Stefano Mazzocchi wrote:

> This thread is become really good.
> Michael Hartle wrote:
> >
> > Hi,
> >
> > I guess that adding practical examples and consequences to the
> > suggestions will help discussing the concepts at a broader scale. I just
> > love examples that can be torn in half and rebuild.
> >
> > Ok, asbestos underwear in position - here we go:
> Sam, seems like people liked this expression very much :)


> > 1.) We want easily deployable packages, just like .war or .ear files in
> > other contexts. For Cocoon, this would be .cwa files; I guess it's just
> > a zip file with some information relating to the package, like a
> > MANIFEST in a .jar file. I would consider this extra information to be
> > at least a sitemap.xmap that controls the sub-URI-space of the package.
> I share your vision totally.
> > 2.) We want these easily deployable .cwa packages to be self-contained.
> > I consider modifying a package for setup issues impractical, so the
> > setup for a package should happen outside of the package. Inversion of
> > control, Avalon principle ;). At the same time this allows a single .cwa
> > package file to be setup and deployed at multiple places at the same time.
> Ditto.
> > Some setup like mounting could happen in a sitemap.xmap, as currently
> > this is the place controlling URI space; this even allows for an
> > auto-mounting extension for the sitemap. Many packages will require
> > setup beyond mounting, for example where to find the corporate identity
> > stylesheets, which accounting database to use, or what's the business
> > name to be put on the tax report thats being produced, so I need both
> > the information about what I CAN configure and what I actually DO
> > configure for this package.
> Again, I was thinking about IoC: have the CWA ask Cocoon about things it
> needs instead of having you to modify the things after setup.

I thought IoC is working the other way: have Cocoon tell the CWA about
those things.

> > I think of the former as sort of a standardized setup-info.xml or the
> > like regulary contained in .cwa packages that have something to be
> > configured. The latter could be an configuration file positioned
> > somewhere near the sitemap.xmap and cocoon.xconf files in the
> > filesystem. One might even refer to the configuration file from the
> > sitemap, so the way the configuration files are being organized is left
> > as a choice to the system administrator.
> I recently came to know MacOSX NetInfo package and found it *very*
> elegant (much more elegant than the 30-years old /etc directory,
> anyway): it's a short of directory server that contains configuration. A
> sort of elegant and simple configuration registry (unlike windows') that
> is used to "serve" configurations to who it requires them.
> It provides a central point of configuration and an easy way to deploy
> something without having to modify it.

I've recently discussed this with other people. A central point of
configuration is essential especially if you have to manage a
distributed environment.


> The contract is the internal tree shape (sort of URI space for
> configurations) and CWA might look for configurations in there. For
> example in a sitemap
>  <map:parameter name="database"
> value="conf://datasource/relational/main"/>
>  <map:parameter name="user"
> value="conf://datasource/relational/main/user"/>
>  <map:parameter name="password"
> value="conf://datasource/relational/main/password"/>
> something like that.
> It is also pretty easy to scan the CWA for conf:// protocols and
> understand if the registry contains already the information or needs to
> prompt the installer for it.
> This way, security sensible information is stored by Cocoon in another
> location, probably out of the addressing space, making it inherently
> more secure (it might even attach directly to an LDAP server, for that
> matter).
> > 3.) As the .cwa package does not know in advance where it will be
> > deployed, it cannot know about the URI space it will be accessable from
> > via the web, yet most content needs to point to other content in this
> > package, for example just simple links from HTML page A to HTML page B.
> I'd assume that the URI structure of the CWA package can be considered a
> contract. So, the only "soft" thing is the location where this "hard"
> URI tree is mounted.
> > If  resource names of pipelines were added to the sitemap which are
> > local to the package/sitemap, the .cwa designer could just use resource
> > names in his package and have them resolved later via taglibs in a page
> > or other means in the sitemap like a cocoon-protocol extension like it
> > was posted for role-based access.
> Exactly, we still have to define "how" those "soft"+"hard" links are
> actually translated to real URL addresses, but we agree on the mechanism
> and this is a good thing.
> > 4.) .cwa packages will rarely be on their own, not interconnecting. So
> > resource naming would need to work between .cwa packages. Giving each
> > deployed .cwa package a global name, the local resource name for a
> > pipeline could be referenced from another position.
> You touch another important point here: if on one hand, addressing by
> role must not sacrifice the ability to have multiple instances for the
> same role, on the other hand, must be precise enough to avoid name
> collisions.
> This is the same problem faced by by both java dynamic loading and xml
> namespaces: both use URI's as unique identification.
> Avalon, for example, uses the inverse dot notation (in short, the
> interface name, i.e. org.apache.cocoon.component.Parser) to create
> unique behaviors identified by the interface that represent them.
> Same thing for namespaces, in fact the xmlns attribute is a way to
> reduce verbosity but doesn't change the nature of the internal infoset
> which assumes that all elements are prefixed with the URI that uniquely
> reference them.
> So, each CWA must indicate both:
>  o its unique role
>  o its instance identifier
> For example, a webmail CWA could be identified by
>  My Fancy WebApp 2.3
> Now, the problem is that we cannot impose the use of something like
>  cocoon://[]/some/resource
> but one solution would be use (abuse?) the XML namespace mechanism
>  <element xmlns:webmail=""
>           href="cocoon://webmail/some/resource"/>
> where we extend the default namespace behavior to do namespace
> resolution even inside the attribute content. In fact, even XSLT does so
> when doing
>  <xsl:template match="ns:element" xmlns:ns="...">
> and ns: is matched not by the prefix, but by the expanded namespace URI.
> As far as uniqueness is concerned, the above mechanism works, but if we
> want to allow more than one instance of the same role, we could indicate
> so like this:
>  <element xmlns:webmail=""
>           href="cocoon://webmail:mywebapp/some/resource"/>
> But this creates a composition problem: one CWA must know in advance the
> instance-specific name of the other CWA. Since this is controlled by the
> CWA deployer and cannot be hardcoded (unless we accept name collisions),
> this is a weak contract and it's very likely to break everything very
> soon. (with a very hard time figuring out what to do).
> So, here is my solution (that closely follows the strategy we designed
> for Avalon blocks):
>   each CWA indicates
>     o  its role as a URI  (
>     o  its name as a human readable form  (My Fancy Webapp)
>     o  its version as major.minor format (2.3)
>     o  its dependancies on other CWA (role:version)
>     o  its dependencies on external configurations
> when the CWA is deployed, the following things happen:
>  1) the CWA deployment descriptor is read
>  2) a machine specific name is given to the deployed instance. (if
> another CWA of the same role:version pair is already in place, the
> instance name must be unique, for example, adding a counter at the end
> such as ""
>  3) for each CWA dependancy do:
>   3.a) check if a CWA with that role is already in place.
>   3.b) if so
>     3.b.i) if only instance of that role, map the role to that instance.
>     3.b.ii) otherwise, prompt the deployer and ask for which available
> instance should be associated to that role.
>   3.c) otherwise, use the role URI to download the required CWA [we can
> define how this is done later] and deploy it.
>  4) for each configuration dependancy do:
>    4.a) check if the configuration key already exists in the conf
> registry
>     4.a.i) if so, prompt the user if the available value is ok
>      4.a.i.1) if so, go on
>      4.a.i.2) otherwise, change the value associated to that
> configuration and relative to that instance only.
>     4.a.ii) otherwise, prompt the deployer for the conf value
>  5) the deployer is finally asked for a URI location to mount the CWA
> instance.
>  1) possible recursive dependancies might create a deadlock on the
> deployment phase, expecially when the Cocoon container is initially
> empty. This is unlikely to happen for well designed components, but we
> can download and scan all required CWA for deadlocks before actually do
> any real deployment so that problems can be stopped *before* entering
> the system.
>  2) if more than one instance of a single webapp is available, the conf
> registry must be smart enough to lookup a configuration based not only
> on the requested path but also on the webapp instance that has requested
> it. This avoid collisions due to the fact that different instances of
> the same role by definition share the same configuration needs.
> > I guess there are plenty of opportunities to discuss what can be done
> > better or easier differently, so let's hear them.
> The only thing that is left to discuss is how (who does it and at what
> level) the address translation between roled-based access and real URI
> address is performed.
> Everything else looks in pretty good design shape to me, but of course,
> comments are more than welcome.

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

View raw message