springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Release plan

[Kopylenko, D. <dko...@ac...>]

+1 for M4. I would agree that the docs should be in "good shape" by the =
time
of RC and final.

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Tuesday, December 02, 2003 9:27 AM
To: spr...@li...
Subject: [Springframework-developer] Release plan


Guys,

We need to settle on a concrete roadmap.

Despite our initial plans to go straight to RC1, I'm inclined to vote =
for an
M4 in two weeks' time, with the significant reworkings that have been
introduced in the meantime (in the bean factory and AOP area), with the
current state of the docs, and still with CGLIB1. We can also introduce =
our
JPetStore version with that release.

I suggest to target RC1 for early January then, with CGLIB2 and - most
importantly - a proper reference manual. In the ideal case, 1.0 final =
could
be ready at the end of January. M4 would correspond to a feature =
freeze,
with full concentration on bugfixes and docs afterwards. RC1 should =
already
be as good as it gets, a true "release candidate".

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
Matthew E. Porter
Sent: Monday, December 01, 2003 6:37 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Hibernate 2.1 and CGLIB


This was a good answer since it provides a roadmap.  Can someone post=20
this on the wiki or the website for others who may have the same=20
question?


Cheers,
   matthew

On Dec 1, 2003, at 11:04 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Hi Matthew,
>
> We've been discussing that for a while. If Hibernate 2.1 gets final
> early enough (and it seems to, being already in RC1 stage), we will=20
> switch to it for our 1.0 RCs. If 2.1 would still be far from final, =
we=20
> would probably have to support both CGLIB1 and CGLIB2 somehow.=20
> Fortunately, that seems not to be necessary anymore!
>
> For the time being, if you don't proxy full classes (but just
> interfaces) or don't use Spring AOP in the first place, you should be =

> able to work with Hibernate 2.1 and its CGLIB2 without hassle. The=20
> same will apply to Hibernate 2.0 users after we've moved to CGLIB2:=20
> You don't need to worry if you don't use Spring AOP will full =
proxies.
>
> I think we can live with requiring an update to Hibernate 2.1 if a
> user wants full AOP proxies in combination. Actually, we probably=20
> *need* to move to CGLIB2 once Hibernate 2.1 final is released: Power=20
> users will want to combine full Spring AOP proxying with the current=20
> Hibernate version, not with a previous one.
>
> Now it would be really great if CGLIB2 were final too until Spring =
1.0
> final! :-) It's no problem to ship a CGLIB2 beta with our upcoming=20
> Spring 1.0 RC1, but it worries me to include a CGLIB2 beta in Spring=20
> 1.0 final. Haven't the Hibernate guys the same problem? Or are they=20
> fine with shipping a CGLIB2 beta with Hibernate 2.1 final?
>
> So I suggest to release our 1.0 RC1 shortly after Hibernate 2.1 =
final,
> already with CGLIB2 support. As I said, we will just force users with =

> full AOP proxies to upgrade to Hibernate 2.1 if using the two in=20
> combination. We could release a 1.0 M4 shortly before that though,=20
> still with CGLIB1 - to ease migration paths for Hibernate 2.0 users.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On=20
> Behalf Of Matthew E. Porter
> Sent: Monday, December 01, 2003 5:06 PM
> To: spr...@li...
> Subject: [Springframework-developer] Hibernate 2.1 and CGLIB
>
>
> I have looked through the mailing list archives but was unable to =
find=20
> the answer to my question.  Will Spring move to support Hibernate 2.1 =

> (as it is the new *recommended* version) and, if so, when?
>
> Also, does anyone know if I can use it now with the cglib version=20
> change?
>
>
>
> Cheers,
>    matthew
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. Does=20
> SourceForge.net help you be more productive?  Does it help you create =

> better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> http://sourceforge.net/donate/=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. Does=20
> SourceForge.net help you be more productive?  Does it help you create =

> better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> http://sourceforge.net/donate/=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive?  Does it help you create =
better
code?  SHARE THE LOVE, and help us help YOU!  Click Here:
http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive?  Does it help you create =
better
code?  SHARE THE LOVE, and help us help YOU!  Click Here:
http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Release plan

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

Guys,

We need to settle on a concrete roadmap.

Despite our initial plans to go straight to RC1, I'm inclined to vote =
for an M4 in two weeks' time, with the significant reworkings that have =
been introduced in the meantime (in the bean factory and AOP area), with =
the current state of the docs, and still with CGLIB1. We can also =
introduce our JPetStore version with that release.

I suggest to target RC1 for early January then, with CGLIB2 and - most =
importantly - a proper reference manual. In the ideal case, 1.0 final =
could be ready at the end of January. M4 would correspond to a feature =
freeze, with full concentration on bugfixes and docs afterwards. RC1 =
should already be as good as it gets, a true "release candidate".

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matthew E. Porter
Sent: Monday, December 01, 2003 6:37 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Hibernate 2.1 and CGLIB


This was a good answer since it provides a roadmap.  Can someone post=20
this on the wiki or the website for others who may have the same=20
question?


Cheers,
   matthew

On Dec 1, 2003, at 11:04 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Hi Matthew,
>
> We've been discussing that for a while. If Hibernate 2.1 gets final=20
> early enough (and it seems to, being already in RC1 stage), we will=20
> switch to it for our 1.0 RCs. If 2.1 would still be far from final, we =

> would probably have to support both CGLIB1 and CGLIB2 somehow.=20
> Fortunately, that seems not to be necessary anymore!
>
> For the time being, if you don't proxy full classes (but just=20
> interfaces) or don't use Spring AOP in the first place, you should be=20
> able to work with Hibernate 2.1 and its CGLIB2 without hassle. The=20
> same will apply to Hibernate 2.0 users after we've moved to CGLIB2:=20
> You don't need to worry if you don't use Spring AOP will full proxies.
>
> I think we can live with requiring an update to Hibernate 2.1 if a=20
> user wants full AOP proxies in combination. Actually, we probably=20
> *need* to move to CGLIB2 once Hibernate 2.1 final is released: Power=20
> users will want to combine full Spring AOP proxying with the current=20
> Hibernate version, not with a previous one.
>
> Now it would be really great if CGLIB2 were final too until Spring 1.0 =

