Menu
▾
▴
Re: [Springframework-developer] Abstract bean definitions
|
From: <jue...@we...> - 2004-09-02 17:30:22
|
As far as I see, it won't break any code as long as you don't use the = "abstract" attribute... In that sense, it should be perfectly = backwards-compatible with existing bean definitions. I think it's = reasonable that a *modification* of your bean definitions might = introduce new behavior. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rod Johnson Sent: Thursday, September 02, 2004 7:17 PM To: spr...@li... Subject: RE: [Springframework-developer] Abstract bean definitions I think this is a reasonable approach. However, it *will* break some = code. But I don't think it's unreasonable for such SPI-dependent code to be broken, so long as we clearly explain the rationale and impact in the release note and doco. I'm inclining towards extensive use of inner beans, which do address = most requirements for private beans. I guess there remains the case where multiple beans within one context reference a bean that should be = private. I don't think public/private should be considered for 1.1 final.=20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 30 August 2004 19:12 To: spr...@li... Subject: Re: [Springframework-developer] Abstract bean definitions Well, getBeansOfType already ignores abstract beans: That method returns bean instances, so the only sensible thing to do here is to simply = ignore abstract beans whose type would match. =20 getBeanDefinitionNames() and getBeanDefinitionNames(type) do return = names of abstract beans too, though, just like getBeanDefinitionCount() includes abstract beans too. If you cast to ConfigurableListableBeanFactory, you = can fetch the BeanDefinition for a given name, which is also supposed to = work for abstract beans - this is needed by PropertyPlaceholderConfigurer, = for example. So for consistency, getBeanDefinitionNames more or less has to return names of abstract beans too. =20 Via ConfigurableListableBeanFactory's getBeanDefinition(name) method, = you can also check whether a bean definition is abstract now, if you = absolutely need to. However, I think that for all normal use cases, getBeansOfType = is what you usually want, as it also checks the type of FactoryBeans and returns concrete instances. So I don't think that the above is a = limitation. And everything's perfectly backwards-compatible as long as you don't = mark a bean "abstract" anyway... =20 Regarding public/private beans, there is a problem waiting there too: = Even private bean definitions need to be visible to ConfigurableListableBeanFactory, for PropertyPlaceholderConfigurer and = co. So should getBeanDefinitionCount and getBeanDefinitionNames include = private beans too? We could simply check in getBean and getBeansOfType to = exclude private beans, but that feels a bit odd... =20 Essentially, do we really need public/private beans now that we have abstract beans? getBeansOfType and autowiring by type already exclude abstract beans, and inner bean definitions solve the TransactionProxyFactoryBean autowiring problem (where both the proxy and = the target match by type). We should clarify the usage scenarios for private beans first, before worrying about them, I guess. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mo 30.08.2004 19:26 An: spr...@li... Betreff: Re: [Springframework-developer] Abstract bean definitions I'll update the docs accordingly. I agree about making a distinction between getting info for usage by = Spring, and by other users, but the usage semantics with only abstract and no public/private are a bit problematic. I assume even getBeanDefinitionNames(Class type); and getBeansOfType(Class type, boolean includePrototypes, boolean includeFactoryBeans) are going to return the abstract beans, right? There is a decent amount = of user code right now which uses these methods to get real live beans. If abstract beans come in as a result of these calls, and people have no = way to exclude them, it basically precludes using abstract beans for any = bean def hierarchies where somebody is going to be using these methods to get live beans... Colin j=FCrgen h=F6ller [werk3AT] wrote: >Rod, Colin, everybody, > >I've implemented an "abstract" attribute for <bean> tags in XML bean definitions. It works as expected in test cases. I've also adapted the "baseTxProxy" bean definitions in Petclinic and JPetStore (as introduced = by Colin) accordingly, marking them as "abstract" rather than "lazy-init". > >There's one issue with visibility, though: For consistency, an abstract bean definition is currently visible just like any other bean = definition: returned by ListableBeanFactory's getBeanDefinitionNames and ConfigurableBeanFactory's getBeanDefinition. On getBean, an BeanIsAbstractException gets thrown. > >We plan to introduce a "public" attribute for Spring 1.2: This could be used to make a bean private, be it abstract or not. IMO, these are effectively two separate concerns: I believe that we should treat them separately, i.e. not automatically make an abstract bean private. > >For example, a bean factory needs to be able to access a parent bean definition in an ancestor bean factory, even if that parent bean is = marked as "abstract" to never get instantiated directly. If an abstract parent = bean definition were automatically private, this wouldn't work. > >What do you think? I'll polish and commit my current implementation tonight, if there are no objections. As I said earlier, I'd like to = release 1.1 final by the end of this week: Abstract bean definitions is the last essential feature for that release. > >Juergen >=20 > ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java = Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java = Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
