springframework-developer — Spring Framework developers list

Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

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

Hi Peter,

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

However, I do agree that the differences betweeen plain BeanFactories 
and ApplicationContexts should probably be better documented, and the 
XMLBeanFactoryLoader should state that it produces a BeanFactory, not an 
ApplicationContext. Alternately, it could possibly produce an 
ApplicationContext.

fyi, I currently override the default BeanFactoryLoader in my ejbs, as 
follows:

    setBeanFactoryLoader(new BeanFactoryLoader() {
      public BeanFactory loadBeanFactory() throws BootstrapException {
        ContextLocator cf = ContextLocatorFactory.getInstance();
        ApplicationContext appContext =
          cf.useContext(ServicesConstants.CONTEXT_GROUP_KEY, 
ServicesConstants.PRIMARY_CONTEXT_ID);
        return appContext;
      }
      public void unloadBeanFactory(BeanFactory bf) throws 
FatalBeanException {
      }
    });

This relies on my own ContextLocator interface/impl, to actually load in 
on-demand, a hierarchy of ApplicationContexts.

Regards,
Colin


Peter den Haan wrote:

> 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.
>  
> 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.)
>  
> 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.
>     * 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).
>     * Instead of creating a new loader, BeanPostProcessor registration
>       could simply be incorporated into XmlBeanFactoryLoader itself.
>     * 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.
>  
>  - Peter
>  
>  

Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

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

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

[Springframework-developer] TSS news

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

FYI, Dion just posted TSS news on our M4 release! He quoted my =
announcement mail literally... I've been surprised myself - I initially =
expected that to happen at the time of the upcoming RC1.
=20
Juergen

Re: [Springframework-developer] ant.bat in the root of the project

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

I think it is completely reasonable for us to expect anybody who wants=20
to build our samples or run them to already have ant installed on their=20
system. Again, this is the expectation of 99% of the projects out there.

(I actually used to do exactly the same thing, include ant libs with=20
every single project, and a build.bat/build.sh in the root. Then a=20
couple of years ago, when ant became completely ubiquitous, I thought=20
about it and realized there was really no reason any longer; it's like=20
assuming make is available, etc.).

Anyways, if you think it makes sense, I really have no problem with it...

j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,=20
>
>I see that ant.bat is not an ideal name due to the conflict with the def=
ault ant.bat - I'll change all ant.bat files to build.bat.
>
>I tend to agree regarding Ant for building the framework. What our inclu=
ded ant.jar is mainly targetted at is building the samples, or even runni=
ng them in case of our JPetStore remote client. And if we'll include ant.=
jar for that anyway, we can and should also provide a convenience build.b=
at for the framework itself, IMO.
>
>Juergen=20
>
>
>-----Original Message-----=20
>From: spr...@li...=20
>[mailto:spr...@li...]On Behalf=20
>Of Colin Sampaleanu=20
>Sent: Wednesday, January 07, 2004 3:46 AM=20
>To: spr...@li...=20
>Subject: [Springframework-developer] ant.bat in the root of the project=20
>
>
>Hi Juergen,=20
>
>Did you intend to add ant.bat to the root of the project? It interferes=20
>with whatever ant version a user may have on their system.=20
>
>It is completely normal and expected (by just about every project out=20
>there) that people have ant installed on their systems, so I've never=20
>understood the practice of adding batch files / shell scripts to=20
>projects to start ant with Ditto for including ant libs in the project=20
>itself; that's a lot of baggage to carry around just in case somebody=20
>doesn't have ant handy...=20
>
>If you do want the file there, perhaps it could be named build.bat?=20
>
>What about the ant libs in the lib dir, is there really any need to have=
=20
>them?=20
>
>Regards,=20
>Colin=20
> =20
>

Re: [Springframework-developer] ant.bat in the root of the project

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

Colin,=20

I see that ant.bat is not an ideal name due to the conflict with the =
default ant.bat - I'll change all ant.bat files to build.bat.

I tend to agree regarding Ant for building the framework. What our =
included ant.jar is mainly targetted at is building the samples, or even =
running them in case of our JPetStore remote client. And if we'll =
include ant.jar for that anyway, we can and should also provide a =
convenience build.bat for the framework itself, IMO.

Juergen=20


-----Original Message-----=20
From: spr...@li...=20
[mailto:spr...@li...]On Behalf=20
Of Colin Sampaleanu=20
Sent: Wednesday, January 07, 2004 3:46 AM=20
To: spr...@li...=20
Subject: [Springframework-developer] ant.bat in the root of the project=20


Hi Juergen,=20

Did you intend to add ant.bat to the root of the project? It interferes=20
with whatever ant version a user may have on their system.=20

It is completely normal and expected (by just about every project out=20
there) that people have ant installed on their systems, so I've never=20
understood the practice of adding batch files / shell scripts to=20
projects to start ant with Ditto for including ant libs in the project=20
itself; that's a lot of baggage to carry around just in case somebody=20
doesn't have ant handy...=20

If you do want the file there, perhaps it could be named build.bat?=20

What about the ant libs in the lib dir, is there really any need to have =

them?=20

Regards,=20
Colin=20





-------------------------------------------------------=20
This SF.net email is sponsored by: IBM Linux Tutorials.=20
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's=20
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.=20
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick=20
_______________________________________________=20
Springframework-developer mailing list=20
Spr...@li...=20
https://lists.sourceforge.net/lists/listinfo/springframework-developer=20

[Springframework-developer] Transaction propagation settings

[Alastair R. <ala...@ph...>]

SGVsbG8sIA0KDQpJIHdhcyBqdXN0IHdvbmRlcmluZyB3aHkgU3ByaW5nJ3MgZGVjbGFyYXRpdmUg
dHJhbnNhY3Rpb24gc3VwcG9ydCBoYXMgUFJPUEFHQVRJT05fUkVRVUlSRUQsIFBST1BBR0FUSU9O
X01BTkRBVE9SWSBhbmQgUFJPUEFHQVRJT05fU1VQUE9SVFMgYnV0IGhhcyBubyBlcXVpdmFsZW50
IG9mIHRoZSBFSkIgMi4wICdSZXF1aXJlc05ldycgdHJhbnNhY3Rpb24gYXR0cmlidXRlPyANCg0K
U29ycnkgaWYgdGhpcyBoYXMgYmVlbiBhc2tlZCBiZWZvcmUgLSBJIGNvdWxkbid0IGZpbmQgYW55
dGhpbmcgaW4gdGhlIGZvcnVtcyAvIGxpc3QgYXJjaGl2ZXMuDQoNCkFsLg0K

Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

I was originally thinking of two marker interfaces for the initializing 
and post initializing BeanPostProcessors (as per a traditional listener 
design), but having two methods would also work fine...

W/regards to the initializing one being allowed to return a wrapped 
instance of the bean, I am not sure there is anything really wrong with 
that. The distinction after all betwen the post processor types is for 
the most part on wether they come before or after the 'officially 
initialized' demarcation point (InitializingBean), and as such whether 
or not the post processor can expect a fully initialized bean, and 
whether the bean can expect at the dermarcation point that it is fully 
initialized. The fact that a post processor can wrap the bean before or 
after doesn't really change much...


jürgen höller [werk3AT] wrote:

