On Tue, 5 Mar 2002, Sylvain Wallez wrote: > Bertrand Delacretaz wrote: > > >On Tuesday 05 March 2002 09:21, Torsten Curdt wrote: > > > >>. . . > >>We should be able to have a separate configuration besides the > >>configuration for the core components. We should be able to define a > >>user.xconf. (or better user-components.xconf?) > >>. . . > >> > > > >From a user's point of view, being able to drop the .xconf and required > >jars in a directory under mount/ would IMHO be a great first step > >towards "pluggable cocoon apps": > > > >mount/my-app > > sitemap.xmap > > cocoon-config/my-components.jar > > cocoon-config/my-jdbc-driver.jar > > cocoon-config/my-app.xconf > > docs/index.xml > > . . . > > > >Currently this mount thing works great (even without stopping cocoon) > >if you need just a sitemap and content files, but as you mention more > >than that needs editing the global cocoon.xconf and/or copying jars > >under WEB-INF.
This leads IMO to a concept where Cocoon has a default or built-in root-sitemap which only contains the deploying and mouning steps for Cocoon Blocks. A "DeployerAction" can handle expansion of a jar with a well-known structure (similay to the SAR concept in Avalon-Phoenix) > In the interpreted sitemap engine, the <map:components> section is > handled as regular component manager configuration (i.e. a .xconf file), > so you can add any component you wish in it. But without having the ability to specify a roles file for abbreviating the configuration specification, right? > The only piece that's missing is a classloader per subsitemap to load > additionnal jars. But we should be careful with that since this places > code in areas that are potentially visible from the client browser (the > servlet engine hides the contents of WEB-INF). A solution could be for > the sitemap engine (or Cocoon itself ?) to forbid access to all URIs > containing 'WEB-INF/'. Yes, it make absolutely sense to have a classloader per sitemap which is able to hot deploy or redeploy whenever you drop in a Cocoon Block jar. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