> final! :-) It's no problem to ship a CGLIB2 beta with our upcoming=20
> Spring 1.0 RC1, but it worries me to include a CGLIB2 beta in Spring=20
> 1.0 final. Haven't the Hibernate guys the same problem? Or are they=20
> fine with shipping a CGLIB2 beta with Hibernate 2.1 final?
>
> So I suggest to release our 1.0 RC1 shortly after Hibernate 2.1 final, =

> already with CGLIB2 support. As I said, we will just force users with=20
> full AOP proxies to upgrade to Hibernate 2.1 if using the two in=20
> combination. We could release a 1.0 M4 shortly before that though,=20
> still with CGLIB1 - to ease migration paths for Hibernate 2.0 users.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Matthew E. Porter
> Sent: Monday, December 01, 2003 5:06 PM
> To: spr...@li...
> Subject: [Springframework-developer] Hibernate 2.1 and CGLIB
>
>
> I have looked through the mailing list archives but was unable to find
> the answer to my question.  Will Spring move to support Hibernate 2.1
> (as it is the new *recommended* version) and, if so, when?
>
> Also, does anyone know if I can use it now with the cglib version
> change?
>
>
>
> Cheers,
>    matthew
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring JPetStore

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

>Before I commit this initial version, I'd like to settle on a directory
name:
Should we use "samples/jpetstore", as it is still pretty close to the
original JPetStore,
and mainly serves for comparison with Clinton's version? I'm inclined to
adopt that:
Then we can still implement a clean-room own PetStore in the future, if we
feel the
need to, naming that other implementation "spetstore" or whatever.

Yes, I think this is a good distinction.

Regards,
Rod

[Springframework-developer] Spring JPetStore

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

Everybody,
=20
I've just finished an intial version of our JPetStore adaptation. =
Quoting myself from the readme:
=20
<quote>
Based on Clinton Begin's JPetStore (http://www.ibatis.com =
<http://www.ibatis.com> ).
=20
Features a Spring-managed middle tier with iBATIS Database Layer as data =
access
strategy, in combination with Spring's transaction and DAO abstractions.
Can work with local JDBC transactions or JTA, with the latter on two =
databases.
Uses the same data model and demo contents as the original JPetStore.
See "WEB-INF/applicationContext.xml" for details.
=20
Offers two alternative web tier implementations with the same user =
interface:
one based on Spring's web MVC, and one based on Struts 1.1. The latter =
is close
to the original JPetStore but reworked for JSTL, to make the JSP =
implementations
as comparable as possible. See "WEB-INF/web.xml", =
"WEB-INF/petstore-servlet.xml",
and "WEB-INF/struts-config.xml" for details.
=20
Compared to the original JPetStore, this implementation is significantly
improved in terms of internal structure and loose coupling: Leveraging =
Spring's
application context concept, there's a central place for wiring =
application
objects now. The most notable improvement is the former PetStoreLogic, =
now
called PetStoreFacade: It it not concerned with transaction details =
anymore.
=20
Note that the Spring-based web tier implementation is deliberately =
similar to
the Struts-based one and does not aim to improve in terms of in-place =
error
messages or the like. The inclusion of two web tier alternatives =
outlines the
differences as well as the similarities in the respective programming =
model,
and also illustrates the different configuration styles.
</quote>
=20
Before I commit this initial version, I'd like to settle on a directory =
name:
Should we use "samples/jpetstore", as it is still pretty close to the =
original JPetStore,
and mainly serves for comparison with Clinton's version? I'm inclined to =
adopt that:
Then we can still implement a clean-room own PetStore in the future, if =
we feel the
need to, naming that other implementation "spetstore" or whatever.
=20
Juergen
=20

[Springframework-developer] Further AOP refactoring

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

All,

Some more AOP refactoring to be aware of. Motivated partly by performance,
but also for clarity and consistency. And more thorough testing.

- There's now a new base class, ProxyConfig, to hold bean properties used in
AdvisedSupport and other proxy creators such as TransactionProxyFactoryBean.
This means that there's more control in creating a TransactionFactory bean,
over whether to force CGLIB or enable CGLIB optimizations.  Note that the
"proxyInterfacesOnly" method is gone: if you set this to false, set the
inherited "proxyTargetClass" property to false. This is consistent with
AdvisedSupport.

