springframework-developer — Spring Framework developers list

[Springframework-developer] AOP

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

All,

I've just checked in some enhancements to AOP support. Earlier today I also
fixed a problem reported by Claude Hussenet in the forums--AOP prototypes
not being independent.

The enhancements are:

- All AOP proxies can be cast to ProxyConfig. This enables them to be
programmatically interrogated or manipulated. Not saying this is a great
idea in general, as callers shouldn't normally depend on the AOP
infrastructure, just the interfaces something implements. AOP is normally an
implementation detail. Nevertheless I think this is useful functionality. I
had this in the previous iteration of Spring AOP. JBoss 4 also offers a
similar feature.

- CGLIB proxies support introductions, and the addition of new interfaces.

- It's possible to force an AOP proxy factory to use CGLIB by setting the
proxyTargetClass property in ProxyConfig to true. This will work even with
interfaces.

Regards,
Rod

[Springframework-developer] Re: Re: Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

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

Thanks Colin

when Juergen actually commits the code, I'll give a try ;)



"Colin Sampaleanu" <col...@ex...> wrote in message
news:3FA...@ex......
> Roger,
>
> Try hitting the 'alternate' CVS server at sf.net described here:
>
>
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#firewal
l
>
> It does allow anon access, and last time I verified this (about a month
> ago), it was completely up to date, as opposed to 24 hours behind like
> the main anon server.
>
>
>
> roger holbrook wrote:
>
> >Hi Juergen
> >
> >The changes you describe sound great - & as soon as anonymous CVS catches
> >up, I'll check them out.  Unfortunately, all I can see so far is an empty
> >beans.factory.config directory :(
> >
> >Many thanks
> >
> >Roger
> >
> >
> >"jürgen höller [werk3AT]" <jue...@we...> wrote in message
> >news:170...@co......
> >Roger,
> >
> >I've adopted your idea of an SPI interface for bean factories: I've just
> >introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory
> >interfaces in a new beans.factory.config package; I've also moved
> >BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
> >postProcessBeanFactory method uses ConfigurableListableBeanFactory now,
as
> >does AbstractApplicationContext's getBeanFactory template method.
> >
> >I'm still not entirely sure why you would want to use a different bean
> >factory with AbstractApplicationContext to leverage AOP functionality.
All
> >of Spring's AOP support should work without making the bean factory
> >implementation explicitly aware of it. BeanPostProcessors and
> >BeanFactoryPostProcessors are automatically detected and applied if
defined
> >as beans in an application context.
> >
> >Thanks for the thorough code review, BTW :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> >roger holbrook
> >Gesendet: So 02.11.2003 18:46
> >An: spr...@li...
> >Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
> >[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
> >AbstractApplicationContext & ListableBeanFactory - Email found in
subject -
> >Email found in subject - Email found in subject - Email found in
subject -
> >Email found in subject
> >
> >
> >
> >
> >Hi Juergen
> >
> >Many thanks for the explanation about
> >AbstractApplicationContext.getBeanFactory.
> >
> >Just to check I've got it straight - would the following be an accurate
> >summary:
> >- ListableBeanFactory & ApplicationContext are client facing interfaces
> >designed to hide all things related to implementation.
> >- ListableBeanFactoryImpl & AbstractApplicationContext provide consistent
> >out-of-the-box BeanFactory implementations that are considered of
essential
> >importance.
> >- Currently the linkage between these 2 default implementations happens
to
> >be that one acts as a delegate class for the other, ie. the return type
in
> >question.
> >
> >The reworking of JdbcBeanFactory as a subclass of
ListableBeanFactoryImpl,
> >obviously solves the wiring problem in this particular case - but it does
> >nothing for the general case of Plug'nPlay.  With the current
arrangement,
> >the one thing I cannot do is achieve effective easy reuse of all that
highly
> >crafted functionality that is so intricately wired up in
AbstractBeanFactory
> >and ListableBeanFactoryImpl - I cannot wrap and delegate !
> >
> >Aside from the implied name conflict, could you not preserve the original
> >intention of making the linkage between the two an internal interface:
> >
> >interface ListableBeanFactoryImp extends ListableBeanFactory {
> >
> >    public void ignoreDependencyType(Class type)
> >
> >    public void addBeanPostProcessor(BeanPostProcessor beanPostProcessor)
> >
> >    public final void destroySingletons()
> >
> >}
> >
> >The example that is actually motivating my thinking, is related to the
AOP
> >stuff.  If I want try to add functionality to a BeanFactory so that it
can
> >be aware of ProxyFactoryBean's for example, then the most simple approach
> >would be to use an XmlBeanFactory to read the bean definitions, but then
to
> >wrap and delegate to this, from within an AOP aware BeanFactory.  The
latter
> >could initialise itself via a BeanFactoryPostProcessor, and then provide
> >useful implementation support within the AOP module, ie it would again be
> >extending a ListableBeanFactoryImp interface, rather than anything client
> >facing.
> >
> >As you say, all this can obviously be achieved by building BeanFactory's
&
> >ApplicationContext's from scratch, but it seems a great shame not to be
able
> >to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)
> >
> >Anyway, I am sure the you get the sense of what I am on about - I just
hope
> >I am not missing something fundamental to the whole issue ;)
> >
> >Roger
> >
> >
> >"jürgen höller [werk3AT]" <jue...@we...> wrote in message
> >news:420...@ma......
> >
> >
> >>First of all, thanks for your kind words, Roger -- I appreciate them!
:-)
> >>
> >>Regarding AbstractApplicationContext.getBeanFactory: I've indeed changed
> >>
> >>
> >its return value from ListableBeanFactory to ListableBeanFactoryImpl a
while
> >ago, reason being that AbstractApplicationContext needs some
configuration
> >stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
> >BeanFactory and ListableBeanFactory interfaces are intended for client
> >applications that access beans, they do not and should not include any
> >factory configuration or lifecycle methods.
> >
> >
> >>In detail, AbstractApplicationContext needs to invoke the following bean
> >>
> >>
> >factory implementation methods:
> >
> >
> >>- ignoreDependencyType: to register ApplicationContext as dependency
type
> >>
> >>
> >to ignore on autowiring (as it is set by the ApplicationContextAware
> >interface, not by a property value).
> >
> >
> >>- addBeanPostProcessor: to register BeanPostProcessors, both
> >>
> >>
> >ApplicationContextAwareProcessor and custom ones, before creating
> >application beans from the bean definitions.
> >
> >
> >>- destroySingletons: to destroy singleton instances on application
context
> >>
> >>
> >shutdown; particularly important for resource holders like a
BasicDataSource
> >or a LocalSessionFactoryBean.
> >
> >
> >>- Furthermore, the postProcessBeanFactory method in the
> >>
> >>
> >BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
> >parameter to allow for access to all these bean factory configuration
> >methods. A ListableBeanFactory interface would be meaningless for this,
as
> >you can't do any post-processing of bean definitions without access to
them
> >and means to manipulate them.
> >
> >
> >>Let's not forget that is always possible to write an own
> >>
> >>
> >ApplicationContext implementation with any kind of bean factory
underneath,
> >or a direct implementation of bean factory functionality instead of a
> >delegate, by not deriving from AbstractApplicationContext. The latter is
> >specifically intended for ListableBeanFactoryImpl delegates, providing
rich
> >configuration functionality on top of them.
> >
> >
> >>Regarding JdbcBeanFactory: This one used a delegate
> >>
> >>
> >ListableBeanFactoryImpl underneath to be able to perform on-demand
> >refreshing. This is somewhat inconsistent with XmlBeanFactory's
> >implementation style: The latter derives from ListableBeanFactoryImpl and
> >adds various XML-related registerBeanDefinitions methods, leaving refresh
> >functionality to application contexts. IMO, that's a clear separation of
> >responsibilities: A BeanFactory is a low-level implementation; an
> >ApplicationContext builds higher-level functionality on top of it.
> >
> >
> >>Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl and
> >>
> >>
> >provide a registerBeanDefinitions(sql) method. Of course, it still has
the
> >former (dataSource,sql) constructor as a convenience. I don't think that
> >anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
> >beans from a database in the first place), so that change shouldn't hurt.
So
> >you can use JdbcBeanFactory with AbstractApplicationContext too, as it is
a
> >ListableBeanFactoryImpl now :-)
> >
> >
> >>Rod, do you agree with the rationale? I believe it's straightforward and
> >>
> >>
> >consistent, particularly now that JdbcBeanFactory has adopted
> >XmlBeanFactory's implementation style. I hope you don't object to
> >JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe
it
> >is important to provide consistent out-of-the-box BeanFactory
> >implementations (i.e. no refresh in bean factories but just in
application
> >contexts).
> >
> >
> >>Juergen
> >>
> >>
> >>-----Ursprüngliche Nachricht-----
> >>Von: Rod Johnson [mailto:rod...@in...]
> >>Gesendet: Sa 01.11.2003 17:32
> >>An: spr...@li...
> >>Cc:
> >>Betreff: Re: [Springframework-developer] Plug'nPlay for
> >>
> >>
> >AbstractApplicationContext & ListableBeanFactory
> >
> >
> >>
> >>Roger,
> >>
> >>
> >>
> >>>I've been lurking about for a fair while, being thoroughly impressed by
> >>>Springframework - the conception, the code, this excellent list, Rod's
> >>>
> >>>
> >>book,
> >>
> >>
> >>>in short the whole shebang - it seems quite a while since I encountered
> >>>
> >>>
> >a
> >
> >
> >>>project that more than anything, just seems to make me smile ;)  Many
> >>>thanks.
> >>>
> >>>
> >>Thanks. Made me smile :-)
> >>
> >>
> >>
> >>>First up is the subject line & the method
> >>>AbstractApplicationContext.getBeanFactory()
> >>>I am wondering if the signature for this method might have been changed
> >>>inadvertently ?  Prior to the introduction of support for
> >>>BeanFactoryPostProcessor's, the method was returning the
> >>>
> >>>
> >>ListableBeanFactory
> >>
> >>
> >>>interface, but thereafter it has been ListableBeanFactoryImpl.  As the
> >>>latter comes with a final modifier on each of the methods implementing
> >>>
> >>>
> >>that
> >>
> >>
> >>>interface, the opportunity for Plug'nPlay appears to have gone
> >>>
> >>>
> >missing...
> >
> >
> >>&
> >>
> >>
> >>>if I'm not mistaken, a first casualty would be the loss of a
> >>>
> >>>
> >>JdbcBeanFactory
> >>
> >>
> >>>within an AbstractApplicationContext.  Can someone shed some
> >>>light - am I just missing something ?
> >>>
> >>>
> >>I'll leave this one to Juergen, but I did notice it in passing and
> >>wondered...
> >>
> >>
> >>
> >>>By the way, on my wanderings I noticed the following typo in
> >>>AbstractBeanDefinition.equals()
> >>>
> >>>
> >>Thanks, fixed it. Ah, the beauty of open source. That code isn't
currently
> >>used btw, it was intended to allow for dynamic reconfiguration
eventually.
> >>There would have been an argument for zapping it for now, actually.
> >>
> >>Regards,
> >>Rod
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: SF.net Giveback Program.
> >>Does SourceForge.net help you be more productive?  Does it
> >>help you create better code?   SHARE THE LOVE, and help us help
> >>YOU!  Click Here: http://sourceforge.net/donate/
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>NHY??X'u?w+m?$>  xZ+? *.m?k +?^? j?z^?y! DD??i ^P)brA?m?q ?z
v
> >>
> >>
>
>
>
>
> -------------------------------------------------------
> 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] Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

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