>Colin,
> 
>You've got a point here. The current invocation order is a result of context implementation issues rather than design from the user perspective. I guess we won't have to worry about backward compatibility too much: After all, we discourage everyone to implement BeanFactoryAware of ApplicationContextAware for typical beans. With the new core.io.Resource stuff in M4, there's even one less reason to implement the latter.
> 
>So let's design this in a clean and obvious manner for RC1. Your first suggestion sounds good to me: However, we would need to introduce a distinction between "initializing" BeanPostProcessors and "post-initializing" ones. This could happen via a marker sub-interface, for example, or via a new method in the interface.
> 
>A special issue is that a BeanPostProcessor can return a wrapped instance of the bean: This isn't really desirable for "initializing" BeanPostProcessors, is it? So maybe we'd even need to introduce a separate interface that just allows processing of the given bean instance. Any thoughts?
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mi 07.01.2004 05:54
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()
>
>
>
>I was hoping for some more discussion on this, but it looks like nobody
>bit...
>
>In the meantime, I have clarified the existing ordering of the lifecycle
>methods in the JavaDocs for InitializingBean, BeanFactoryAware, and
>ApplcationContextAware.
>
>I still think there somewhat of a (big) hole with regards to the current
>initializing method handling. Currently, BeanPostProcessors are all
>applied _after_ ApplicationContextAware (although this order is not
>documented). This works for any BeanPostProcessors which expect to be
>given fully initialized beans, as they will be given a bean initialized
>fully (and knowing it) due to use of afterPropertiesSet
>(InitializingBean), setBeanFactory (BeanFactoryAware), or
>setApplicationContext (ApplicationContextAware). However, if somebody
>needs to apply a BeanPostProcessor to set some properties of a bean as
>part of the initialization, there is _no_ reliable mechanism to call an
>init method on the bean afterwards; neither via an entry in the XML def,
>nor via a marker interface.
>
>What makes the most sense to _me_ is to have the following sequence apply:
>-  BeanFactoryAware, ApplicationContextAware, a set of 'initializing'
>BeanPostProcessors, InitializingBean, and finally a another set of
>'post-initializing' BeanPostProcessors.
>
>This obviously has implications in terms of backwards compatibility
>since InitializingBean applies in a different sequence. A solution which
>would be completely backwards compatible (but I think less obvious),
>would be to do
>- InitializingBean, BeanFactoryAware, 'initializing' BeanPostProcessors,
>ApplicationContextAware, 'post-initializing' BeanPostProcessors. People
>could in this case use any of the three marker interfaces to initialize,
>as suitable...
>
>Any comments?
>
>Regards,
>Colin
>
>Colin Sampaleanu wrote:
>
>  
>
>>I think any distinction between 'basic JavaBean stuff' and
>>'application context stuff' is often going to be artificial. If you
>>think about some class that actually needs the context, it is probably
>>going to use it in a similar fashion to any other property inside it.
>>
>>But the initialize method (or the specific instance
>>afterPropertiesSet) is also a lifecycle method, and it is in the wrong
>>order as far as _any_ BeanPostProcessors are concerned, including
>>ApplicationContextAware. Right now there is no mechanism to specify
>>that an init method should be called after everything has been done to
>>it by the context, including post processors. You can't even rely on
>>setApplicationContext() as your init method because in fact some
>>post-processors may act after it.
>>
>>If you think about it, you should be able to take a working
>>beanfactory, with working beans, and if you need something special
>>from the application context (like the post-processors, or indirectly,
>>via the fact that one of its dependencies needs the application
>>context) just switch to using the same setup in an application
>>context. You can't really do that if you can no longer rely on the
>>original init methods from when you were in the bean factory.
>>
>>So for sure I think there is a need for the ability to call an init
>>method once post-processing is done, and I can't see the justification
>>for making this different than the existing beanfactory init mechanism...
>>
>>Regards,
>>Colin
>>
>>Rod Johnson wrote:
>>
>>    
>>
>>>Colin,
>>>
>>>I like the present order: not surprisingly, perhaps, as I chose it. The
>>>rationale is: get the basic JavaBean stuff in order first, then do any
>>>application context stuff.
>>>
>>>Certainly the docs should be consistent.
>>>
>>>Now at least I understand the confusion: setApplicationContext() is not
>>>treated as a normal JavaBean property, but as a lifecycle method.
>>>Perhaps
>>>the "set" prefix was unwise.
>>>
>>>Regards,
>>>Rod
>>>
>>>----- Original Message ----- From: "Colin Sampaleanu"
>>><col...@ex...>
>>>To: <spr...@li...>
>>>Sent: Monday, January 05, 2004 8:35 PM
>>>Subject: [Springframework-developer] Rationale for
>>>setApplicationContext()
>>>coming after afterPropertiesSet()
>>>
>>>
>>>I've had a couple of discussions now with people where I've tried to
>>>explain why setApplicationContext comes after afterPropertiesSet (and
>>>after any custom initializing method you define), and frankly, I think
>>>it just doesn't make sense except for the fact that it's that way
>>>right now.
>>>
>>>Most beans should of course not be using the application context, but if
>>>they need it, people are not going to understand the rationale as to why
>>>that property is set after the initializing method is called, and that
>>>they must instead treat setApplicationContext itself as an initializer
>>>method.
>>>
>>>I don't know if anybody thinks it's worth changing the order, but if
>>>not, this thing is going to hit new users on the head on a regular
>>>basis... At a minimum, if no code is changed, we need to update the
>>>JavaDoc for ApplicationContextAware to explain the order. I can do
>>>that...
>>>
>>>Regards,
>>>Colin
>>>
>>>jürgen höller [werk3AT] wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Actually, this is intended behavior, although it may be debatable
>>>>whether
>>>> 
>>>>        
>>>>
>>>it is appropriate. setApplicationContext is not really meant to be
>>>combined
>>>with an init-method. The latter is for non-Spring-aware beans, while the
>>>former is the strongest dependency a bean can have on Spring. You should
>>>*not* design your beans to depend on that initialization order.
>>>
>>>
>>>      
>>>
>>>>As a solution, you could put your initialization code in your
>>>> 
>>>>        
>>>>
>>>setApplicationContext implementation, or in an initApplicationContext()
>>>method that gets triggered by setApplicationContext. Have a look at the
>>>ApplicationObjectSupport convenience base class, it provides such a
>>>method
>>>out of the box. Of course, extending ApplicationObjectSupport is not an
>>>option if you already have a different natural base class.
>>>
>>>
>>>      
>>>
>>>>Juergen
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Keith Donald [mailto:kd...@cs...]
>>>>Sent: Thursday, October 30, 2003 4:22 PM
>>>>To: spr...@li...
>>>>Subject: RE: [Springframework-user] setApplicationContext not being
>>>>called
>>>>
>>>>
>>>>Juergen,
>>>>
>>>>Wanted to update you on this issue post M2.  setApplicationContext
>>>>is being
>>>> 
>>>>        
>>>>
>>>called now on all my ApplicationContextAware beans, thanks.  The only
>>>issue
>>>I have remaining is it seems the bean init-method method
>>>("initialize()" in
>>>my case) is called by the container before setApplicationContext.  My
>>>initialize() method does stuff that requires the context - for
>>>example, it
>>>looks up messages for initializing view components.  So I would
>>>really need
>>>setApplicationContext() called before initialize() to prevent
>>>NullPointerExceptions.
>>>
>>>
>>>      
>>>
>>>>Thanks,
>>>>Keith
>>>>
>>>>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] -
>>>> 
>>>>        
>>>>
>>><initialize called>
>>>
>>>
>>>      
>>>
>>>>2003-10-30 10:16:58,193 DEBUG
>>>>[com.csi.cogids.console.qQueryNavigator] -
>>>> 
>>>>        
>>>>
>>><setApplicationContext called>
>>>
>>>
>>>      
>>>
>>>>Keith Donald
>>>>Senior Software Engineer
>>>>kd...@cs...
>>>>321-676-2923 x403
>>>>
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: spr...@li...
>>>> 
>>>>        
>>>>
>>>[mailto:spr...@li...] On Behalf Of
>>>jürgen höller [werk3AT]
>>>
>>>
>>>      
>>>
>>>>Sent: Thursday, October 23, 2003 2:14 AM
>>>>To: spr...@li...
>>>>Subject: Re: [Springframework-user] setApplicationContext not being
>>>>called
>>>>
>>>>
>>>>Keith,
>>>>
>>>>This was caused by the fact that ApplicationContextAware was being
>>>> 
>>>>        
>>>>
>>>processed after the underlying bean factory finished its work, on
>>>demand in
>>>getBean calls to the application context. I've completely reworked
>>>this for
>>>1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also
>>>internally used for processing ApplicationContextAware beans, to be
>>>applied
>>>when the underlying bean factory creates any kind of bean.
>>>
>>>
>>>      
>>>
>>>>So as of 1.0 M2, to be released tomorrow, this should work properly
>>>>in all
>>>> 
>>>>        
>>>>
>>>cases. If there should be any remaining issues, please report them
>>>against
>>>1.0 M2. If you're eager, you can also try a CVS snapshot today.
>>>
>>>
>>>      
>>>
>>>>Juergen
>>>>
>>>>
>>>>
>>>>-----Ursprüngliche Nachricht----- Von: Keith Donald
>>>>[mailto:kd...@cs...]
>>>>Gesendet: Di 21.10.2003 19:50
>>>>An: spr...@li...
>>>>Cc:
>>>>Betreff: [Springframework-user] setApplicationContext not being called
>>>>
>>>>
>>>>
>>>>Forgive me if this issue has already been addressd.  It appears
>>>>setApplicationContext(ApplicationContext) is not being called on my
>>>>ApplicationContextAware prototype beans that are not directly
>>>>instantiated
>>>>by a call to beanFactory.getBean(beanName), but rather are wired
>>>>"child"
>>>>beans instantiated as a result of a <bean ref> references from a parent
>>>>prototype.
>>>>
>>>>To give you an example of what I mean:
>>>>
>>>>       // parent prototype
>>>>       <bean      id="sessionVisualizerPage"
>>>>               class="com.csi.cogids.console.SessionVisualizerPage"
>>>>           singleton="false">
>>>>         <property name="queryNavigator"><ref
>>>>bean="queryNavigator"/></property>
>>>>    </bean>
>>>>
>>>>       // child prototype
>>>>   <bean       id="queryNavigator"
>>>>            class="com.csi.cogids.console.query.QueryNavigator"
>>>>        singleton="false"
>>>>      init-method="initialize">
>>>>     <property name="newQueryAction"><ref
>>>>bean="newQueryAction"/></property>
>>>>     <property name="newGroupAction"><ref
>>>>bean="newGroupAction"/></property>
>>>>   </bean>
>>>>
>>>>A sessionVisualizerPage prototype gets instantiated when the page is
>>>> 
>>>>        
>>>>
>>>loaded
>>>
>>>
>>>      
>>>
>>>>in my application.  The queryNavigator prototype also gets instantiated
>>>>because of the <bean ref>.  setApplicationContext() IS called on
>>>>sessionVisualizerPage, but not on QueryNavigator, even though both are
>>>>ApplicationContextAware for message lookups.
>>>>
>>>>Thanks,
>>>>Keith
>>>>
>>>>Keith Donald
>>>>Senior Software Engineer
>>>>kd...@cs...
>>>>321-676-2923 x403
>>>>  
>>>>        
>>>>

Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

Colin,
=20
You've got a point here. The current invocation order is a result of =
context implementation issues rather than design from the user =
perspective. I guess we won't have to worry about backward compatibility =
too much: After all, we discourage everyone to implement =
BeanFactoryAware of ApplicationContextAware for typical beans. With the =
new core.io.Resource stuff in M4, there's even one less reason to =
implement the latter.
=20
So let's design this in a clean and obvious manner for RC1. Your first =
suggestion sounds good to me: However, we would need to introduce a =
distinction between "initializing" BeanPostProcessors and =
"post-initializing" ones. This could happen via a marker sub-interface, =
for example, or via a new method in the interface.
=20
A special issue is that a BeanPostProcessor can return a wrapped =
instance of the bean: This isn't really desirable for "initializing" =
BeanPostProcessors, is it? So maybe we'd even need to introduce a =
separate interface that just allows processing of the given bean =
instance. Any thoughts?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 07.01.2004 05:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Rationale for =
setApplicationContext() coming after afterPropertiesSet()



I was hoping for some more discussion on this, but it looks like nobody
bit...

In the meantime, I have clarified the existing ordering of the lifecycle
methods in the JavaDocs for InitializingBean, BeanFactoryAware, and
ApplcationContextAware.

I still think there somewhat of a (big) hole with regards to the current
initializing method handling. Currently, BeanPostProcessors are all
applied _after_ ApplicationContextAware (although this order is not
documented). This works for any BeanPostProcessors which expect to be
given fully initialized beans, as they will be given a bean initialized
fully (and knowing it) due to use of afterPropertiesSet
(InitializingBean), setBeanFactory (BeanFactoryAware), or
setApplicationContext (ApplicationContextAware). However, if somebody
needs to apply a BeanPostProcessor to set some properties of a bean as
part of the initialization, there is _no_ reliable mechanism to call an
init method on the bean afterwards; neither via an entry in the XML def,
nor via a marker interface.

What makes the most sense to _me_ is to have the following sequence =
apply:
-  BeanFactoryAware, ApplicationContextAware, a set of 'initializing'
BeanPostProcessors, InitializingBean, and finally a another set of
'post-initializing' BeanPostProcessors.

This obviously has implications in terms of backwards compatibility
since InitializingBean applies in a different sequence. A solution which
would be completely backwards compatible (but I think less obvious),
would be to do
- InitializingBean, BeanFactoryAware, 'initializing' BeanPostProcessors,
ApplicationContextAware, 'post-initializing' BeanPostProcessors. People
could in this case use any of the three marker interfaces to initialize,
as suitable...

Any comments?

Regards,
Colin

Colin Sampaleanu wrote:

> I think any distinction between 'basic JavaBean stuff' and
> 'application context stuff' is often going to be artificial. If you
> think about some class that actually needs the context, it is probably
> going to use it in a similar fashion to any other property inside it.
>
> But the initialize method (or the specific instance
> afterPropertiesSet) is also a lifecycle method, and it is in the wrong
> order as far as _any_ BeanPostProcessors are concerned, including
> ApplicationContextAware. Right now there is no mechanism to specify
> that an init method should be called after everything has been done to
> it by the context, including post processors. You can't even rely on
> setApplicationContext() as your init method because in fact some
> post-processors may act after it.
>
> If you think about it, you should be able to take a working
> beanfactory, with working beans, and if you need something special
> from the application context (like the post-processors, or indirectly,
> via the fact that one of its dependencies needs the application
> context) just switch to using the same setup in an application
> context. You can't really do that if you can no longer rely on the
> original init methods from when you were in the bean factory.
>
> So for sure I think there is a need for the ability to call an init
> method once post-processing is done, and I can't see the justification
> for making this different than the existing beanfactory init =
mechanism...
>
> Regards,
> Colin
>
> Rod Johnson wrote:
>
>> Colin,
>>
>> I like the present order: not surprisingly, perhaps, as I chose it. =
The
>> rationale is: get the basic JavaBean stuff in order first, then do =
any
>> application context stuff.
>>
>> Certainly the docs should be consistent.
>>
>> Now at least I understand the confusion: setApplicationContext() is =
not
>> treated as a normal JavaBean property, but as a lifecycle method.
>> Perhaps
>> the "set" prefix was unwise.
>>
>> Regards,
>> Rod
>>
>> ----- Original Message ----- From: "Colin Sampaleanu"
>> <col...@ex...>
>> To: <spr...@li...>
>> Sent: Monday, January 05, 2004 8:35 PM
>> Subject: [Springframework-developer] Rationale for
>> setApplicationContext()
>> coming after afterPropertiesSet()
>>
>>
>> I've had a couple of discussions now with people where I've tried to
>> explain why setApplicationContext comes after afterPropertiesSet (and
>> after any custom initializing method you define), and frankly, I =
think
>> it just doesn't make sense except for the fact that it's that way
>> right now.
>>
>> Most beans should of course not be using the application context, but =
if
>> they need it, people are not going to understand the rationale as to =
why
>> that property is set after the initializing method is called, and =
that
>> they must instead treat setApplicationContext itself as an =
initializer
>> method.
>>
>> I don't know if anybody thinks it's worth changing the order, but if
>> not, this thing is going to hit new users on the head on a regular
>> basis... At a minimum, if no code is changed, we need to update the
>> JavaDoc for ApplicationContextAware to explain the order. I can do
>> that...
>>
>> Regards,
>> Colin
>>
>> j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>=20
>>
>>> Actually, this is intended behavior, although it may be debatable
>>> whether
>>> =20
>>
>> it is appropriate. setApplicationContext is not really meant to be
>> combined
>> with an init-method. The latter is for non-Spring-aware beans, while =
the
>> former is the strongest dependency a bean can have on Spring. You =
should
>> *not* design your beans to depend on that initialization order.
>>=20
>>
>>> As a solution, you could put your initialization code in your
>>> =20
>>
>> setApplicationContext implementation, or in an =
initApplicationContext()
>> method that gets triggered by setApplicationContext. Have a look at =
the
>> ApplicationObjectSupport convenience base class, it provides such a
>> method
>> out of the box. Of course, extending ApplicationObjectSupport is not =
an
>> option if you already have a different natural base class.
>>=20
>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: Keith Donald [mailto:kd...@cs...]
>>> Sent: Thursday, October 30, 2003 4:22 PM
>>> To: spr...@li...
>>> Subject: RE: [Springframework-user] setApplicationContext not being
>>> called
>>>
>>>
>>> Juergen,
>>>
>>> Wanted to update you on this issue post M2.  setApplicationContext
>>> is being
>>> =20
>>
>> called now on all my ApplicationContextAware beans, thanks.  The only
>> issue
>> I have remaining is it seems the bean init-method method
>> ("initialize()" in
>> my case) is called by the container before setApplicationContext.  My
>> initialize() method does stuff that requires the context - for
>> example, it
>> looks up messages for initializing view components.  So I would
>> really need
>> setApplicationContext() called before initialize() to prevent
>> NullPointerExceptions.
>>=20
>>
>>> Thanks,
>>> Keith
>>>
>>> 2003-10-30 10:16:58,099 DEBUG =
[com.csi.cogids.console.QueryNavigator] -
>>> =20
>>
>> <initialize called>
>>=20
>>
>>> 2003-10-30 10:16:58,193 DEBUG
>>> [com.csi.cogids.console.qQueryNavigator] -
>>> =20
>>
>> <setApplicationContext called>
>>=20
>>
>>> Keith Donald
>>> Senior Software Engineer
>>> kd...@cs...
>>> 321-676-2923 x403
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> =20
>>
>> [mailto:spr...@li...] On Behalf =
Of
>> j=FCrgen h=F6ller [werk3AT]
>>=20
>>
>>> Sent: Thursday, October 23, 2003 2:14 AM
>>> To: spr...@li...
>>> Subject: Re: [Springframework-user] setApplicationContext not being
>>> called
>>>
>>>
>>> Keith,
>>>
>>> This was caused by the fact that ApplicationContextAware was being
>>> =20
>>
>> processed after the underlying bean factory finished its work, on
>> demand in
>> getBean calls to the application context. I've completely reworked
>> this for
>> 1.0 M2; now, the bean factory has a BeanPostProcessor hook that is =
also
>> internally used for processing ApplicationContextAware beans, to be
>> applied
>> when the underlying bean factory creates any kind of bean.
>>=20
>>
>>> So as of 1.0 M2, to be released tomorrow, this should work properly
>>> in all
>>> =20
>>
>> cases. If there should be any remaining issues, please report them
>> against
>> 1.0 M2. If you're eager, you can also try a CVS snapshot today.
>>=20
>>
>>> Juergen
>>>
>>>
>>>
>>> -----Urspr=FCngliche Nachricht----- Von: Keith Donald
>>> [mailto:kd...@cs...]
>>> Gesendet: Di 21.10.2003 19:50
>>> An: spr...@li...
>>> Cc:
>>> Betreff: [Springframework-user] setApplicationContext not being =
called
>>>
>>>
>>>
>>> Forgive me if this issue has already been addressd.  It appears
>>> setApplicationContext(ApplicationContext) is not being called on my
>>> ApplicationContextAware prototype beans that are not directly
>>> instantiated
>>> by a call to beanFactory.getBean(beanName), but rather are wired
>>> "child"
>>> beans instantiated as a result of a <bean ref> references from a =
parent
>>> prototype.
>>>
>>> To give you an example of what I mean:
>>>
>>>        // parent prototype
>>>        <bean      id=3D"sessionVisualizerPage"
>>>                =
class=3D"com.csi.cogids.console.SessionVisualizerPage"
>>>            singleton=3D"false">
>>>          <property name=3D"queryNavigator"><ref
>>> bean=3D"queryNavigator"/></property>
>>>     </bean>
>>>
>>>        // child prototype
>>>    <bean       id=3D"queryNavigator"
>>>             class=3D"com.csi.cogids.console.query.QueryNavigator"
>>>         singleton=3D"false"
>>>       init-method=3D"initialize">
>>>      <property name=3D"newQueryAction"><ref
>>> bean=3D"newQueryAction"/></property>
>>>      <property name=3D"newGroupAction"><ref
>>> bean=3D"newGroupAction"/></property>
>>>    </bean>
>>>
>>> A sessionVisualizerPage prototype gets instantiated when the page is
>>> =20
>>
>> loaded
>>=20
>>
>>> in my application.  The queryNavigator prototype also gets =
instantiated
>>> because of the <bean ref>.  setApplicationContext() IS called on
>>> sessionVisualizerPage, but not on QueryNavigator, even though both =
are
>>> ApplicationContextAware for message lookups.
>>>
>>> Thanks,
>>> Keith
>>>
>>> Keith Donald
>>> Senior Software Engineer
>>> kd...@cs...
>>> 321-676-2923 x403
>>>  =20
>>





-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

I was hoping for some more discussion on this, but it looks like nobody 
bit...

In the meantime, I have clarified the existing ordering of the lifecycle 
methods in the JavaDocs for InitializingBean, BeanFactoryAware, and 
ApplcationContextAware.

I still think there somewhat of a (big) hole with regards to the current 
initializing method handling. Currently, BeanPostProcessors are all 
applied _after_ ApplicationContextAware (although this order is not 
documented). This works for any BeanPostProcessors which expect to be 
given fully initialized beans, as they will be given a bean initialized 
fully (and knowing it) due to use of afterPropertiesSet 
(InitializingBean), setBeanFactory (BeanFactoryAware), or 
setApplicationContext (ApplicationContextAware). However, if somebody 
needs to apply a BeanPostProcessor to set some properties of a bean as 
part of the initialization, there is _no_ reliable mechanism to call an 
init method on the bean afterwards; neither via an entry in the XML def, 
nor via a marker interface.

What makes the most sense to _me_ is to have the following sequence apply:
-  BeanFactoryAware, ApplicationContextAware, a set of 'initializing' 
BeanPostProcessors, InitializingBean, and finally a another set of 
'post-initializing' BeanPostProcessors.

This obviously has implications in terms of backwards compatibility 
since InitializingBean applies in a different sequence. A solution which 
would be completely backwards compatible (but I think less obvious), 
would be to do
- InitializingBean, BeanFactoryAware, 'initializing' BeanPostProcessors, 
ApplicationContextAware, 'post-initializing' BeanPostProcessors. People 
could in this case use any of the three marker interfaces to initialize, 
as suitable...

Any comments?

Regards,
Colin

Colin Sampaleanu wrote:

