[Springframework-developer] Re: Autowiring and dependency checks

[roger h. <apo...@sn...>]

Hi Juergen

As I've just been looking at the code in AbstractApplicationContext, I
noticed where the new method that you mentioned, getBeansOfType(), is called
in refreshListeners() - & I am wondering if on occasions it might be useful
to be able to refine the collection of instances it returns, rather than the
eager result of anything it can find - singleton, prototype, FactoryBean
generated or not ?

In the case of registering ApplicationListeners, I presume the net
effect will be that any prototype instances returned and registered,
will then just get lost to the GC, since no application code will ever get
to reference them.  But in other situations it may be more important to be
able to discriminate - perhaps using:

getBeansOfType(Class type, boolean singletons)

or even:

getBeansOfType(Class type, boolean singletons, boolean factoryBeanObjects)

Just a thought.

Btw, as this appears to be the only reference to addListener() within
AbstractApplicationContext, what's the rational for registering eligible
singleton beans as listeners, but not prototypes ?

Roger




"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:420...@ma......
> I've committed all of the changes, except the optional object dependencies
docu stuff. FactoryBean has a getObjectType method now, returning an advance
guess on which type getObject will return (or null if not known). That is
particularly useful for prototype FactoryBeans that create new instances on
each getObject call; autowiring will still work if they implement
getObjectType correctly.
>
> For singleton FactoryBeans, autowiring will check the created singletons
themselves if getObjectType returns null, as singletons are assumed to be
created on initialization anyway -- checking them on autowiring will not
incur an inefficiency. That way, DataSource dependencies will automatically
get resolved with a JndiObjectFactoryBean, even though the type is not known
in advance with the latter. Note that getObjectType will be invoked on the
fully configured FactoryBean, it can therefore rely on initialization.
>
> Everyone who's interested, please it give this stuff a try -- it works
pretty nicely with one of our werk3AT apps (although we won't use autowiring
in the end as we believe in the value of explicit associations; we will use
dependency checks though). Note that you can still set explicit associations
for dependencies that autowire can't resolve; autowire will then just
address all remaining dependencies. And as already suggested, it will ignore
dependencies where no matching bean is found, allowing for optional
dependencies. Add dependency-check="objects" for strict autowiring that
requires all dependencies to be satisfied.
>
> Juergen
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Do 30.10.2003 11:31
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Autowiring and dependency checks
>
>
>
> Juergen,
>
> I basically agree with your points.
>
> > So as a summary, I propose the following changes:
> > 1. "default-dependency-check" and "default-autowire" (already done but
not
> committed yet)
> Yes.
>
> > 2. ignore certain dependency types for autowiring, BeanFactory and
> ApplicationContext in particular (done too)
> Yes.
>
> > 3. explicitly document optional object dependencies in framework beans
to
> ease dependency check settings
>
> We may be able to do better than rely on docs.
>
> Some kind of metadata could be provided to autowiring specifying what's
> optional and what's not. This might make sense for framework components.
> Options:
> 1. Attach metadata attributes to properties with something like
> @OptionalProperty. We could compile this metadata in with Spring if our
> metadata support came on far enough so that our runtime information would
> find it. If there was no available metadata it would just assume that all
> properties were optional or required. This would have the advantage of
> defining a powerful way for users to specify whether or not their
properties
> were required.
> 2. Add BeanInfo like classes (checking whether there are any features we
can
> use from the JavaBeans BeanInfo stuff, which I think was painful to use)
> 3. Use XML or properties metadata packaged along with the classes.
>
> > 4. redefine autowiring to not complain if no matching bean found
(promote
> additional "objects" dependency check as an option)
>
> Yes.
>
> > 5. introduce a ListableBeanFactory.getBeansOfType(Class type) method and
> build autowire-by-type on it
> Yes, a getBeansOfType() method would be useful. And the FactoryBean type
> issue is overdue for clarification. Should the FactoryBean have a
getType()
> method on it, to return null if it can't know (as with JNDI)? Or a
> subinterface, TypedFactoryBean? This would enable most factory beans to
work
> with getBeanNamesOfType() as well. Of course even with JNDI the user could
> specify a type like javax.sql.DataSource and it would give the FactoryBean
a
> way of checking that the value in finds in JNDI makes sense.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> NHYX?uw+m> xZ?*m ?+?j z?y!DD? P)brA?m?q ?z v