No problem, thanks for the update

Roger

"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Ehm, I haven't committed the changes yet (sorry, forgot to mention that)...
will do so tonight after some final polishing, together with refactored
transaction manager implementations and some other minor stuff.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of roger holbrook
Sent: Tuesday, November 04, 2003 5:50 PM
To: spr...@li...
Subject: [[W3-SPAM]] - [Springframework-developer] Re: Re: Plug'nPlay
for AbstractApplicationContext & ListableBeanFactory - Email found in
subject



Hi Juergen

The changes you describe sound great - & as soon as anonymous CVS catches
up, I'll check them out.  Unfortunately, all I can see so far is an empty
beans.factory.config directory :(

Many thanks

Roger


"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Roger,

I've adopted your idea of an SPI interface for bean factories: I've just
introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory
interfaces in a new beans.factory.config package; I've also moved
BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
postProcessBeanFactory method uses ConfigurableListableBeanFactory now, as
does AbstractApplicationContext's getBeanFactory template method.

I'm still not entirely sure why you would want to use a different bean
factory with AbstractApplicationContext to leverage AOP functionality. All
of Spring's AOP support should work without making the bean factory
implementation explicitly aware of it. BeanPostProcessors and
BeanFactoryPostProcessors are automatically detected and applied if defined
as beans in an application context.

Thanks for the thorough code review, BTW :-)

Juergen


________________________________

Von: spr...@li... im Auftrag von
roger holbrook
Gesendet: So 02.11.2003 18:46
An: spr...@li...
Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory - Email found in subject -
Email found in subject - Email found in subject - Email found in subject -
Email found in subject




Hi Juergen

Many thanks for the explanation about
AbstractApplicationContext.getBeanFactory.

Just to check I've got it straight - would the following be an accurate
summary:
- ListableBeanFactory & ApplicationContext are client facing interfaces
designed to hide all things related to implementation.
- ListableBeanFactoryImpl & AbstractApplicationContext provide consistent
out-of-the-box BeanFactory implementations that are considered of essential
importance.
- Currently the linkage between these 2 default implementations happens to
be that one acts as a delegate class for the other, ie. the return type in
question.

The reworking of JdbcBeanFactory as a subclass of ListableBeanFactoryImpl,
obviously solves the wiring problem in this particular case - but it does
nothing for the general case of Plug'nPlay.  With the current arrangement,
the one thing I cannot do is achieve effective easy reuse of all that highly
crafted functionality that is so intricately wired up in AbstractBeanFactory
and ListableBeanFactoryImpl - I cannot wrap and delegate !

Aside from the implied name conflict, could you not preserve the original
intention of making the linkage between the two an internal interface:

interface ListableBeanFactoryImp extends ListableBeanFactory {

    public void ignoreDependencyType(Class type)

    public void addBeanPostProcessor(BeanPostProcessor beanPostProcessor)

    public final void destroySingletons()

}

The example that is actually motivating my thinking, is related to the AOP
stuff.  If I want try to add functionality to a BeanFactory so that it can
be aware of ProxyFactoryBean's for example, then the most simple approach
would be to use an XmlBeanFactory to read the bean definitions, but then to
wrap and delegate to this, from within an AOP aware BeanFactory.  The latter
could initialise itself via a BeanFactoryPostProcessor, and then provide
useful implementation support within the AOP module, ie it would again be
extending a ListableBeanFactoryImp interface, rather than anything client
facing.

As you say, all this can obviously be achieved by building BeanFactory's &
ApplicationContext's from scratch, but it seems a great shame not to be able
to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)

Anyway, I am sure the you get the sense of what I am on about - I just hope
I am not missing something fundamental to the whole issue ;)

Roger


"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:420...@ma......
> First of all, thanks for your kind words, Roger -- I appreciate them! :-)
>
> Regarding AbstractApplicationContext.getBeanFactory: I've indeed changed
its return value from ListableBeanFactory to ListableBeanFactoryImpl a while
ago, reason being that AbstractApplicationContext needs some configuration
stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
BeanFactory and ListableBeanFactory interfaces are intended for client
applications that access beans, they do not and should not include any
factory configuration or lifecycle methods.
>
> In detail, AbstractApplicationContext needs to invoke the following bean
factory implementation methods:
>
> - ignoreDependencyType: to register ApplicationContext as dependency type
to ignore on autowiring (as it is set by the ApplicationContextAware
interface, not by a property value).
>
> - addBeanPostProcessor: to register BeanPostProcessors, both
ApplicationContextAwareProcessor and custom ones, before creating
application beans from the bean definitions.
>
> - destroySingletons: to destroy singleton instances on application context
shutdown; particularly important for resource holders like a BasicDataSource
or a LocalSessionFactoryBean.
>
> - Furthermore, the postProcessBeanFactory method in the
BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
parameter to allow for access to all these bean factory configuration
methods. A ListableBeanFactory interface would be meaningless for this, as
you can't do any post-processing of bean definitions without access to them
and means to manipulate them.
>
> Let's not forget that is always possible to write an own
ApplicationContext implementation with any kind of bean factory underneath,
or a direct implementation of bean factory functionality instead of a
delegate, by not deriving from AbstractApplicationContext. The latter is
specifically intended for ListableBeanFactoryImpl delegates, providing rich
configuration functionality on top of them.
>
> Regarding JdbcBeanFactory: This one used a delegate
ListableBeanFactoryImpl underneath to be able to perform on-demand
refreshing. This is somewhat inconsistent with XmlBeanFactory's
implementation style: The latter derives from ListableBeanFactoryImpl and
adds various XML-related registerBeanDefinitions methods, leaving refresh
functionality to application contexts. IMO, that's a clear separation of
responsibilities: A BeanFactory is a low-level implementation; an
ApplicationContext builds higher-level functionality on top of it.
>
> Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl and
provide a registerBeanDefinitions(sql) method. Of course, it still has the
former (dataSource,sql) constructor as a convenience. I don't think that
anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
beans from a database in the first place), so that change shouldn't hurt. So
you can use JdbcBeanFactory with AbstractApplicationContext too, as it is a
ListableBeanFactoryImpl now :-)
>
> Rod, do you agree with the rationale? I believe it's straightforward and
consistent, particularly now that JdbcBeanFactory has adopted
XmlBeanFactory's implementation style. I hope you don't object to
JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe it
is important to provide consistent out-of-the-box BeanFactory
implementations (i.e. no refresh in bean factories but just in application
contexts).
>
> Juergen
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Sa 01.11.2003 17:32
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory
>
>
>
> Roger,
>
> > I've been lurking about for a fair while, being thoroughly impressed by
> > Springframework - the conception, the code, this excellent list, Rod's
> book,
> > in short the whole shebang - it seems quite a while since I encountered
a
> > project that more than anything, just seems to make me smile ;)  Many
> > thanks.
>
> Thanks. Made me smile :-)
>
> > First up is the subject line & the method
> > AbstractApplicationContext.getBeanFactory()
> > I am wondering if the signature for this method might have been changed
> > inadvertently ?  Prior to the introduction of support for
> > BeanFactoryPostProcessor's, the method was returning the
> ListableBeanFactory
> > interface, but thereafter it has been ListableBeanFactoryImpl.  As the
> > latter comes with a final modifier on each of the methods implementing
> that
> > interface, the opportunity for Plug'nPlay appears to have gone
missing...
> &
> > if I'm not mistaken, a first casualty would be the loss of a
> JdbcBeanFactory
> > within an AbstractApplicationContext.  Can someone shed some
> > light - am I just missing something ?
>
> I'll leave this one to Juergen, but I did notice it in passing and
> wondered...
>
> >
> > By the way, on my wanderings I noticed the following typo in
> > AbstractBeanDefinition.equals()
>
> Thanks, fixed it. Ah, the beauty of open source. That code isn't currently
> used btw, it was intended to allow for dynamic reconfiguration eventually.
> There would have been an argument for zapping it for now, actually.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> NHY??X'u?w+m?$>  xZ+? *.m?k +?^? j?z^?y! DD??i ^P)brA?m?q ?z v











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







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

Re: [Springframework-developer] Re: Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

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

Roger,