> I think any distinction between 'basic JavaBean stuff' and 
> 'application context stuff' is often going to be artificial. If you 
> think about some class that actually needs the context, it is probably 
> going to use it in a similar fashion to any other property inside it.
>
> But the initialize method (or the specific instance 
> afterPropertiesSet) is also a lifecycle method, and it is in the wrong 
> order as far as _any_ BeanPostProcessors are concerned, including 
> ApplicationContextAware. Right now there is no mechanism to specify 
> that an init method should be called after everything has been done to 
> it by the context, including post processors. You can't even rely on 
> setApplicationContext() as your init method because in fact some 
> post-processors may act after it.
>
> If you think about it, you should be able to take a working 
> beanfactory, with working beans, and if you need something special 
> from the application context (like the post-processors, or indirectly, 
> via the fact that one of its dependencies needs the application 
> context) just switch to using the same setup in an application 
> context. You can't really do that if you can no longer rely on the 
> original init methods from when you were in the bean factory.
>
> So for sure I think there is a need for the ability to call an init 
> method once post-processing is done, and I can't see the justification 
> for making this different than the existing beanfactory init mechanism...
>
> Regards,
> Colin
>
> Rod Johnson wrote:
>
>> Colin,
>>
>> I like the present order: not surprisingly, perhaps, as I chose it. The
>> rationale is: get the basic JavaBean stuff in order first, then do any
>> application context stuff.
>>
>> Certainly the docs should be consistent.
>>
>> Now at least I understand the confusion: setApplicationContext() is not
>> treated as a normal JavaBean property, but as a lifecycle method. 
>> Perhaps
>> the "set" prefix was unwise.
>>
>> Regards,
>> Rod
>>
>> ----- Original Message ----- From: "Colin Sampaleanu" 
>> <col...@ex...>
>> To: <spr...@li...>
>> Sent: Monday, January 05, 2004 8:35 PM
>> Subject: [Springframework-developer] Rationale for 
>> setApplicationContext()
>> coming after afterPropertiesSet()
>>
>>
>> I've had a couple of discussions now with people where I've tried to
>> explain why setApplicationContext comes after afterPropertiesSet (and
>> after any custom initializing method you define), and frankly, I think
>> it just doesn't make sense except for the fact that it's that way 
>> right now.
>>
>> Most beans should of course not be using the application context, but if
>> they need it, people are not going to understand the rationale as to why
>> that property is set after the initializing method is called, and that
>> they must instead treat setApplicationContext itself as an initializer
>> method.
>>
>> I don't know if anybody thinks it's worth changing the order, but if
>> not, this thing is going to hit new users on the head on a regular
>> basis... At a minimum, if no code is changed, we need to update the
>> JavaDoc for ApplicationContextAware to explain the order. I can do 
>> that...
>>
>> Regards,
>> Colin
>>
>> jürgen höller [werk3AT] wrote:
>>
>>  
>>
>>> Actually, this is intended behavior, although it may be debatable 
>>> whether
>>>   
>>
>> it is appropriate. setApplicationContext is not really meant to be 
>> combined
>> with an init-method. The latter is for non-Spring-aware beans, while the
>> former is the strongest dependency a bean can have on Spring. You should
>> *not* design your beans to depend on that initialization order.
>>  
>>
>>> As a solution, you could put your initialization code in your
>>>   
>>
>> setApplicationContext implementation, or in an initApplicationContext()
>> method that gets triggered by setApplicationContext. Have a look at the
>> ApplicationObjectSupport convenience base class, it provides such a 
>> method
>> out of the box. Of course, extending ApplicationObjectSupport is not an
>> option if you already have a different natural base class.
>>  
>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: Keith Donald [mailto:kd...@cs...]
>>> Sent: Thursday, October 30, 2003 4:22 PM
>>> To: spr...@li...
>>> Subject: RE: [Springframework-user] setApplicationContext not being
>>> called
>>>
>>>
>>> Juergen,
>>>
>>> Wanted to update you on this issue post M2.  setApplicationContext 
>>> is being
>>>   
>>
>> called now on all my ApplicationContextAware beans, thanks.  The only 
>> issue
>> I have remaining is it seems the bean init-method method 
>> ("initialize()" in
>> my case) is called by the container before setApplicationContext.  My
>> initialize() method does stuff that requires the context - for 
>> example, it
>> looks up messages for initializing view components.  So I would 
>> really need
>> setApplicationContext() called before initialize() to prevent
>> NullPointerExceptions.
>>  
>>
>>> Thanks,
>>> Keith
>>>
>>> 2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] -
>>>   
>>
>> <initialize called>
>>  
>>
>>> 2003-10-30 10:16:58,193 DEBUG 
>>> [com.csi.cogids.console.qQueryNavigator] -
>>>   
>>
>> <setApplicationContext called>
>>  
>>
>>> Keith Donald
>>> Senior Software Engineer
>>> kd...@cs...
>>> 321-676-2923 x403
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>>   
>>
>> [mailto:spr...@li...] On Behalf Of
>> jürgen höller [werk3AT]
>>  
>>
>>> Sent: Thursday, October 23, 2003 2:14 AM
>>> To: spr...@li...
>>> Subject: Re: [Springframework-user] setApplicationContext not being 
>>> called
>>>
>>>
>>> Keith,
>>>
>>> This was caused by the fact that ApplicationContextAware was being
>>>   
>>
>> processed after the underlying bean factory finished its work, on 
>> demand in
>> getBean calls to the application context. I've completely reworked 
>> this for
>> 1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also
>> internally used for processing ApplicationContextAware beans, to be 
>> applied
>> when the underlying bean factory creates any kind of bean.
>>  
>>
>>> So as of 1.0 M2, to be released tomorrow, this should work properly 
>>> in all
>>>   
>>
>> cases. If there should be any remaining issues, please report them 
>> against
>> 1.0 M2. If you're eager, you can also try a CVS snapshot today.
>>  
>>
>>> Juergen
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht----- Von: Keith Donald 
>>> [mailto:kd...@cs...]
>>> Gesendet: Di 21.10.2003 19:50
>>> An: spr...@li...
>>> Cc:
>>> Betreff: [Springframework-user] setApplicationContext not being called
>>>
>>>
>>>
>>> Forgive me if this issue has already been addressd.  It appears
>>> setApplicationContext(ApplicationContext) is not being called on my
>>> ApplicationContextAware prototype beans that are not directly 
>>> instantiated
>>> by a call to beanFactory.getBean(beanName), but rather are wired 
>>> "child"
>>> beans instantiated as a result of a <bean ref> references from a parent
>>> prototype.
>>>
>>> To give you an example of what I mean:
>>>
>>>        // parent prototype
>>>        <bean      id="sessionVisualizerPage"
>>>                class="com.csi.cogids.console.SessionVisualizerPage"
>>>            singleton="false">
>>>          <property name="queryNavigator"><ref
>>> bean="queryNavigator"/></property>
>>>     </bean>
>>>
>>>        // child prototype
>>>    <bean       id="queryNavigator"
>>>             class="com.csi.cogids.console.query.QueryNavigator"
>>>         singleton="false"
>>>       init-method="initialize">
>>>      <property name="newQueryAction"><ref
>>> bean="newQueryAction"/></property>
>>>      <property name="newGroupAction"><ref
>>> bean="newGroupAction"/></property>
>>>    </bean>
>>>
>>> A sessionVisualizerPage prototype gets instantiated when the page is
>>>   
>>
>> loaded
>>  
>>
>>> in my application.  The queryNavigator prototype also gets instantiated
>>> because of the <bean ref>.  setApplicationContext() IS called on
>>> sessionVisualizerPage, but not on QueryNavigator, even though both are
>>> ApplicationContextAware for message lookups.
>>>
>>> Thanks,
>>> Keith
>>>
>>> Keith Donald
>>> Senior Software Engineer
>>> kd...@cs...
>>> 321-676-2923 x403
>>>    
>>

[Springframework-developer] ant.bat in the root of the project

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

Hi Juergen,

Did you intend to add ant.bat to the root of the project? It interferes 
with whatever ant version a user may have on their system.

It is completely normal and expected (by just about every project out 
there) that people have ant installed on their systems, so I've never 
understood the practice of adding batch files / shell scripts to 
projects to start ant with Ditto for including ant libs in the project 
itself; that's a lot of baggage to carry around just in case somebody 
doesn't have ant handy...

If you do want the file there, perhaps it could be named build.bat?

What about the ant libs in the lib dir, is there really any need to have 
them?

Regards,
Colin

[Springframework-developer] [Springframework-developer]

[Ross M. <ro...@at...>]

BTW congratulations on the M4 release guys!

We moved to it yesterday without any problems.

Cheers,

Ross

Re: [Springframework-developer] Serializable support

[Ross M. <ro...@at...>]

Hi all,

A better solution would be to make the logger transient as it doesn't 
really make sense to serialise (sorry, serialize ;-)) it. Plus i don't 
think org.apache.commons.logging.Log or implementations are Serializable.

Cheers,

Ross

MacMahon, Mark wrote:

> Hi All,
> 
> I have got a package of Spring configured objects that I would like to use
> interchangeably in both a web application and 
> an EJB application (from SFSB).
> Some of my Objects are BeanFactoryAware so that they can create on demand,
> prototype instances of spring configured objects.
> 
> All works well in web application mode. However I cannot get it to work
> reliably in ejb mode due to the fact that BeanFactory is not serializable -
> exceptions on passivation of the SFSB.
> 
> Why isn't BeanFactory serializable? I can see that the Log class is being
> stored as a member rather than a class variable in some of the spring
> classes but surely this can be changed easily?
> 
> 
> Shouldn't the BeanFactoryWare interface be documented so as to discourage
> use of it in beans that are used in an EJB environment?
> 
> Is there any way that I can avoid reverting back to using a typical java
> singleton for access to the BeanFactory for the scenario that I have
> described (loading prototypes on demand)
> 
> 
> I am also getting problems passivating the SFSB due to the fact that
> AbstractEnterpriseBean stores its logger as a member rather than a class
> variable:
> Is this convenience really worth sacrificing serializable support?
> 
> abstract class AbstractEnterpriseBean implements EnterpriseBean 
> {
> 
> 	/** Logger, available to subclasses */
> 	protected final Log logger = LogFactory.getLog(getClass());
> 	
> 	//Change to static to support serializable
> 	//private final static Log logger =
> LogFactory.getLog(AbstractEnterpriseBean.class);
> 	
> }
> 
> 
> 
> Please forgive me if I am addressing the wrong mailing list here!
> 
> Any help appreciated!
> Thanks in advance!
> 
> Mark
> 
> ____________________________________________________ 
> 
> emuse technologies 
> U24 Trinity Enterprise Centre, Pearse Street, Dublin 2, Ireland.
> Tel:  +353 (0)1 6717317 Fax:  +353 (0)1 6717319 
> website: <http://www.emusetechnologies.com/> 
> email:    in...@em... <mailto:in...@em...>
> ____________________________________________________ 
> 
> This message has been scanned for viruses using GroupShield for Exchange
> Server.
> 
> CONFIDENTIALITY NOTICE - The information contained in this email message is
> intended only for confidential use of the named recipient. If the reader is
> not the intended recipient or the person responsible for delivering it to
> the recipient, you are hereby notified that you have received this
> communication in error and that any review, dissemination or copying of this
> communication is strictly prohibited. If you have received this in error,
> please notify the sender immediately.
> 
> The information, opinions and recommendations contained herein are and must
> be construed solely as statements of opinion and not statements of fact. No
> warranty, expressed or implied, as to the accuracy, timeliness,
> completeness, merchantability or fitness for any particular purpose of any
> such recommendation or information is given or made by emuse technologies in
> any form or manner whatsoever.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Problem with HibernateTransactionManager in M4

[Joseph F. <jfi...@pr...>]

Hello,

