cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: [RT] Cocoon web applications
Date Sun, 07 Oct 2001 01:28:26 GMT
Stefano Mazzocchi wrote:

>>Ok, asbestos underwear in position - here we go:
>Sam, seems like people liked this expression very much :)
It was sort of an inspiring picture, I admit ;)

>>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.
Oh, I am not thinking of modifying the CWA for any purpose, I simply 
meant supplying Cocoon with configuration information it would pass on 
to the CWA when appropriate. I am interpreting the IoC principle the 
other way around; the CWA is "just" a web application among many others 
that are also being some sort of drop-in. So it is not the CWA 
actively/dynamically asking Cocoon about something, but Cocoon handing 
down configuration information to the CWA at a certain stage.

>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"
> <map:parameter name="user"
> <map:parameter name="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
The concept of allowing different sources (LDAP, filesystem, etc) for 
configuration as described is interesting, although I do think that each 
application should have it's own dedicated branch for setup information 
instead of forcing each parameter to be explicitly being passed; as 
large CWAs are going to happen (they will, right ?), the sheer length of 
the list of "parameters" for customizing them could well justify this 

This would even allow passing on an instance of configuration source to 
the CWA, this instance implementing some ConfigurationSource-interface - 
be aware that I am not sure whether such an interface or class with this 
name is already existing, and I am not knowingly referring to anything 
here as I just made a wild guess how this could be named. This might be 
an LDAPConfigurationSource or a FileConfigurationSource, being able to 
deliver arbitrary configuration information to the CWA as a stream of 
SAX events. And those ConfigurationSource's could be defined in the 
sitemap and being configured with parameters when needed. Hey, why not 
simply consider different configuration sources as sources for SAX 
events directly ?

>>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.
That's what I meant but didn't express. ;)

>>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.
Ok, so the "how" basically has to allow the developer to interchangably 
use "soft" and "hard" links all over the place, even though "soft" links 
might need one or two steps in addition.

>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.
I would consider this approach an abuse of the XML namespace mechanism, 
as in the way it is used in the XML definition, it is setting up a short 
namespace alias for the notation ns:element, not as a preprocessing 
instruction like #define in C. I think we should be able to come up with 
something more clear.

>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.
I am always fearful of prompts that do something for me that I may not 
have understood completely. Do we speak of a solely installer-based 
approach here or might this allow the admin to just drop-in the .cwa 
file and add an entry to the sitemap without anything able to directly 
prompt at all ?

We should give the administrator a way to explicitly name a certain 
instance, leaving the administrator the choice between automatic 
GUI-driven and good-old vi-driven approaches, as the admin can partially 
or completely override the naming scheme and refer CWA dependencies to 
their targets manually. Whenever people would use the dynamic naming 
scheme to ensure multiple installations do not collide, they show a 
certain lack of interest to make sure they connect CWA dependencies 

>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
>    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
Basically this sounds good ;)

> 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.
Are there already existing solutions being used in Cocoon ? What about 
the cocoon:// protocol ?

Best regards,

Michael Hartle

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

View raw message