Try hitting the 'alternate' CVS server at sf.net described here:
  
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#firewall

It does allow anon access, and last time I verified this (about a month 
ago), it was completely up to date, as opposed to 24 hours behind like 
the main anon server.



roger holbrook wrote:

>Hi Juergen
>
>The changes you describe sound great - & as soon as anonymous CVS catches
>up, I'll check them out.  Unfortunately, all I can see so far is an empty
>beans.factory.config directory :(
>
>Many thanks
>
>Roger
>
>
>"jürgen höller [werk3AT]" <jue...@we...> wrote in message
>news:170...@co......
>Roger,
>
>I've adopted your idea of an SPI interface for bean factories: I've just
>introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory
>interfaces in a new beans.factory.config package; I've also moved
>BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
>postProcessBeanFactory method uses ConfigurableListableBeanFactory now, as
>does AbstractApplicationContext's getBeanFactory template method.
>
>I'm still not entirely sure why you would want to use a different bean
>factory with AbstractApplicationContext to leverage AOP functionality. All
>of Spring's AOP support should work without making the bean factory
>implementation explicitly aware of it. BeanPostProcessors and
>BeanFactoryPostProcessors are automatically detected and applied if defined
>as beans in an application context.
>
>Thanks for the thorough code review, BTW :-)
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von
>roger holbrook
>Gesendet: So 02.11.2003 18:46
>An: spr...@li...
>Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
>[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
>AbstractApplicationContext & ListableBeanFactory - Email found in subject -
>Email found in subject - Email found in subject - Email found in subject -
>Email found in subject
>
>
>
>
>Hi Juergen
>
>Many thanks for the explanation about
>AbstractApplicationContext.getBeanFactory.
>
>Just to check I've got it straight - would the following be an accurate
>summary:
>- ListableBeanFactory & ApplicationContext are client facing interfaces
>designed to hide all things related to implementation.
>- ListableBeanFactoryImpl & AbstractApplicationContext provide consistent
>out-of-the-box BeanFactory implementations that are considered of essential
>importance.
>- Currently the linkage between these 2 default implementations happens to
>be that one acts as a delegate class for the other, ie. the return type in
>question.
>
>The reworking of JdbcBeanFactory as a subclass of ListableBeanFactoryImpl,
>obviously solves the wiring problem in this particular case - but it does
>nothing for the general case of Plug'nPlay.  With the current arrangement,
>the one thing I cannot do is achieve effective easy reuse of all that highly
>crafted functionality that is so intricately wired up in AbstractBeanFactory
>and ListableBeanFactoryImpl - I cannot wrap and delegate !
>
>Aside from the implied name conflict, could you not preserve the original
>intention of making the linkage between the two an internal interface:
>
>interface ListableBeanFactoryImp extends ListableBeanFactory {
>
>    public void ignoreDependencyType(Class type)
>
>    public void addBeanPostProcessor(BeanPostProcessor beanPostProcessor)
>
>    public final void destroySingletons()
>
>}
>
>The example that is actually motivating my thinking, is related to the AOP
>stuff.  If I want try to add functionality to a BeanFactory so that it can
>be aware of ProxyFactoryBean's for example, then the most simple approach
>would be to use an XmlBeanFactory to read the bean definitions, but then to
>wrap and delegate to this, from within an AOP aware BeanFactory.  The latter
>could initialise itself via a BeanFactoryPostProcessor, and then provide
>useful implementation support within the AOP module, ie it would again be
>extending a ListableBeanFactoryImp interface, rather than anything client
>facing.
>
>As you say, all this can obviously be achieved by building BeanFactory's &
>ApplicationContext's from scratch, but it seems a great shame not to be able
>to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)
>
>Anyway, I am sure the you get the sense of what I am on about - I just hope
>I am not missing something fundamental to the whole issue ;)
>
>Roger
>
>
>"jürgen höller [werk3AT]" <jue...@we...> wrote in message
>news:420...@ma......
>  
>
>>First of all, thanks for your kind words, Roger -- I appreciate them! :-)
>>
>>Regarding AbstractApplicationContext.getBeanFactory: I've indeed changed
>>    
>>
>its return value from ListableBeanFactory to ListableBeanFactoryImpl a while
>ago, reason being that AbstractApplicationContext needs some configuration
>stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
>BeanFactory and ListableBeanFactory interfaces are intended for client
>applications that access beans, they do not and should not include any
>factory configuration or lifecycle methods.
>  
>
>>In detail, AbstractApplicationContext needs to invoke the following bean
>>    
>>
>factory implementation methods:
>  
>
>>- ignoreDependencyType: to register ApplicationContext as dependency type
>>    
>>
>to ignore on autowiring (as it is set by the ApplicationContextAware
>interface, not by a property value).
>  
>
>>- addBeanPostProcessor: to register BeanPostProcessors, both
>>    
>>
>ApplicationContextAwareProcessor and custom ones, before creating
>application beans from the bean definitions.
>  
>
>>- destroySingletons: to destroy singleton instances on application context
>>    
>>
>shutdown; particularly important for resource holders like a BasicDataSource
>or a LocalSessionFactoryBean.
>  
>
>>- Furthermore, the postProcessBeanFactory method in the
>>    
>>
>BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
>parameter to allow for access to all these bean factory configuration
>methods. A ListableBeanFactory interface would be meaningless for this, as
>you can't do any post-processing of bean definitions without access to them
>and means to manipulate them.
>  
>
>>Let's not forget that is always possible to write an own
>>    
>>
>ApplicationContext implementation with any kind of bean factory underneath,
>or a direct implementation of bean factory functionality instead of a
>delegate, by not deriving from AbstractApplicationContext. The latter is
>specifically intended for ListableBeanFactoryImpl delegates, providing rich
>configuration functionality on top of them.
>  
>
>>Regarding JdbcBeanFactory: This one used a delegate
>>    
>>
>ListableBeanFactoryImpl underneath to be able to perform on-demand
>refreshing. This is somewhat inconsistent with XmlBeanFactory's
>implementation style: The latter derives from ListableBeanFactoryImpl and
>adds various XML-related registerBeanDefinitions methods, leaving refresh
>functionality to application contexts. IMO, that's a clear separation of
>responsibilities: A BeanFactory is a low-level implementation; an
>ApplicationContext builds higher-level functionality on top of it.
>  
>
>>Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl and
>>    
>>
>provide a registerBeanDefinitions(sql) method. Of course, it still has the
>former (dataSource,sql) constructor as a convenience. I don't think that
>anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
>beans from a database in the first place), so that change shouldn't hurt. So
>you can use JdbcBeanFactory with AbstractApplicationContext too, as it is a
>ListableBeanFactoryImpl now :-)
>  
>
>>Rod, do you agree with the rationale? I believe it's straightforward and
>>    
>>
>consistent, particularly now that JdbcBeanFactory has adopted
>XmlBeanFactory's implementation style. I hope you don't object to
>JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe it
>is important to provide consistent out-of-the-box BeanFactory
>implementations (i.e. no refresh in bean factories but just in application
>contexts).
>  
>
>>Juergen
>>
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Rod Johnson [mailto:rod...@in...]
>>Gesendet: Sa 01.11.2003 17:32
>>An: spr...@li...
>>Cc:
>>Betreff: Re: [Springframework-developer] Plug'nPlay for
>>    
>>
>AbstractApplicationContext & ListableBeanFactory
>  
>
>>
>>Roger,
>>
>>    
>>
>>>I've been lurking about for a fair while, being thoroughly impressed by
>>>Springframework - the conception, the code, this excellent list, Rod's
>>>      
>>>
>>book,
>>    
>>
>>>in short the whole shebang - it seems quite a while since I encountered
>>>      
>>>
>a
>  
>
>>>project that more than anything, just seems to make me smile ;)  Many
>>>thanks.
>>>      
>>>
>>Thanks. Made me smile :-)
>>
>>    
>>
>>>First up is the subject line & the method
>>>AbstractApplicationContext.getBeanFactory()
>>>I am wondering if the signature for this method might have been changed
>>>inadvertently ?  Prior to the introduction of support for
>>>BeanFactoryPostProcessor's, the method was returning the
>>>      
>>>
>>ListableBeanFactory
>>    
>>
>>>interface, but thereafter it has been ListableBeanFactoryImpl.  As the
>>>latter comes with a final modifier on each of the methods implementing
>>>      
>>>
>>that
>>    
>>
>>>interface, the opportunity for Plug'nPlay appears to have gone
>>>      
>>>
>missing...
>  
>
>>&
>>    
>>
>>>if I'm not mistaken, a first casualty would be the loss of a
>>>      
>>>
>>JdbcBeanFactory
>>    
>>
>>>within an AbstractApplicationContext.  Can someone shed some
>>>light - am I just missing something ?
>>>      
>>>
>>I'll leave this one to Juergen, but I did notice it in passing and
>>wondered...
>>
>>    
>>
>>>By the way, on my wanderings I noticed the following typo in
>>>AbstractBeanDefinition.equals()
>>>      
>>>
>>Thanks, fixed it. Ah, the beauty of open source. That code isn't currently
>>used btw, it was intended to allow for dynamic reconfiguration eventually.
>>There would have been an argument for zapping it for now, actually.
>>
>>Regards,
>>Rod
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: SF.net Giveback Program.
>>Does SourceForge.net help you be more productive?  Does it
>>help you create better code?   SHARE THE LOVE, and help us help
>>YOU!  Click Here: http://sourceforge.net/donate/
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>NHY??X'u?w+m?$>  xZ+? *.m?k +?^? j?z^?y! DD??i ^P)brA?m?q ?z v
>>    
>>

Re: [Springframework-developer] Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

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

