On Jun 15, 2014, at 7:23 AM, Jason Pell <[email protected]> wrote: > Optimization to only load the first extension found when only one is > asked for. > > Broke some code our project uses. We are overriding the > JettyHTTPServerEngineFactory with our own extended one. And because the > ConfiguredBeanLocator would return our bean first in the getBeansOfType > call we were able to successfully override JettyHTTPServerEngineFactory > with our own. > > With the change in 2.7.12-SNAPSHOT to always look for a bean of a specific > name first, our override never gets a look in. > > I have worked around it by naming our overridden > JettyHTTPServerEngineFactory bean the same as the one included by cxf > itself, so it again gets to be the chosen extension. > > But I was curious as to why this change was made.
The primary reason was to make sure we’re not loading a bunch of things that we know will never be used. Basically, lower the memory footprint and make startup a little bit faster. For example, we now have two different HTTPConduitFactory implementations. With the old behavior, BOTH were being loaded, but only the first one (maybe, more on that in a sec) actually registered as an extension and thus the second was was loaded, held onto by the extension object, possibly consuming threads for its thread pool and such, lifecycle listeners created/added/called, but not actually used. The change made sure only one is loaded. Related notes: In SOME cases, it wasn’t the first one that was used, it was the last one. That was really bizarre as it was supposed to be the first. Definitely trying to make things more predictable and consistent. There were a couple of race conditions in the code as well. This was the source of a lot of the random failures in the systests/ws-rm. If two (or more) threads requested the RMManager at the same time, they were getting different instances and thus the maps of sequence ID’s didn’t line up and such. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