- There are now distinct MethodInvocation implementations and AopProxy
implementations for dynamic proxies, CGLIB and "optimized CGLIB". Note that
there appears to be code duplication here and it would be possible to
refactor the invoke or interceptor methods using a template method in the
base class, but this would add a distinct performance overhead (I've
benchmarked it). As you know, I abhor code duplication and I wouldn't do
this without good reason.
Having sep class should also help with CGLIB1/2 migration. (We could even
autodetect the CGLIB version, as the cost of creating a new proxy isn't
usually that significant: it's the cost of using it that matters.)

- All the AopProxy tests run for CGLIB, DPs and optimized CGLIB to guarantee
consistent behaviour. (Helps to cope with the code duplication also.) Hence
you'll note about 50 more tests in the suite, now up to 1103 tests.

"CGLIB subclass optimizations" mean that methods with no advice aren't
overridden. This gives a 2x performance boost for non-advised methods
(excluding the work of the method, which may of course be more significant).
However, there are some tradeoffs to be aware of in certain cases:

- To do this, the original target is copied fieldwise into the instance of
the enhanced class. This means  that the original class must have a no-arg
constructor. Also if the old target was registered as a listener for other
objects, the new class won't be.
- This doesn't work with pooling, thread local or other "dynamic"
TargetSources: only for a single shared instance
- It's impossible to change the target or TargetSource or advice thereafter.

So this is a good value optimization for shared objects without unusual
requirements: in short, it's safe most of the time.

Note that CGLIB performance should be pretty good without this agressive
optimization. With its own AopProxy using MethodProxy rather than
reflection, CGLIB seems slightly faster than dynamic proxies.

Overall, the overhead of AOP in typical usage is probably under half what it
was with M3, and 15% of what it was before then.

Regards,
Rod

Re: [Springframework-developer] Spring Enhancement

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

Rob,
=20
Spring has already been supporting a declarative "init-method" and =
"destroy-method" for quite a while, as an alternative to implementing =
InitializingBean or DisposableBean, respectively. The init method is =
called after properties population, the destroy method on factory =
shutdown. The intention behind those is exactly to be able to decouple =
classes from Spring completely.
=20
I believe those capabilities, together with constructor resolution, =
should cover 95% of everyday JavaBeans and similar components with =
non-default constructors. For anything beyond, like arbitrary method =
invocations inbetween property population, you can and should implement =
either a wrapper or a FactoryBean. It would be pretty complex to cover =
all possible scenarions here: It's probably not worth the additional =
complexity in the framework to support those final 5% with generic means =
too.
=20
BTW, a feature that Colin recently added is MethodInvokingFactoryBean, =
but that's targetting a different use case: Invoking static factory =
methods and exposing the returned object in the bean factory, for bean =
references etc. Obviously, it's not built into the bean factory core but =
rather implemented as FactoryBean.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rob Butler
Gesendet: Mo 01.12.2003 22:32
An: spr...@li...
Betreff: [Springframework-developer] Spring Enhancement



Spring now provides the ability to instantiate an object using either a =
JavaBean no arg constructor, or any normal Java constructor.  But it =
does not support calling methods.

Also, Spring requires that a class implement the InitializingBean =
interface if it needs to perform some "setup" work after the setters =
have all been called.  This means that any class that has this need is =
tied to the Springframework.

What if the ability to call any arbitrary method was added to Spring?  =
Then users could call "afterPropertiesSet" to do "setup" work without =
having to implement the InitializingBean interface.  Ideally method =
calls could be in any order along with calls to setters.  Spring would =
then call each in order.  Thus, allowing some setters to be called, then =
some methods, then more setters if necessary.  If this is not possible, =
then methods should be called after setters.

This would allow complete decoupling of classes from Spring.  The =
InitializingBean & BeanFactoryAware interfaces would no longer be needed =
(although could remain for backwards compatibility).  This would be very =
useful when contributing code to other projects that do not want to have =
a dependency on Spring.  Also, it would allow virtually any class used =
by /developed for  another IOC framework / lightweight container to be =
used in Spring.

Thoughts?

Later
Rob



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring Enhancement

[Mike Cannon-B. <mi...@at...>]

Or an even better idea... how about supporting OGNL within the Spring config
files? (like Xwork does)

This would be _awesome_ and I just found a second use case for it (the very
minute Rob's email came in).

My use case - Maps.

The Map syntax is nice, but not very useful in practicality I'm finding as
the key and value of the map are usually related, for instance I often want
to put a list of referenced beans into a map, with ref.getName() (or some
method) called for the key.

At the moment I have to add a setBeans(List) method to my class, and then in
that setter iterate and add to a map - smelly!

If we allowed OGNL expressions, it would be very simple to do this in the
config file itself:

<property value="myMapProp">
  <map>
    <entry>
      <key>$referencedBean.name</key>
      <value><ref bean="referencedBean" /></value>
    </entry>
... More entries
  </map>
</property>

I'm sure there are a million other places where OGNL would be useful too,
but AFAIK the above can't be done _without_ it?

Or have I just been at this desk far too long?

M

On 2/12/03 8:32 AM, "Rob Butler" (rob...@ve...) penned the
words:

> Spring now provides the ability to instantiate an object using either a
> JavaBean no arg constructor, or any normal Java constructor.  But it does not
> support calling methods.
> 
> Also, Spring requires that a class implement the InitializingBean interface if
> it needs to perform some "setup" work after the setters have all been called.
> This means that any class that has this need is tied to the Springframework.
> 
> What if the ability to call any arbitrary method was added to Spring?  Then
> users could call "afterPropertiesSet" to do "setup" work without having to
> implement the InitializingBean interface.  Ideally method calls could be in
> any order along with calls to setters.  Spring would then call each in order.
> Thus, allowing some setters to be called, then some methods, then more setters
> if necessary.  If this is not possible, then methods should be called after
> setters.
> 
> This would allow complete decoupling of classes from Spring.  The
> InitializingBean & BeanFactoryAware interfaces would no longer be needed
> (although could remain for backwards compatibility).  This would be very
> useful when contributing code to other projects that do not want to have a
> dependency on Spring.  Also, it would allow virtually any class used by
> /developed for  another IOC framework / lightweight container to be used in
> Spring.
> 
> Thoughts?
> 
> Later
> Rob
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring Enhancement

[Rob B. <rob...@ve...>]

Spring now provides the ability to instantiate an object using either a
JavaBean no arg constructor, or any normal Java constructor.  But it does
not support calling methods.

Also, Spring requires that a class implement the InitializingBean interface
if it needs to perform some "setup" work after the setters have all been
called.  This means that any class that has this need is tied to the
Springframework.

What if the ability to call any arbitrary method was added to Spring?  Then
users could call "afterPropertiesSet" to do "setup" work without having to
implement the InitializingBean interface.  Ideally method calls could be in
any order along with calls to setters.  Spring would then call each in
order.  Thus, allowing some setters to be called, then some methods, then
more setters if necessary.  If this is not possible, then methods should be
called after setters.

This would allow complete decoupling of classes from Spring.  The
InitializingBean & BeanFactoryAware interfaces would no longer be needed
(although could remain for backwards compatibility).  This would be very
useful when contributing code to other projects that do not want to have a
dependency on Spring.  Also, it would allow virtually any class used by
/developed for  another IOC framework / lightweight container to be used in
Spring.

Thoughts?

Later
Rob

[Springframework-developer] Spring Enhancement

[Rob B. <rob...@ve...>]

Spring now provides the ability to instantiate an object using either a JavaBean no arg constructor, or any normal Java constructor.  But it does not support calling methods.

Also, Spring requires that a class implement the InitializingBean interface if it needs to perform some "setup" work after the setters have all been called.  This means that any class that has this need is tied to the Springframework.

What if the ability to call any arbitrary method was added to Spring?  Then users could call "afterPropertiesSet" to do "setup" work without having to implement the InitializingBean interface.  Ideally method calls could be in any order along with calls to setters.  Spring would then call each in order.  Thus, allowing some setters to be called, then some methods, then more setters if necessary.  If this is not possible, then methods should be called after setters.

This would allow complete decoupling of classes from Spring.  The InitializingBean & BeanFactoryAware interfaces would no longer be needed (although could remain for backwards compatibility).  This would be very useful when contributing code to other projects that do not want to have a dependency on Spring.  Also, it would allow virtually any class used by /developed for  another IOC framework / lightweight container to be used in Spring.

Thoughts?

Later
Rob

[Springframework-developer] Re: [Hibernate] Hibernate & Spring Javabean instantiation

[Max R. A. <ma...@ac...>]

You are always welcome to post your SpringBeanFactoryInterceptor on our Wiki ;)

/max

Rob Butler wrote:

>>Have you taken a look at Interceptor.instantiate(Class clazz, Serializable id) ?
>>
>>With that you can do whatever you want regarding construction of objects ;)
>>
> 
> 
> Cool, exactly what I was looking for!  That along with Hibernate's Lifecycle interface will do everything I was asking for in my original message.  The only thing that isn't provided is a default spring interceptor implementation, although building one shouldn't be hard.
> 
> Thanks Max. & Way to go Hibernate!
> 
> Later
> Rob
> 