Ehm, I haven't committed the changes yet (sorry, forgot to mention =
that)... will do so tonight after some final polishing, together with =
refactored transaction manager implementations and some other minor =
stuff.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of roger holbrook
Sent: Tuesday, November 04, 2003 5:50 PM
To: spr...@li...
Subject: [[W3-SPAM]] - [Springframework-developer] Re: Re: Plug'nPlay
for AbstractApplicationContext & ListableBeanFactory - Email found in
subject



Hi Juergen

The changes you describe sound great - & as soon as anonymous CVS =
catches
up, I'll check them out.  Unfortunately, all I can see so far is an =
empty
beans.factory.config directory :(

Many thanks

Roger


"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
news:170...@co......
Roger,

I've adopted your idea of an SPI interface for bean factories: I've just
introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory
interfaces in a new beans.factory.config package; I've also moved
BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
postProcessBeanFactory method uses ConfigurableListableBeanFactory now, =
as
does AbstractApplicationContext's getBeanFactory template method.

I'm still not entirely sure why you would want to use a different bean
factory with AbstractApplicationContext to leverage AOP functionality. =
All
of Spring's AOP support should work without making the bean factory
implementation explicitly aware of it. BeanPostProcessors and
BeanFactoryPostProcessors are automatically detected and applied if =
defined
as beans in an application context.

Thanks for the thorough code review, BTW :-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
roger holbrook
Gesendet: So 02.11.2003 18:46
An: spr...@li...
Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory - Email found in =
subject -
Email found in subject - Email found in subject - Email found in subject =
-
Email found in subject




Hi Juergen

Many thanks for the explanation about
AbstractApplicationContext.getBeanFactory.

Just to check I've got it straight - would the following be an accurate
summary:
- ListableBeanFactory & ApplicationContext are client facing interfaces
designed to hide all things related to implementation.
- ListableBeanFactoryImpl & AbstractApplicationContext provide =
consistent
out-of-the-box BeanFactory implementations that are considered of =
essential
importance.
- Currently the linkage between these 2 default implementations happens =
to
be that one acts as a delegate class for the other, ie. the return type =
in
question.

The reworking of JdbcBeanFactory as a subclass of =
ListableBeanFactoryImpl,
obviously solves the wiring problem in this particular case - but it =
does
nothing for the general case of Plug'nPlay.  With the current =
arrangement,
the one thing I cannot do is achieve effective easy reuse of all that =
highly
crafted functionality that is so intricately wired up in =
AbstractBeanFactory
and ListableBeanFactoryImpl - I cannot wrap and delegate !

Aside from the implied name conflict, could you not preserve the =
original
intention of making the linkage between the two an internal interface:

interface ListableBeanFactoryImp extends ListableBeanFactory {

    public void ignoreDependencyType(Class type)

    public void addBeanPostProcessor(BeanPostProcessor =
beanPostProcessor)

    public final void destroySingletons()

}

The example that is actually motivating my thinking, is related to the =
AOP
stuff.  If I want try to add functionality to a BeanFactory so that it =
can
be aware of ProxyFactoryBean's for example, then the most simple =
approach
would be to use an XmlBeanFactory to read the bean definitions, but then =
to
wrap and delegate to this, from within an AOP aware BeanFactory.  The =
latter
could initialise itself via a BeanFactoryPostProcessor, and then provide
useful implementation support within the AOP module, ie it would again =
be
extending a ListableBeanFactoryImp interface, rather than anything =
client
facing.

As you say, all this can obviously be achieved by building BeanFactory's =
&
ApplicationContext's from scratch, but it seems a great shame not to be =
able
to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)

Anyway, I am sure the you get the sense of what I am on about - I just =
hope
I am not missing something fundamental to the whole issue ;)

Roger


"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
news:420...@ma......
> First of all, thanks for your kind words, Roger -- I appreciate them! =
:-)
>
> Regarding AbstractApplicationContext.getBeanFactory: I've indeed =
changed
its return value from ListableBeanFactory to ListableBeanFactoryImpl a =
while
ago, reason being that AbstractApplicationContext needs some =
configuration
stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
BeanFactory and ListableBeanFactory interfaces are intended for client
applications that access beans, they do not and should not include any
factory configuration or lifecycle methods.
>
> In detail, AbstractApplicationContext needs to invoke the following =
bean
factory implementation methods:
>
> - ignoreDependencyType: to register ApplicationContext as dependency =
type
to ignore on autowiring (as it is set by the ApplicationContextAware
interface, not by a property value).
>
> - addBeanPostProcessor: to register BeanPostProcessors, both
ApplicationContextAwareProcessor and custom ones, before creating
application beans from the bean definitions.
>
> - destroySingletons: to destroy singleton instances on application =
context
shutdown; particularly important for resource holders like a =
BasicDataSource
or a LocalSessionFactoryBean.
>
> - Furthermore, the postProcessBeanFactory method in the
BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
parameter to allow for access to all these bean factory configuration
methods. A ListableBeanFactory interface would be meaningless for this, =
as
you can't do any post-processing of bean definitions without access to =
them
and means to manipulate them.
>
> Let's not forget that is always possible to write an own
ApplicationContext implementation with any kind of bean factory =
underneath,
or a direct implementation of bean factory functionality instead of a
delegate, by not deriving from AbstractApplicationContext. The latter is
specifically intended for ListableBeanFactoryImpl delegates, providing =
rich
configuration functionality on top of them.
>
> Regarding JdbcBeanFactory: This one used a delegate
ListableBeanFactoryImpl underneath to be able to perform on-demand
refreshing. This is somewhat inconsistent with XmlBeanFactory's
implementation style: The latter derives from ListableBeanFactoryImpl =
and
adds various XML-related registerBeanDefinitions methods, leaving =
refresh
functionality to application contexts. IMO, that's a clear separation of
responsibilities: A BeanFactory is a low-level implementation; an
ApplicationContext builds higher-level functionality on top of it.
>
> Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl =
and
provide a registerBeanDefinitions(sql) method. Of course, it still has =
the
former (dataSource,sql) constructor as a convenience. I don't think that
anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
beans from a database in the first place), so that change shouldn't =
hurt. So
you can use JdbcBeanFactory with AbstractApplicationContext too, as it =
is a
ListableBeanFactoryImpl now :-)
>
> Rod, do you agree with the rationale? I believe it's straightforward =
and
consistent, particularly now that JdbcBeanFactory has adopted
XmlBeanFactory's implementation style. I hope you don't object to
JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe =
it
is important to provide consistent out-of-the-box BeanFactory
implementations (i.e. no refresh in bean factories but just in =
application
contexts).
>
> Juergen
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Sa 01.11.2003 17:32
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory
>
>
>
> Roger,
>
> > I've been lurking about for a fair while, being thoroughly impressed =
by
> > Springframework - the conception, the code, this excellent list, =
Rod's
> book,
> > in short the whole shebang - it seems quite a while since I =
encountered
a
> > project that more than anything, just seems to make me smile ;)  =
Many
> > thanks.
>
> Thanks. Made me smile :-)
>
> > First up is the subject line & the method
> > AbstractApplicationContext.getBeanFactory()
> > I am wondering if the signature for this method might have been =
changed
> > inadvertently ?  Prior to the introduction of support for
> > BeanFactoryPostProcessor's, the method was returning the
> ListableBeanFactory
> > interface, but thereafter it has been ListableBeanFactoryImpl.  As =
the
> > latter comes with a final modifier on each of the methods =
implementing
> that
> > interface, the opportunity for Plug'nPlay appears to have gone
missing...
> &
> > if I'm not mistaken, a first casualty would be the loss of a
> JdbcBeanFactory
> > within an AbstractApplicationContext.  Can someone shed some
> > light - am I just missing something ?
>
> I'll leave this one to Juergen, but I did notice it in passing and
> wondered...
>
> >
> > By the way, on my wanderings I noticed the following typo in
> > AbstractBeanDefinition.equals()
>
> Thanks, fixed it. Ah, the beauty of open source. That code isn't =
currently
> used btw, it was intended to allow for dynamic reconfiguration =
eventually.
> There would have been an argument for zapping it for now, actually.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> N=18HY??X'u?=16w=1A+m?$> =12 xZ+? =17*.m?k +=0E?^? j?z^?=1Dy! =
DD=10?=11?i ^=0EP)brA?m?q =07?z v











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







-------------------------------------------------------
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: Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

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

Hi Juergen

The changes you describe sound great - & as soon as anonymous CVS catches
up, I'll check them out.  Unfortunately, all I can see so far is an empty
beans.factory.config directory :(

Many thanks

Roger


"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Roger,

I've adopted your idea of an SPI interface for bean factories: I've just
introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory
interfaces in a new beans.factory.config package; I've also moved
BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
postProcessBeanFactory method uses ConfigurableListableBeanFactory now, as
does AbstractApplicationContext's getBeanFactory template method.

I'm still not entirely sure why you would want to use a different bean
factory with AbstractApplicationContext to leverage AOP functionality. All
of Spring's AOP support should work without making the bean factory
implementation explicitly aware of it. BeanPostProcessors and
BeanFactoryPostProcessors are automatically detected and applied if defined
as beans in an application context.

Thanks for the thorough code review, BTW :-)

Juergen


________________________________

Von: spr...@li... im Auftrag von
roger holbrook
Gesendet: So 02.11.2003 18:46
An: spr...@li...
Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory - Email found in subject -
Email found in subject - Email found in subject - Email found in subject -
Email found in subject




Hi Juergen

Many thanks for the explanation about
AbstractApplicationContext.getBeanFactory.

Just to check I've got it straight - would the following be an accurate
summary:
- ListableBeanFactory & ApplicationContext are client facing interfaces
designed to hide all things related to implementation.
- ListableBeanFactoryImpl & AbstractApplicationContext provide consistent
out-of-the-box BeanFactory implementations that are considered of essential
importance.
- Currently the linkage between these 2 default implementations happens to
be that one acts as a delegate class for the other, ie. the return type in
question.

