|
From: Colin S. <col...@ex...> - 2004-11-12 14:28:36
|
I've looked briefly through the old getBeansOfType code, but don't have time now to actually figure out why there was no problem before. My guess is that getBeansOfType was broken for prototypes or something of that nature, and Juergen actually fixed that functionality as part of the changes. I've just changed refreshListeners() to not include prototypes, as I can't see how this would ever ben correct. This should resolve the problem. Colin Sampaleanu wrote: > The code in AbstractApplicationContext.refreshListeners() definitely > looks suspect; as you say it does a getBeansOfType(), and includes > prototypes via a true flag for that param. But looking back, this code > has been that way since the 1.0.2 days at least. However it looks like > Juergen changed getBeansOfType() in DefaultListableBeanFactory, a couple > of times in October. I'm looking into that... > <br> > <br> > <br>Keith Donald wrote: > <br> > <br><blockquote type=cite>I am seeing some odd behavior with Spring > prototypes that are also > ApplicationListeners in the latest snapshot. > <br> > <br> > <br> > <br>Specifically, the context seems to be PRE instantiating and > registering prototype instances that are application listeners (via a > getBeansOfType call), even if no request for instantiation was > made. > Also, later requests for a new prototype result in that prototype not > being registered as an application listener for the instantiating context. > <br> > <br> > <br> > <br>This is not the behavior I expected! I was under the > assumption beans > instantiated by the container that are application listeners would be > auto-registered with the context after instantiation, as a post > process activity. Thoughts? Keith > <br> > <br></blockquote> > <br> |