Can I just ask exactly what are you trying to configure in the spring file? Just about everything that is configured in spring CAN be done programatically via API's. It just may take a bit to find all the API's that are needed.
Thus, you MAY be able pull the spring jars out and then use the API's to do the configuration. You can keep your configs in any form that is convenient to you. Dan On Thursday 11 December 2008 10:41:11 pm Steve Cohen wrote: > Thanks. This is intriguing. Of course this involves Spring, which, > again, I'm NOT using -- or am I??? My application isn't consciously > part of the Spring Framework - but then it does, of course need the > Spring libraries for the CXF and cxf.xml is a Spring config file. So > tell me - is it possible for me to put my toe in the Spring water > without getting my whole body wet? I guess "all wet" would be defined > as Spring in web.xml, etc. I can't afford the time to go that deep yet, > but if this solves my problem, I could start edging in that direction > and maybe (probably, I think) even like it. This approach to runtime > environmental configuration is very much in the spirit of my home-grown > system only more systematic. > > 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. > Must I have a spring-config.xml to tell it where? And if so, what > causes THAT to be loaded? > > I'm not snarking here. If I can make this work, I think I'll go with > it. What is the minimum Spring footprint I need to get this going. > > Christian Schneider wrote: > > Hi Steve, > > > > there is a nice article that shows how to use the > > PropertyPlaceHolderConfigurer. > > > > http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.h > >tml > > > > > > There is no list of passwords and locations. You simply have different > > property files for your different environments. For example: > > > > Develop: > > File config.properties > > url=http://dev.server.com/service > > username=client1 > > password=mydevpasswd > > > > Test: > > File config.properties > > url=http://test.anotherserver/service > > username=client1 > > password=mytestpassword > > > > Ideally you manage to keep these files separate from your module (war > > in your case). So you can deploy a new version by copying the war and > > the config stays the same. > > I guess you had a quite similar solution with your property files > > already?! > > > > Greetings > > > > Christian > > > > Steve Cohen schrieb: > >> Thanks, Christian. > >> > >> This certainly sounds like it could be the answer to my dilemma and I > >> agree wholeheartedly with you that this is a normal scenario that > >> needs to be supported. > >> However, I don't fully understand what you are suggesting here. > >> Something must be a selector (a key) into the list of locations and > >> passwords and somehow this key needs to be passed to the object doing > >> the resolution. Is there a fleshed out sample of this anywhere? > >> > >> Steve -- Daniel Kulp [email protected] http://dankulp.com/blog
