Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-01-07 21:55:46
|
Peter, =20 You've got a point here. The separation between a bean factory and an = application context is that the former just deals with bean definitions, = but does not treat defined beans (e.g. in an XML file) in special ways = like the latter. An application context detects MessageSources, = BeanPostProcessors, and BeanFactoryPostProcessors; a DispatcherServlet = web application context even more of such special beans. =20 I'd like to keep the bean factories as-is, mainly for programmatic use: = You can register BeanPostProcessors, custom editors, etc via = DefaultListableBeanFactory's configuration properties. An easy way to = make post-processors available in EJB implementation classes would to be = to simply load a ClassPathXmlApplicationContext instead of an = XmlBeanFactory in the BeanFactoryLoader used. Of course, you can always = implement such a custom loader yourself, but we can also consider making = this the default loader. =20 In any case, I completely agree that clarifying the default strategy in = the docs is a must. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Peter den Haan Gesendet: Mi 07.01.2004 22:22 An: spr...@li... Betreff: [Springframework-developer] PostProcessor infrastructure in = DefaultListableBeanFactory and EJB support classes One thing that recently confused the heck out of me was that my AOP = interceptors wouldn't work in an EJB context (1.0M4). Advice simply = wasn't being applied to my beans even though precisely the same = configuration worked fine in the web tier. Given that = DefaultListableBeanFactory does contain the full BeanPostProcessor = infrastructure, I didn't see how that could be. =20 Upon closer examination, it turned out that the bean factory does not = initialise its own BeanPostProcessors. Instead, = AbstractApplicationContext does this by pulling all beans implementing = BeanPostProcessor out of the factory and registering them in order = before any of the other beans get instantiated. The XmlBeanFactoryLoader = used by the EJB support classes, on the other hand, does no such thing. = (Something similar can be said about BeanFactoryPostProcessors. Unless = I'm missing something, this interface receives support only in an = application context and has no bean hierarchy support at all.) =20 Given that more and more of Spring's infrastructure relies on = postprocessing, the BeanFactory support in AbstractEnterpriseBean seems = crippled unless you roll your own XmlBeanFactoryLoader along the lines = of attached class. We could do any of a number of things with this. * BeanPostProcessor registration could be made a responsibility of = DefaultListableBeanFactory, although this might break existing software. = I assume there's a good reason why this is an context rather than a = factory responsibility.=20 * A new loader along the lines of attached file could be added to the = framework, and should probably used by default in = AbstractEnterpriseBean. Wholesale cutting and pasting from = AbstractApplicationContext can be avoided by migrating = BeanFactoryPostProcessor and BeanPostProcessor registration to either a = utility class or to utility methods in DefaultListableBeanFactory (these = would not be part of the normal factory refresh, but would have to be = invoked explicitly).=20 * Instead of creating a new loader, BeanPostProcessor registration could = simply be incorporated into XmlBeanFactoryLoader itself.=20 * Everything could be left as is. In that case I feel the restrictions = of bean support in a plain factory (as in EJBs) should be very clearly = documented, otherwise this is going to confuse and discourage quite a = few people. Thanks for reading as far as this :) Let me know what you think. I would = be more than happy to supply patches for the above against the current = CVS head. =20 - Peter =20 =20 |
|
From: <jue...@we...> - 2004-01-22 07:50:28
|
Colin, =20 It may be a detail, but I'm not too happy with the two virtually = identical classes XmlBeanFactoryLoader and = XmlApplicationContextBeanFactoryLoader (and the name of the latter). =20 I suggest to refactor the latter as a subclass of XmlBeanFactoryLoader: = Why not simply offer a "BeanFactory createBeanFactory(String = beanFactoryPath)" template method there, defaulting to an = XmlBeanFactory? The subclass could then override this for a = ClassPathXmlApplicationContext. =20 Regarding the name, I suggest to call the subclass = "XmlApplicationContextLoader", even if it does not contain the full = interface name "BeanFactoryLoader": After all, an ApplicationContext = *is* a BeanFactory, so it's better to just use one of the two terms in = the class name, IMO. =20 As a side note, the transaction manager implementation names do not = contain the full interface name "PlatformTransactionManager" either. In = general, if the resulting name is expressive enough, I prefer such a = simplified name instead of one that contains the full interface name in = the first place. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: So 18.01.2004 01:21 An: spr...@li...; Peter den Haan Betreff: Re: [Springframework-developer] PostProcessor infrastructure in = DefaultListableBeanFactory and EJB support classes As per the thread below from about a week ago, I have defaulted AbstractEnterpriseBean and its subclasses to use a new XmlApplicationContextBeanFactoryLoader, which will load and create an ApplicationContext from the classpath. For a lighter weight solution when ApplicationContexts are not needed, people may still switch in the old XmlBeanFactoryLoader. One comment though, is that if you look at a common usage scenario, which is to call out from Session ejbs to service POJOs using Hibernate-based DAO/Mapper objects, this solution is still not good enough, in that every EJB ends up creating an application context, which ends up creating a new session factory for every EJB. For this reason, I still drop in a custom BeanFactoryLoader which loads/accesses a shared ApplicationContext via the KeyedSingletonContextLocator I posted here a while ago. Regards, Colin Colin Sampaleanu wrote: > Peter den Haan wrote: > >> Colin Sampaleanu wrote: >> >>> eanPostProcessors are a function of ApplicationContexts, so it is >>> normal that BeanFactories which are not also ApplicationContexts = (such >>> as that produced by XMLBeanFactoryLoader) do no post-processing. >>> =20 >> >> Ah, but that's the funny thing. This is not entirely true. The actual >> postprocessing plumbing is part and parcel of the >> DefaultListableBeanFactory >> itself. However, it does not auto-register any postprocessors itself. >> That >> is done by the application context. Given the important place >> postprocessing >> has been gaining in the Spring infrastructure, it seems odd that EJBs >> do get >> a BeanFactory that does in fact have all it takes (you do not need a >> full >> context) but is still very limited because its postprocessing >> plumbing isn't >> initialised. >> >> Users new to the product would expect Spring to provide some >> out-of-the-box >> support for a fully functional bean container in the EJB tier, >> probably by >> default. As things stand, you won't be getting this without coding >> (and a >> nontrivial understanding of Spring subtleties). >>=20 >> > The fact that DefaultListableBeanFactory has some of the support code > is somewhat irrelevant. The contract is that if something has the > ApplicationContext interface it supports BeanPostProcessors, and if it > doesn't (i.e. it is simply a BeanFactory), it doesn't support > BeanPostProcessors. And this is how the current code behaves. As I > said, I agree that the distinction between application contexts and > bean factories needs to be better documented, and it probably makes > sense for the default BeanFactoryLoader in the base EJB classes to > produce an ApplicationContext variant instead of just a regular > BeanFactory. That code actually got into Spring before I got to the > project, so I'm not sure why it was decided one way vs. another. If > there is no opposition, I am quite willing to make that change... > > Regards, > Colin > ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-01-22 14:39:58
|
I originally kept them separate because I wasn't sure it was even worth keeping the old XmlBeanFactoryLoader around. Given that the appcontext implementation is the default, and brings in the appcontext related classes anyways, I can't think of many compelling reasons why somebody using ejbs would override and use a beanfactory instead... However, as today I was going to check in the beanfactory/context loading stuff I mentioned last week, I was thinking that there are some similarities between the existing interface and usage scenarios to what I was going to check in. I am going to try to see if I can combine the classes. In this case, most of the code would move elsewhere, and all that would stay in the ejb package would be a small subclass that has a specific jndi path. jürgen höller [werk3AT] wrote: >Colin, > >It may be a detail, but I'm not too happy with the two virtually identical classes XmlBeanFactoryLoader and XmlApplicationContextBeanFactoryLoader (and the name of the latter). > >I suggest to refactor the latter as a subclass of XmlBeanFactoryLoader: Why not simply offer a "BeanFactory createBeanFactory(String beanFactoryPath)" template method there, defaulting to an XmlBeanFactory? The subclass could then override this for a ClassPathXmlApplicationContext. > >Regarding the name, I suggest to call the subclass "XmlApplicationContextLoader", even if it does not contain the full interface name "BeanFactoryLoader": After all, an ApplicationContext *is* a BeanFactory, so it's better to just use one of the two terms in the class name, IMO. > >As a side note, the transaction manager implementation names do not contain the full interface name "PlatformTransactionManager" either. In general, if the resulting name is expressive enough, I prefer such a simplified name instead of one that contains the full interface name in the first place. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Colin Sampaleanu >Gesendet: So 18.01.2004 01:21 >An: spr...@li...; Peter den Haan >Betreff: Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes > > > >As per the thread below from about a week ago, I have defaulted >AbstractEnterpriseBean and its subclasses to use a new >XmlApplicationContextBeanFactoryLoader, which will load and create an >ApplicationContext from the classpath. For a lighter weight solution >when ApplicationContexts are not needed, people may still switch in the >old XmlBeanFactoryLoader. > >One comment though, is that if you look at a common usage scenario, >which is to call out from Session ejbs to service POJOs using >Hibernate-based DAO/Mapper objects, this solution is still not good >enough, in that every EJB ends up creating an application context, which >ends up creating a new session factory for every EJB. For this reason, I >still drop in a custom BeanFactoryLoader which loads/accesses a shared >ApplicationContext via the KeyedSingletonContextLocator I posted here a >while ago. > >Regards, >Colin > > >Colin Sampaleanu wrote: > > > >>Peter den Haan wrote: >> >> >> >>>Colin Sampaleanu wrote: >>> >>> >>> >>>>eanPostProcessors are a function of ApplicationContexts, so it is >>>>normal that BeanFactories which are not also ApplicationContexts (such >>>>as that produced by XMLBeanFactoryLoader) do no post-processing. >>>> >>>> >>>> >>>Ah, but that's the funny thing. This is not entirely true. The actual >>>postprocessing plumbing is part and parcel of the >>>DefaultListableBeanFactory >>>itself. However, it does not auto-register any postprocessors itself. >>>That >>>is done by the application context. Given the important place >>>postprocessing >>>has been gaining in the Spring infrastructure, it seems odd that EJBs >>>do get >>>a BeanFactory that does in fact have all it takes (you do not need a >>>full >>>context) but is still very limited because its postprocessing >>>plumbing isn't >>>initialised. >>> >>>Users new to the product would expect Spring to provide some >>>out-of-the-box >>>support for a fully functional bean container in the EJB tier, >>>probably by >>>default. As things stand, you won't be getting this without coding >>>(and a >>>nontrivial understanding of Spring subtleties). >>> >>> >>> >>> >>The fact that DefaultListableBeanFactory has some of the support code >>is somewhat irrelevant. The contract is that if something has the >>ApplicationContext interface it supports BeanPostProcessors, and if it >>doesn't (i.e. it is simply a BeanFactory), it doesn't support >>BeanPostProcessors. And this is how the current code behaves. As I >>said, I agree that the distinction between application contexts and >>bean factories needs to be better documented, and it probably makes >>sense for the default BeanFactoryLoader in the base EJB classes to >>produce an ApplicationContext variant instead of just a regular >>BeanFactory. That code actually got into Spring before I got to the >>project, so I'm not sure why it was decided one way vs. another. If >>there is no opposition, I am quite willing to make that change... >> >>Regards, >>Colin >> >> |
|
From: <jue...@we...> - 2004-01-23 01:54:06
|
That sounds good - looking forward to seeing your new loader stuff! BTW, = I'm about to finish the extended transaction propagation support = today... I guess it would be good to do a definite feature freeze this = weekend, to be able to test and review for a couple of days and = hopefully release RC1 late next week. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Thursday, January 22, 2004 3:41 PM To: spr...@li... Subject: Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes I originally kept them separate because I wasn't sure it was even worth=20 keeping the old XmlBeanFactoryLoader around. Given that the appcontext=20 implementation is the default, and brings in the appcontext related=20 classes anyways, I can't think of many compelling reasons why somebody=20 using ejbs would override and use a beanfactory instead... However, as today I was going to check in the beanfactory/context=20 loading stuff I mentioned last week, I was thinking that there are some=20 similarities between the existing interface and usage scenarios to what=20 I was going to check in. I am going to try to see if I can combine the=20 classes. In this case, most of the code would move elsewhere, and all=20 that would stay in the ejb package would be a small subclass that has a=20 specific jndi path. j=FCrgen h=F6ller [werk3AT] wrote: >Colin, >=20 >It may be a detail, but I'm not too happy with the two virtually = identical classes XmlBeanFactoryLoader and = XmlApplicationContextBeanFactoryLoader (and the name of the latter). >=20 >I suggest to refactor the latter as a subclass of XmlBeanFactoryLoader: = Why not simply offer a "BeanFactory createBeanFactory(String = beanFactoryPath)" template method there, defaulting to an = XmlBeanFactory? The subclass could then override this for a = ClassPathXmlApplicationContext. >=20 >Regarding the name, I suggest to call the subclass = "XmlApplicationContextLoader", even if it does not contain the full = interface name "BeanFactoryLoader": After all, an ApplicationContext = *is* a BeanFactory, so it's better to just use one of the two terms in = the class name, IMO. >=20 >As a side note, the transaction manager implementation names do not = contain the full interface name "PlatformTransactionManager" either. In = general, if the resulting name is expressive enough, I prefer such a = simplified name instead of one that contains the full interface name in = the first place. >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag = von Colin Sampaleanu >Gesendet: So 18.01.2004 01:21 >An: spr...@li...; Peter den Haan >Betreff: Re: [Springframework-developer] PostProcessor infrastructure = in DefaultListableBeanFactory and EJB support classes > > > >As per the thread below from about a week ago, I have defaulted >AbstractEnterpriseBean and its subclasses to use a new >XmlApplicationContextBeanFactoryLoader, which will load and create an >ApplicationContext from the classpath. For a lighter weight solution >when ApplicationContexts are not needed, people may still switch in the >old XmlBeanFactoryLoader. > >One comment though, is that if you look at a common usage scenario, >which is to call out from Session ejbs to service POJOs using >Hibernate-based DAO/Mapper objects, this solution is still not good >enough, in that every EJB ends up creating an application context, = which >ends up creating a new session factory for every EJB. For this reason, = I >still drop in a custom BeanFactoryLoader which loads/accesses a shared >ApplicationContext via the KeyedSingletonContextLocator I posted here a >while ago. > >Regards, >Colin > > >Colin Sampaleanu wrote: > > =20 > >>Peter den Haan wrote: >> >> =20 >> >>>Colin Sampaleanu wrote: >>> >>> =20 >>> >>>>eanPostProcessors are a function of ApplicationContexts, so it is >>>>normal that BeanFactories which are not also ApplicationContexts = (such >>>>as that produced by XMLBeanFactoryLoader) do no post-processing. >>>>=20 >>>> =20 >>>> >>>Ah, but that's the funny thing. This is not entirely true. The actual >>>postprocessing plumbing is part and parcel of the >>>DefaultListableBeanFactory >>>itself. However, it does not auto-register any postprocessors itself. >>>That >>>is done by the application context. Given the important place >>>postprocessing >>>has been gaining in the Spring infrastructure, it seems odd that EJBs >>>do get >>>a BeanFactory that does in fact have all it takes (you do not need a >>>full >>>context) but is still very limited because its postprocessing >>>plumbing isn't >>>initialised. >>> >>>Users new to the product would expect Spring to provide some >>>out-of-the-box >>>support for a fully functional bean container in the EJB tier, >>>probably by >>>default. As things stand, you won't be getting this without coding >>>(and a >>>nontrivial understanding of Spring subtleties). >>> >>> >>> =20 >>> >>The fact that DefaultListableBeanFactory has some of the support code >>is somewhat irrelevant. The contract is that if something has the >>ApplicationContext interface it supports BeanPostProcessors, and if it >>doesn't (i.e. it is simply a BeanFactory), it doesn't support >>BeanPostProcessors. And this is how the current code behaves. As I >>said, I agree that the distinction between application contexts and >>bean factories needs to be better documented, and it probably makes >>sense for the default BeanFactoryLoader in the base EJB classes to >>produce an ApplicationContext variant instead of just a regular >>BeanFactory. That code actually got into Spring before I got to the >>project, so I'm not sure why it was decided one way vs. another. If >>there is no opposition, I am quite willing to make that change... >> >>Regards, >>Colin >> =20 >> ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <rod...@in...> - 2004-01-23 08:13:01
|
Yes, a feature freeze is nearly upon us. I have to commit some AOP changes I made yesterday (fairly minor). Haven'= t tried CVS yet... Also I want to upgrade to latest Commons Attributes today. Then I'm done. Regards, Rod ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, January 22, 2004 2:59 PM Subject: RE: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes That sounds good - looking forward to seeing your new loader stuff! BTW, = I'm about to finish the extended transaction propagation support today... I guess it would be good to do a definite feature freeze this weekend, to b= e able to test and review for a couple of days and hopefully release RC1 la= te next week. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Thursday, January 22, 2004 3:41 PM To: spr...@li... Subject: Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes I originally kept them separate because I wasn't sure it was even worth keeping the old XmlBeanFactoryLoader around. Given that the appcontext implementation is the default, and brings in the appcontext related classes anyways, I can't think of many compelling reasons why somebody using ejbs would override and use a beanfactory instead... However, as today I was going to check in the beanfactory/context loading stuff I mentioned last week, I was thinking that there are some similarities between the existing interface and usage scenarios to what I was going to check in. I am going to try to see if I can combine the classes. In this case, most of the code would move elsewhere, and all that would stay in the ejb package would be a small subclass that has a specific jndi path. j=FCrgen h=F6ller [werk3AT] wrote: >Colin, > >It may be a detail, but I'm not too happy with the two virtually identic= al classes XmlBeanFactoryLoader and XmlApplicationContextBeanFactoryLoader (= and the name of the latter). > >I suggest to refactor the latter as a subclass of XmlBeanFactoryLoader: = Why not simply offer a "BeanFactory createBeanFactory(String beanFactoryPath)= " template method there, defaulting to an XmlBeanFactory? The subclass coul= d then override this for a ClassPathXmlApplicationContext. > >Regarding the name, I suggest to call the subclass "XmlApplicationContextLoader", even if it does not contain the full interface name "BeanFactoryLoader": After all, an ApplicationContext *is*= a BeanFactory, so it's better to just use one of the two terms in the class name, IMO. > >As a side note, the transaction manager implementation names do not cont= ain the full interface name "PlatformTransactionManager" either. In general, = if the resulting name is expressive enough, I prefer such a simplified name instead of one that contains the full interface name in the first place. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag vo= n Colin Sampaleanu >Gesendet: So 18.01.2004 01:21 >An: spr...@li...; Peter den Haan >Betreff: Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes > > > >As per the thread below from about a week ago, I have defaulted >AbstractEnterpriseBean and its subclasses to use a new >XmlApplicationContextBeanFactoryLoader, which will load and create an >ApplicationContext from the classpath. For a lighter weight solution >when ApplicationContexts are not needed, people may still switch in the >old XmlBeanFactoryLoader. > >One comment though, is that if you look at a common usage scenario, >which is to call out from Session ejbs to service POJOs using >Hibernate-based DAO/Mapper objects, this solution is still not good >enough, in that every EJB ends up creating an application context, which >ends up creating a new session factory for every EJB. For this reason, I >still drop in a custom BeanFactoryLoader which loads/accesses a shared >ApplicationContext via the KeyedSingletonContextLocator I posted here a >while ago. > >Regards, >Colin > > >Colin Sampaleanu wrote: > > > >>Peter den Haan wrote: >> >> >> >>>Colin Sampaleanu wrote: >>> >>> >>> >>>>eanPostProcessors are a function of ApplicationContexts, so it is >>>>normal that BeanFactories which are not also ApplicationContexts (suc= h >>>>as that produced by XMLBeanFactoryLoader) do no post-processing. >>>> >>>> >>>> >>>Ah, but that's the funny thing. This is not entirely true. The actual >>>postprocessing plumbing is part and parcel of the >>>DefaultListableBeanFactory >>>itself. However, it does not auto-register any postprocessors itself. >>>That >>>is done by the application context. Given the important place >>>postprocessing >>>has been gaining in the Spring infrastructure, it seems odd that EJBs >>>do get >>>a BeanFactory that does in fact have all it takes (you do not need a >>>full >>>context) but is still very limited because its postprocessing >>>plumbing isn't >>>initialised. >>> >>>Users new to the product would expect Spring to provide some >>>out-of-the-box >>>support for a fully functional bean container in the EJB tier, >>>probably by >>>default. As things stand, you won't be getting this without coding >>>(and a >>>nontrivial understanding of Spring subtleties). >>> >>> >>> >>> >>The fact that DefaultListableBeanFactory has some of the support code >>is somewhat irrelevant. The contract is that if something has the >>ApplicationContext interface it supports BeanPostProcessors, and if it >>doesn't (i.e. it is simply a BeanFactory), it doesn't support >>BeanPostProcessors. And this is how the current code behaves. As I >>said, I agree that the distinction between application contexts and >>bean factories needs to be better documented, and it probably makes >>sense for the default BeanFactoryLoader in the base EJB classes to >>produce an ApplicationContext variant instead of just a regular >>BeanFactory. That code actually got into Spring before I got to the >>project, so I'm not sure why it was decided one way vs. another. If >>there is no opposition, I am quite willing to make that change... >> >>Regards, >>Colin >> >> ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Peter d. H. <pe...@de...> - 2004-01-07 22:57:48
|
J=FCrgen H=F6ller wrote: > I'd like to keep the bean factories as-is, mainly for programmatic use [...] I wouldn't advocate anything else -- changing the way bean factories work would break a lot of stuff. The smallest change that could possibly work would be to modify XmlBeanFactoryLoader to detect and register postprocessors in the same way that AbstractApplicationContext does. This would allow all the important Spring plumbing to work out of the box in t= he EJB tier, and I don't expect that it would break much (if anything). Moving the postprocessor registration code to utility methods in BeanFact= ory is merely a suggested refactoring to prevent code duplication and would n= ot in any way change the way bean factories work. > An easy way to make post-processors available in EJB implementation classes would to be to simply load a > ClassPathXmlApplicationContext instead of an XmlBeanFactory in the BeanFactoryLoader used. Of course, > you can always implement such a custom loader yourself, but we can also consider making this the default loader. This is slightly more of a change, but would be an excellent option. IMHO unless there is a strong reason to the contrary the default should be something that supports postprocessors; either an application context, or= a factory with initialised postprocessors as above. - Peter |