[Springframework-developer] Re: [Hibernate] Hibernate & Spring Javabean instantiation

[Rob B. <rob...@ve...>]

> Have you taken a look at Interceptor.instantiate(Class clazz, Serializable id) ?
> 
> With that you can do whatever you want regarding construction of objects ;)
> 

Cool, exactly what I was looking for!  That along with Hibernate's Lifecycle interface will do everything I was asking for in my original message.  The only thing that isn't provided is a default spring interceptor implementation, although building one shouldn't be hard.

Thanks Max. & Way to go Hibernate!

Later
Rob

Re: [Springframework-developer] Hibernate 2.1 and CGLIB

[Matthew E. P. <ma...@me...>]

This was a good answer since it provides a roadmap.  Can someone post=20
this on the wiki or the website for others who may have the same=20
question?


Cheers,
   matthew

On Dec 1, 2003, at 11:04 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Hi Matthew,
>
> We've been discussing that for a while. If Hibernate 2.1 gets final=20
> early enough (and it seems to, being already in RC1 stage), we will=20
> switch to it for our 1.0 RCs. If 2.1 would still be far from final, we=20=

> would probably have to support both CGLIB1 and CGLIB2 somehow.=20
> Fortunately, that seems not to be necessary anymore!
>
> For the time being, if you don't proxy full classes (but just=20
> interfaces) or don't use Spring AOP in the first place, you should be=20=

> able to work with Hibernate 2.1 and its CGLIB2 without hassle. The=20
> same will apply to Hibernate 2.0 users after we've moved to CGLIB2:=20
> You don't need to worry if you don't use Spring AOP will full proxies.
>
> I think we can live with requiring an update to Hibernate 2.1 if a=20
> user wants full AOP proxies in combination. Actually, we probably=20
> *need* to move to CGLIB2 once Hibernate 2.1 final is released: Power=20=

> users will want to combine full Spring AOP proxying with the current=20=

> Hibernate version, not with a previous one.
>
> Now it would be really great if CGLIB2 were final too until Spring 1.0=20=

> final! :-) It's no problem to ship a CGLIB2 beta with our upcoming=20
> Spring 1.0 RC1, but it worries me to include a CGLIB2 beta in Spring=20=

> 1.0 final. Haven't the Hibernate guys the same problem? Or are they=20
> fine with shipping a CGLIB2 beta with Hibernate 2.1 final?
>
> So I suggest to release our 1.0 RC1 shortly after Hibernate 2.1 final,=20=

> already with CGLIB2 support. As I said, we will just force users with=20=

> full AOP proxies to upgrade to Hibernate 2.1 if using the two in=20
> combination. We could release a 1.0 M4 shortly before that though,=20
> still with CGLIB1 - to ease migration paths for Hibernate 2.0 users.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Matthew E. Porter
> Sent: Monday, December 01, 2003 5:06 PM
> To: spr...@li...
> Subject: [Springframework-developer] Hibernate 2.1 and CGLIB
>
>
> I have looked through the mailing list archives but was unable to find
> the answer to my question.  Will Spring move to support Hibernate 2.1
> (as it is the new *recommended* version) and, if so, when?
>
> Also, does anyone know if I can use it now with the cglib version
> change?
>
>
>
> Cheers,
>    matthew
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: [Hibernate] Hibernate & Spring Javabean instantiation

[Max R. A. <ma...@ac...>]

Hi Rob,

Have you taken a look at Interceptor.instantiate(Class clazz, Serializable id) ?

With that you can do whatever you want regarding construction of objects ;)

/max

Rob Butler wrote:

> I have posted this to the Hibernate & Spring mailing lists as I think this will require the involvement of both development teams to answer.
> 
> Hibernate uses **javabean no-arg constructors** to instantiate objects and then uses javabean setters / getters when mapping from / to the database.
> 
> Spring uses javabean no-arg constructors to instantiate objects and then uses javabean setters to "configure" the objects.  Optionally, Spring can then call BeanFactoryAware.setBeanFactory for "Bean Factory Aware beans" and InitializingBean.afterPropertiesSet to inform the object it is fully configured if it has setup work to do.
> 
> This is all good, but what if I have an object that needs to be configured via spring, but needs to be persisted  via Hibernate?  

>Initially if I obtain the object from Spring via context.getBean("bean-name") the bean will have been instantiated and configured via Spring, 
 > nd persisting the object via Hibernate should work fine.  However, if I then retrieve the object from the DB via Hibernate the Spring bean factories are

