Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 62244 invoked from network); 26 Feb 2007 07:32:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Feb 2007 07:32:49 -0000 Received: (qmail 52671 invoked by uid 500); 26 Feb 2007 07:32:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 52251 invoked by uid 500); 26 Feb 2007 07:32:55 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 52240 invoked by uid 99); 26 Feb 2007 07:32:55 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO [127.0.0.1]) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Feb 2007 23:32:55 -0800 Message-ID: <45E28D32.9090307@apache.org> Date: Mon, 26 Feb 2007 08:33:06 +0100 From: Carsten Ziegeler User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: New Features for the spring configurator References: <45DEEAB8.3000209@apache.org> <45DF215D.4000805@mobilebox.pl> <45E28AF8.2090807@apache.org> In-Reply-To: <45E28AF8.2090807@apache.org> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Carsten Ziegeler wrote: > Leszek Gawron wrote: > controlled via an additional attribute). >> I have been trying to use configurator outside cocoon for my other >> spring based projects. Thing is the configurator automatically imports >> property files and contexts in META-INF/cocoon/spring. What should I do >> to have limit it's functionality to properties? >> > Currently, you have no way to specify this. You can exclude reading the > properties from the various locations, but not the beans. > > I was always wondering if we need such a configuration or not. If we > would have a clean separation between api and impl, you would never > include a jar containing an impl (and META-INF/cocoon/spring > configuration files) if you don't need these components. At least we > could argue that this is a good theory. In addition, as soon as you > think about disabling the automatic include of spring configuration > files, you will have the use case were you want to include most of them > automatically but not a specific one. Which of course leads to a > configuration possibility of excludes and includes. > > So my idea was to start simple and extend the functionality if needed. > First step was to always include all configurations, the next step will > be to disable this. I'll update the code today. > Ok, forget most of the stuff I said above, you can disable the inclusion by specifying the "readFromClasspath" attribute on the settings element: Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/