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:43:27 GMT
On Sun, 7 Oct 2001, Michael Hartle wrote:

> 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.

Exactly my thought :)

> >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).
> >
> 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
> approach.
> 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 ?

I don't think we should go that fax to hand configuration over as SAX
events. Avalons Configuration object is smart enought for it. Also, I
don't like to additionally blow up the sitemap with stuff like
ConfigurationSource. I'd rather see that going into cocoon.xconf have a
component that is the ConfigurationSource used by Cocoon to hand over
the configuration to a CWA.

> >>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 ?

I see the web based (Cocoon based) configuration editor here for
deployment configuration (yes, JMX comes to mind also).


> 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
> correctly.
> >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.
> >
> Basically this sounds good ;)
> >
> >NOTE:
> >
> > 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:

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

View raw message