springframework-developer — Spring Framework developers list

[Springframework-developer] Factory bean created with factory method throws NullPointerException since 1.1.3

[Rolf K. <ma...@ro...>]

Hi list,

I developed a small app using Spring 1.1.1, 1.1.2 and now 1.1.3.
Since 1.1.3 some test of my app fail.

You can download a test case to reproduce this with Spring 1.1.3 from
http://www.apache.org/~roku/spring-factory-beans-test.zip . Just add the
sources to the Spring test folder and run the test(s).

I want to give a small overview of the problem:

bean config:

<beans>
  <bean 
    id="peopleFactory" 
    class="org.springframework.beans.PeopleFactoryImpl"
    factory-method="getInstance"/>

  <bean 
    id="person" 
    class="org.springframework.beans.Person"
    factory-bean="peopleFactory"
    factory-method="getPerson"/>		
</beans>

Getting the first bean via BeanFactory is no problem. Getting the second
bean is not working in 1.1.3 anymore. 

I debugged the Spring sources a bit and the problem really seems to be a
bug. The offending statement is in class
AbstractAutowireCapableBeanFactory line 381:

  for (int i = 0; i < factoryClass.getMethods().length; i++) {

The variable factoryClass is null, since the method getType(..) invoked
in line 372 returns null. Please see that method for further details.

Looking at this class in Spring 1.1.2 shows the difference.
Unfortunately I have no patch available. Maybe it isnt' a bug anyway.

Please have a look.

Thanks and I wish a happy new new year.

-- 
Rolf Kulemann

[Springframework-developer] Preparing for 1.1.4

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

Hi everybody,
=20
I've scheduled release 1.1.4 for January 5th. This release is supposed =
to be the "definitive" release in the 1.1 branch. Subsequently, =
preparations for 1.2 RC1 will start, with JMX support, Hibernate 3 =
support, etc.
=20
Please report any issues you encounter with 1.1.3 as soon as possible, =
in particular compatibility issues. 1.1.4 will only have minor new =
features; the focus is clearly on bug fixes and fine-tuning.
=20
If you're eager, please give a nightly 1.1.4-dev snapshot a try =
(http://www.springframework.org/downloads/nightly), which already =
contains a number of changes since 1.1.3 (see the included changelog for =
details).
=20
Finally, on this occasion: Merry Christmas and a Happy New Year! Thanks =
for your ongoing support, and see you in 2005 :-)
=20
Cheers,
=20
Juergen

[Springframework-developer] Re: [Springframework-user] Spring + jBPM

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

<quote>
I could see a specialized FactoryBean to create different types of
services e.g. DefinitionService, ExecutionService, SchedulerService, so
these services could be directly injected into interested beans. Would
anyone be interested to see this support in Spring core?
</quote>
=20
I doubt that we should include JBPM support classes in Spring core. =
Else, everyone and their grandma will want support classes for their =
product in Spring's core ;-)
=20
I guess we're at the point of creating an extension package once again. =
For such stuff, we really need to set up an extension package: not part =
of the Spring core, probably not as thoroughly supported as the core, =
but nevertheless available for everyone interested.
A long-time candidate for such an extension package is our Commons =
Validator support in the sandbox.
=20
Effectively, such a package would be a collection of small extensions =
that didn't make it into the core, for whatever reason, but aren't large =
enough to warrant their own project either. (Acegi and the Portlet =
support are good examples for large extensions that *are* worth having =
their own project.)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag von =
Dmitriy Kopylenko
Gesendet: Do 23.12.2004 17:40
An: spr...@li...
Betreff: Re: [Springframework-user] Spring + jBPM



J.Enrique Ruiz wrote:

>
>> Have any users integrated these applications together?
>> Looking for some pointers on how to give jBPM access to the spring
>> context's to look up beans.
>>=20
>>
> We have integrated these two applications.
>
> This is the application context to do it:
>
> <beans>
>
>  <bean id=3D"bpe.jbpmConfiguration" =
class=3D"org.jbpm.JbpmConfiguration">
>    <constructor-arg>
>      <props>
>        <prop key=3D"jbpm.log.stdout">off</prop>
>        <prop key=3D"hibernate.connection.url">
>          jdbc:postgresql://localhost:5432/db
>        </prop>
>        <prop key=3D"hibernate.connection.username">user</prop>
>        <prop key=3D"hibernate.connection.password">passw</prop>
>        <prop
> key=3D"hibernate.connection.driver_class">org.postgresql.Driver</prop>
>        <prop key=3D"hibernate.dialect">
>          net.sf.hibernate.dialect.PostgreSQLDialect
>        </prop>
>      </props>
>    </constructor-arg>
>  </bean>
>
>  <bean id=3D"bpe.jbpmServiceFactory" =
class=3D"org.jbpm.JbpmServiceFactory">
>    <constructor-arg>
>      <ref bean=3D"bpe.jbpmConfiguration" />
>    </constructor-arg>
>  </bean>
>
>  <bean id=3D"myWorkflowService" class=3D"...">
>    <property name=3D"jbpmServiceFactory">
>      <ref bean=3D"bpe.jbpmServiceFactory"/>
>    </property>
>  </bean>
>
> </beans>
>
> You can use <ref bean=3D"bpe.jbpmServiceFactory"/> to set the JBPM
> service factory in your beans, now you have access to
> JbpmServiceFactory services.
>
> Regards.
>
I could see a specialized FactoryBean to create different types of
services e.g. DefinitionService, ExecutionService, SchedulerService, so
these services could be directly injected into interested beans. Would
anyone be interested to see this support in Spring core?

Regards,
Dmitriy.


-------------------------------------------------------
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-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user

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

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

Good analysis, Colin!
=20
I've just fixed both problems, hopefully: getBeansOfType simply ignores =
beans for which getType itself fails with a BeanCreationException, which =
usually indicates a FactoryBean that couldn't be properly created. The =
BeanFactory will automatically remove such failed instances from the =
singleton cache anyway, so we don't even have to worry about cleanup.
=20
This should cover both scenarios: "lazy-init" markers for FactoryBeans =
that should never be created (of course it's recommended to use =
"abstract" here), as well as FactoryBeans that cause circular references =
during the type check.
=20
Note that both problems just arise with FactoryBeans and autowiring by =
type - plain bean definitions or FactoryBeans without autowiring or with =
autowiring by name shouldn't cause such headaches!
=20
BTW, in total, autowiring by type is a quite expensive operation. This =
doesn't really matter for singletons that get created on startup, but it =
certainly shows effect for prototypes. We would have to think about =
special mechanisms to speed this up, for example caching getBeansOfType =
results per given type (not for 1.1.4, though, I guess).
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Do 23.12.2004 05:47
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: =
FactoryBeanCircularReferenceException with 1.1.3



Juergen,

I have done some digging into this. There are in fact two levels to this
issue.

What I am referring to is the fact that from 1.1.1 to 1.1.2, when
getBeansOfType (as used for autowiring) is called, 1.1.2+ ends up
creating all factory beans so that it can call getObjectType() on them
to see if the returned type is a match. 1.1.1 and earlier did not do
this. Where I saw people get surprised by this is for abstract parent
classes that were not marked abstract, but rather just lazy. The parent
factory bean (like the TransactionProxyFactory) would get created, and
it would except. Now in the case of the abstract parent the solution is
just to mark it abstract, no big deal.

Now I think this also triggered this circular dependency problem
mentioned below. In 1.1.1 the factory beans would not get created for
the getBeansOfType(), while now they do, and in Patrick's case he got
the circular dependency error as Spring though two beans were depending
on each other. Now I don't necessarilly know enough about his config to
know if there is a real bug here that could be fixed in Spring, or there
is now a real circular dependency now that the factory bean is actually
being created. Sounds like the latter.

Aside from the circular dependency issue, there is the basic question of
whether getBeansOfType() as used for autowiring should even consider
factory beans (controlled by the 'includeFactoryBeans flag) as it does
now, or should not, as it worked for 1.1.1-. I sort of think the current
behaviour makes sense, otherwise you will miss autowiring anything
produced by FactoryBeans that have not already been instantiated.
Additionally, most singletons will be pre-instantiated anyway. On the
other hand, for a singleton marked lazy-init, that was probably for a
reason. And the factory bean return type may not match the type, or
return null, in which case it will be ignored anyway. This is sort of a
chicken and egg thing, you don't want to create it if you don't need it,
but you don't know if you need it until you create it... One possible
solution I can see for this case is to add an optional "type" attribute
which may be set on a bean def (and is only relevant for factory beans).
If this exists, it would be used in lieu of a getObjectType() call on
the  factory bean itself.

Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>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.
>
>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.
>
>Juergen
>
>
>________________________________
>
>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:
>=20
>
>>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:
>>
>>  =20
>>
>>>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:
>>>
>>>
>>>    =20
>>>
>>>>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
>>>>      =20
>>>>



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

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

[Steven D. <ste...@gm...>]

Colin,

This is slightly off-topic but while you are talking about the object
type parameter on factory beans I have a requirement where I would
like factory beans to return more than one class type. This is for the
case where tens or hunderds of different types need to be factored.
Adding a factory bean for every one of these types in the config is
unrealistic, a multi-class factory bean would in my view be the only
really flexible solution.

The multi class factory bean could look like this:

public Object getObject(Class);
public Class[] getObjectTypes();

Currently I would implement this behavior by using one factory bean
that returns one very big class that implements multiple interfaces.
That's only doable if there are not naming clashes between the methods
of the different interfaces.

So if you are going to add a type attribute to the config would you be
able to take the multiple class factory bean scenario in mind?

Thanks

Steven


On Wed, 22 Dec 2004 23:47:27 -0500, Colin Sampaleanu <col...@ex...> wr=
ote:
> Juergen,
>=20
> I have done some digging into this. There are in fact two levels to this
> issue.
>=20
> What I am referring to is the fact that from 1.1.1 to 1.1.2, when
> getBeansOfType (as used for autowiring) is called, 1.1.2+ ends up
> creating all factory beans so that it can call getObjectType() on them
> to see if the returned type is a match. 1.1.1 and earlier did not do
> this. Where I saw people get surprised by this is for abstract parent
> classes that were not marked abstract, but rather just lazy. The parent
> factory bean (like the TransactionProxyFactory) would get created, and
> it would except. Now in the case of the abstract parent the solution is
> just to mark it abstract, no big deal.
>=20
> Now I think this also triggered this circular dependency problem
> mentioned below. In 1.1.1 the factory beans would not get created for
> the getBeansOfType(), while now they do, and in Patrick's case he got
> the circular dependency error as Spring though two beans were depending
> on each other. Now I don't necessarilly know enough about his config to
> know if there is a real bug here that could be fixed in Spring, or there
> is now a real circular dependency now that the factory bean is actually
> being created. Sounds like the latter.
>=20
> Aside from the circular dependency issue, there is the basic question of
> whether getBeansOfType() as used for autowiring should even consider
> factory beans (controlled by the 'includeFactoryBeans flag) as it does
> now, or should not, as it worked for 1.1.1-. I sort of think the current
> behaviour makes sense, otherwise you will miss autowiring anything
> produced by FactoryBeans that have not already been instantiated.
> Additionally, most singletons will be pre-instantiated anyway. On the
> other hand, for a singleton marked lazy-init, that was probably for a
> reason. And the factory bean return type may not match the type, or
> return null, in which case it will be ignored anyway. This is sort of a
> chicken and egg thing, you don't want to create it if you don't need it,
> but you don't know if you need it until you create it... One possible
> solution I can see for this case is to add an optional "type" attribute
> which may be set on a bean def (and is only relevant for factory beans).
> If this exists, it would be used in lieu of a getObjectType() call on
> the  factory bean itself.
>=20
> Colin
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> >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 s=
uch cases that fail for you yet. This is the reason why it wasn't noticed t=
hat the checks became over-eager in some respects.
> >
> >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.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag vo=
n Patrick Burleson
> >Gesendet: Mi 22.12.2004 15:41
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Re: FactoryBeanCircularReferenc=
eException 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 FactoryBea=
ns.
> >>
> >>I'm not sure Juergen actually intended this change, or it's happening
> >>because he fixed some other bugs related to getBeansOfType, which I kno=
w
> >>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
>=20
> >>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 wa=
y
> >>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
> >>>>
> >>>>
>=20
> -------------------------------------------------------
> 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
>=20
>

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

[Colin S. <col...@ex...>]

Juergen,

I have done some digging into this. There are in fact two levels to this 
issue.

What I am referring to is the fact that from 1.1.1 to 1.1.2, when 
getBeansOfType (as used for autowiring) is called, 1.1.2+ ends up 
creating all factory beans so that it can call getObjectType() on them 
to see if the returned type is a match. 1.1.1 and earlier did not do 
this. Where I saw people get surprised by this is for abstract parent 
classes that were not marked abstract, but rather just lazy. The parent 
factory bean (like the TransactionProxyFactory) would get created, and 
it would except. Now in the case of the abstract parent the solution is 
just to mark it abstract, no big deal.

Now I think this also triggered this circular dependency problem 
mentioned below. In 1.1.1 the factory beans would not get created for 
the getBeansOfType(), while now they do, and in Patrick's case he got 
the circular dependency error as Spring though two beans were depending 
on each other. Now I don't necessarilly know enough about his config to 
know if there is a real bug here that could be fixed in Spring, or there 
is now a real circular dependency now that the factory bean is actually 
being created. Sounds like the latter.

Aside from the circular dependency issue, there is the basic question of 
whether getBeansOfType() as used for autowiring should even consider 
factory beans (controlled by the 'includeFactoryBeans flag) as it does 
now, or should not, as it worked for 1.1.1-. I sort of think the current 
behaviour makes sense, otherwise you will miss autowiring anything 
produced by FactoryBeans that have not already been instantiated. 
Additionally, most singletons will be pre-instantiated anyway. On the 
other hand, for a singleton marked lazy-init, that was probably for a 
reason. And the factory bean return type may not match the type, or 
return null, in which case it will be ignored anyway. This is sort of a 
chicken and egg thing, you don't want to create it if you don't need it, 
but you don't know if you need it until you create it... One possible 
solution I can see for this case is to add an optional "type" attribute 
which may be set on a bean def (and is only relevant for factory beans). 
If this exists, it would be used in lieu of a getObjectType() call on 
the  factory bean itself.

Colin

jürgen höller [werk3AT] wrote:

>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.
> 
>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.
> 
>Juergen
> 
>
>________________________________
>
>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=null), 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=true (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
>>>>        
>>>>

[Springframework-developer] spring build.176 Build Successful

[<al...@jt...>]

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#901090; }.unittests-failure { fon=
t-family:arial,helvetica,sans-serif; font-size:8pt; color:#FF0000; }.checks=
tyle-oddrow { background-color:#CCCCCC }.checkstyle-data { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; }.checkstyle-sectionh=
eader { background-color:#000066; font-family:arial,helvetica,sans-serif; f=
ont-size:10pt; color:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.176</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>12/23/2004 00:16:47</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>22 minutes 2 seconds</td></tr><tr><td class=3D"header-data"><span=
 class=3D"header-label">Last changed:&nbsp;</span>12/22/2004 17:59:59</td><=
/tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log ent=
ry:&nbsp;</span>added ServletContextAttributeFactoryBean, ServletContextAtt=
ributeExporter, ServletContextPropertyPlaceholderConfigurer</td></tr></tabl=
e><p>
<p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-data">Note: S=
ome input files use or override a deprecated API.<br class=3D"none"/>Note: =
Recompile with -deprecation for details.<br class=3D"none"/>Note: /jteam/bu=
ild2/checkout/spring/spring/mock/org/springframework/mock/web/MockHttpSessi=
on.java uses or overrides a deprecated API.<br class=3D"none"/>Note: Recomp=
ile with -deprecation for details.<br class=3D"none"/>Note: Some input file=
s use or override a deprecated API.<br class=3D"none"/>Note: Recompile with=
 -deprecation for details.<br class=3D"none"/></pre></td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Javadoc Errors/War=
nings: (26)                    </td></tr><tr><td><pre class=3D"compile-data=
">/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc/support=
/lob/OracleLobHandler.java:76: warning - Tag @see: reference not found: ora=
cle.sql.BLOB<br/>/jteam/build2/checkout/spring/spring/src/org/springframewo=
rk/jdbc/support/lob/OracleLobHandler.java:76: warning - Tag @see: reference=
 not found: oracle.sql.CLOB<br/>/jteam/build2/checkout/spring/spring/src/or=
g/springframework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag=
 @see: reference not found: oracle.sql.BLOB#DURATION_SESSION<br/>/jteam/bui=
ld2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/OracleL=
obHandler.java:115: warning - Tag @see: reference not found: oracle.sql.BLO=
B#MODE_READWRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springfra=
mework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag @see: refe=
rence not found: oracle.sql.CLOB#DURATION_SESSION<br/>/jteam/build2/checkou=
t/spring/spring/src/org/springframework/jdbc/support/lob/OracleLobHandler.j=
ava:115: warning - Tag @see: reference not found: oracle.sql.CLOB#MODE_READ=
WRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc=
/support/lob/OracleLobHandler.java:154: warning - Tag @see: reference not f=
ound: oracle.jdbc.OracleConnection<br/>/jteam/build2/checkout/spring/spring=
/src/org/springframework/jdbc/support/lob/OracleLobHandler.java:164: warnin=
g - Tag @see: reference not found: oracle.sql.BLOB#createTemporary<br/>/jte=
am/build2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/O=
racleLobHandler.java:164: warning - Tag @see: reference not found: oracle.s=
ql.CLOB#createTemporary<br/>/jteam/build2/checkout/spring/spring/src/org/sp=
ringframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor.java:49: war=
ning - Tag @see: reference not found: org.jboss.resource.adapter.jdbc.Wrapp=
edConnection#getUnderlyingConnection<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor=
.java:49: warning - Tag @see: reference not found: org.jboss.resource.adapt=
er.jdbc.WrappedStatement#getUnderlyingStatement<br/>/jteam/build2/checkout/=
spring/spring/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJd=
bcExtractor.java:49: warning - Tag @see: reference not found: org.jboss.res=
ource.adapter.jdbc.WrappedResultSet#getUnderlyingResultSet<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bLogicNativeJdbcExtractor.java:45: warning - Tag @see: reference not found:=
 weblogic.jdbc.extensions.WLConnection#getVendorConnection<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bSphereNativeJdbcExtractor.java:34: warning - Tag @see: reference not found=
: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:34: warning - Tag @see: reference not found: com.ibm.ws.r=
sadapter.jdbc.WSJdbcUtil#getNativeConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:34: warning - Tag @see: reference not found: com.ibm.ejs.=
cm.proxy.ConnectionProxy#getPhysicalConnection<br/>/jteam/build2/checkout/s=
pring/spring/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.jav=
a:170: warning - Tag @see: reference not found: com.ibatis.sqlmap.engine.tr=
ansaction.jdbc.JdbcTransactionConfig<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.java:170: war=
ning - Tag @see: reference not found: com.ibatis.sqlmap.engine.transaction.=
jta.JtaTransactionConfig<br/>/jteam/build2/checkout/spring/spring/src/org/s=
pringframework/orm/ibatis/SqlMapClientFactoryBean.java:198: warning - Tag @=
see: reference not found: com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTra=
nsactionConfig<br/>/jteam/build2/checkout/spring/spring/src/org/springframe=
work/orm/ibatis/SqlMapClientFactoryBean.java:198: warning - Tag @see: refer=
ence not found: com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConf=
ig<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/transac=
tion/jta/WebLogicJtaTransactionManager.java:67: warning - Tag @see: referen=
ce not found: weblogic.transaction.TransactionManager#forceResume<br/>/jtea=
m/build2/checkout/spring/spring/src/org/springframework/transaction/jta/Web=
LogicServerTransactionManagerFactoryBean.java:45: warning - Tag @see: refer=
ence not found: weblogic.transaction.TxHelper#getTransactionManager<br/>/jt=
eam/build2/checkout/spring/spring/src/org/springframework/transaction/jta/W=
ebSphereTransactionManagerFactoryBean.java:47: warning - Tag @see: referenc=
e not found: com.ibm.ws.Transaction.TransactionManagerFactory#getTransactio=
nManager<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/t=
ransaction/jta/WebSphereTransactionManagerFactoryBean.java:47: warning - Ta=
g @see: reference not found: com.ibm.ejs.jts.jta.JTSXA#getTransactionManage=
r<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/transact=
ion/jta/WebSphereTransactionManagerFactoryBean.java:47: warning - Tag @see:=
 reference not found: com.ibm.ejs.jts.jta.TransactionManagerFactory#getTran=
sactionManager<br/>/jteam/build2/checkout/spring/spring/src/org/springframe=
work/web/servlet/handler/metadata/PathMap.java:31: warning - @@org.apache.c=
ommons.attributes.Indexed() is an unknown tag.<br/></pre></td></tr></table>=
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (2137)                </td></tr><tr><td class=
=3D"unittests-data" colspan=3D"2">                            All Tests Pas=
sed                        </td></tr><tr><td><table width=3D"98%" border=3D=
"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"></table></td></tr>=
<tr></tr><tr><td colspan=3D"2">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"1" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"6" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (20)                </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
jhoeller</td><td class=3D"modifications-data">changelog.txt</td><td class=
=3D"modifications-data">added ServletContextAttributeFactoryBean, ServletCo=
ntextAttributeExporter, ServletContextPropertyPlaceholderConfigurer</td></t=
r><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modif=
ied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modifica=
tions-data">src/org/springframework/jndi/JndiObjectFactoryBean.java</td><td=
 class=3D"modifications-data">improved javadoc</td></tr><tr class=3D"modifi=
cations-evenrow"><td class=3D"modifications-data">modified</td><td class=3D=
"modifications-data">jhoeller</td><td class=3D"modifications-data">src/org/=
springframework/beans/factory/support/AbstractBeanFactory.java</td><td clas=
s=3D"modifications-data">added not-null assertions</td></tr><tr class=3D"mo=
difications-oddrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">src/o=
rg/springframework/beans/factory/config/PropertyPlaceholderConfigurer.java<=
/td><td class=3D"modifications-data">factored out system property resolutio=
n into overloaded "resolvePlaceholder" method</td></tr><tr class=3D"modific=
ations-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"=
modifications-data">jhoeller</td><td class=3D"modifications-data">src/org/s=
pringframework/aop/framework/adapter/AdvisorAdapterRegistrationManager.java=
</td><td class=3D"modifications-data">polishing</td></tr><tr class=3D"modif=
ications-oddrow"><td class=3D"modifications-data">modified</td><td class=3D=
"modifications-data">jhoeller</td><td class=3D"modifications-data">src/org/=
springframework/context/support/ApplicationContextAwareProcessor.java</td><=
td class=3D"modifications-data">polishing</td></tr><tr class=3D"modificatio=
ns-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">jhoeller</td><td class=3D"modifications-data">src/org/sprin=
gframework/web/struts/ActionServletAwareProcessor.java</td><td class=3D"mod=
ifications-data">polishing</td></tr><tr class=3D"modifications-oddrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
jhoeller</td><td class=3D"modifications-data">src/org/springframework/web/c=
ontext/support/ServletContextAwareProcessor.java</td><td class=3D"modificat=
ions-data">added not-null check for ServletContext reference</td></tr><tr c=
lass=3D"modifications-evenrow"><td class=3D"modifications-data">added</td><=
td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-dat=
a">test/org/springframework/web/context/support/ServletContextSupportTests.=
java</td><td class=3D"modifications-data">added ServletContextAttributeFact=
oryBean, ServletContextAttributeExporter, ServletContextPropertyPlaceholder=
Configurer</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modific=
ations-data">added</td><td class=3D"modifications-data">jhoeller</td><td cl=
ass=3D"modifications-data">src/org/springframework/web/context/support/Serv=
letContextAttributeExporter.java</td><td class=3D"modifications-data">added=
 ServletContextAttributeFactoryBean, ServletContextAttributeExporter, Servl=
etContextPropertyPlaceholderConfigurer</td></tr><tr class=3D"modifications-=
evenrow"><td class=3D"modifications-data">added</td><td class=3D"modificati=
ons-data">jhoeller</td><td class=3D"modifications-data">src/org/springframe=
work/web/context/support/ServletContextAttributeFactoryBean.java</td><td cl=
ass=3D"modifications-data">added ServletContextAttributeFactoryBean, Servle=
tContextAttributeExporter, ServletContextPropertyPlaceholderConfigurer</td>=
</tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">ad=
ded</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modifica=
tions-data">src/org/springframework/web/context/support/ServletContextPrope=
rtyPlaceholderConfigurer.java</td><td class=3D"modifications-data">added Se=
rvletContextAttributeFactoryBean, ServletContextAttributeExporter, ServletC=
ontextPropertyPlaceholderConfigurer</td></tr><tr class=3D"modifications-eve=
nrow"><td class=3D"modifications-data">modified</td><td class=3D"modificati=
ons-data">jhoeller</td><td class=3D"modifications-data">src/org/springframe=
work/orm/hibernate/HibernateTemplate.java</td><td class=3D"modifications-da=
ta">fixed code examples in javadoc</td></tr><tr class=3D"modifications-oddr=
ow"><td class=3D"modifications-data">modified</td><td class=3D"modification=
s-data">jhoeller</td><td class=3D"modifications-data">src/org/springframewo=
rk/jdbc/datasource/DataSourceTransactionManager.java</td><td class=3D"modif=
ications-data">polishing</td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">src/org/springframework/orm/hi=
bernate/HibernateTransactionManager.java</td><td class=3D"modifications-dat=
a">added check for pre-bound JDBC connection</td></tr><tr class=3D"modifica=
tions-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"mo=
difications-data">jhoeller</td><td class=3D"modifications-data">src/org/spr=
ingframework/orm/ojb/PersistenceBrokerTransactionManager.java</td><td class=
=3D"modifications-data">added check for pre-bound JDBC connection</td></tr>=
<tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modifi=
ed</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modificat=
ions-data">src/org/springframework/orm/jdo/JdoTransactionManager.java</td><=
td class=3D"modifications-data">added check for pre-bound JDBC connection</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mo=
difications-data">mock/org/springframework/mock/web/MockHttpServletRequest.=
java</td><td class=3D"modifications-data">fixed "setAttribute" to correctly=
 handle null values</td></tr><tr class=3D"modifications-evenrow"><td class=
=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoel=
ler</td><td class=3D"modifications-data">mock/org/springframework/mock/web/=
MockHttpSession.java</td><td class=3D"modifications-data">fixed "setAttribu=
te" to correctly handle null values</td></tr><tr class=3D"modifications-odd=
row"><td class=3D"modifications-data">modified</td><td class=3D"modificatio=
ns-data">jhoeller</td><td class=3D"modifications-data">mock/org/springframe=
work/mock/web/MockServletContext.java</td><td class=3D"modifications-data">=
fixed "setAttribute" to correctly handle null values</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(16)                    </td>=
</tr><tr><td class=3D"distributables-data">Building jar: /jteam/build2/chec=
kout/spring/spring/dist/spring-core.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building jar: /jteam/build2/che=
ckout/spring/spring/dist/spring-aop.jar</td></tr><tr><td class=3D"distribut=
ables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spring-=
context.jar</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distr=
ibutables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spr=
ing-dao.jar</td></tr><tr><td class=3D"distributables-data">Building jar: /j=
team/build2/checkout/spring/spring/dist/spring-orm.jar</td></tr><tr class=
=3D"distributables-oddrow"><td class=3D"distributables-data">Building jar: =
/jteam/build2/checkout/spring/spring/dist/spring-web.jar</td></tr><tr><td c=
lass=3D"distributables-data">Building jar: /jteam/build2/checkout/spring/sp=
ring/dist/spring-webmvc.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building jar: /jteam/build2/checkout/spring=
/spring/dist/spring.jar</td></tr><tr><td class=3D"distributables-data">Buil=
ding jar: /jteam/build2/checkout/spring/spring/dist/spring-mock.jar</td></t=
r><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bui=
lding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/d=
ist/buildtest.war</td></tr><tr><td class=3D"distributables-data">Building w=
ar: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/dist/bui=
ldtest.war</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distri=
butables-data">Building war: /jteam/build2/checkout/spring/spring/autobuild=
s/apps/buildtest/dist/buildtest.war</td></tr><tr><td class=3D"distributable=
s-data">Building jar: /jteam/build2/checkout/spring/spring/autobuilds/apps/=
jpetstore/war/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building war: /jteam/build2/che=
ckout/spring/spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr><=
tr><td class=3D"distributables-data">Building jar: /jteam/build2/checkout/s=
pring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar</td></=
tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bu=
ilding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/jpetstore/=
dist/jpetstore.war</td></tr></table>
</body></html>

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

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

[Patrick B. <pbu...@gm...>]

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=null), 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=true (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
>

Re: [Springframework-developer] JasperReports Support

[Patrick B. <pbu...@gm...>]

Juergen,

Well, it turns out, that is what I decided to do. My reporting service
will throw a "ReportingException" that will basically wrap the
JapserReports exception as a runtime exception.

Thanks for the insight into why it was designed that way in Spring. It
does make sense to do it that way.

Patrick



On Wed, 22 Dec 2004 15:29:48 +0100, j=FCrgen h=F6ller [ werk3AT ]
<jue...@we...> wrote:
> Hi Patrick,
>=20
> I assume you're referring to the JasperReportsUtils class here, as the we=
b view support does not require explicit exception handling in the first pl=
ace.
>=20
> That utility class is meant to be used for non-web usage of JasperReports=
, analogous to our existing VelocityEngineUtils and FreeMarkerTemplateUtils=
 classes. Like the latter two, it throws the native exception of the respec=
tive tool.
>=20
> In application code, such exceptions are supposed to be wrapped in contex=
t-sensitive exceptions, for example MailPreparationException if preparing m=
ail context for use with Spring's mail support. Failure to render templates=
 should always result in meaningful error message for the user, for example=
 "could not generate annual report data for report mail", instead of some "=
invalid expression in template file xxx" message.
>=20
> Of course, one could argue that generic RuntimeExceptions wouldn't hurt h=
ere either. Usually template/report rendering is part of a larger operation=
, though, so wrapping in a context-sensitive exception should be a natural =
thing to do.
>=20
> Juergen
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von=
 Patrick Burleson
> Gesendet: Di 21.12.2004 22:15
> An: spr...@li...
> Betreff: [Springframework-developer] JasperReports Support
>=20
>=20
> So I was checking out the JasperReports support stuff in 1.1.3. Good
> work there. My only question is, why not wrap JS's checked Exception
> with a RuntimeException? JS Execptions don't seem to be too
> recoverable.
>=20
> Patrick
>=20
>=20
> -------------------------------------------------------
> 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
>=20
> -------------------------------------------------------
> 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
>

Re: [Springframework-developer] JasperReports Support

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

Hi Patrick,
=20
I assume you're referring to the JasperReportsUtils class here, as the =
web view support does not require explicit exception handling in the =
first place.
=20
That utility class is meant to be used for non-web usage of =
JasperReports, analogous to our existing VelocityEngineUtils and =
FreeMarkerTemplateUtils classes. Like the latter two, it throws the =
native exception of the respective tool.
=20
In application code, such exceptions are supposed to be wrapped in =
context-sensitive exceptions, for example MailPreparationException if =
preparing mail context for use with Spring's mail support. Failure to =
render templates should always result in meaningful error message for =
the user, for example "could not generate annual report data for report =
mail", instead of some "invalid expression in template file xxx" =
message.
=20
Of course, one could argue that generic RuntimeExceptions wouldn't hurt =
here either. Usually template/report rendering is part of a larger =
operation, though, so wrapping in a context-sensitive exception should =
be a natural thing to do.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Patrick Burleson
Gesendet: Di 21.12.2004 22:15
An: spr...@li...
Betreff: [Springframework-developer] JasperReports Support



So I was checking out the JasperReports support stuff in 1.1.3. Good
work there. My only question is, why not wrap JS's checked Exception
with a RuntimeException? JS Execptions don't seem to be too
recoverable.

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

Re: [Springframework-developer] Re: H3 support

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

Yes, I intend to put Hibernate 3 support into the =
"org.springframework.orm.hibernate3" package, and continue to support =
our current Hibernate 2.1 integration for some time to come. Hibernate 3 =
has explicitly been designed to co-exist with Hibernate 2.1 in the same =
application, if necessary, so there shouldn't be any problems in that =
respect.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Dmitriy Kopylenko
Gesendet: Di 21.12.2004 20:21
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: H3 support



+1 for H3 support in 1.2 (this will fit nicely into our schedule as we
starting a brand new app in January and I'm planning to use Spring/H3
combination)

Also, what is the strategy of maintaining support for 2 branches of
Hibernate - 2.x and 3.x Will 3.x support go into its own module e.g.
"o.s.orm.hibernate3"?

Thanks,
Dmitriy.

j=FCrgen h=F6ller [werk3AT] wrote:

>The current plan is to ship Hibernate 3 support in Spring 1.2, starting =
with 1.2 RC1 which is scheduled for early February. That should coincide =
nicely with Hibernate 3's release schedule; there might be a release =
candidate out there too by early February.
>
>Alternatively, we could go for Hibernate 3 support in the upcoming =
Spring 1.1.4, but I'm not fond of that for a variety of reasons: =
Hibernate 3 is still beta, support for it is actually a major new =
feature that's worth of a Spring 1.x release, and there's potential for =
a lot of subtle bugs in Hibernate 3 support (which we should be able to =
address in a proper sequence of releases, like in 1.2 RC1 -> RC2 -> =
final).
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Artur Karazniewicz
>Gesendet: Di 21.12.2004 18:57
>An: spr...@li...
>Betreff: [Springframework-developer] Re: H3 support
>
>
>
>Dmitriy Kopylenko wrote:
>
>=20
>
>>I know it has been discussed before, but again, since Hibernate 3 =
beta1
>>is out and they plan to release final in Q1 of 2005, how do we go =
about
>>support/integration, if ever?
>>  =20
>>
>
>+1
>
>I'v worked with HB3 alpha from the begining. Everything works well - =
even
>deployed minor project based on HB3 alpha without any problems. Would =
be
>nice to see support for HB3 in sandbox. I think good start point is the
>patch I added to JIRA some time ago.
>
>Artur
>
>
>
>-------------------------------------------------------
>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
>=20
>




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

[Springframework-developer] spring-beandoc

[Darren D. <da...@da...>]

I've spent some more time on this and have now added the sources to CVS. =
 It's
very much to be considered alpha software with some design flaws, missing
functionality and implementation bugs.  A lot of work is still needed on =
the
output too (willing volunteers with good XSL/HTML/CSS and web design skil=
ls
required!)

Latest output from the JPetstore context files can be seen at
<http://springframework.sourceforge.net/beandoc/>

Allow me to take this opportunity to wish everyone a very Merry Christmas=
 and
happy New Year!

Regards,
--=20
Darren Davison
Public Key: #DD356B0D

[Springframework-developer] new Spring article on javalobby

[Steven D. <ste...@gm...>]

Hi,

There's a new article on Spring at JavaLobby. Could you please put it
in the Spring web site?

http://www.javalobby.com

Thanks

Steven Devijver

Re: [Springframework-developer] Re: H3 support

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

I agree on all counts.

I think Hibernate 2 support will remain important for the foreseeable future, due to the number of 
production apps on Hibernate 2. Many of those might benefit from Hibernate 3, but not enough to 
justify migration if they're working just fine on H2.

R

jürgen höller [werk3AT] wrote:
> The current plan is to ship Hibernate 3 support in Spring 1.2, starting with 1.2 RC1 which is scheduled for early February. That should coincide nicely with Hibernate 3's release schedule; there might be a release candidate out there too by early February.
>  
> Alternatively, we could go for Hibernate 3 support in the upcoming Spring 1.1.4, but I'm not fond of that for a variety of reasons: Hibernate 3 is still beta, support for it is actually a major new feature that's worth of a Spring 1.x release, and there's potential for a lot of subtle bugs in Hibernate 3 support (which we should be able to address in a proper sequence of releases, like in 1.2 RC1 -> RC2 -> final).
>  
> Juergen
>  
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von Artur Karazniewicz
> Gesendet: Di 21.12.2004 18:57
> An: spr...@li...
> Betreff: [Springframework-developer] Re: H3 support
> 
> 
> 
> Dmitriy Kopylenko wrote:
> 
> 
>>I know it has been discussed before, but again, since Hibernate 3 beta1
>>is out and they plan to release final in Q1 of 2005, how do we go about
>>support/integration, if ever?
> 
> 
> +1
> 
> I'v worked with HB3 alpha from the begining. Everything works well - even
> deployed minor project based on HB3 alpha without any problems. Would be
> nice to see support for HB3 in sandbox. I think good start point is the
> patch I added to JIRA some time ago.
> 
> Artur
> 
> 
> 
> -------------------------------------------------------
> 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
> 

-- 

____________________________________________________
Rod Johnson
CEO, Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________

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

[Colin S. <col...@ex...>]

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=null), 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=true (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
>>    
>>

[Springframework-developer] JasperReports Support

[Patrick B. <pbu...@gm...>]

So I was checking out the JasperReports support stuff in 1.1.3. Good
work there. My only question is, why not wrap JS's checked Exception
with a RuntimeException? JS Execptions don't seem to be too
recoverable.

Patrick

Re: [Springframework-developer] Re: H3 support

[Dmitriy K. <dko...@ru...>]

+1 for H3 support in 1.2 (this will fit nicely into our schedule as w=
e=20
starting a brand new app in January and I'm planning to use Spring/H3=
=20
combination)

Also, what is the strategy of maintaining support for 2 branches of=
=20
Hibernate - 2.x and 3.x Will 3.x support go into its own module e.g.=
=20
"o.s.orm.hibernate3"?

Thanks,
Dmitriy.

j=FCrgen h=F6ller [werk3AT] wrote:

>The current plan is to ship Hibernate 3 support in Spring 1.2, start=
ing with 1.2 RC1 which is scheduled for early February. That should c=
oincide nicely with Hibernate 3's release schedule; there might be a =
release candidate out there too by early February.
>=20
>Alternatively, we could go for Hibernate 3 support in the upcoming S=
pring 1.1.4, but I'm not fond of that for a variety of reasons: Hiber=
nate 3 is still beta, support for it is actually a major new feature =
that's worth of a Spring 1.x release, and there's potential for a lot=
 of subtle bugs in Hibernate 3 support (which we should be able to ad=
dress in a proper sequence of releases, like in 1.2 RC1 -> RC2 -> fin=
al).
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftra=
g von Artur Karazniewicz
>Gesendet: Di 21.12.2004 18:57
>An: spr...@li...
>Betreff: [Springframework-developer] Re: H3 support
>
>
>
>Dmitriy Kopylenko wrote:
>
> =20
>
>>I know it has been discussed before, but again, since Hibernate 3 b=
eta1
>>is out and they plan to release final in Q1 of 2005, how do we go a=
bout
>>support/integration, if ever?
>>   =20
>>
>
>+1
>
>I'v worked with HB3 alpha from the begining. Everything works well -=
 even
>deployed minor project based on HB3 alpha without any problems. Woul=
d be
>nice to see support for HB3 in sandbox. I think good start point is =
the
>patch I added to JIRA some time ago.
>
>Artur
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real us=
ers.
>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-develop=
er
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real us=
ers.
>Discover which products truly live up to the hype. Start reading now=
.=20
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-develop=
er
> =20
>

Re: [Springframework-developer] Re: H3 support

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

The current plan is to ship Hibernate 3 support in Spring 1.2, starting =
with 1.2 RC1 which is scheduled for early February. That should coincide =
nicely with Hibernate 3's release schedule; there might be a release =
candidate out there too by early February.
=20
Alternatively, we could go for Hibernate 3 support in the upcoming =
Spring 1.1.4, but I'm not fond of that for a variety of reasons: =
Hibernate 3 is still beta, support for it is actually a major new =
feature that's worth of a Spring 1.x release, and there's potential for =
a lot of subtle bugs in Hibernate 3 support (which we should be able to =
address in a proper sequence of releases, like in 1.2 RC1 -> RC2 -> =
final).
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Artur Karazniewicz
Gesendet: Di 21.12.2004 18:57
An: spr...@li...
Betreff: [Springframework-developer] Re: H3 support



Dmitriy Kopylenko wrote:

> I know it has been discussed before, but again, since Hibernate 3 =
beta1
> is out and they plan to release final in Q1 of 2005, how do we go =
about
> support/integration, if ever?

+1

I'v worked with HB3 alpha from the begining. Everything works well - =
even
deployed minor project based on HB3 alpha without any problems. Would be
nice to see support for HB3 in sandbox. I think good start point is the
patch I added to JIRA some time ago.

Artur



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

[Springframework-developer] Re: H3 support

[Artur K. <kar...@as...>]

Dmitriy Kopylenko wrote:

> I know it has been discussed before, but again, since Hibernate 3 beta1
> is out and they plan to release final in Q1 of 2005, how do we go about
> support/integration, if ever?

+1

I'v worked with HB3 alpha from the begining. Everything works well - even
deployed minor project based on HB3 alpha without any problems. Would be
nice to see support for HB3 in sandbox. I think good start point is the
patch I added to JIRA some time ago.

Artur

[Springframework-developer] Re: FactoryBeanCircularReferenceException with 1.1.3

[Patrick B. <pbu...@gm...>]

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
>

[Springframework-developer] FactoryBeanCircularReferenceException with 1.1.3

[Patrick B. <pbu...@gm...>]

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

[Springframework-developer] H3 support

[Dmitriy K. <dko...@ru...>]

I know it has been discussed before, but again, since Hibernate 3 beta1 
is out and they plan to release final in Q1 of 2005, how do we go about 
support/integration, if ever?

Regards,
Dmitriy.

Re: [asm] Re: [Springframework-developer] ASM commons

[Dmitriy K. <dko...@ru...>]

>- we already have support for AOP alliance aspects on top of AWProxy
>or hooked in CGLib proxy, and this with the AW statically compiled
>performance [for sure, still needs to create the object arrays args,
>wrap / cast everything etc]
>
>  
>
Alex, can you please point out where I could find AOP Alliance support 
code for AWProxy? Is it in cvs?

Thanks,
Dmitriy.

Re: [asm] Re: [Springframework-developer] ASM commons

[Alexandre V. <ava...@gm...>]

well as I said, the AW Proxy is fairly useless alone, and our need in
AW is not in the proxy, but actually
- a method hook to post process the bytecode of the proxy
- a kind of mechanism to map a proxy class name to the class name its
proxies, so that a matching engine can handle the match for f.e.
execution(* Target.doSome(..)) in a transparent way when it gets the
proxy class information of Target (be it implements based or extends
based).
- that proxy classes have the same annotations of the class it proxies
(this is the case in AWProxy, don't know for f.e. Cglib)

This indeed fit well in a ASM common, though a bit too small to
deserve a dedicated name  ? [aside it is not that tied to ASM]

As regards which AOP things will be possible to bind to the proxy, I
consider it out of the scope since
- we already have many proxy based AOP, unless the goal is to impl the
RI of AOP Alliance on top of proxies in a joint effort [ is that the
goal ?]
- we already have support for AOP alliance aspects on top of AWProxy
or hooked in CGLib proxy, and this with the AW statically compiled
performance [for sure, still needs to create the object arrays args,
wrap / cast everything etc]

So what should be the exact scope and user value of ASM common ?

Alex
[PS: replying to all lists but don't know if I am subsribed to all so
please accept my post if you have to moderate it and let me know so
that I subscribe to the missing list(s)]




On Mon, 20 Dec 2004 20:44:23 +0000, Rob Harrop <ro...@ca...> wrote:
> Eugene,
> 
> I like the idea and I am more than willing to help. It would be great to
> provide a common framework for this kind of thing along with commons
> support for the AOP Alliance interfaces which will allow for the
> construction of really high performance AOP proxies.
> 
> Rob
> 
> Eugene Kuleshov wrote:
> 
> > Folks,
> >
> >   Sorry for the cross posting, but I'd like to make a formal proposal
> > for coordinated efford to generalize some of the common bytecode
> > transformations with ASM.
> >
> >   It has been identified that Spring, AspectWerkz, CGLIB and DynAop
> > (indirectly trough CGLIB) projects have needs for "class proxy"
> > bytecode transformation. So, it seems makes sense to implement
> > something common and generic enoigh to be used across all projects.
> >
> >   Thank you.
> >
> >   Eugene
> >
> >
> > BRUNETON Eric RD-MAPS-GRE wrote:
> >
> > [skipped]
> >
> >> ... This could be an opportunity to start a new asm.adapters package
> >> containing commonly used adapters (the starting point could be a review
> >> of existing ASM adapters in CGLIB, AspectWerkz, ... to see if some
> >> abstract or even concrete transformers can be shared - after a
> >> generalization step, to make them customizable and reusable). This could
> >> be a common effort of the ASM community.
> >>
> >> Eric
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
> 
> 
> 
> --
> You receive this message as a subscriber of the as...@ob... mailing list.
> To unsubscribe: mailto:asm...@ob...
> For general help: mailto:sy...@ob...?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
> 
> 
>