The reworking of JdbcBeanFactory as a subclass of ListableBeanFactoryImpl,
obviously solves the wiring problem in this particular case - but it does
nothing for the general case of Plug'nPlay.  With the current arrangement,
the one thing I cannot do is achieve effective easy reuse of all that highly
crafted functionality that is so intricately wired up in AbstractBeanFactory
and ListableBeanFactoryImpl - I cannot wrap and delegate !

Aside from the implied name conflict, could you not preserve the original
intention of making the linkage between the two an internal interface:

interface ListableBeanFactoryImp extends ListableBeanFactory {

    public void ignoreDependencyType(Class type)

    public void addBeanPostProcessor(BeanPostProcessor beanPostProcessor)

    public final void destroySingletons()

}

The example that is actually motivating my thinking, is related to the AOP
stuff.  If I want try to add functionality to a BeanFactory so that it can
be aware of ProxyFactoryBean's for example, then the most simple approach
would be to use an XmlBeanFactory to read the bean definitions, but then to
wrap and delegate to this, from within an AOP aware BeanFactory.  The latter
could initialise itself via a BeanFactoryPostProcessor, and then provide
useful implementation support within the AOP module, ie it would again be
extending a ListableBeanFactoryImp interface, rather than anything client
facing.

As you say, all this can obviously be achieved by building BeanFactory's &
ApplicationContext's from scratch, but it seems a great shame not to be able
to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)

Anyway, I am sure the you get the sense of what I am on about - I just hope
I am not missing something fundamental to the whole issue ;)

Roger


"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:420...@ma......
> First of all, thanks for your kind words, Roger -- I appreciate them! :-)
>
> Regarding AbstractApplicationContext.getBeanFactory: I've indeed changed
its return value from ListableBeanFactory to ListableBeanFactoryImpl a while
ago, reason being that AbstractApplicationContext needs some configuration
stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
BeanFactory and ListableBeanFactory interfaces are intended for client
applications that access beans, they do not and should not include any
factory configuration or lifecycle methods.
>
> In detail, AbstractApplicationContext needs to invoke the following bean
factory implementation methods:
>
> - ignoreDependencyType: to register ApplicationContext as dependency type
to ignore on autowiring (as it is set by the ApplicationContextAware
interface, not by a property value).
>
> - addBeanPostProcessor: to register BeanPostProcessors, both
ApplicationContextAwareProcessor and custom ones, before creating
application beans from the bean definitions.
>
> - destroySingletons: to destroy singleton instances on application context
shutdown; particularly important for resource holders like a BasicDataSource
or a LocalSessionFactoryBean.
>
> - Furthermore, the postProcessBeanFactory method in the
BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
parameter to allow for access to all these bean factory configuration
methods. A ListableBeanFactory interface would be meaningless for this, as
you can't do any post-processing of bean definitions without access to them
and means to manipulate them.
>
> Let's not forget that is always possible to write an own
ApplicationContext implementation with any kind of bean factory underneath,
or a direct implementation of bean factory functionality instead of a
delegate, by not deriving from AbstractApplicationContext. The latter is
specifically intended for ListableBeanFactoryImpl delegates, providing rich
configuration functionality on top of them.
>
> Regarding JdbcBeanFactory: This one used a delegate
ListableBeanFactoryImpl underneath to be able to perform on-demand
refreshing. This is somewhat inconsistent with XmlBeanFactory's
implementation style: The latter derives from ListableBeanFactoryImpl and
adds various XML-related registerBeanDefinitions methods, leaving refresh
functionality to application contexts. IMO, that's a clear separation of
responsibilities: A BeanFactory is a low-level implementation; an
ApplicationContext builds higher-level functionality on top of it.
>
> Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl and
provide a registerBeanDefinitions(sql) method. Of course, it still has the
former (dataSource,sql) constructor as a convenience. I don't think that
anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
beans from a database in the first place), so that change shouldn't hurt. So
you can use JdbcBeanFactory with AbstractApplicationContext too, as it is a
ListableBeanFactoryImpl now :-)
>
> Rod, do you agree with the rationale? I believe it's straightforward and
consistent, particularly now that JdbcBeanFactory has adopted
XmlBeanFactory's implementation style. I hope you don't object to
JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe it
is important to provide consistent out-of-the-box BeanFactory
implementations (i.e. no refresh in bean factories but just in application
contexts).
>
> Juergen
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Sa 01.11.2003 17:32
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory
>
>
>
> Roger,
>
> > I've been lurking about for a fair while, being thoroughly impressed by
> > Springframework - the conception, the code, this excellent list, Rod's
> book,
> > in short the whole shebang - it seems quite a while since I encountered
a
> > project that more than anything, just seems to make me smile ;)  Many
> > thanks.
>
> Thanks. Made me smile :-)
>
> > First up is the subject line & the method
> > AbstractApplicationContext.getBeanFactory()
> > I am wondering if the signature for this method might have been changed
> > inadvertently ?  Prior to the introduction of support for
> > BeanFactoryPostProcessor's, the method was returning the
> ListableBeanFactory
> > interface, but thereafter it has been ListableBeanFactoryImpl.  As the
> > latter comes with a final modifier on each of the methods implementing
> that
> > interface, the opportunity for Plug'nPlay appears to have gone
missing...
> &
> > if I'm not mistaken, a first casualty would be the loss of a
> JdbcBeanFactory
> > within an AbstractApplicationContext.  Can someone shed some
> > light - am I just missing something ?
>
> I'll leave this one to Juergen, but I did notice it in passing and
> wondered...
>
> >
> > By the way, on my wanderings I noticed the following typo in
> > AbstractBeanDefinition.equals()
>
> Thanks, fixed it. Ah, the beauty of open source. That code isn't currently
> used btw, it was intended to allow for dynamic reconfiguration eventually.
> There would have been an argument for zapping it for now, actually.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> NHY??X'u?w+m?$>  xZ+? *.m?k +?^? j?z^?y! DD??i ^P)brA?m?q ?z v











-------------------------------------------------------
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] doc format

[William G. T. Jr. <wg...@ru...>]

Folks,

This may be bit late, but I just stumbled upon it this morning.

AurigaDoc is a java-xml-xsl based documentation tool for writing xml 
documents and converting them to other open formats like HTML(single and 
multi page), DHTML, PDF, PostScript, Formatting Object(FO), RTF, Java 
Help and HTML Help(.chm)
http://aurigadoc.sourceforge.net/

I haven't used it yet, but the examples look good.

The source files are XML and you write content using subset of XHTML. 
The problem I've found with DocBook is that not many ppl know it.

later.
Bill
-- 
William G. Thompson, Jr.
Associate Director of New Technologies
Administrative Computing Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wg...@ru...

Re: [Springframework-developer] RE: Question about Bean Factories - the Singleton attribute/property

[Cameron B. <ca...@da...>]

Great Explanation !

Thanks.  It makes perfect sense now :)

Cameron

jürgen höller [werk3AT] wrote:

>Effectively, FactoryBean.isSingleton just gives a hint whether getObject will return a cached singleton or a new instance on each call. Currently, this is just evaluated for getBeansOfType checks. The singleton flag of the bean definition on the other hand determines how the bean factory treats the FactoryBean itself.
>
>If the FactoryBean is not a singleton, each reference to it will create a new FactoryBean in the bean factory. That instance can in turn return an internally cached singleton on getObject or a new object on each call. Obviously, a non-singleton FactoryBean that returns a singleton object does not make much sense.
>
>So if you implement FactoryBean.isSingleton = false and correspondingly create a new instance on each getObject call to your FactoryBean, bean references will always get a new object. Making the FactoryBean itself a singleton too is orthogonal to this; you will almost always have it as singleton.
>
>So there are two independent singleton statuses involved:
>- the one of the FactoryBean: Should the bean factory create a new FactoryBean on each reference?
>- the one of the object created by the FactoryBean: Does the FactoryBean create a new object on each getObject call?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Cameron Braid
>Sent: Tuesday, November 04, 2003 4:06 PM
>To: spr...@li...
>Subject: [[W3-SPAM]] - [Springframework-developer] Question about Bean
>Factories - the Singleton attribute/property - Email found in subject
>
>
>I am implementing a bean factory that is not a singleton.
>
>There are two places where I can specify this property :
>
>1) in the <bean singleton="true|false|"> tag
>2) in the boolean FactoryBean.isSingleton()
>
>The doco states :
>
>  The singleton status of the FactoryBean itself will
>     * generally be provided by the owning BeanFactory.
>
>Please explain how this works.
>
>If I implement isSingleton = false, then someone configures <bean ... 
>singleton="true" >  what will happen ?
>
>Thanks,
>
>Cameron
>
>  
>


-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

[Springframework-developer] RE: Question about Bean Factories - the Singleton attribute/property

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

Effectively, FactoryBean.isSingleton just gives a hint whether getObject =
will return a cached singleton or a new instance on each call. =
Currently, this is just evaluated for getBeansOfType checks. The =
singleton flag of the bean definition on the other hand determines how =
the bean factory treats the FactoryBean itself.

If the FactoryBean is not a singleton, each reference to it will create =
a new FactoryBean in the bean factory. That instance can in turn return =
an internally cached singleton on getObject or a new object on each =
call. Obviously, a non-singleton FactoryBean that returns a singleton =
object does not make much sense.

So if you implement FactoryBean.isSingleton =3D false and =
correspondingly create a new instance on each getObject call to your =
FactoryBean, bean references will always get a new object. Making the =
FactoryBean itself a singleton too is orthogonal to this; you will =
almost always have it as singleton.

So there are two independent singleton statuses involved:
- the one of the FactoryBean: Should the bean factory create a new =
FactoryBean on each reference?
- the one of the object created by the FactoryBean: Does the FactoryBean =
create a new object on each getObject call?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Cameron Braid
Sent: Tuesday, November 04, 2003 4:06 PM
To: spr...@li...
Subject: [[W3-SPAM]] - [Springframework-developer] Question about Bean
Factories - the Singleton attribute/property - Email found in subject


