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ürgen höller [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
>
>
|
