cocoon-dev mailing list archives

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

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

You're right, I was more 'subverting' the control, but in this case, a
passive operation would be very much bean-like. Well, the two
alternatives are equivalent under a certain light so, as long as all the
required features are met, I don't care what side the control takes.

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

well, both xml configurations and java properties have tree-like shapes,
just like directory servers and netinfo-like registries. I was proposing
to simply make this more coherent internally and abstract it on the
repository (but completely transparent from the configurable entities
asking for their configurations).

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

Well, I don't think the number of parameters depend on the size of the
CWA being deployed and I don't think I get your point.
> 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.

Normally, configurations are strings or numbers. Do you really want to
receive a stream of SAX events that you have to write your own code to
interpret, instead of being able to simply *ask* a configuration
repository for the configuration you want?

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

Because this is exactly what flexiblity syndrome looks like: when you
have a hammer in your hand, everything looks like a nail.
> >>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.

"hard" links are expressed just like you would do normally: I mean,
between the CWA, all pages know the location of the others and know
they'll never change once deployed (this is why "hard"). So you can
reference it as you do today in the sitemap when reading stuff on your
context file space.

The "soft" part takes into account the fact that CWA might be "mounted"
in a position choosen by the deployer, thus one CWA cannot base address
resolution to a hard position (since it might change) but has to look it
up using some sort of indirect addressing, which I proposed it to be
based on behavioral interfaces, just like we do for Avalon components.
> >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.

Ok, comment considered. Any suggestion will be welcome.
> >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. 

This is why the CWA will also contain a description of the configuration
that you are being asked to provide.

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

As you guys wish, I don't see any reason to force one behavior or the
> 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.

You got the wrong perception here, since I'm trying to help
administrators instead of doing stuff for them behind their backs. But
if you don't like that, fine, you'll always have the good old
configuration files to modify by hand.

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

Se my next mail to Berin for that.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message