I just upgraded to the m4 jar in our app, and I'm having an small problem
with the HibernateTransactionManager. It looks like there was a piece of
code added to set the flush mode to AUTO for non read-only transactions. In
my case, I need the flush mode set to COMMIT. Is there a reason AUTO is
needed there? Would COMMIT cause some other problem that I'm not aware of
yet? If not, could it somehow be a configurable parameter?

Thanks!

Joe

Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

I think any distinction between 'basic JavaBean stuff' and 'application=20
context stuff' is often going to be artificial. If you think about some=20
class that actually needs the context, it is probably going to use it in=20
a similar fashion to any other property inside it.

But the initialize method (or the specific instance afterPropertiesSet)=20
is also a lifecycle method, and it is in the wrong order as far as _any_=20
BeanPostProcessors are concerned, including ApplicationContextAware.=20
Right now there is no mechanism to specify that an init method should be=20
called after everything has been done to it by the context, including=20
post processors. You can't even rely on setApplicationContext() as your=20
init method because in fact some post-processors may act after it.

If you think about it, you should be able to take a working beanfactory,=20
with working beans, and if you need something special from the=20
application context (like the post-processors, or indirectly, via the=20
fact that one of its dependencies needs the application context) just=20
switch to using the same setup in an application context. You can't=20
really do that if you can no longer rely on the original init methods=20
from when you were in the bean factory.

So for sure I think there is a need for the ability to call an init=20
method once post-processing is done, and I can't see the justification=20
for making this different than the existing beanfactory init mechanism...

Regards,
Colin

Rod Johnson wrote:

>Colin,
>
>I like the present order: not surprisingly, perhaps, as I chose it. The
>rationale is: get the basic JavaBean stuff in order first, then do any
>application context stuff.
>
>Certainly the docs should be consistent.
>
>Now at least I understand the confusion: setApplicationContext() is not
>treated as a normal JavaBean property, but as a lifecycle method. Perhap=
s
>the "set" prefix was unwise.
>
>Regards,
>Rod
>
>----- Original Message -----=20
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Monday, January 05, 2004 8:35 PM
>Subject: [Springframework-developer] Rationale for setApplicationContext=
()
>coming after afterPropertiesSet()
>
>
>I've had a couple of discussions now with people where I've tried to
>explain why setApplicationContext comes after afterPropertiesSet (and
>after any custom initializing method you define), and frankly, I think
>it just doesn't make sense except for the fact that it's that way right =
now.
>
>Most beans should of course not be using the application context, but if
>they need it, people are not going to understand the rationale as to why
>that property is set after the initializing method is called, and that
>they must instead treat setApplicationContext itself as an initializer
>method.
>
>I don't know if anybody thinks it's worth changing the order, but if
>not, this thing is going to hit new users on the head on a regular
>basis... At a minimum, if no code is changed, we need to update the
>JavaDoc for ApplicationContextAware to explain the order. I can do that.=
..
>
>Regards,
>Colin
>
>j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:
>
> =20
>
>>Actually, this is intended behavior, although it may be debatable wheth=
er
>>   =20
>>
>it is appropriate. setApplicationContext is not really meant to be combi=
ned
>with an init-method. The latter is for non-Spring-aware beans, while the
>former is the strongest dependency a bean can have on Spring. You should
>*not* design your beans to depend on that initialization order.
> =20
>
>>As a solution, you could put your initialization code in your
>>   =20
>>
>setApplicationContext implementation, or in an initApplicationContext()
>method that gets triggered by setApplicationContext. Have a look at the
>ApplicationObjectSupport convenience base class, it provides such a meth=
od
>out of the box. Of course, extending ApplicationObjectSupport is not an
>option if you already have a different natural base class.
> =20
>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: Keith Donald [mailto:kd...@cs...]
>>Sent: Thursday, October 30, 2003 4:22 PM
>>To: spr...@li...
>>Subject: RE: [Springframework-user] setApplicationContext not being
>>called
>>
>>
>>Juergen,
>>
>>Wanted to update you on this issue post M2.  setApplicationContext is b=
eing
>>   =20
>>
>called now on all my ApplicationContextAware beans, thanks.  The only is=
sue
>I have remaining is it seems the bean init-method method ("initialize()"=
 in
>my case) is called by the container before setApplicationContext.  My
>initialize() method does stuff that requires the context - for example, =
it
>looks up messages for initializing view components.  So I would really n=
eed
>setApplicationContext() called before initialize() to prevent
>NullPointerExceptions.
> =20
>
>>Thanks,
>>Keith
>>
>>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] -
>>   =20
>>
><initialize called>
> =20
>
>>2003-10-30 10:16:58,193 DEBUG [com.csi.cogids.console.qQueryNavigator] =
-
>>   =20
>>
><setApplicationContext called>
> =20
>
>>Keith Donald
>>Senior Software Engineer
>>kd...@cs...
>>321-676-2923 x403
>>
>>
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>   =20
>>
>[mailto:spr...@li...] On Behalf Of
>j=C3=BCrgen h=C3=B6ller [werk3AT]
> =20
>
>>Sent: Thursday, October 23, 2003 2:14 AM
>>To: spr...@li...
>>Subject: Re: [Springframework-user] setApplicationContext not being cal=
led
>>
>>
>>Keith,
>>
>>This was caused by the fact that ApplicationContextAware was being
>>   =20
>>
>processed after the underlying bean factory finished its work, on demand=
 in
>getBean calls to the application context. I've completely reworked this =
for
>1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also
>internally used for processing ApplicationContextAware beans, to be appl=
ied
>when the underlying bean factory creates any kind of bean.
> =20
>
>>So as of 1.0 M2, to be released tomorrow, this should work properly in =
all
>>   =20
>>
>cases. If there should be any remaining issues, please report them again=
st
>1.0 M2. If you're eager, you can also try a CVS snapshot today.
> =20
>
>>Juergen
>>
>>
>>
>>-----Urspr=C3=BCngliche Nachricht-----=20
>>Von: Keith Donald [mailto:kd...@cs...]
>>Gesendet: Di 21.10.2003 19:50
>>An: spr...@li...
>>Cc:
>>Betreff: [Springframework-user] setApplicationContext not being called
>>
>>
>>
>>Forgive me if this issue has already been addressd.  It appears
>>setApplicationContext(ApplicationContext) is not being called on my
>>ApplicationContextAware prototype beans that are not directly instantia=
ted
>>by a call to beanFactory.getBean(beanName), but rather are wired "child=
"
>>beans instantiated as a result of a <bean ref> references from a parent
>>prototype.
>>
>>To give you an example of what I mean:
>>
>>        // parent prototype
>>        <bean      id=3D"sessionVisualizerPage"
>>                class=3D"com.csi.cogids.console.SessionVisualizerPage"
>>            singleton=3D"false">
>>          <property name=3D"queryNavigator"><ref
>>bean=3D"queryNavigator"/></property>
>>     </bean>
>>
>>        // child prototype
>>    <bean       id=3D"queryNavigator"
>>             class=3D"com.csi.cogids.console.query.QueryNavigator"
>>         singleton=3D"false"
>>       init-method=3D"initialize">
>>      <property name=3D"newQueryAction"><ref
>>bean=3D"newQueryAction"/></property>
>>      <property name=3D"newGroupAction"><ref
>>bean=3D"newGroupAction"/></property>
>>    </bean>
>>
>>A sessionVisualizerPage prototype gets instantiated when the page is
>>   =20
>>
>loaded
> =20
>
>>in my application.  The queryNavigator prototype also gets instantiated
>>because of the <bean ref>.  setApplicationContext() IS called on
>>sessionVisualizerPage, but not on QueryNavigator, even though both are
>>ApplicationContextAware for message lookups.
>>
>>Thanks,
>>Keith
>>
>>Keith Donald
>>Senior Software Engineer
>>kd...@cs...
>>321-676-2923 x403
>>   =20
>>

RE: [Springframework-developer] Serializable support

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

A serializable beanfactory in my opinion is not a really good option,
what about the beans it contains? Should they be serializable as well
(which is what a serializable beanfactory would indicate as far as I'm
concerned).

We use the BeanFactory in EJBs a lot and we declare it as being
transient and force re-initialization an activation. This just works
fine. When limiting the amount of beans in a BeanFactory for an EJB and
creating multiple beanfactories for multiple different EJBs, it
shouldn't be that big an overhead.

Alef


> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of MacMahon, Mark
> Sent: Tuesday, January 06, 2004 1:34 PM
> To: 'spr...@li...'
> Subject: [Springframework-developer] Serializable support
> 
> 
> 
> Hi All,
> 
> I have got a package of Spring configured objects that I 
> would like to use interchangeably in both a web application and 
> an EJB application (from SFSB).
> Some of my Objects are BeanFactoryAware so that they can 
> create on demand, prototype instances of spring configured objects.
> 
> All works well in web application mode. However I cannot get 
> it to work reliably in ejb mode due to the fact that 
> BeanFactory is not serializable - exceptions on passivation 
> of the SFSB.
> 
> Why isn't BeanFactory serializable? I can see that the Log 
> class is being stored as a member rather than a class 
> variable in some of the spring classes but surely this can be 
> changed easily?
> 
> 
> Shouldn't the BeanFactoryWare interface be documented so as 
> to discourage use of it in beans that are used in an EJB environment?
> 
> Is there any way that I can avoid reverting back to using a 
> typical java singleton for access to the BeanFactory for the 
> scenario that I have described (loading prototypes on demand)
> 
> 
> I am also getting problems passivating the SFSB due to the 
> fact that AbstractEnterpriseBean stores its logger as a 
> member rather than a class
> variable:
> Is this convenience really worth sacrificing serializable support?
> 
> abstract class AbstractEnterpriseBean implements EnterpriseBean 
> {
> 
> 	/** Logger, available to subclasses */
> 	protected final Log logger = LogFactory.getLog(getClass());
> 	
> 	//Change to static to support serializable
> 	//private final static Log logger = 
> LogFactory.getLog(AbstractEnterpriseBean.class);
> 	
> }
> 
> 
> 
> Please forgive me if I am addressing the wrong mailing list here!
> 
> Any help appreciated!
> Thanks in advance!
> 
> Mark
> 
> ____________________________________________________ 
> 
> emuse technologies 
> U24 Trinity Enterprise Centre, Pearse Street, Dublin 2, Ireland.
> Tel:  +353 (0)1 6717317 Fax:  +353 (0)1 6717319 
> website: <http://www.emusetechnologies.com/> 
> email:    in...@em... <mailto:in...@em...>
> ____________________________________________________ 
> 
> This message has been scanned for viruses using GroupShield 
> for Exchange Server.
> 
> CONFIDENTIALITY NOTICE - The information contained in this 
> email message is intended only for confidential use of the 
> named recipient. If the reader is not the intended recipient 
> or the person responsible for delivering it to the recipient, 
> you are hereby notified that you have received this 
> communication in error and that any review, dissemination or 
> copying of this communication is strictly prohibited. If you 
> have received this in error, please notify the sender immediately.
> 
> The information, opinions and recommendations contained 
> herein are and must be construed solely as statements of 
> opinion and not statements of fact. No warranty, expressed or 
> implied, as to the accuracy, timeliness, completeness, 
> merchantability or fitness for any particular purpose of any 
> such recommendation or information is given or made by emuse 
> technologies in any form or manner whatsoever.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's Free Linux Tutorials.  Learn everything from the 
> bash shell to sys admin. Click now! 
> http://ads.osdn.com/?ad_id=1278&alloc_id=> 3371&op=click
> 
> 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Serializable support