>by-passed because Hibernte uses the javabean no-arg constructors directly, and not the spring bean factories.
> 
> This could be a problem if:
> 
> 1) Some attributes of the javabean were not persisted in the DB, but should be loaded from the Spring config when the object is re-instantiated.  Business rules are the best example of this - Think of range limitations like a number must be between 5 and 15 - then the business changes the rules and the number must now be between 3 and 15, or 8 and 15. 
> 
> This may also require the business rules to be re-checked after the object is loaded by Hibernate.  Does Hibernate support any "after load" method calls to the object so it can perform this kind of task?  Could one be added?  It would be possible to call an "after load" method from within the DAO code the app developer must write, but it would not be possible to have the app do this on collections if we are using Hibernates lazy load features.
> 
> 2) The javabean needs to be "BeanFactoryAware" and have the setBeanFactory method called.
> 3) The javabean relies on having the spring InitializingBean.afterPropertiesSet method called.
> 
> 
> Both #2 and #3 should happen BEFORE any "after load" Hibernate method call, because those resources may be needed during the Hibernate call.
> 
> I think that adding support for this use case will probably require changes to Hibernate for it to support not only the javabean no-arg constructor, but also the spring bean factory method of object instantiation.  Better yet, to be more generic Hibernate should support the use of user defined "factory" methods.  Then Spring should provide a "Hibernate factory" that Hibernate could use to load any object from the Spring bean factory.  Providing this capability along with the Hibernate "after load" method call would allow for better "Idiomatic" java persistence.
> 
> Another option may be for Spring to have some sort of a way for a javabean no-arg constructor to call a "configure me" method.  I.E. the no-arg constructor could have code within it that calls Spring, and Spring configures the object using javabean setters, calls BeanFactoryAware.setBeanFactory and InitializingBean.afterPropertiesSet (if appropriate).  This is probably not a good option as it would be impossible to have two instances of the object that are configured differently.  Also, it's probably not possible / easy to do.
> 
> Or did I completely miss something and this already possible?
> Thoughts?
> 
> Later
> Rob
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel

RE: [Springframework-developer] Hibernate 2.1 and CGLIB

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

Hi Matthew,

We've been discussing that for a while. If Hibernate 2.1 gets final =
early enough (and it seems to, being already in RC1 stage), we will =
switch to it for our 1.0 RCs. If 2.1 would still be far from final, we =
would probably have to support both CGLIB1 and CGLIB2 somehow. =
Fortunately, that seems not to be necessary anymore!

For the time being, if you don't proxy full classes (but just =
interfaces) or don't use Spring AOP in the first place, you should be =
able to work with Hibernate 2.1 and its CGLIB2 without hassle. The same =
will apply to Hibernate 2.0 users after we've moved to CGLIB2: You don't =
need to worry if you don't use Spring AOP will full proxies.

I think we can live with requiring an update to Hibernate 2.1 if a user =
wants full AOP proxies in combination. Actually, we probably *need* to =
move to CGLIB2 once Hibernate 2.1 final is released: Power users will =
want to combine full Spring AOP proxying with the current Hibernate =
version, not with a previous one.

Now it would be really great if CGLIB2 were final too until Spring 1.0 =
final! :-) It's no problem to ship a CGLIB2 beta with our upcoming =
Spring 1.0 RC1, but it worries me to include a CGLIB2 beta in Spring 1.0 =
final. Haven't the Hibernate guys the same problem? Or are they fine =
with shipping a CGLIB2 beta with Hibernate 2.1 final?

So I suggest to release our 1.0 RC1 shortly after Hibernate 2.1 final, =
already with CGLIB2 support. As I said, we will just force users with =
full AOP proxies to upgrade to Hibernate 2.1 if using the two in =
combination. We could release a 1.0 M4 shortly before that though, still =
with CGLIB1 - to ease migration paths for Hibernate 2.0 users.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matthew E. Porter
Sent: Monday, December 01, 2003 5:06 PM
To: spr...@li...
Subject: [Springframework-developer] Hibernate 2.1 and CGLIB


I have looked through the mailing list archives but was unable to find=20
the answer to my question.  Will Spring move to support Hibernate 2.1=20
(as it is the new *recommended* version) and, if so, when?

Also, does anyone know if I can use it now with the cglib version=20
change?



Cheers,
   matthew



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Hibernate & Spring Javabean instantiation

[Rob B. <rob...@ve...>]

I have posted this to the Hibernate & Spring mailing lists as I think this will require the involvement of both development teams to answer.

Hibernate uses **javabean no-arg constructors** to instantiate objects and then uses javabean setters / getters when mapping from / to the database.

Spring uses javabean no-arg constructors to instantiate objects and then uses javabean setters to "configure" the objects.  Optionally, Spring can then call BeanFactoryAware.setBeanFactory for "Bean Factory Aware beans" and InitializingBean.afterPropertiesSet to inform the object it is fully configured if it has setup work to do.

This is all good, but what if I have an object that needs to be configured via spring, but needs to be persisted  via Hibernate?  Initially if I obtain the object from Spring via context.getBean("bean-name") the bean will have been instantiated and configured via Spring, and persisting the object via Hibernate should work fine.  However, if I then retrieve the object from the DB via Hibernate the Spring bean factories are by-passed because Hibernte uses the javabean no-arg constructors directly, and not the spring bean factories.

This could be a problem if:

1) Some attributes of the javabean were not persisted in the DB, but should be loaded from the Spring config when the object is re-instantiated.  Business rules are the best example of this - Think of range limitations like a number must be between 5 and 15 - then the business changes the rules and the number must now be between 3 and 15, or 8 and 15. 

This may also require the business rules to be re-checked after the object is loaded by Hibernate.  Does Hibernate support any "after load" method calls to the object so it can perform this kind of task?  Could one be added?  It would be possible to call an "after load" method from within the DAO code the app developer must write, but it would not be possible to have the app do this on collections if we are using Hibernates lazy load features.

2) The javabean needs to be "BeanFactoryAware" and have the setBeanFactory method called.
3) The javabean relies on having the spring InitializingBean.afterPropertiesSet method called.


Both #2 and #3 should happen BEFORE any "after load" Hibernate method call, because those resources may be needed during the Hibernate call.

I think that adding support for this use case will probably require changes to Hibernate for it to support not only the javabean no-arg constructor, but also the spring bean factory method of object instantiation.  Better yet, to be more generic Hibernate should support the use of user defined "factory" methods.  Then Spring should provide a "Hibernate factory" that Hibernate could use to load any object from the Spring bean factory.  Providing this capability along with the Hibernate "after load" method call would allow for better "Idiomatic" java persistence.

