Re: [Springframework-developer] Abstract bean definitions

[<jue...@we...>]

I've committed the current implementation last night. Feel free to play =
with it :-) We should agree on the final semantics ASAP, to be able to =
release 1.1 final by the end of the week.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 30.08.2004 20:12
An: spr...@li...
Betreff: 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.

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.

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...

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...

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.

Juergen


________________________________

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
>
>




-------------------------------------------------------
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