I am implementing a bean factory that is not a singleton.

There are two places where I can specify this property :

1) in the <bean singleton=3D"true|false|"> tag
2) in the boolean FactoryBean.isSingleton()

The doco states :

  The singleton status of the FactoryBean itself will
     * generally be provided by the owning BeanFactory.

Please explain how this works.

If I implement isSingleton =3D false, then someone configures <bean ...=20
singleton=3D"true" >  what will happen ?

Thanks,

Cameron

--=20
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler =
http://www.martinfowler.com/distributedComputing/refactoring.pdf]





-------------------------------------------------------
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] Question about Bean Factories - the Singleton attribute/property

[Cameron B. <ca...@da...>]

I am implementing a bean factory that is not a singleton.

There are two places where I can specify this property :

1) in the <bean singleton="true|false|"> tag
2) in the boolean FactoryBean.isSingleton()

The doco states :

  The singleton status of the FactoryBean itself will
     * generally be provided by the owning BeanFactory.

Please explain how this works.

If I implement isSingleton = false, then someone configures <bean ... 
singleton="true" >  what will happen ?

Thanks,

Cameron

-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

Re: [Springframework-developer] How to use the ProxyFactory to enhance an instance

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

Cameron,

Just wanted to let you know that I will look at this, probably towards the
end of the week. Let me know if you progress in the meantime...

Regards,
Rod

----- Original Message ----- 
From: "Cameron Braid" <ca...@da...>
To: <spr...@li...>
Sent: Monday, November 03, 2003 11:27 AM
Subject: [Springframework-developer] How to use the ProxyFactory to enhance
an instance


> I was experimenting with generating AOP proxies.
>
> I want to create a proxy that is a superclass of an action, to allow me to
add transactional interceptors.
>
> I tried using
>
>         Object action = createAction();
>         ProxyFactory proxyFactory = new ProxyFactory(action);
>         proxyFactory.addInterceptor(.. my interceptor ...);
>         return proxyFactory.getProxy();
>
> though this uses a J2SE proxy, which only works on the defined interfaces.
>
> I tried to get the aop proxy factory to use cblib by doing this :
>
>         Object action = createAction();
>         ProxyFactory proxyFactory = new ProxyFactory(action);
>         proxyFactory.setInterfaces(new Class[]{});
>         proxyFactory.addInterceptor(transactionInterceptor);
>         proxyFactory.addInterceptor(new InvokerInterceptor(action));
>         return proxyFactory.getProxy();
>
> to create a proxy that has a target, but I need to remove the interfaces
otherwise a J2SE proxy will be created.
>
> This works ok, except for the fact that I am using an instance of the
action for the target, and cglib creates a new instance from the call to
enhance
>
> Enhancer.enhance(config.getTarget().getClass(),
config.getProxiedInterfaces(), ...)
>
> Is there any way that the proxy factory can be rigged to allow
specification of a target class, without an instance, then instead of me
creating an instance, cglib can create it for me ?
>
> Something like
>
>         Class actionClazz = getActionClass()
>         ProxyFactory proxyFactory = new ProxyFactory(actionClazz);
>         proxyFactory.addInterceptor(transactionInterceptor);
>         proxyFactory.addInterceptor(new ProxyTargetInvokerInterceptor());
>         return proxyFactory.getProxy();
>
> Though I don't know how the invoker interceptor will work, since there is
no actual target external to the proxy.
> Maybe a new ProxyTargetInvokerInterceptor() could be added.  Without it,
invocations on the proxy would be exhibit the same behaviour as if an
InvokerInterceptor didn't exist at all.
>
> I dunno if I have made this very clear.. I am new to the AOP terminoligy .
>
> Cameron.
>
>
> -- 
> Any damn fool can write code that a computer can understand...
> The trick is to write code that humans can understand.
> [Martin Fowler
http://www.martinfowler.com/distributedComputing/refactoring.pdf]------------------------------------------------------- 
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] Code base is broken

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

Once again, rebuilt the project and now everything is fine. Could be a bug
in Eclipse (I'm using 2.1)
 
Sorry for the confusion.
 
Dmitriy.

-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...] 
Sent: Tuesday, November 04, 2003 8:34 AM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] Code base is broken


Correction,
I can see now ITestBean and TestBean but for some reason they cannot be
resolved in Eclipse. I'll try to rebuild the project.
 
Dmitriy.

-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...] 
Sent: Tuesday, November 04, 2003 8:29 AM
To: 'spr...@li...'
Subject: [Springframework-developer] Code base is broken



Hello all, 

I've just resynchronized with the latest CVS code base and found that
org.springframework.beans.ITestBean and org.springframework.beans.TestBean
are missing. Therefore it introduces a "disarray" i.e. all the tests relying
on these classes will not compile.

Regards, 
Dmitriy. 

RE: [Springframework-developer] Code base is broken

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

Correction,
I can see now ITestBean and TestBean but for some reason they cannot be
resolved in Eclipse. I'll try to rebuild the project.
 
Dmitriy.

-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...] 
Sent: Tuesday, November 04, 2003 8:29 AM
To: 'spr...@li...'
Subject: [Springframework-developer] Code base is broken



Hello all, 

I've just resynchronized with the latest CVS code base and found that
org.springframework.beans.ITestBean and org.springframework.beans.TestBean
are missing. Therefore it introduces a "disarray" i.e. all the tests relying
on these classes will not compile.

Regards, 
Dmitriy. 

[Springframework-developer] Code base is broken

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

Hello all,

I've just resynchronized with the latest CVS code base and found that
org.springframework.beans.ITestBean and org.springframework.beans.TestBean
are missing. Therefore it introduces a "disarray" i.e. all the tests relying
on these classes will not compile.

Regards,
Dmitriy.

RE: [Springframework-developer] Documentation based on DocBook: call for decision :)

[Alef A. \(JTeam\) <al...@jt...>]

> What did you use to write this - a plain editor or something wysiwyg? 
I usually do this kind of stuff in a plain editor, but there are quite
some editors out there... Also wysiwyg ones...
> 
> > 1. Do we agree on having documentation based on DocBook?
> > 
> 
> It seems to be a good choice if since we can generate both 
> pdf and html.  I 
> assume there is an ant task so we can make this part of the 
> build.  Have you 
> tried generating both pdf and html with a document that 
> includes graphics and 
> source code listings.  Sometimes it's hard to get it to look 
> good in several 
> formats.
Yup, there's some extra targets included in my local build.xml (docpdf,
dochtml, dochtml-single), basically I ripped them from Hibernate. Works
quite well... About the images and code-listings, I hjaven't had a look
at that yet, will see if that works!

> > 2. Are we going to aggregate all documentation in one sort of 
> > reference-manual (docbook allows us to publish it in HTML as well).
> > 
> 
> I'd like to see a "Spring Users Guide" and separate tutorials 
> for "Bean 
> Container", MVC, JDBC, AOP etc.
That seems reasonble.

> Wiki does not seem to very popular - maybe it's beacuse the 
> one we have is not 
> that great.  Somehow we should make it clear though what the 
> preferred channel 
> for support is - wiki, forums or mailing lists.
Agree. Hibernate uses coWiki, which is quite powerful and can be used to
maintain the website as well (the complete hib website is coWiki-based).
Could be an option. Also to get more interaction with users, having to
subscribe to a mailinglist gives people the creeps sometimes...
But, we don't have to do this right now (or at all). I think we just
have to keeps things like that in the back of our heads...


> Could that be beacause you were doing accounting the week before this
one. :-)
Well, that's finished now, a couple of more shitty jobs to do, then back
to development :)

Re: [Springframework-developer] Documentation based on DocBook: call for decision :)

[<tri...@tr...>]

Quoting "Alef Arendsen (JTeam)" <al...@jt...>:

> All,
> 
> I've spent some more time in front of the TV and organizing some docs
> together during the commercials (I hate those!). The result can be found
> in the docs directory in the spring-reference.pdf file. I've prepared a
> basic structure and did some work on the beanfactory chapter to get some
> impression how things would look (so have a look at that chapter
> specifically).
> 
> Before I go on (if even), a couple of questions (the sources for the
> docbook xml can be found in a zip located at www.jteam.nl/docbook.zip)
> 

What did you use to write this - a plain editor or something wysiwyg? 

> 1. Do we agree on having documentation based on DocBook?
> 

It seems to be a good choice if since we can generate both pdf and html.  I 
assume there is an ant task so we can make this part of the build.  Have you 
tried generating both pdf and html with a document that includes graphics and 
source code listings.  Sometimes it's hard to get it to look good in several 
formats.

> 2. Are we going to aggregate all documentation in one sort of
> reference-manual (docbook allows us to publish it in HTML as well).
> 

I'd like to see a "Spring Users Guide" and separate tutorials for "Bean 
Container", MVC, JDBC, AOP etc.

> 3. What about the coWiki approach we suggested a couple of days ago?
> 

Wiki does not seem to very popular - maybe it's beacuse the one we have is not 
that great.  Somehow we should make it clear though what the preferred channel 
for support is - wiki, forums or mailing lists.

> I'd like us to decide on this soon so I can either go on (and add it to
> CVS so other people can do whatever they want) or leave it :-).
> 
> Alef
> 
> P.s. __sometimes__ I actually like documenting stuff, like this week :)
> 

Could that be beacause you were doing accounting the week before this one. :-)

> 
> 
> 
> 
> -------------------------------------------------------
> 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] Scheduler update #2

[Alef A. \(JTeam\) <al...@jt...>]

<off-topic>

Juergen,

Interesting stuff you have there. I'd love to participate in such
projects :)...

> That should work reliably in a
> cluster, shouldn't it? Has anyone experience with such load 
> balancing via JMS, particularly if execution reports are required?

