cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Problems with http conduit declared in OSGi spring configuration
Date Mon, 06 May 2013 19:22:05 GMT

On May 6, 2013, at 12:48 PM, geecxf <> wrote:

> There's something about the logic of that explanation that does not make
> sense to me (though I'll readily admit that may very well be due to my
> ignorance on the matter).
> You say that the bundle might be picking up the wrong bus. But why would the
> bundle pick up the right bus on a restart? Why would it pick up the right
> bus if I deliberately load the configuration through the bundle context?
> When I step through the code, there's only one bus.

If there is not a bus available in whatever the current context is (blueprint, spring, etc…)
that would then have it injected, many of the API's call BusFactory.getThreadDefaultBus()
(which may, in turn, call getDefaultBus()).   In that case, if some other bundle or some other
event had triggered the creation of a Bus, it may get that bus instead.   

On a restart, things may just be happening in a different order (or in parallel, that's somewhat
important as blueprint will start bundles in parallel by default.  In that case, could be

> What is evident from debugging the code is that the conduit is created AFTER
> the client calls are made, after the WebClient is created, after the init
> method that contains the client code is executed, and after the bean that
> contains that init method is instantiated. It's clearly a timing issue and
> probably one that is easy to reproduce by simply creating a bean with an
> init method that uses an http conduit declared in the same Spring
> configuration file.

No, because you cannot create a HTTPConduit object in Spring.  http:conduit is abstract. 
   Spring does not create them.

> Is there any insight at all on the order of execution of these things? Are
> beans in a Spring configuration file created before or after the cxf
> configuration beans are processed?

Again, this is not something I've (or apparently others) have seen before.   If you are unwilling
to create a simple test case to show the problem, I'm not sure how much more we can help.
  You'll need to dig into the code to figure things out.   Only thing I can suggest is a breakpoint
in org.apache.cxf.configuration.spring.ConfigurerImpl to which conduits are being configured
and which ApplicationContext is being used for that.

Daniel Kulp -
Talend Community Coder -

View raw message