Return-Path: Delivered-To: apmail-cxf-users-archive@www.apache.org Received: (qmail 88432 invoked from network); 12 Dec 2008 14:02:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Dec 2008 14:02:21 -0000 Received: (qmail 10129 invoked by uid 500); 12 Dec 2008 14:02:32 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 9907 invoked by uid 500); 12 Dec 2008 14:02:32 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 9896 invoked by uid 99); 12 Dec 2008 14:02:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Dec 2008 06:02:32 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.202.165.196] (HELO smtpout04-03.prod.mesa1.secureserver.net) (64.202.165.196) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 12 Dec 2008 14:02:16 +0000 Received: (qmail 17674 invoked from network); 12 Dec 2008 14:01:54 -0000 Received: from unknown (24.12.191.198) by smtpout04-04.prod.mesa1.secureserver.net (64.202.165.199) with ESMTP; 12 Dec 2008 14:01:54 -0000 Message-ID: <49426ED0.7070308@javactivity.org> Date: Fri, 12 Dec 2008 08:01:52 -0600 From: Steve Cohen User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: users@cxf.apache.org Subject: Re: Runtime CXF configuration WITHOUT using Spring References: <4940FD34.7050905@javactivity.org> <61b5d9410812110405l6ccb4c6ald71d2951d72cbe82@mail.gmail.com> <49410BF1.6060202@javactivity.org> <49416E00.3000808@die-schneider.net> <494171AF.7090106@javactivity.org> <4941A476.60200@die-schneider.net> <4941DD57.7050901@javactivity.org> <49425253.9070905@dcs.shef.ac.uk> <494265E7.9060406@javactivity.org> <61b5d9410812120536q79b40700yb4a50b68c9a57507@mail.gmail.com> In-Reply-To: <61b5d9410812120536q79b40700yb4a50b68c9a57507@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Exactly. I'm not really OPPOSED to Spring, I just don't have time to rearchitect a substantial application. But if CXF is forcing me to include the Spring jars, and I can get other benefits of Spring from these jars without rearchitecting, I'm not going to look that gift horse in the mouth. Rearchitecting can come later, when I have time, and I guess it's nice to know that Spring can be used piecemeal like this unlike some other "Frameworks" out there that make you bend to their idea of how things ought to be. Benson Margulies wrote: > There has been a fairly serious case of 'who's on first?' going on here? > > Or, to paraphrase Voltaire, "Steve didn't know that he was already > speaking in Spring." > > If Steve really wanted to be Spring-free, he'd need to tear down the > use of the CXFServet's standard Spring-y behavior and build up his > service from the API himself. On the other hand, my impression is that > now that he realizes the non-impact of how Spring plays out in the > servlet, he's gone over to the dark side. > > > On Fri, Dec 12, 2008 at 8:23 AM, Steve Cohen wrote: > >> Thanks, Ian, for this cogent explanation. >> >> This is exactly what I need to know and it sounds like it will work. I >> didn't understand the whole >> >> >> >> classpath:config.properties >> >> >> >> construct. I hadn't understood what the "locations" property was for and >> didn't realize that I could put a file url there instead. This looks like >> exactly what I want, now that you've explained it. A better name might have >> been configLocations or something but that's how it goes. >> >> Since locations can evidently take a list of possible values, am I to assume >> that this list is ordered and that I could define strategy of standard >> configurations with possible overridables for us in a development setting? >> If so, am I correct in presuming that the first item in the list is the >> first to be searched, so that the defaults would go on the bottom? >> >> Well, you've made my day. I think I must go and read the source of >> PropertyPlaceHolderConfigurer.java and figure all this out for myself. >> Basically I've been trying to roll my own version of this kind of setup for >> a long time. >> >> >> >> Ian Roberts wrote: >> >>> Steve Cohen wrote: >>> >>> >>>> But I don't completely understand yet. Okay, let's say I make the small >>>> step of putting the PropertyPlaceHolderConfigurer into my cxf.xml >>>> file. How does the PropertyPlaceHolderConfigurer know where to find my >>>> config.properties files? We get into these chicken and egg problems. >>>> >>> The location is set in the block that sets up the configurer >>> within cxf.xml: >>> >>> >> >>> >>> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> >>> >>> >>> classpath:config.properties >>> >>> >>> >>> >>> classpath:config.properties means it looks for config.properties on your >>> classpath (i.e. in WEB-INF/classes). You could put an absolute file URL >>> in there instead (file:///home/me/config.properties) if you want it to >>> load from a fixed location rather than from inside your webapp. >>> >>> It's also worth noting that a PropertyPlaceholderConfigurer will use >>> Java system properties if it can't find the relevant entry in >>> config.properties, i.e. if you have a ${webservice.username} placeholder >>> in your cxf.xml but no webservice.username=blah in config.properties >>> then it will look at the Java system property with the same name. If >>> you *only* want to resolve system properties and not bother with >>> config.properties at all then you could just use: >>> >>> >> >>> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" >>> /> >>> >>> Ian >>> >>> >>> >> > > >