Well, I think it should work. One of our projects runs with distributed
JMS right now, Not really two-way like you mentioned, but it works
perfectly. We did it with JBoss (3.2) and had To go through quite some
hassle before we got it running, but it works like a charm now... We've
in fact got distributed XA transactions with Jboss/Oracle running there
as well, pretty cool...

</off-topic>

[Springframework-developer] Documentation based on DocBook: call for decision :)

[Alef A. \(JTeam\) <al...@jt...>]

All,

I've spent some more time in front of the TV and organizing some docs
together during the commercials (I hate those!). The result can be found
in the docs directory in the spring-reference.pdf file. I've prepared a
basic structure and did some work on the beanfactory chapter to get some
impression how things would look (so have a look at that chapter
specifically).

Before I go on (if even), a couple of questions (the sources for the
docbook xml can be found in a zip located at www.jteam.nl/docbook.zip)

1. Do we agree on having documentation based on DocBook?

2. Are we going to aggregate all documentation in one sort of
reference-manual (docbook allows us to publish it in HTML as well).

3. What about the coWiki approach we suggested a couple of days ago?

I'd like us to decide on this soon so I can either go on (and add it to
CVS so other people can do whatever they want) or leave it :-).

Alef

P.s. __sometimes__ I actually like documenting stuff, like this week :)

Re: [Springframework-developer] Scheduler update #2

[Ivan R. <iv...@we...>]

jürgen höller [werk3AT] wrote:

Jürgen,

I admire your ability to write long and interesting emails. Thank you
for informing us about the interesting work that you're doing :)


> - A CommandTaskDefinition (implements Runnable) takes a class name,
 > bean property values, and an execute method (plus optional
 > arguments). On run, it would simply instantiate the class, populate
 > the bean properties, and invoke the execute method.

   This sounds appealing but we effectively already have it with the
   combination of bean definition and SpringBeanTask definition.

   Personally, I don't mind having to do it in two steps. It also
   gives you the flexibility to reference the bean you are scheduling,
   and to schedule beans more than once if required.


 > - An EjbTaskDefinition (implements Runnable) takes a JNDI name and
 > method name plus arguments. Other such convenience classes can be
 > added, of course.

   And many other come to mind: native exec, HTTP, BeanShell, etc. We
   could group these in a separate package because they would apply
   to all scheduler implementations through the power of abstraction.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Scheduler update #2

[Ivan R. <iv...@we...>]

> My early findings are based on assumptions I'm making about "Chronos".  If
> any of my assumptions are incorrect, please let me know (I should be more
> accurate once I can examine the source).

   Here is the Javadoc documentation:
   http://www.webkreator.com/download/chronos/javadoc/

   and here's the source:
   http://www.webkreator.com/download/chronos/chronos-20031103.zip
   (the Eclipse folder archived)

   I'll probably remove the CronTask class. The PersistentScheduler
   interface is not used (it will probably be removed, too). Other
   than this I plan to change CronScheduler.createTask(String) into
   CronScheduler.createTask(String, String) (as in the manual).

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

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

Roger,
=20
I've adopted your idea of an SPI interface for bean factories: I've just =
introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory =
interfaces in a new beans.factory.config package; I've also moved =
BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's =
postProcessBeanFactory method uses ConfigurableListableBeanFactory now, =
as does AbstractApplicationContext's getBeanFactory template method.
=20
I'm still not entirely sure why you would want to use a different bean =
factory with AbstractApplicationContext to leverage AOP functionality. =
All of Spring's AOP support should work without making the bean factory =
implementation explicitly aware of it. BeanPostProcessors and =
BeanFactoryPostProcessors are automatically detected and applied if =
defined as beans in an application context.
=20
Thanks for the thorough code review, BTW :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von roger holbrook
Gesendet: So 02.11.2003 18:46
An: spr...@li...
Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - =
[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for =
AbstractApplicationContext & ListableBeanFactory - Email found in =
subject - Email found in subject - Email found in subject - Email found =
in subject - Email found in subject




Hi Juergen

Many thanks for the explanation about
AbstractApplicationContext.getBeanFactory.

Just to check I've got it straight - would the following be an accurate
summary:
- ListableBeanFactory & ApplicationContext are client facing interfaces
designed to hide all things related to implementation.
- ListableBeanFactoryImpl & AbstractApplicationContext provide =
consistent
out-of-the-box BeanFactory implementations that are considered of =
essential
importance.
- Currently the linkage between these 2 default implementations happens =
to
be that one acts as a delegate class for the other, ie. the return type =
in
question.

The reworking of JdbcBeanFactory as a subclass of =
ListableBeanFactoryImpl,
obviously solves the wiring problem in this particular case - but it =
does
nothing for the general case of Plug'nPlay.  With the current =
arrangement,
the one thing I cannot do is achieve effective easy reuse of all that =
highly
crafted functionality that is so intricately wired up in =
AbstractBeanFactory
and ListableBeanFactoryImpl - I cannot wrap and delegate !

Aside from the implied name conflict, could you not preserve the =
original
intention of making the linkage between the two an internal interface:

interface ListableBeanFactoryImp extends ListableBeanFactory {

    public void ignoreDependencyType(Class type)

    public void addBeanPostProcessor(BeanPostProcessor =
beanPostProcessor)

    public final void destroySingletons()

}

The example that is actually motivating my thinking, is related to the =
AOP
stuff.  If I want try to add functionality to a BeanFactory so that it =
can
be aware of ProxyFactoryBean's for example, then the most simple =
approach
would be to use an XmlBeanFactory to read the bean definitions, but then =
to
wrap and delegate to this, from within an AOP aware BeanFactory.  The =
latter
could initialise itself via a BeanFactoryPostProcessor, and then provide
useful implementation support within the AOP module, ie it would again =
be
extending a ListableBeanFactoryImp interface, rather than anything =
client
facing.

As you say, all this can obviously be achieved by building BeanFactory's =
&
ApplicationContext's from scratch, but it seems a great shame not to be =
able
to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)

Anyway, I am sure the you get the sense of what I am on about - I just =
hope
I am not missing something fundamental to the whole issue ;)

Roger


"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
news:420...@ma......
> First of all, thanks for your kind words, Roger -- I appreciate them! =
:-)
>
> Regarding AbstractApplicationContext.getBeanFactory: I've indeed =
changed
its return value from ListableBeanFactory to ListableBeanFactoryImpl a =
while
ago, reason being that AbstractApplicationContext needs some =
configuration
stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
BeanFactory and ListableBeanFactory interfaces are intended for client
applications that access beans, they do not and should not include any
factory configuration or lifecycle methods.
>
> In detail, AbstractApplicationContext needs to invoke the following =
bean
factory implementation methods:
>
> - ignoreDependencyType: to register ApplicationContext as dependency =
type
to ignore on autowiring (as it is set by the ApplicationContextAware
interface, not by a property value).
>
> - addBeanPostProcessor: to register BeanPostProcessors, both
ApplicationContextAwareProcessor and custom ones, before creating
application beans from the bean definitions.
>
> - destroySingletons: to destroy singleton instances on application =
context
shutdown; particularly important for resource holders like a =
BasicDataSource
or a LocalSessionFactoryBean.
>
> - Furthermore, the postProcessBeanFactory method in the
BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
parameter to allow for access to all these bean factory configuration
methods. A ListableBeanFactory interface would be meaningless for this, =
as
you can't do any post-processing of bean definitions without access to =
them
and means to manipulate them.
>
> Let's not forget that is always possible to write an own
ApplicationContext implementation with any kind of bean factory =
underneath,
or a direct implementation of bean factory functionality instead of a
delegate, by not deriving from AbstractApplicationContext. The latter is
specifically intended for ListableBeanFactoryImpl delegates, providing =
rich
configuration functionality on top of them.
>
> Regarding JdbcBeanFactory: This one used a delegate
ListableBeanFactoryImpl underneath to be able to perform on-demand
refreshing. This is somewhat inconsistent with XmlBeanFactory's
implementation style: The latter derives from ListableBeanFactoryImpl =
and
adds various XML-related registerBeanDefinitions methods, leaving =
refresh
functionality to application contexts. IMO, that's a clear separation of
responsibilities: A BeanFactory is a low-level implementation; an
ApplicationContext builds higher-level functionality on top of it.
>
> Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl =
and
provide a registerBeanDefinitions(sql) method. Of course, it still has =
the
former (dataSource,sql) constructor as a convenience. I don't think that
anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
beans from a database in the first place), so that change shouldn't =
hurt. So
you can use JdbcBeanFactory with AbstractApplicationContext too, as it =
is a
ListableBeanFactoryImpl now :-)
>
> Rod, do you agree with the rationale? I believe it's straightforward =
and
consistent, particularly now that JdbcBeanFactory has adopted
XmlBeanFactory's implementation style. I hope you don't object to
JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe =
it
is important to provide consistent out-of-the-box BeanFactory
implementations (i.e. no refresh in bean factories but just in =
application
contexts).
>
> Juergen
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Sa 01.11.2003 17:32
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory
>
>
>
> Roger,
>
> > I've been lurking about for a fair while, being thoroughly impressed =
by
> > Springframework - the conception, the code, this excellent list, =
Rod's
> book,
> > in short the whole shebang - it seems quite a while since I =
encountered
a
> > project that more than anything, just seems to make me smile ;)  =
Many
> > thanks.
>
> Thanks. Made me smile :-)
>
> > First up is the subject line & the method
> > AbstractApplicationContext.getBeanFactory()
> > I am wondering if the signature for this method might have been =
changed
> > inadvertently ?  Prior to the introduction of support for
> > BeanFactoryPostProcessor's, the method was returning the
> ListableBeanFactory
> > interface, but thereafter it has been ListableBeanFactoryImpl.  As =
the
> > latter comes with a final modifier on each of the methods =
implementing
> that
> > interface, the opportunity for Plug'nPlay appears to have gone
missing...
> &
> > if I'm not mistaken, a first casualty would be the loss of a
> JdbcBeanFactory
> > within an AbstractApplicationContext.  Can someone shed some
> > light - am I just missing something ?
>
> I'll leave this one to Juergen, but I did notice it in passing and
> wondered...
>
> >
> > By the way, on my wanderings I noticed the following typo in
> > AbstractBeanDefinition.equals()
>
> Thanks, fixed it. Ah, the beauty of open source. That code isn't =
currently
> used btw, it was intended to allow for dynamic reconfiguration =
eventually.
> There would have been an argument for zapping it for now, actually.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> N=18HY??X'u?=16w=1A+m?$> =12 xZ+? =17*.m?k +=0E?^? j?z^?=1Dy! =
DD=10?=11?i ^=0EP)brA?m?q =07?z v











