Brian, I apologise for the confusing thread. At the moment I just want to get a reading on whether this particular behaviour of factory-method beans wrt to circular dependencies actually concerns anyone. To me it seems like an unnecessary inconsistency, but maybe to everyone else it's just that factory-method beans are different because they *are* different.
CS deals with circular dependencies beautifully, and the factory-bean/factory-method construct is itself incredibly useful, but the two of them together? No dice. It seems to me this can be at least partly fixed, but is there a fundamental reason it shouldn't be? For the record, in my initial post I was just playing with ideas. I have in fact ended up using different CS config files that are selectively loaded depending on values determined at runtime, and not the factory-bean idea I first posted. Jaime Metcher -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Brian Kotek Sent: Tuesday, 22 May 2007 3:27 PM To: [email protected] Subject: [coldspring-dev] Dynamic bean properties redux Looking back at the thread, I'm not sure what it is you're trying to do that using dynamic property values or different coldspring XML files won't allow you to do already? Thanks. On 5/22/07, Jaime Metcher <[EMAIL PROTECTED]> wrote: I don't know if there's anyone here but me and the tumbleweeds, but at least no one is arguing... Anyway, here's a proposal: if a bean has a no-arg factory-method constructor, create it along with all the other CreateObject-ed beans. Otherwise, leave things as they are i.e. bomb if that bean has a circular dependency. I think that introduces more consistency - you could make the more general statement "if a bean has a no-arg constructor...", and of course CreateObject() is always a no-arg constructor. If anyone thinks this is a good idea I'll go ahead and create a patch. BTW, what I said earlier wasn't quite right. A factory-method bean can participate in circular dependencies as long as its dependants are instantiated before it i.e. the order in which you do getBean() calls matters. Jaime Metcher > -----Original Message----- > From: [email protected] > [mailto:[EMAIL PROTECTED] Behalf Of Jaime > Metcher > Sent: Monday, 21 May 2007 7:07 PM > To: [email protected] > Subject: [coldspring-dev] Dynamic bean properties redux > > > Actually, it seems to be a limitation of ColdSpring that beans > created by a > factory-bean/factory-method can't participate in circular dependencies at > all. I can imagine a case where a no-arg factory-method could > participate, > but the general case seems to be intractable. > > Now that I think of it, a no-arg factory-method followed by an init-method > would mimic quite closely the way the "normal" beans are initialized. Has > anyone else been thinking along these lines? Not perceived to be > a problem? > > Jaime Metcher > > > -----Original Message----- > > From: [email protected] > > [mailto:[EMAIL PROTECTED] Behalf Of Jaime > > Metcher > > Sent: Saturday, 19 May 2007 7:46 AM > > To: [email protected] > > Subject: [coldspring-dev] Dynamic bean properties redux > > > > > > After more investigation, a couple of potential downsides to > > method number 3 > > are apparent. Firstly, all alternatives will be instantiated > even though > > only one will be used for a given app. Not a problem if the > > beanFactory is > > shared across apps. Secondly, the use of a factory-bean makes > > the config a > > little bit more prone to runaway circular dependencies. Again not > > necessarily a problem. > > > > And then there's method number 4: > > > > 4. Load multiple XML config files, some of which may be determined at > > runtime. > > > > if (CGI.SERVER_NAME is "widgetsite.com.au") > > widgetConfigFile = "AUConfig.xml"; > > else > > widgetConfigFile = "USConfig.xml"; > > > > application.beanFactory.loadBeansFromXmlFile(widgetConfigFile,true); > > > application.beanFactory.loadBeansFromXmlFile("myStandardConfig.xml",true); > > > > Jaime Metcher > > > > > -----Original Message----- > > > From: [email protected] > > > [mailto: [EMAIL PROTECTED] Behalf Of Tom > > > Chiverton > > > Sent: Friday, 18 May 2007 6:38 PM > > > To: [email protected] > > > Subject: [coldspring-dev] Dynamic bean properties redux > > > > > > > > > On Thursday 17 May 2007, Jaime Metcher wrote: > > > > This is a lot more config than the other alternatives, but wrt > > > the app code > > > > I think more transparent. Thoughts? > > > > > > I like it. > > > > > > -- > > > > > > Tom Chiverton > > > Helping to seamlessly morph corporate portals > > > on: http://thefalken.livejournal.com > > > > > > **************************************************** > > > > > > This email is sent for and on behalf of Halliwells LLP. > > > > > > Halliwells LLP is a limited liability partnership registered in > > > England and Wales under registered number OC307980 whose > > > registered office address is at St James's Court Brown Street > > > Manchester M2 2JF. A list of members is available for inspection > > > at the registered office. Any reference to a partner in relation > > > to Halliwells LLP means a member of Halliwells LLP. Regulated by > > > the Law Society. > > > > > > CONFIDENTIALITY > > > > > > This email is intended only for the use of the addressee named > > > above and may be confidential or legally privileged. If you are > > > not the addressee you must not read it and must not use any > > > information contained in nor copy it nor inform any person other > > > than Halliwells LLP or the addressee of its existence or > > > contents. If you have received this email in error please delete > > > it and notify Halliwells LLP IT Department on 0870 365 8008. > > > > > > For more information about Halliwells LLP visit www.halliwells.com. > > > > > > > > > > > > > > > > > > > > >