[Tim M. <tec...@mo...>]

MacMahon, Mark wrote:

> Hi All,
> 
<snip>

> 
> I am also getting problems passivating the SFSB due to the fact that
> AbstractEnterpriseBean stores its logger as a member rather than a class
> variable:
> Is this convenience really worth sacrificing serializable support?
> 
> abstract class AbstractEnterpriseBean implements EnterpriseBean 
> {
> 
> 	/** Logger, available to subclasses */
> 	protected final Log logger = LogFactory.getLog(getClass());
> 	
> 	//Change to static to support serializable
> 	//private final static Log logger =
> LogFactory.getLog(AbstractEnterpriseBean.class);
> 	
> }
> 

I am working along with Mark on this issue and now have some further 
points to note:

I see that there is now a note on the "logger" variable that it should 
be reinitialised during activation for a stateful session bean. This has 
been implemented (logger set to null during passivation) but we now 
receive the following error during passivation:

javax.ejb.EJBException: Could not passivate; failed to save state; 
CausedByException is:
	org.springframework.aop.framework.Cglib2AopProxy
	at 
org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:378)
	at 
org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:85)

I have even set the logger on the Cglib2AopProxy to a static variable 
but this did not help.

I do reiterate Mark's comments about the loggers used in the Spring 
code. It would be much easier to use these classes if the loggers were 
static. It may require a little more code placed in to initialise a 
logger for the subclasses but the resulting stability would be worth it.

Currently it looks like we'll have to stop using Spring's stateful 
session bean until it can be passivated successfully.

Once again, thanks for a great framework and looking forward to 1.0!

Tim McAuley

RE: [Springframework-developer] Rationale for setApplicationConte xt() coming after afterPropertiesSet()

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

I think that setApplicationContext() is not a bad name for a lifecycle
method - similar to EJB's setSessionContext().

Just my 2c.

Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]=20
Sent: Tuesday, January 06, 2004 4:31 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Rationale for
setApplicationContext() coming after afterPropertiesSet()


Colin,

I like the present order: not surprisingly, perhaps, as I chose it. The
rationale is: get the basic JavaBean stuff in order first, then do any
application context stuff.

Certainly the docs should be consistent.

Now at least I understand the confusion: setApplicationContext() is not
treated as a normal JavaBean property, but as a lifecycle method. =
Perhaps
the "set" prefix was unwise.

Regards,
Rod

----- Original Message -----=20
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, January 05, 2004 8:35 PM
Subject: [Springframework-developer] Rationale for =
setApplicationContext()
coming after afterPropertiesSet()


I've had a couple of discussions now with people where I've tried to =
explain
why setApplicationContext comes after afterPropertiesSet (and after any
custom initializing method you define), and frankly, I think it just =
doesn't
make sense except for the fact that it's that way right now.

Most beans should of course not be using the application context, but =
if
they need it, people are not going to understand the rationale as to =
why
that property is set after the initializing method is called, and that =
they
must instead treat setApplicationContext itself as an initializer =
method.

I don't know if anybody thinks it's worth changing the order, but if =
not,
this thing is going to hit new users on the head on a regular basis... =
At a
minimum, if no code is changed, we need to update the JavaDoc for
ApplicationContextAware to explain the order. I can do that...

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>Actually, this is intended behavior, although it may be debatable=20
>whether
it is appropriate. setApplicationContext is not really meant to be =
combined
with an init-method. The latter is for non-Spring-aware beans, while =
the
former is the strongest dependency a bean can have on Spring. You =
should
*not* design your beans to depend on that initialization order.
>
>As a solution, you could put your initialization code in your
setApplicationContext implementation, or in an initApplicationContext()
method that gets triggered by setApplicationContext. Have a look at the
ApplicationObjectSupport convenience base class, it provides such a =
method
out of the box. Of course, extending ApplicationObjectSupport is not an
option if you already have a different natural base class.
>
>Juergen
>
>
>-----Original Message-----
>From: Keith Donald [mailto:kd...@cs...]
>Sent: Thursday, October 30, 2003 4:22 PM
>To: spr...@li...
>Subject: RE: [Springframework-user] setApplicationContext not being=20
>called
>
>
>Juergen,
>
>Wanted to update you on this issue post M2.  setApplicationContext is=20
>being
called now on all my ApplicationContextAware beans, thanks.  The only =
issue
I have remaining is it seems the bean init-method method =
("initialize()" in
my case) is called by the container before setApplicationContext.  My
initialize() method does stuff that requires the context - for example, =
it
looks up messages for initializing view components.  So I would really =
need
setApplicationContext() called before initialize() to prevent
NullPointerExceptions.
>
>Thanks,
>Keith
>
>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] =
-
<initialize called>
>2003-10-30 10:16:58,193 DEBUG [com.csi.cogids.console.qQueryNavigator] =

>-
<setApplicationContext called>
>
>Keith Donald
>Senior Software Engineer
>kd...@cs...
>321-676-2923 x403
>
>
>
>
>-----Original Message-----
>From: spr...@li...
[mailto:spr...@li...] On Behalf Of
j=FCrgen h=F6ller [werk3AT]
>Sent: Thursday, October 23, 2003 2:14 AM
>To: spr...@li...
>Subject: Re: [Springframework-user] setApplicationContext not being=20
>called
>
>
>Keith,
>
>This was caused by the fact that ApplicationContextAware was being
processed after the underlying bean factory finished its work, on =
demand in
getBean calls to the application context. I've completely reworked this =
for
1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also
internally used for processing ApplicationContextAware beans, to be =
applied
when the underlying bean factory creates any kind of bean.
>
>So as of 1.0 M2, to be released tomorrow, this should work properly in =

>all
cases. If there should be any remaining issues, please report them =
against
1.0 M2. If you're eager, you can also try a CVS snapshot today.
>
>Juergen
>
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Keith Donald [mailto:kd...@cs...]
> Gesendet: Di 21.10.2003 19:50
> An: spr...@li...
> Cc:
> Betreff: [Springframework-user] setApplicationContext not being =
called
>
>
>
> Forgive me if this issue has already been addressd.  It appears
> setApplicationContext(ApplicationContext) is not being called on my=20
> ApplicationContextAware prototype beans that are not directly=20
> instantiated by a call to beanFactory.getBean(beanName), but rather=20
> are wired "child" beans instantiated as a result of a <bean ref>=20
> references from a parent prototype.
>
> To give you an example of what I mean:
>
>         // parent prototype
>         <bean      id=3D"sessionVisualizerPage"
>                 =
class=3D"com.csi.cogids.console.SessionVisualizerPage"
>             singleton=3D"false">
>           <property name=3D"queryNavigator"><ref=20
> bean=3D"queryNavigator"/></property>
>      </bean>
>
>         // child prototype
>     <bean       id=3D"queryNavigator"
>              class=3D"com.csi.cogids.console.query.QueryNavigator"
>          singleton=3D"false"
>        init-method=3D"initialize">
>       <property name=3D"newQueryAction"><ref=20
> bean=3D"newQueryAction"/></property>
>       <property name=3D"newGroupAction"><ref=20
> bean=3D"newGroupAction"/></property>
>     </bean>
>
> A sessionVisualizerPage prototype gets instantiated when the page is
loaded
> in my application.  The queryNavigator prototype also gets=20
> instantiated because of the <bean ref>.  setApplicationContext() IS=20
> called on sessionVisualizerPage, but not on QueryNavigator, even=20
> though both are ApplicationContextAware for message lookups.
>
> Thanks,
> Keith
>
> Keith Donald
> Senior Software Engineer
> kd...@cs...
> 321-676-2923 x403
>
>




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Serializable support

[MacMahon, M. <M.M...@em...>]

Hi All,

I have got a package of Spring configured objects that I would like to use
interchangeably in both a web application and 
an EJB application (from SFSB).
Some of my Objects are BeanFactoryAware so that they can create on demand,
prototype instances of spring configured objects.

All works well in web application mode. However I cannot get it to work
reliably in ejb mode due to the fact that BeanFactory is not serializable -
exceptions on passivation of the SFSB.

Why isn't BeanFactory serializable? I can see that the Log class is being
stored as a member rather than a class variable in some of the spring
classes but surely this can be changed easily?


Shouldn't the BeanFactoryWare interface be documented so as to discourage
use of it in beans that are used in an EJB environment?

Is there any way that I can avoid reverting back to using a typical java
singleton for access to the BeanFactory for the scenario that I have
described (loading prototypes on demand)


I am also getting problems passivating the SFSB due to the fact that
AbstractEnterpriseBean stores its logger as a member rather than a class
variable:
Is this convenience really worth sacrificing serializable support?

abstract class AbstractEnterpriseBean implements EnterpriseBean 
{

	/** Logger, available to subclasses */
	protected final Log logger = LogFactory.getLog(getClass());
	
	//Change to static to support serializable
	//private final static Log logger =
LogFactory.getLog(AbstractEnterpriseBean.class);
	
}



Please forgive me if I am addressing the wrong mailing list here!

Any help appreciated!
Thanks in advance!

Mark

____________________________________________________ 

emuse technologies 
U24 Trinity Enterprise Centre, Pearse Street, Dublin 2, Ireland.
Tel:  +353 (0)1 6717317 Fax:  +353 (0)1 6717319 
website: <http://www.emusetechnologies.com/> 
email:    in...@em... <mailto:in...@em...>
____________________________________________________ 

This message has been scanned for viruses using GroupShield for Exchange
Server.

CONFIDENTIALITY NOTICE - The information contained in this email message is
intended only for confidential use of the named recipient. If the reader is
not the intended recipient or the person responsible for delivering it to
the recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination or copying of this
communication is strictly prohibited. If you have received this in error,
please notify the sender immediately.

The information, opinions and recommendations contained herein are and must
be construed solely as statements of opinion and not statements of fact. No
warranty, expressed or implied, as to the accuracy, timeliness,
completeness, merchantability or fitness for any particular purpose of any
such recommendation or information is given or made by emuse technologies in
any form or manner whatsoever.

Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

Colin,

