Re: [Springframework-developer] Re: FactoryBeanCircularReferenceException with 1.1.3

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

I agree that over-eager checks should be avoided, as long as the overall =
semantics are not affected. Unfortunately, our test suite does not cover =
such cases that fail for you yet. This is the reason why it wasn't =
noticed that the checks became over-eager in some respects.
=20
Colin, could you please create unit tests for such a scenario and commit =
them in commented-out state (as they will currently fail, of course)? =
I'll try to refine the internals of the autowiring mechanism to make =
those test cases pass for 1.1.4 then.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Patrick Burleson
Gesendet: Mi 22.12.2004 15:41
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: =
FactoryBeanCircularReferenceException with 1.1.3



Colin,

Thanks for the info. It is definitely a bit of a shame for the code to
be so eager since I think a common case of Spring usage is to wrap a
service with the TransactionProxyFactory and if any service depends on
another, then autowire is probably out of the question.

The really odd thing that added to the confusion was the fact that
Spring reported a CircularDependency when there really wasn't one. We
had service A that depended on service B (which was set to autowire),
but the circular dependency was thrown for Service C, which does
depend on A, but has nothing to do with B. Very confusing.

With our app, we have decided that autowire shouldn't be used because
we want people who use our code to able to override our definitions
with their own. So autowiring would cause some problems.

Overall, it would be nice to be able to specify behavior to either
revert back to the less eager method or to possibly recheck Factory
dependencies after each bean has been instantiated to see if an
autowire dpenedency has become available. (Although I guess this could
be a costly operation with lots of Factory beans).

It would certainly seem that once you have any Factory beans, then
autowiring will probably fail for you if you have any sort of
interdepencies between the Factory targets. This is probably not the
best.

Patrick

On Tue, 21 Dec 2004 17:53:57 -0500, Colin Sampaleanu <col...@ex...> =
wrote:
> I've run into this while investigating some forum questions. For =
1.1.2,
> Spring became much more aggressive about instantiating FactoryBeans in
> order to figure out what to autowire. Whereas the before it would not
> instantiate FactoryBeans for which a type is not known
> (getObjectType=3Dnull), it now seems to instantiate all such =
FactoryBeans.
>
> I'm not sure Juergen actually intended this change, or it's happening
> because he fixed some other bugs related to getBeansOfType, which I =
know
> happened.
>
> This is arguably not a great change. One thing it means is that every
> factory bean (which doesn't declare the return type at least) even if
> marked lazy-init, will be instantiated as soon as another bean does an
> autowire. This is what cause people who were using a parent
> TransactionProxyFactoryBean template marked only lazy=3Dtrue (but not
> abstract) to all of a sudden have this parent bean start being
> instantiated when they switched from 1.1.1 to 1.1.2...
>
> I would personally vote to go back to the old behaviour... While this
> means that autowiring will not work for lazy-loaded singleton factory
> beans (that have not be instantiated yet), Spring always worked that =
way
> anyway, and it can be documented.
>
> Colin
>
>
> Patrick Burleson wrote:
>
> >A little more information on this:
> >
> >This has something to do with auto-wiring. The bean before the bean
> >that supposedly causes the circular reference was defined to have
> >auto-wire by type. Once I removed this definition, the circular
> >dependency went away. Is it a function of auto-wire to try and figure
> >out the type of every other bean to find dependencies?
> >
> >If so, that would probably explain it. As the target bean of a
> >transaction proxy is dependent on the bean that was defined as
> >auto-wire. But another transaction proxy target we have is dependent
> >on the other transaction proxy bean. I know that's really confusing,
> >but I think it's a common case when one service depends on another. I
> >guess that's one of the inherent dangers of auto-wiring. I just =
wonder
> >why it didn't fail in 1.1.1?
> >
> >Thanks,
> >Patrick
> >
> >
> >On Tue, 21 Dec 2004 11:30:18 -0500, Patrick Burleson
> ><pbu...@gm...> wrote:
> >
> >
> >>I upgraded our app to use Spring 1.1.3 yesterday and started getting =
a
> >>FactoryBeanCircularReferenceException during startup. This error =
does
> >>not occur with Spring 1.1.1, haven't tried 1.1.2 just yet.
> >>
> >>As far as I can tell, I don't see any circular dependencies in our
> >>config. It's almost as if the factory forgot to go back and mark one
> >>of our FactoryBeans as being complete before moving on to the next
> >>Factory bean. I know that sounds impossible, and it probably is, but =
I
> >>at least wanted to get this out there.
> >>
> >>I'm going to try and figure out exactly why it thinks there's a
> >>circular dependency, but it might take some time.
> >>
> >>Thanks,
> >>Patrick
> >>
> >>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real =
users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer