Dan, as you suggested, I put various break points in
org.apache.cxf.configuration.spring.ConfigurerImpl. What I discovered is
that if I put my cxf HTTPConduit definitions in the main spring
configuration, when configureBean() is called the application context is in
a different bundle than expected.

To make the scenario more concrete lets say that I have two bundles:
1. A "producer" bundle that creates a cxf bus for the purpose of hosting web
services that are registered with our platform.
2. A "consumer" bundle (at a higher run level) that launches clients which
consume services that the "producer" bundle manages.

What is happening is that when configureBean() is called for HTTPConduits
that are declared in the spring configuration file of the "consumer" bundle
the application context is the "producer" bundle.

However, if I modify the "consumer" bundle to load the configuration from a
separate configuration file in a bundle and application context aware class
like so:

        String[] configs = new String[]
        {
            "classpath:META-INF/spring/cxf-context.xml" //$NON-NLS-1$
        };
        OsgiBundleXmlApplicationContext appContext = new
OsgiBundleXmlApplicationContext(configs,
                AuthConsumer.applicationContext);
        appContext.setBundleContext(AuthConsumer.bundleContext);
        appContext.refresh();

Then whenever configureBean() is called the application context is in the
"consumer" bundle as expected.

I hope I am making myself clear since this is confusing to explain. I also
hope it helps explain what is going on well enough that you or someone else
can think of some ways why this is happening and how to get around them.





--
View this message in context: 
http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727445.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to