Another option may be for Spring to have some sort of a way for a javabean no-arg constructor to call a "configure me" method.  I.E. the no-arg constructor could have code within it that calls Spring, and Spring configures the object using javabean setters, calls BeanFactoryAware.setBeanFactory and InitializingBean.afterPropertiesSet (if appropriate).  This is probably not a good option as it would be impossible to have two instances of the object that are configured differently.  Also, it's probably not possible / easy to do.

Or did I completely miss something and this already possible?
Thoughts?

Later
Rob

[Springframework-developer] Re: Hibernate 2.1 and CGLIB

[Chris N. <ch...@si...>]

Matthew E. Porter wrote:
> I have looked through the mailing list archives but was unable to find
> the answer to my question.  Will Spring move to support Hibernate 2.1
> (as it is the new *recommended* version) and, if so, when?

Someone else will have to answer.

> Also, does anyone know if I can use it now with the cglib version
> change?

I thought there might be a way (by using the BCEL version of CGLIB 1.0), but
I was wrong. Since 1.0 and 2.0 use incompatible versions of the ASM
library, you cannot use them together. Which means that for now Spring's
use of CGLIB is incompatible with Hibernate 2.1.

Chris

[Springframework-developer] Hibernate 2.1 and CGLIB

[Matthew E. P. <ma...@po...>]

I have looked through the mailing list archives but was unable to find 
the answer to my question.  Will Spring move to support Hibernate 2.1 
(as it is the new *recommended* version) and, if so, when?

Also, does anyone know if I can use it now with the cglib version 
change?



Cheers,
   matthew

[Springframework-developer] App Testing

[Darren D. <dda...@kg...>]

I've finally got something concrete in place for the application testing
stuff, but I need some thoughts from people before continuing much further.

The code written so far is fairly tightly tied to both the sample application
and the server that it will be deployed upon.  This is inevitable, but it's
also written in such a way that various tests can be called from a 'master'
script in a standard and parameterised fashion.

As a result, there are a number of dependencies that the autobuild code will
need to rely upon; namely

1 - each sample app has a build.xml in the root folder (eg
samples/petclinic/build.xml).  Currently this is the case, ideally we need to
adopt it as an internal standard.

2 - each sample app's build.xml contains a 'warfile' target that leaves the
deployment unit in a directory called 'dist' off the sample app root. 
Currently this is the case, but probably won't be if non-web sample apps are
developed.  Perhaps a more generic target name of 'dist' would help if this
occurs.

3 - clearly the application tests (HttpUnit) are tied closely to the view
structure of each sample app in the same way as JUntit tests are tied to the
structure of classes they test.  Once tests are commited, changes to the
sample apps will have to take this into account and involve changes to the app
test code too.  An alternative would be to develop one or more sample apps
purely for the purpose of build & deployment testing so that sample apps are
free to be developed along a more user-educational line without concern for
auto-builds.  The downside is that the purpose developed apps are likely to be
unrealistic and biased to passing tests which defeats much of the purpose of
doing it.  Personally, I prefer the idea of using the existing samples.

In summary, 

 - any strong feelings plus or minus for changing 'warfile' target names to
'dist' or 'deploy-unit' or something in the sample apps?

 - any preference for creating new (test-friendly) apps for this, or using the
possibly more real-world existing sample apps with the additional overhead of
maintaining test source if the sample apps themselves change?


Just for info, I'm snagging the following namespaces in the project for this:

${spring.root}/autobuilds (and sub-dirs)
${spring.root}/target/autobuilds (and sub-dirs)
org.springframework.apptests.* (package root)
org.springframework.autobuilds.* (package root)

.. just in case anyone else was thinking of using them :-)


Darren.



--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] AOP changes

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

All,

I've made some further AOP changes, partly to allow for further CGLIB
optimization, but principally to allow for a cleaner approach to pooling
etc.

The InvokerInterceptor is now gone. The old approach of the terminal
interceptor invoking the target object has been replaced by this behaviour
in the MethodInvocation itself. Of course other "terminal" invokers such as
the EJB invokers will continue to work just fine as they don't call proceed.

Other MethodInvocation implementations--CGLIB etc.--can have their own
invocation behavior, for greater efficiency. (We don't want to end up
calling Method.invoke with CGLIB.)

Instead, there's a new interface: org.springframework.aop.TargetSource will
identifies the "this" part of the joinpoint. (Of course this kind of thing
isn't "classic" AOP and I don't think it can be done with AspectJ. But it's
useful.) Normally the implementation is SingletonTargetSource, which caches
a target. However, PrototypeInvokerInterceptor etc. are now in the
aop.target package as PrototypeTargetSource, ThreadLocalTargetSource etc. A
TargetSource or target can be used as the final name in an interceptor
chain, as a target could formerly, so there shouldn't be that much impact on
code.

The only effect on your code should be:
- if you use the PrototypeInvokerInterceptor, PoolingInvokerInterceptor or
ThreadLocalInvokerInterceptor, in which case you need to move that bean
definition to the corresponding TargetSource, which will be configured
similarly.
- if you created AOP proxies programmatically using an InvokerInterceptor.
This is no longer necessary.
- if you've subclassed or otherwise depended on the internals of some of the
AOP classes.

Note that it's no longer necessary to add an InvokerInterceptor as the last
advisor when creating a proxy programmatically: a nice feature.

So for:

ProxyFactory p = new ProxyFactory(target);
p.addInterceptor(0, new DebugInterceptor());

Can omit the index (0) in the second line.

In the second line now we can add interceptors in order without bothering
about the index (although this version will still work). Because there's no
InvokerInterceptor, there are no longer any special requirements for the
last interceptor.

Regards,
Rod

Re: [Springframework-developer] Problems after DBCP upgrade (to 1.1)

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

Petra,

It's definitely not a Spring issue. Did you upgrade Commons Pool to 1.1 at
the same time? It looks like it wants commons-pool.jar as well. I upgraded
both at once and had no problem.

Rgds,
Rod

----- Original Message ----- 
From: "petra staub" <ca...@ho...>
To: <spr...@li...>
Sent: Saturday, November 29, 2003 7:42 PM
Subject: [Springframework-developer] Problems after DBCP upgrade (to 1.1)