I like the present order: not surprisingly, perhaps, as I chose it. The
rationale is: get the basic JavaBean stuff in order first, then do any
application context stuff.

Certainly the docs should be consistent.

Now at least I understand the confusion: setApplicationContext() is not
treated as a normal JavaBean property, but as a lifecycle method. Perhaps
the "set" prefix was unwise.

Regards,
Rod

----- Original Message -----=20
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, January 05, 2004 8:35 PM
Subject: [Springframework-developer] Rationale for setApplicationContext(=
)
coming after afterPropertiesSet()


I've had a couple of discussions now with people where I've tried to
explain why setApplicationContext comes after afterPropertiesSet (and
after any custom initializing method you define), and frankly, I think
it just doesn't make sense except for the fact that it's that way right n=
ow.

Most beans should of course not be using the application context, but if
they need it, people are not going to understand the rationale as to why
that property is set after the initializing method is called, and that
they must instead treat setApplicationContext itself as an initializer
method.

I don't know if anybody thinks it's worth changing the order, but if
not, this thing is going to hit new users on the head on a regular
basis... At a minimum, if no code is changed, we need to update the
JavaDoc for ApplicationContextAware to explain the order. I can do that...

Regards,
Colin

j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>Actually, this is intended behavior, although it may be debatable whethe=
r
it is appropriate. setApplicationContext is not really meant to be combin=
ed
with an init-method. The latter is for non-Spring-aware beans, while the
former is the strongest dependency a bean can have on Spring. You should
*not* design your beans to depend on that initialization order.
>
>As a solution, you could put your initialization code in your
setApplicationContext implementation, or in an initApplicationContext()
method that gets triggered by setApplicationContext. Have a look at the
ApplicationObjectSupport convenience base class, it provides such a metho=
d
out of the box. Of course, extending ApplicationObjectSupport is not an
option if you already have a different natural base class.
>
>Juergen
>
>
>-----Original Message-----
>From: Keith Donald [mailto:kd...@cs...]
>Sent: Thursday, October 30, 2003 4:22 PM
>To: spr...@li...
>Subject: RE: [Springframework-user] setApplicationContext not being
>called
>
>
>Juergen,
>
>Wanted to update you on this issue post M2.  setApplicationContext is be=
ing
called now on all my ApplicationContextAware beans, thanks.  The only iss=
ue
I have remaining is it seems the bean init-method method ("initialize()" =
in
my case) is called by the container before setApplicationContext.  My
initialize() method does stuff that requires the context - for example, i=
t
looks up messages for initializing view components.  So I would really ne=
ed
setApplicationContext() called before initialize() to prevent
NullPointerExceptions.
>
>Thanks,
>Keith
>
>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] -
<initialize called>
>2003-10-30 10:16:58,193 DEBUG [com.csi.cogids.console.qQueryNavigator] -
<setApplicationContext called>
>
>Keith Donald
>Senior Software Engineer
>kd...@cs...
>321-676-2923 x403
>
>
>
>
>-----Original Message-----
>From: spr...@li...
[mailto:spr...@li...] On Behalf Of
j=C3=BCrgen h=C3=B6ller [werk3AT]
>Sent: Thursday, October 23, 2003 2:14 AM
>To: spr...@li...
>Subject: Re: [Springframework-user] setApplicationContext not being call=
ed
>
>
>Keith,
>
>This was caused by the fact that ApplicationContextAware was being
processed after the underlying bean factory finished its work, on demand =
in
getBean calls to the application context. I've completely reworked this f=
or
1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also
internally used for processing ApplicationContextAware beans, to be appli=
ed
when the underlying bean factory creates any kind of bean.
>
>So as of 1.0 M2, to be released tomorrow, this should work properly in a=
ll
cases. If there should be any remaining issues, please report them agains=
t
1.0 M2. If you're eager, you can also try a CVS snapshot today.
>
>Juergen
>
>
>
> -----Urspr=C3=BCngliche Nachricht-----=20
> Von: Keith Donald [mailto:kd...@cs...]
> Gesendet: Di 21.10.2003 19:50
> An: spr...@li...
> Cc:
> Betreff: [Springframework-user] setApplicationContext not being called
>
>
>
> Forgive me if this issue has already been addressd.  It appears
> setApplicationContext(ApplicationContext) is not being called on my
> ApplicationContextAware prototype beans that are not directly instantia=
ted
> by a call to beanFactory.getBean(beanName), but rather are wired "child=
"
> beans instantiated as a result of a <bean ref> references from a parent
> prototype.
>
> To give you an example of what I mean:
>
>         // parent prototype
>         <bean      id=3D"sessionVisualizerPage"
>                 class=3D"com.csi.cogids.console.SessionVisualizerPage"
>             singleton=3D"false">
>           <property name=3D"queryNavigator"><ref
> bean=3D"queryNavigator"/></property>
>      </bean>
>
>         // child prototype
>     <bean       id=3D"queryNavigator"
>              class=3D"com.csi.cogids.console.query.QueryNavigator"
>          singleton=3D"false"
>        init-method=3D"initialize">
>       <property name=3D"newQueryAction"><ref
> bean=3D"newQueryAction"/></property>
>       <property name=3D"newGroupAction"><ref
> bean=3D"newGroupAction"/></property>
>     </bean>
>
> A sessionVisualizerPage prototype gets instantiated when the page is
loaded
> in my application.  The queryNavigator prototype also gets instantiated
> because of the <bean ref>.  setApplicationContext() IS called on
> sessionVisualizerPage, but not on QueryNavigator, even though both are
> ApplicationContextAware for message lookups.
>
> Thanks,
> Keith
>
> Keith Donald
> Senior Software Engineer
> kd...@cs...
> 321-676-2923 x403
>
>




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Attributes

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

I've just adapted the build script of JPetStore's attributes version for =
adding the attribute jars to the classpath too. I've also added an =
ant.bat to samples/jpetstore/attributes - it is now possible to use the =
Ant version that we ship with the distribution -, and also to the =
framework root. Compiling with Commons Attributes is now significantly =
simpler than before: It works out-of-the-box now, like all our sample =
app builds. No more need to have a separate Ant distribution with =
manually added jar files.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mo 05.01.2004 18:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Attributes



I did, Fri. morning if I remember. Then my DSL went down before I could
post the message below...

If you have the libs in the ant classpath, you should just be able to
remove them and still have the build work for you.

Rod Johnson wrote:

>Sounds great. I'm all for this change. Would you like to commit it?
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Monday, January 05, 2004 5:06 PM
>Subject: Re: [Springframework-developer] Attributes
>
>
>=20
>
>>A few days ago I changed the build to make the taskdef for the =
attribute
>>compiler use a classpath to bring in these needed jars, instead of
>>relying on the user to add them to the ant lib dir.
>>
>>Generally it can cause complications/problems to add libs directly to
>>the ant lib dir, and best avoided if at all possible. For example, if
>>you add xjavadoc.jar there, then you have to add all the other xdoclet
>>modules there as well, if you want to use xdoclet elsewhere.
>>
>>There seem to be no issues with this approach, with both ant 1.6 and
>>  =20
>>
>1.5...
>=20
>
>>Rod Johnson wrote:
>>
>>  =20
>>
>>>The tests now depend on a Commons Attributes precompile step. =
However,
>>>    =20
>>>
>this
>=20
>
>>>doesn't take very long at all as it applies only to one package.
>>>
>>>However, you will need to put the following files in your =
$ANT_HOME/lib
>>>    =20
>>>
>to
>=20
>
>>>get the tests to run:
>>>
>>>- Commons Attributes compiler Jar (in CVS)
>>>- commons-collections.jar (in CVS)
>>>- xjavadoc.jar (from XDoclet project). I'm not sure whether to put =
this
>>>    =20
>>>
>in
>=20
>
>>>CVS as none of our code uses it. Thoughts?
>>>
>>>For now, I've named the attributes-dependent test case so that =
Eclipse
>>>    =20
>>>
>won't
>=20
>
>>>pick up. I'll change this when I get time so that the build is also
>>>triggered under Eclipse.
>>>
>>>Regards,
>>>Rod
>>>
>>>
>>>    =20
>>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: IBM Linux Tutorials.
>>Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
>>Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
>>Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>  =20
>>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
>Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
>Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

I've had a couple of discussions now with people where I've tried to=20
explain why setApplicationContext comes after afterPropertiesSet (and=20
after any custom initializing method you define), and frankly, I think=20
it just doesn't make sense except for the fact that it's that way right n=
ow.

Most beans should of course not be using the application context, but if=20
they need it, people are not going to understand the rationale as to why=20
that property is set after the initializing method is called, and that=20
they must instead treat setApplicationContext itself as an initializer=20
method.

I don't know if anybody thinks it's worth changing the order, but if=20
not, this thing is going to hit new users on the head on a regular=20
basis... At a minimum, if no code is changed, we need to update the=20
JavaDoc for ApplicationContextAware to explain the order. I can do that..=
.

Regards,
Colin

j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>Actually, this is intended behavior, although it may be debatable whethe=
r it is appropriate. setApplicationContext is not really meant to be comb=
ined with an init-method. The latter is for non-Spring-aware beans, while=
 the former is the strongest dependency a bean can have on Spring. You sh=
ould *not* design your beans to depend on that initialization order.
>
>As a solution, you could put your initialization code in your setApplica=
tionContext implementation, or in an initApplicationContext() method that=
 gets triggered by setApplicationContext. Have a look at the ApplicationO=
bjectSupport convenience base class, it provides such a method out of the=
 box. Of course, extending ApplicationObjectSupport is not an option if y=
ou already have a different natural base class.
>
>Juergen
>
>
>-----Original Message-----
>From: Keith Donald [mailto:kd...@cs...]
>Sent: Thursday, October 30, 2003 4:22 PM
>To: spr...@li...
>Subject: RE: [Springframework-user] setApplicationContext not being
>called
>
>
>Juergen,
>
>Wanted to update you on this issue post M2.  setApplicationContext is be=
ing called now on all my ApplicationContextAware beans, thanks.  The only=
 issue I have remaining is it seems the bean init-method method ("initial=
ize()" in my case) is called by the container before setApplicationContex=
t.  My initialize() method does stuff that requires the context - for exa=
mple, it looks up messages for initializing view components.  So I would =
really need setApplicationContext() called before initialize() to prevent=
 NullPointerExceptions.
>
>Thanks,
>Keith
>
>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] - =
<initialize called>
>2003-10-30 10:16:58,193 DEBUG [com.csi.cogids.console.qQueryNavigator] -=
 <setApplicationContext called>