-------------------------------------------------------
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] Scheduler update #2

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

Juergen, 

>Remote EJBs don't seem to be a good fit, as the C-based central scheduling
server would have to use IIOP to talk to them.

Can a remote EJB expose a Web service API("end point") ?

Dmitriy.

Re: [Springframework-developer] Scheduler update #2

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

Ivan,=20

I'm delighted to see the progress of your scheduler. A nice coincidence =
is that I'm currently working on a J2EE integration project for a major =
existing job scheduler myself (as I've already announced in September). =
We should try to align our efforts, I guess -- particularly in terms of =
the job programming model.

With the scheduler that I'm addressing, the actual scheduling happens on =
a central server. The server notifies executors on all kinds of =
platforms for individual job execution requests, collecting execution =
reports afterwards. This concept aims at central control of all kinds of =
enterprise systems with unified means. I'm involved in the design of an =
executor for J2EE platforms.

This is obviously different to the programmatic job scheduling that =
Chronos, Quartz, and Flux are targeted at: The latter is ideal for =
embedding into applications, using the scheduler as library. This is of =
course a very valid approach; basically a sophisticated replacement of =
java.util.Timer.

In my view, the ideal job programming model should be reusable across =
both kinds of schedulers. This shouldn't be too hard to do, but the =
requirements are different in certain respects. For example, embedded =
schedulers hardly need to collect execution reports in a central manner =
but rather rely on the job implementations to perform proper logging.

-----=20

A further major difference is that embedded schedulers run within their =
parent application and just need to execute jobs in that process. OTOH, =
a J2EE executor for a central job scheduler needs to be able to dispatch =
job execution requests to multiple J2EE applications within a server or =
even cluster.

My current design idea involves a central executor in the J2EE server, =
implemented as JCA 1.5 resource adapter that starts up with the server =
and listens for job execution requests coming in via a network port. =
This connector then dispatches messages to JMS queues, using one such =
queue per application, and listens for execution reports coming in via a =
response queue, again one per app.

Each scheduler-aware J2EE application needs to have a JMS listener =
attachted to its queue, being able to parse and execute incoming job =
execution requests. Ideally, that listener should not be specific per =
scheduling system but rather a generic component that interprets a =
generic message format for job execution requests.

I haven't been able to come up with a non-intrusive mechanism to execute =
jobs in a specific J2EE application. After all, the application needs to =
have some kind of "door" that the executor can use to dispatch job =
execution requests to it. Using JMS queues per application seems to be =
the most natural approach; including a generic JMS listener is probably =
as non-intrusive as it gets.

Such a JMS queue can also provide for automatic distribution of job =
execution requests across a cluster, via distributed destinations. =
Execution reports would come back via corresponding response queues. =
That should work reliably in a cluster, shouldn't it? Has anyone =
experience with such load balancing via JMS, particularly if execution =
reports are required?

An alternative approach would be to expose a special executor web =
service in each application, sending job execution requests to it and =
periodically polling it for execution reports. Remote EJBs don't seem to =
be a good fit, as the C-based central scheduling server would have to =
use IIOP to talk to them.

-----=20

Finally, regarding job scheduling abstraction in Spring. The problem =
that I see is that job models differ widely between current schedulers:

- At the core, Chronos schedules Runnables, while Quartz requires jobs =
to implement its Job interface with an execute(JobExecutionContext) =
method. Alternatively, Chronos offers ExecWrapper to specify an =
execution method to invoke plus arguments.

- Chronos schedules job instances, or alternatively job commands with a =
new instance per execution via the ExecWrapper. Quartz always creates =
new instances for each execution, following the command pattern.

- Chronos expects its jobs to be either preconfigured instances or to =
not need any configuration besides the arguments of the method to =
invoke. Quartz jobs have access to a Map of configuration parameters via =
the JobExecutionContext's JobDataMap.

I tend to prefer the command pattern, with bean-style parameters instead =
of a JobDataMap, and an execute method without parameters. All this =
metadata can easily be applied dynamically, not requiring a job to =
implement any specific interface. Such a bean-style task definition can =
easily be implemented as a Runnable itself, similar to the current =
ExecWrapper but more powerful in terms of parametrization.

So I envisage a job model like the following:=20

- The most basic job is a Runnable instance.=20

- A CommandTaskDefinition (implements Runnable) takes a class name, bean =
property values, and an execute method (plus optional arguments). On =
run, it would simply instantiate the class, populate the bean =
properties, and invoke the execute method.

- An EjbTaskDefinition (implements Runnable) takes a JNDI name and =
method name plus arguments. Other such convenience classes can be added, =
of course.=20

- A SpringBeanTaskDefinition (implements Runnable) takes a BeanFactory =
reference and a bean name, delegating to the specified prototype or =
singleton from the given Spring bean factory on run.

- A SpringEventTaskDefinition (implements Runnable) takes an =
ApplicationContext reference and a class name (referring to a class of =
type ApplicationEvent).

Such jobs can easily be run by Chronos as they are all Runnables. For =
Quartz, we'd need a generic Quartz Job implementation that receives a =
Runnable in its JobDataMap and invokes run in its execute method. Then =
we could seamlessly execute any of the above kinds of job with either =
scheduler - the most important goal of abstraction, I guess.

Juergen=20


-----Original Message-----=20
From: spr...@li...=20
[mailto:spr...@li...]On Behalf=20
Of Rod Johnson=20
Sent: Monday, November 03, 2003 10:09 AM=20
To: spr...@li...=20
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Scheduler update=20
#2 - Email found in subject=20


Ivan,=20

Thanks for the update.=20

> Will the scheduler be accepted as a part of Spring?=20

We should probably take a vote on this.=20

I would probably make it a separate project and download within Spring,=20
spring-scheduler, dependent on the main codebase. Other crucial things =
are:=20

- Code review.=20
- Volume of code. If there's lots of code, it's a stronger argument for=20
putting it outside the main codebase.=20
- Any dependencies it introduces.=20
- Unit test coverage. As our target is to go above 80% for 1.0 RC1, new =
code=20
must have this kind of level of test coverage, verified via Clover.=20
- Your commitment to maintaining it, providing forum/list support etc.=20

> I am all for having pluggable scheduler, so people can choose the one=20
> they like. Is anyone willing to contribute a Quartz wrapper? Now would =

> be a very good time to get the abstraction interfaces right.=20
+1=20

I think abstraction interfaces are very important, and consistent with=20
Spring's approach in general.=20

Providing a default scheduler implementation as standard might flow from =

that.=20

Regards,=20
Rod=20




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

Re: [Springframework-developer] JDBC refactoring

[<tri...@tr...>]

Rod,

I'll take a look at the new functionality this week.  Still have to figure out a
solution for a thread safe way of handling resultsets returned from the
StoredProcedure class.  I'll keep you posted if I find anything.

Thomas

> Hi Guys,
> 
> I've done the following refactoring to the JDBC packages:
> 
> - Reworked SQLException translation. Now there's a SQLErrorCodes factory,
> not a SQLExceptionTranslator factory. This allows the
> SQLErrorCodeSQLExceptionTranslator to be subclassed for custom translation.
> There's a new protected customTranslate() method for a first shot at
> translation. If it returns null (as the SQLErrorCodeSQLExceptionTranslator
> implementation does) resolution is via the codes. I've added tests for error
> code lookup.
> 
> - Refactored the jdbc.object package to pull the JdbcTemplate field and
> related properties into RdbmsOperation.
> 
> - This enables multiple RdbmsOperation objects to be created with one
> JdbcTemplate. Instead of always creating their own JdbcTemplate, an
> RdbmsOperation exposes a JdbcTemplate bean property and (for some
> subclasses) constructor argument. This is appropriate for example if you
> want to set up custom configuration in the JdbcTemplate such as custom
> exception translators, warning policy etc.
> 
> I've improved the test suite. Hopefully there won't be any nasty surprises,
> but please let me know if there are any implications I've overlooked.
> 
> Regards,
> Rod
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] JDBC refactoring

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

Hi Guys,

I've done the following refactoring to the JDBC packages:

- Reworked SQLException translation. Now there's a SQLErrorCodes factory,
not a SQLExceptionTranslator factory. This allows the
SQLErrorCodeSQLExceptionTranslator to be subclassed for custom translation.
There's a new protected customTranslate() method for a first shot at
translation. If it returns null (as the SQLErrorCodeSQLExceptionTranslator
implementation does) resolution is via the codes. I've added tests for error
code lookup.

- Refactored the jdbc.object package to pull the JdbcTemplate field and
related properties into RdbmsOperation.

- This enables multiple RdbmsOperation objects to be created with one
JdbcTemplate. Instead of always creating their own JdbcTemplate, an
RdbmsOperation exposes a JdbcTemplate bean property and (for some
subclasses) constructor argument. This is appropriate for example if you
want to set up custom configuration in the JdbcTemplate such as custom
exception translators, warning policy etc.

I've improved the test suite. Hopefully there won't be any nasty surprises,
but please let me know if there are any implications I've overlooked.

Regards,
Rod