> I upgraded to DBCP 1.1 and now my webapplication throws during startup
> an exception when the ContextLoaderListener want to initiate the
> datasource...
>
> Does anyone have experienced something similar or knows what is going
wrong?
> Is it actually a springframework issue or definitly a problem of  DBCP?
>
> Thanks for any support!
>
>
> ...oh yes...the dump....
>
> 2003-11-29 20:33:18 StandardContext[/TestApp]: Exception sending context
> initialized event to listener instance of class org.spr
> ingframework.web.context.ContextLoaderListener
> java.lang.NoSuchMethodError:
org.apache.commons.pool.impl.GenericObjectPool:
> method <init>()V not found
>         at
>
org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.jav
a:765)
>         at
>
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:5
18)
>         at
>
org.springframework.orm.hibernate.LocalDataSourceConnectionProvider.getConne
ction(LocalDataSourceConnectionProvider.java
> :44)
>         at
>
net.sf.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:71)
>         at
> net.sf.hibernate.cfg.Configuration.buildSettings(Configuration.java:1072)
>         at
>
net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:71
8)
>         at
>
org.springframework.orm.hibernate.LocalSessionFactoryBean.newSessionFactory(
LocalSessionFactoryBean.java:292)
>         at
>
org.springframework.orm.hibernate.LocalSessionFactoryBean.afterPropertiesSet
(LocalSessionFactoryBean.java:246)
>         at
>
org.springframework.beans.factory.support.AbstractBeanFactory.callLifecycleM
ethodsIfNecessary(AbstractBeanFactory.java:8
> 83)
>         at
>
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(Abs
tractBeanFactory.java:480)
>         at
>
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:211)
>         at
>
org.springframework.beans.factory.support.AbstractBeanFactory.resolveReferen
ce(AbstractBeanFactory.java:823)
>         at
>
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIf
Necessary(AbstractBeanFactory.java:794)
>         at
>
org.springframework.beans.factory.support.AbstractBeanFactory.applyPropertyV
alues(AbstractBeanFactory.java:761)
>         at
>
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(Abs
tractBeanFactory.java:479)
>         at
>
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:211)
>         at
>
org.springframework.context.support.AbstractApplicationContext.getBean(Abstr
actApplicationContext.java:469)
>         at
>
org.springframework.context.support.AbstractApplicationContext.preInstantiat
eSingletons(AbstractApplicationContext.java:
> 355)
>         at
>
org.springframework.context.support.AbstractApplicationContext.refresh(Abstr
actApplicationContext.java:241)
>         at
>
org.springframework.web.context.support.XmlWebApplicationContext.setServletC
ontext(XmlWebApplicationContext.java:124)
>         at
>
org.springframework.web.context.ContextLoader.initContext(ContextLoader.java
:58)
>         at
>
org.springframework.web.context.ContextLoaderListener.contextInitialized(Con
textLoaderListener.java:29)
>         at
>
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:
3270)
>         at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:3599)
>         at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>         at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
>         at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>         at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
>         at
> org.apache.catalina.core.StandardService.start(StandardService.java:497)
>         at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
>         at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
>         at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
>         at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
>         at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
>
> _________________________________________________________________
>   Schluß mit Spam - MSN hilft Ihnen hier weiter.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Problems after DBCP upgrade (to 1.1)

[petra s. <ca...@ho...>]

Please excuse...I found it...

It was simply the outdated jakarta commons-pool. The update to version 1.1
solved my problem, I think.

...I should have looked more close enough to the log...sorry...

_________________________________________________________________
MSN Messenger  -  Wer in Echtzeit kommunizieren will, lädt den MSN 
Messenger. Cool, kostenlos und mit 3D Emoticons:  http://messenger.msn.ch

[Springframework-developer] Problems after DBCP upgrade (to 1.1)

[petra s. <ca...@ho...>]

I upgraded to DBCP 1.1 and now my webapplication throws during startup
an exception when the ContextLoaderListener want to initiate the 
datasource...

Does anyone have experienced something similar or knows what is going wrong?
Is it actually a springframework issue or definitly a problem of  DBCP?

Thanks for any support!


...oh yes...the dump....

2003-11-29 20:33:18 StandardContext[/TestApp]: Exception sending context 
initialized event to listener instance of class org.spr
ingframework.web.context.ContextLoaderListener
java.lang.NoSuchMethodError: org.apache.commons.pool.impl.GenericObjectPool: 
method <init>()V not found
        at 
org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:765)
        at 
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:518)
        at 
org.springframework.orm.hibernate.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java
:44)
        at 
net.sf.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:71)
        at 
net.sf.hibernate.cfg.Configuration.buildSettings(Configuration.java:1072)
        at 
net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:718)
        at 
org.springframework.orm.hibernate.LocalSessionFactoryBean.newSessionFactory(LocalSessionFactoryBean.java:292)
        at 
org.springframework.orm.hibernate.LocalSessionFactoryBean.afterPropertiesSet(LocalSessionFactoryBean.java:246)
        at 
org.springframework.beans.factory.support.AbstractBeanFactory.callLifecycleMethodsIfNecessary(AbstractBeanFactory.java:8
83)
        at 
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:480)
        at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:211)
        at 
org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:823)
        at 
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:794)
        at 
org.springframework.beans.factory.support.AbstractBeanFactory.applyPropertyValues(AbstractBeanFactory.java:761)
        at 
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:479)
        at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:211)
        at 
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:469)
        at 
org.springframework.context.support.AbstractApplicationContext.preInstantiateSingletons(AbstractApplicationContext.java:
355)
        at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:241)
        at 
org.springframework.web.context.support.XmlWebApplicationContext.setServletContext(XmlWebApplicationContext.java:124)
        at 
org.springframework.web.context.ContextLoader.initContext(ContextLoader.java:58)
        at 
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:29)
        at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3270)
        at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3599)
        at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
        at 
org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
        at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
        at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
        at 
org.apache.catalina.core.StandardService.start(StandardService.java:497)
        at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
        at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
        at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