>
>Keith Donald
>Senior Software Engineer
>kd...@cs...
>321-676-2923 x403
>
>
>
>
>-----Original Message-----
>From: spr...@li... [mailto:springfra=
mew...@li...] On Behalf Of j=C3=BCrgen h=C3=B6=
ller [werk3AT]
>Sent: Thursday, October 23, 2003 2:14 AM
>To: spr...@li...
>Subject: Re: [Springframework-user] setApplicationContext not being call=
ed
>
>
>Keith,
>=20
>This was caused by the fact that ApplicationContextAware was being proce=
ssed after the underlying bean factory finished its work, on demand in ge=
tBean calls to the application context. I've completely reworked this for=
 1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also =
internally used for processing ApplicationContextAware beans, to be appli=
ed when the underlying bean factory creates any kind of bean.
>=20
>So as of 1.0 M2, to be released tomorrow, this should work properly in a=
ll cases. If there should be any remaining issues, please report them aga=
inst 1.0 M2. If you're eager, you can also try a CVS snapshot today.
>=20
>Juergen
>=20
>=20
>
>	-----Urspr=C3=BCngliche Nachricht-----=20
>	Von: Keith Donald [mailto:kd...@cs...]=20
>	Gesendet: Di 21.10.2003 19:50=20
>	An: spr...@li...=20
>	Cc:=20
>	Betreff: [Springframework-user] setApplicationContext not being called
>=09
>=09
>
>	Forgive me if this issue has already been addressd.  It appears
>	setApplicationContext(ApplicationContext) is not being called on my
>	ApplicationContextAware prototype beans that are not directly instantia=
ted
>	by a call to beanFactory.getBean(beanName), but rather are wired "child=
"
>	beans instantiated as a result of a <bean ref> references from a parent
>	prototype.
>=09
>	To give you an example of what I mean:
>=09
>	        // parent prototype
>	        <bean      id=3D"sessionVisualizerPage"
>	                class=3D"com.csi.cogids.console.SessionVisualizerPage"
>	            singleton=3D"false">
>	          <property name=3D"queryNavigator"><ref
>	bean=3D"queryNavigator"/></property>
>	     </bean>
>=09
>	        // child prototype
>	    <bean       id=3D"queryNavigator"
>	             class=3D"com.csi.cogids.console.query.QueryNavigator"
>	         singleton=3D"false"
>	       init-method=3D"initialize">
>	      <property name=3D"newQueryAction"><ref
>	bean=3D"newQueryAction"/></property>
>	      <property name=3D"newGroupAction"><ref
>	bean=3D"newGroupAction"/></property>
>	    </bean>
>=09
>	A sessionVisualizerPage prototype gets instantiated when the page is lo=
aded
>	in my application.  The queryNavigator prototype also gets instantiated
>	because of the <bean ref>.  setApplicationContext() IS called on
>	sessionVisualizerPage, but not on QueryNavigator, even though both are
>	ApplicationContextAware for message lookups.
>=09
>	Thanks,
>	Keith
>=09
>	Keith Donald
>	Senior Software Engineer
>	kd...@cs...
>	321-676-2923 x403
>=09
>

Re: [Springframework-developer] Attributes

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

I did, Fri. morning if I remember. Then my DSL went down before I could 
post the message below...

If you have the libs in the ant classpath, you should just be able to 
remove them and still have the build work for you.

Rod Johnson wrote:

>Sounds great. I'm all for this change. Would you like to commit it?
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Monday, January 05, 2004 5:06 PM
>Subject: Re: [Springframework-developer] Attributes
>
>
>  
>
>>A few days ago I changed the build to make the taskdef for the attribute
>>compiler use a classpath to bring in these needed jars, instead of
>>relying on the user to add them to the ant lib dir.
>>
>>Generally it can cause complications/problems to add libs directly to
>>the ant lib dir, and best avoided if at all possible. For example, if
>>you add xjavadoc.jar there, then you have to add all the other xdoclet
>>modules there as well, if you want to use xdoclet elsewhere.
>>
>>There seem to be no issues with this approach, with both ant 1.6 and
>>    
>>
>1.5...
>  
>
>>Rod Johnson wrote:
>>
>>    
>>
>>>The tests now depend on a Commons Attributes precompile step. However,
>>>      
>>>
>this
>  
>
>>>doesn't take very long at all as it applies only to one package.
>>>
>>>However, you will need to put the following files in your $ANT_HOME/lib
>>>      
>>>
>to
>  
>
>>>get the tests to run:
>>>
>>>- Commons Attributes compiler Jar (in CVS)
>>>- commons-collections.jar (in CVS)
>>>- xjavadoc.jar (from XDoclet project). I'm not sure whether to put this
>>>      
>>>
>in
>  
>
>>>CVS as none of our code uses it. Thoughts?
>>>
>>>For now, I've named the attributes-dependent test case so that Eclipse
>>>      
>>>
>won't
>  
>
>>>pick up. I'll change this when I get time so that the build is also
>>>triggered under Eclipse.
>>>
>>>Regards,
>>>Rod
>>>
>>>
>>>      
>>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: IBM Linux Tutorials.
>>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
>>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Attributes

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

Sounds great. I'm all for this change. Would you like to commit it?

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, January 05, 2004 5:06 PM
Subject: Re: [Springframework-developer] Attributes


> A few days ago I changed the build to make the taskdef for the attribute
> compiler use a classpath to bring in these needed jars, instead of
> relying on the user to add them to the ant lib dir.
>
> Generally it can cause complications/problems to add libs directly to
> the ant lib dir, and best avoided if at all possible. For example, if
> you add xjavadoc.jar there, then you have to add all the other xdoclet
> modules there as well, if you want to use xdoclet elsewhere.
>
> There seem to be no issues with this approach, with both ant 1.6 and
1.5...
>
>
> Rod Johnson wrote:
>
> >The tests now depend on a Commons Attributes precompile step. However,
this
> >doesn't take very long at all as it applies only to one package.
> >
> >However, you will need to put the following files in your $ANT_HOME/lib
to
> >get the tests to run:
> >
> >- Commons Attributes compiler Jar (in CVS)
> >- commons-collections.jar (in CVS)
> >- xjavadoc.jar (from XDoclet project). I'm not sure whether to put this
in
> >CVS as none of our code uses it. Thoughts?
> >
> >For now, I've named the attributes-dependent test case so that Eclipse
won't
> >pick up. I'll change this when I get time so that the build is also
> >triggered under Eclipse.
> >
> >Regards,
> >Rod
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Attributes

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

A few days ago I changed the build to make the taskdef for the attribute 
compiler use a classpath to bring in these needed jars, instead of 
relying on the user to add them to the ant lib dir.

Generally it can cause complications/problems to add libs directly to 
the ant lib dir, and best avoided if at all possible. For example, if 
you add xjavadoc.jar there, then you have to add all the other xdoclet 
modules there as well, if you want to use xdoclet elsewhere.

There seem to be no issues with this approach, with both ant 1.6 and 1.5...


Rod Johnson wrote:

>The tests now depend on a Commons Attributes precompile step. However, this
>doesn't take very long at all as it applies only to one package.
>
>However, you will need to put the following files in your $ANT_HOME/lib to
>get the tests to run:
>
>- Commons Attributes compiler Jar (in CVS)
>- commons-collections.jar (in CVS)
>- xjavadoc.jar (from XDoclet project). I'm not sure whether to put this in
>CVS as none of our code uses it. Thoughts?
>
>For now, I've named the attributes-dependent test case so that Eclipse won't
>pick up. I'll change this when I get time so that the build is also
>triggered under Eclipse.
>
>Regards,
>Rod
>  
>

Re: [Springframework-developer] 1.0 M4 ready for release

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

Unfortunately for unexplained reasons my DSL connectivity was cut for 3=20
days, right after I updated to the new release candidate code on Friday=20
morning. Just wanted to let you know I had/have no issues with the new co=
de.


j=FCrgen h=F6ller [werk3AT] wrote:

>Last chance for any last minute feedback... the M4 release is just aroun=
d the corner (to be released today).
>=20
>Has anybody tried deploying the sample apps, particularly JPetStore, and=
 had problems? Note that JPetStore can also be built for Commons Attribut=
es ("attributes" directory), allows to choose between the Spring and the =
Struts web tier in web.xml, and has a demo remote client ("client" direct=
ory).
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n j=FCrgen h=F6ller [werk3AT]
>Gesendet: Fr 02.01.2004 01:22
>An: spr...@li...
>Betreff: [Springframework-developer] 1.0 M4 ready for release
>
>
>
>Hi everybody,
>
>First of all, a happy new year! It's been a great year 2003, particularl=
y considering that the Spring Framework project didn't even exist 12 mont=
hs ago (we'll celebrate first birthday in February). Of course, the frame=
work version that came with Rod's book was already there: But we've seen =
massive refinement of the framework since, even exploring completely new =
areas like AOP support and transaction management, and have attracted a s=
ignificant number of users (with about 3000 downloads per release since 1=
.0 M1). I'd like to thank everybody for their contributions, no matter wh=
at kind, in what area, and to what extent!
>
>I've just finished my preparations of our upcoming release 1.0 M4. In go=
od old Spring Framework tradition, a last minute change in the core has s=
neaked in: I've introduced the core.io package with its Resource interfac=
e and out-of-the-box implementations ClassPathResource, FileSystemResourc=
e, etc. It's used in the BeanDefinitionRegistry area, and also for all fo=
rmer "configLocation" Strings - they are all of type Resource now. Thanks=
 to an automatically registered PropertyEditor, specifying String paths i=
n bean definitions works just like before, but the receiving beans do not=
 have to be ApplicationContextAware anymore to be able to resolve resourc=
e locations in a generic way.
>
>As most people have already found out, 1.0 M4 introduces our version of =
Clinton Begin's JPetStore, with a Spring-managed middle tier that leverag=
es our new iBATIS Database Layer integration, and alternative Spring Web =
MVC and Struts web tiers. A recent addition is remoting support: The out-=
of-the-box JPetStore illustrates remoting via Hessian, Burlap, RMI, and o=
ur new JAX-RPC support via Axis. Like Clinton's original version did with=
 Axis, we export an OrderService. An included OrderServiceClient invokes =
the OrderService to show an order by number, via all configured protocols=
. This should work without hassle via the included Ant scripts and the re=
adme.
>
>I'll release 1.0 M4 tomorrow night, sort of a new year's present for the=
 Spring community ;-) Everybody who has some time left, please give the c=
urrent CVS contents a try, particularly "playing user": Generate a releas=
e zip, unzip it, build the samples, deploy the samples. Note that as of 1=
.0 M4, there are two release zips: "spring-framework-1.0-m4" with everyth=
ing but third-party libraries (~8 MB), and "spring-framework-1.0-m4-with-=
dependencies" which includes all libraries that are required for building=
 the samples and the framework itself (~16.8 MB). Both distributions ship=
 with build scripts and all sources and tests.
>
>Regards,
>Juergen
> =20
>