Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: error (nike.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: Problems with http conduit declared in OSGi spring configuration
From: Daniel Kulp <dkulp@apache.org>
In-Reply-To: <1367858937601-5727299.post@n5.nabble.com>
Date: Mon, 6 May 2013 15:22:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E84BD5FD-61EE-4080-A949-5766DA22E526@apache.org>
References: <51818AFB.5050609@gmail.com>
 <1367851465349-5727282.post@n5.nabble.com> <5187C3CC.8010306@gmail.com>
 <1367852621523-5727286.post@n5.nabble.com>
 <095DF5A1-3C0C-44DC-9B63-CFA2E742A0F3@apache.org>
 <1367854342059-5727290.post@n5.nabble.com>
 <035BB967-C2EB-40D6-9440-316A93BEE843@apache.org>
 <5187D170.9070700@gmail.com> <1367856455329-5727294.post@n5.nabble.com>
 <3A4773AF-31DA-4D5F-A1CB-B90C25E34D56@apache.org>
 <1367858937601-5727299.post@n5.nabble.com>
To: users@cxf.apache.org,
 geecxf <amiri@ge.com>


On May 6, 2013, at 12:48 PM, geecxf <amiri@ge.com> 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).
>=20
> 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=85) 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.  =20

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 unpredicable).


> 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.


--=20
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com