_________________________________________________________________
  Schluß mit Spam - MSN hilft Ihnen hier weiter.

[Springframework-developer] Re: Re: CGLIB question

[Chris N. <ch...@si...>]

Chris Nokleberg wrote:
> If you can get the field copying to work and plug invokeSuper into your
> system this option is preferrable, since you only have one object and
> there is *zero* overhead for non-intercepted methods.

FYI this second option (invokeSuper+NoOp) is possible with CGLIB 1, just
return false from your MethodFilter for the non-advised methods. I can
backport the code if it's useful. The first option using LazyLoader is
CGLIB 2 only.

Chris

[Springframework-developer] Re: Re: CGLIB question

[Chris N. <ch...@si...>]

Rod Johnson wrote:
> Unfortunately I think there's a fatal flaw in my solution using CGLIB 1.0.
> There are now two objects, even if the enhanced one starts off with the
> same state. "Optimized" invocations go to the original target, advised
> ones to the enhanced class and never to the original object. This is fine
> if there's no conversational state but the results can, ahem, be rather
> interesting if there is.

I can imagine.

> I can't see a way round this with CGLIB 1.0.
> 
> It seems that CGLIB 2.0 solves this problem, if the LazyLoaderCallback
> works as I understand. If it does solve this problem, could you please
> send me the sample code?

There are two ways to go about this. One is to use the proxy object as a
"shell" which dispatches all of its methods, one way or another, to the
original instance. The proxy, since it extends the original class, will
have a bunch of uninitialized fields, but they will go unused.

Here is some code using CGLIB 2 that takes a bean and creates a proxy that
will delegate to the bean. Some methods use the LazyLoader callback, and
others use a MethodInterceptor. You will have to plug in the algorithm to
choose which are which. FYI this is a bit different from normal use of
LazyLoader because you don't really care about the laziness, but there is
no "LoadRightNow" callback and it would end up working the same anyway.

public Object createProxy(final Object bean) {
    Enhancer e = new Enhancer();
    e.setSuperclass(bean.getClass());
    e.setCallbackFilter(new CallbackFilter() {
        public int accept(Method method) {
            // Return the index into the callback array.  We will put
            // the MethodInterceptor into index 0, and the LazyLoader
            // into index 1.
            return methodShouldBeAdvised(method) ? 0 : 1;
        }
    });
    e.setCallbacks(new Callback[]{
        // index 0: MethodInterceptor
        new MethodInterceptor() {
            public Object intercept(Object obj,
                                    Method method,
                                    Object[] args,
                                    MethodProxy proxy) throws Throwable {
                // Use either of these methods to direct method to the
                // original bean. We are ignoring the "obj" argument--it is
                // the proxy instance. Somehow your "advice" plugs in here.

                // method A: reflection (slow)
                // return method.invoke(bean, args);

                // method B: generated MethodProxy (faster)
                return proxy.invoke(bean, args);
            }
        },
        // index 1: LazyLoader
        new LazyLoader() {
            public Object loadObject() {
                return bean;
            }
        }
    });
    return e.create();
}

The *other* possibility is to use something similar to your current
solution, which copies the fields from the original instance. As you point
out, having the two objects in play causes problems, so you really need to
throw out the original instance if you want this to work. This means that
all intercepted methods cannot be redirected to the original instance, but
instead must eventually call the "super" method of the proxy itself. There
is no way to do this using the java.lang.reflect.Method object passed to
the interceptor, since (understandably) invoking it on the proxy will
result in an infinite loop.

The solution is to use the MethodProxy invokeSuper method. This calls a
special synthetic method in the generated class which then calls the proper
method in the base class.

Here is the same code but using invokeSuper within the interceptor, and
using the NoOp callback for non-intercepted methods:

public Object createProxy(Object bean) {
    Enhancer e = new Enhancer();
    e.setSuperclass(bean.getClass());
    e.setCallbackFilter(new CallbackFilter() {
        public int accept(Method method) {
            return methodShouldBeAdvised(method) ? 0 : 1;
        }
    });
    e.setCallbacks(new Callback[]{
        // index 0: MethodInterceptor
        new MethodInterceptor() {
            public Object intercept(Object obj,
                                    Method method,
                                    Object[] args,
                                    MethodProxy proxy) throws Throwable {
                // Invoke method in superclass (avoiding interception).
                // Of course you still need to plug in your advice code 
                // here somehow.
                return proxy.invokeSuper(obj, args);
            }
        },
        // index 1: NoOp
        NoOp.INSTANCE
    });
    Object proxy = e.create();
    copyFieldsFromBeanToProxy(bean, proxy);
    return proxy;
}

If you can get the field copying to work and plug invokeSuper into your
system this option is preferrable, since you only have one object and there
is *zero* overhead for non-intercepted methods.

> Also, since that would be a killer reason to go to CGLIB 2.0, I guess it
> brings the whole version thing up again. CGLIB 2.0 isn't backward
> compatible, is it, so it will break old versions of Hibernate?

You cannot drop in 2.0 for 1.0. However, they can be used simultaneously
except that 1.0 uses ASM 1.3 *or* BCEL, and 2.0 uses *only* ASM 1.4. If you
use CGLIB 1.0 w/o the ASM classes, and make sure that bcel.jar is in your
classpath, you can use CGLIB 1.0 and 2.0 at the same time. Otherwise you
will have to choose to support either Hibernate 2.0 or 2.1, and choose your
CGLIB version accordingly (I would strongly recommend Hibernate 2.1 if you
take this route).

Chris

[Springframework-developer] Re: Re: CGLIB question

[Chris N. <ch...@si...>]

Rod Johnson wrote:
> I considered the bean copy route, but the object I was using in my
> application was actually Type 3 and we must now consider that as well.
> Also, there may not be getter methods on the source: only setters.

That makes sense.

> Interestingly, CGLIB 1.0 performance vs DP performance seems pretty much
> the same otherwise.

For JDK 1.4 it is probably in the same ballpark. The two biggest costs are
argument array creation and the reflective method call. The former is
required for both DPs and CGLIB, and the latter is implemented using code
generation in 1.4 anyway. I'm sure there is a bigger difference for 1.3,
and of course with DP you can not extend a class.

Chris