Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
MIME-Version: 1.0
In-Reply-To: <3A5E1E65-F1E6-4F6C-8524-7D5EFF31C2A3@pronoia-solutions.com>
References: <B4344B88-45FA-4123-B911-5350A9C40C72@pronoia-solutions.com>
	<56B075BF.7070402@die-schneider.net>
	<05311D92-7219-46F7-8A48-1759DF332642@pronoia-solutions.com>
	<56B113A3.8030200@die-schneider.net>
	<F3F2AA8E-4F40-4D62-BD94-FAE03ED1D49F@pronoia-solutions.com>
	<56B12A73.4030002@die-schneider.net>
	<02A02F2C-8679-4356-BBEE-1634701B68BF@pronoia-solutions.com>
	<CAH6_LNmBhyWc=O4HXAQXcBhkuOYkQbed+akj-5+2FGNEOmd5_w@mail.gmail.com>
	<3A5E1E65-F1E6-4F6C-8524-7D5EFF31C2A3@pronoia-solutions.com>
Date: Fri, 5 Feb 2016 15:10:14 -0600
Message-ID: 
 <CAA8i-pbtcQsueGtw+jaXY=j6=_YyC8vjLLWgc0bGJtMuo+G1hA@mail.gmail.com>
Subject: Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
From: Brad Johnson <brad.johnson@mediadriver.com>
To: users@camel.apache.org
Content-Type: multipart/alternative; boundary=001a114a97f6037083052b0c472b

--001a114a97f6037083052b0c472b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Quinn,

If you wouldn't mind putting a reference in there as a "may be related to"
the other issue that would be great.  There shouldn't be a reason in an
OSGi environment for any classloaders grabbing concrete implementations
from other bundles and the current Camel classloader mechanics explicitly
use that reach around when they can't find what they are looking for. It
may be a different bug but ultimately that loophole has to be closed.

Brad

On Fri, Feb 5, 2016 at 3:01 PM, Quinn Stevenson <quinn@pronoia-solutions.co=
m
> wrote:

> OK - I=E2=80=99ve created an new JIRA issue describing what I=E2=80=99m s=
eeing.
> https://issues.apache.org/jira/browse/CAMEL-9570 <
> https://issues.apache.org/jira/browse/CAMEL-9570>
>
>  I=E2=80=99ll extract some samples from my projects and add them to the t=
icket
> shortly.
>
>
> > On Feb 3, 2016, at 12:05 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
> >
> > I would use a new issue that just explains what happens without trying =
to
> > interpret. We do not yet know what really happens but I hope we can fin=
d
> > out.
> >
> > Christian
> >
> > 2016-02-03 3:40 GMT+01:00 Quinn Stevenson <quinn@pronoia-solutions.com>=
:
> >
> >> I would expect the CamelContext to keep trying to run as well, but I
> >> expected it to hit the call to the OSGi service, block, and then timeo=
ut
> >> and throw a ServiceUnavailableException.  But what I=E2=80=99m seeing =
is the
> call
> >> to the OSGi service is completing (it=E2=80=99s basically and echo ser=
vice right
> >> now), and continues to complete.  My test route is driven by a timer,
> and
> >> it will continue to log calls to the OSGi service even when the bundle
> >> providing the service has been stopped.
> >>
> >> I checked and made sure I didn=E2=80=99t have any other bundles provid=
ing the
> >> service.
> >>
> >> The really strange part to me is just injecting what should be the
> service
> >> proxy into the RouteBuilder results in a route that isn=E2=80=99t usin=
g
> Blueprint
> >> service proxies.  I=E2=80=99ve changed the route to use the bean compo=
nent,
> which
> >> works as I=E2=80=99d expect as long as I don=E2=80=99t inject the bean=
 into the route
> >> builder.
> >>
> >> I was going to put some samples in the JIRA issue that was created for
> >> this - is that still the right place?  Or do we need a different JIRA
> issue?
> >>
> >>> On Feb 2, 2016, at 3:15 PM, Christian Schneider <
> chris@die-schneider.net>
> >> wrote:
> >>>
> >>> On 02.02.2016 23:08, Quinn Stevenson wrote:
> >>>> Christian -
> >>>>
> >>>> I don=E2=80=99t know about a class loader issue, but I do know when =
I run the
> >> route configured as you have it below, I=E2=80=99m not getting a proxy=
 to the
> >> service.  I know this because if I stop the bundle containing the OSGi
> >> service, the Camel context keeps running - I don=E2=80=99t get a
> >> ServiceUnavailableException after the timeout.  In fact, it keeps usin=
g
> >> whatever is injected into the RouteBuilder.
> >>>>
> >>>> I think that=E2=80=99s where the class loader thing came from - it a=
ppear to
> be
> >> using the implementation of the service directly - not via a Blueprint
> >> proxy.
> >>>>
> >>>>
> >>> It is normal that the camel context keeps running as blueprint uses
> >> service damping. So the proxy should remain the same when the service
> goes
> >> away or changes.
> >>> I would expect the service call to block and return
> >> ServiceUnavailableException after the blueprint service timeout though
> in
> >> case there is no service.
> >>>
> >>> Sounds quite strange.
> >>>
> >>> Can you check in karaf using the service:list command that there is
> >> really no Echo service running anymore?
> >>>
> >>> Christian
> >>>
> >>> --
> >>> Christian Schneider
> >>> http://www.liquid-reality.de
> >>>
> >>> Open Source Architect
> >>> http://www.talend.com
> >>>
> >>
> >>
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> > <
> https://owa.talend.com/owa/redir.aspx?C=3D3aa4083e0c744ae1ba52bd062c5a7e4=
6&URL=3Dhttp%3a%2f%2fwww.liquid-reality.de
> >
> >
> > Open Source Architect
> > http://www.talend.com
> > <
> https://owa.talend.com/owa/redir.aspx?C=3D3aa4083e0c744ae1ba52bd062c5a7e4=
6&URL=3Dhttp%3a%2f%2fwww.talend.com
> >
>
>

--001a114a97f6037083052b0c472b--