RE: [Springframework-developer] Abstract bean definitions

[Rod J. <ro...@in...>]

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