Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 68498 invoked by uid 500); 5 Mar 2002 09:55:59 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 68480 invoked from network); 5 Mar 2002 09:55:58 -0000 Message-ID: <3C849570.7030809@anyware-tech.com> Date: Tue, 05 Mar 2002 10:52:48 +0100 From: Sylvain Wallez Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en, fr MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] user-components.xconf References: <20020305092516.C624123CDE@dj.codeconsult.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. > In the interpreted sitemap engine, the section is handled as regular component manager configuration (i.e. a .xconf file), so you can add any component you wish in it. 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/'. Thoughts ? Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:sylvain@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org