What seems to be the issue is that the BusExtensionPostProcessor isn't being properly registered or called. If you look in there in the postProcessBeforeInitialization call, it SHOULD be calling getBus() which then would register a SpringBeanLocator which is what is used when you call bus.getExtension(....) to find the appropriate Spring bean.
Can you put a breakpoint in there and make sure it's properly being hit and registered? I'm almost wondering if there is a second Bus being created someplace and that second bus is being picked up in some places, but that one isn't getting the SpringBeanLocator set. Hmm... I wondering if the line: bus = (Bus)context.getBean(Bus.DEFAULT_BUS_ID); should be changed to something like context.getBeanNamesForType(Bus.class) to make sure all the "Bus" beans are grabbed. Anyway, if you could either try that or provide a debuggable test case, that would be great. Dan On Monday 22 November 2010 12:43:44 pm Stephane Nicoll wrote: > Yes, the lazy init in the Spring beans since 2.3.0 does seem to > introduce a set of regressions. For instance, > this is the declaration of the faulty bean: > > <bean id="org.apache.cxf.phase.PhaseManager" > class="org.apache.cxf.phase.PhaseManagerImpl" > lazy-init="true"/> > > The difference with other extensions is that PhaseManagerImpl does NOT > need the bus so it has not constructor argument. What happens is the > lazy init does not force the object to be created and it's not added > as an extension. If I copy/paste the bean above in my project with > lazy-init to false, I don't have the NPE anymore but something else: > > "Could not find conduit initiator for transport > http://schemas.xmlsoap.org/soap/http"; > > Looking at it a bit deeper it seems again an initialization issue. > > I have tried the workaround you are suggesting and I got this > > org.apache.cxf.transport.http_jetty.JettyHTTPServerEngineFactory': > Cannot resolve reference to bean 'cxf' while setting constructor > argument; nested exception is > org.springframework.beans.factory.NoSuchBeanDefinitionException: No > bean named 'cxf' is defined > > Are these issues tracked somewhere in Jira. I initially thought that I > was the only one having them because of my setup but given the > workaround provided in your link, it seems something need to be fixed > in CXF itself. > > Thanks, > Stéphane > > On Mon, Nov 22, 2010 at 3:46 PM, Marco Zapletal > > <[email protected]> wrote: > > On 22.11.2010 14:57, Stephane Nicoll wrote: > >> On Mon, Nov 15, 2010 at 1:53 AM, Willem Jiang<[email protected]>wrote: > >>> On 11/12/10 6:51 PM, Stephane Nicoll wrote: > >>>> On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang<[email protected] > >>>> > >>>>> wrote: > >>>> If you put the cxf-servlet here, The ServletTransportFactory will > >>>> replace > >>> > >>> all registered transportIds with itself, that could explain why you > >>> can't find the JettyTransportFactory here. > >>> > >>> If you are using the servlet transport, please don't include other http > >>> related transport. > >> > >> Okay this works better but now I am getting another weird issue in > >> another test. I got a NullPointerException on the PhaseManager. This is > >> the code in ClientImpl: > >> > >> PhaseManager pm = bus.getExtension(PhaseManager.class); > >> > >> The returned pm instance is null which leads to a NPE latter > >> (setupInterceptorChain). I searched where this phase manager was defined > >> and it is in cxf.xml which I obviously import. > >> > >> I tried to build a sample that could run with CXF without our extensions > >> but it's quite hard so if you can help me debugging this I would > >> appreciate it. > > > > this seems to be similar to the problem I had. Willem posted a workaround > > on the camel mailing list. > > > > http://camel.465427.n5.nabble.com/camel-cxf-exception-when-parsing-cxf-sc > > hemaLocation-element-td3253254i20.html > > > > regards, > > marco -- Daniel Kulp [email protected] http://dankulp.com/blog
