plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Feinauer <j.feina...@pragmaticminds.de>
Subject Re: SPI Module - OSGi Bundle
Date Tue, 05 May 2020 10:34:34 GMT
Hi Etienne and Niclas,

indeed we could orient (again) on how JDBC does that in OSGi.
They really focus on "late binding" so that you resolve the driver directly when you need
it.
In theory, there is no such thing as a DriverManager in OSGi but only a PlcDriver with the
capability ("plc4x-protocol": "s7") or something.

I did it witht he driver maanger mostly fort he ease as first approach.

Julian

Am 05.05.20, 12:30 schrieb "Niclas Hedhman" <niclas@hedhman.org>:

    Also, just in case, a custom activator is ever required, it can be
    overridden easily without breaking the over all design

    On Tue, May 5, 2020 at 6:27 PM Niclas Hedhman <niclas@hedhman.org> wrote:

    > Yes, that's what I mean, because that is what you have inside the loop, so
    > it should work.
    >
    > On Tue, May 5, 2020 at 11:50 AM Robinet, Etienne <43823@etu.he2b.be>
    > wrote:
    >
    >> Hi Niclas,
    >> thanks for the feedback. So you mean to make the Activator in API/SPI
    >> generic so every Driver would call it and declare the service itself?
    >>
    >> Le mar. 5 mai 2020 à 05:25, Niclas Hedhman <niclas@hedhman.org> a écrit
:
    >>
    >> > What you are doing is not particularly OSGi-y... The expected way to do
    >> > this is to have each bundle register their PlcDriver or Transport to the
    >> > OSGi service registry.
    >> >
    >> > That said, what you have done is otherwise fine, as you basically
    >> trying to
    >> > centralize the BundleActivators away from respective Driver/Transport.
    >> And
    >> > I assume you do so to limit code in the drivers/transports.
    >> >
    >> > Another way would be to make two generic BundleActivator in this bundle
    >> and
    >> > have each driver/transport just declare them in the manifest. That
    >> would be
    >> > a bit more conventional.
    >> >
    >> > // Niclas
    >> >
    >> > On Tue, May 5, 2020 at 11:06 AM Robinet, Etienne <43823@etu.he2b.be>
    >> > wrote:
    >> >
    >> > > Hi all,
    >> > > With the change of Christofer this problem got solved. Nonetheless,
I
    >> > kept
    >> > > the work I did (inspired by the work of Lukasz) to make an Activator
    >> for
    >> > > API (Driver Services) and SPI (Transport Services). I also tested it,
    >> but
    >> > > as I am pretty new to this, if anyone could just give me a feedback
on
    >> > the
    >> > > code:
    >> > >
    >> > > API Activator:
    >> > >
    >> > >
    >> >
    >> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java
    >> > > SPI Activator:
    >> > >
    >> > >
    >> >
    >> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/spi/src/main/java/org/apache/plc4x/java/osgi/SpiActivator.java
    >> > >
    >> > > If everything is alright, I could merge this today.
    >> > >
    >> > > Etienne
    >> > >
    >> > > Le mar. 7 avr. 2020 à 17:52, Christofer Dutz <
    >> christofer.dutz@c-ware.de>
    >> > a
    >> > > écrit :
    >> > >
    >> > > > Hi folks,
    >> > > >
    >> > > > I just pushed a change that might get rid of this error.
    >> > > >
    >> > > > I added the Plc4xBootstrap in an attempt to get the TestTransport
    >> > > working.
    >> > > > For some reasons the netty folks created the EmbeddedChannel
    >> > differently
    >> > > > than the rest.
    >> > > > However as the TestTransport is the only one needing this change,
I
    >> > moved
    >> > > > these classes to the test-transport module
    >> > > > and extended NettyChannelFactory with a createBootstrap method
    >> which is
    >> > > > simply overridden in TestTransport.
    >> > > >
    >> > > > So please give everything a try if it now works as planned.
    >> > > >
    >> > > > Chris
    >> > > >
    >> > > >
    >> > > >
    >> > > > Am 07.04.20, 17:36 schrieb "Etienne Robinet" <43823@etu.he2b.be>:
    >> > > >
    >> > > >     Hi all,
    >> > > >     I’ve checked the Manifest. If I put the Embed-Dependency
to the
    >> > > > plc4j-spi artifact  it does not find the Transport Service. And
if I
    >> > dont
    >> > > > it does not find the Plc4xBootstrap.
    >> > > >
    >> > > >     Etienne ROBINET
    >> > > >
    >> > > >     > Le 7 avr. 2020 à 16:48, Łukasz Dywicki <luke@code-house.org>
    >> a
    >> > > > écrit :
    >> > > >     >
    >> > > >     > I was updating my local checkout yesterday. Can't promise
if I
    >> > will
    >> > > > be
    >> > > >     > able to help, but will give a try with 0.7 snapshot.
    >> > > >     >
    >> > > >     > Best,
    >> > > >     > Łukasz
    >> > > >     >
    >> > > >     >
    >> > > >     >> On 07.04.2020 15:39, Etienne Robinet wrote:
    >> > > >     >> Hi again,
    >> > > >     >> I've been looking at this issue all day, and I am
back to the
    >> > > > initial error:
    >> > > >     >> https://i.imgur.com/LLfan8H.png
    >> > > >     >>
    >> > > >     >> The difference is I used and Activator for API and
SPI to
    >> > register
    >> > > > the driver and transports Service, which are then loaded by the
    >> custom
    >> > > > blueprint. The error now is caused again because this class is
not
    >> > > exported
    >> > > > (I think?) by the SPI, but is used by one of the dependency
    >> (io.netty).
    >> > > >     >> Any ideas on how to solve this?
    >> > > >     >>
    >> > > >     >> Etienne
    >> > > >     >>
    >> > > >     >>> On 2020/04/07 06:53:54, Etienne Robinet <
    >> erobinet@apache.org>
    >> > > > wrote:
    >> > > >     >>> Hi all,
    >> > > >     >>> the faulty ClassLoader is the
    >> > > > BundleDelegatingClassLoader(plc4x-test [191]). Which means that
the
    >> > > custom
    >> > > > bundle can not find the class right?
    >> > > >     >>>
    >> > > >     >>> I'm sorry if it's a silly question but I am pretty
new to
    >> this.
    >> > > >     >>>
    >> > > >     >>> Etienne
    >> > > >     >>>
    >> > > >     >>> On 2020/04/06 20:28:17, Łukasz Dywicki <luke@code-house.org
    >> >
    >> > > > wrote:
    >> > > >     >>>> I haven't used Camel for a while, but to
me it seems to be
    >> a
    >> > > > problem
    >> > > >     >>>> caused by caller's classloader.
    >> > > >     >>>>
    >> > > >     >>>> See that in stack trace you have a thread
which is started
    >> by
    >> > > > camel, so
    >> > > >     >>>> there are 3 or even 4 classloaders to be
considered:
    >> > > >     >>>> - plc4x, definitely not a faulty one
    >> > > >     >>>> - netty, could be troublesome but unlikely
to be used
    >> > > >     >>>> - camel-core, or component itself
    >> > > >     >>>> - custom bundle which started the route
    >> > > >     >>>>
    >> > > >     >>>> Anything beside last one which knows all
the dependencies
    >> will
    >> > > > blow up
    >> > > >     >>>> whole universe. Here is why - only the custom
bundle knows
    >> all
    >> > > the
    >> > > >     >>>> dependencies necessary to run logic and can
be used to fix
    >> > > messed
    >> > > > up
    >> > > >     >>>> classpath. In most of the cases, that's the
"trick" you
    >> have
    >> > to
    >> > > > make in
    >> > > >     >>>> order to get OSGi happy.
    >> > > >     >>>> Camel component may not, and should not depend
on specific
    >> > > driver,
    >> > > >     >>>> however in your case it does. Possibly due
to new APIs in
    >> > > > transport
    >> > > >     >>>> layer its shouldn't be used for adhoc fixes.
    >> > > >     >>>>
    >> > > >     >>>> We can try to turn drivers into services
(see here
    >> > > >     >>>>
    >> > > >
    >> > >
    >> >
    >> https://github.com/splatch/plc4x/commit/5ce379cf8d2f5dc91fdfb6d8a8e2c0531906e69f
    >> > > > )
    >> > > >     >>>> in order to cut concrete class dependency
and rely on
    >> isolated
    >> > > > APIs.
    >> > > >     >>>> This code was done before new abstractions
over netty were
    >> > > > introduced,
    >> > > >     >>>> but it should cut in half API and caller
side (not sure if
    >> > we're
    >> > > > on
    >> > > >     >>>> declarative services).
    >> > > >     >>>>
    >> > > >     >>>> My tip to you Etienne - please verify which
class loader is
    >> > used
    >> > > > in your
    >> > > >     >>>> polling cycle. You can do that by making
breakpoint in
    >> faulty
    >> > > > method of
    >> > > >     >>>> S7Driver and evaluating expression
    >> > > >     >>>> "Thread.currentThread().getContextClassLoader()".
    >> > > >     >>>> Once you know that you can either fix classloading
in the
    >> > > calling
    >> > > > class
    >> > > >     >>>> loader or override classloader for thread
to proper one.
    >> > > >     >>>>
    >> > > >     >>>> Best,
    >> > > >     >>>> Łukasz
    >> > > >     >>>>
    >> > > >     >>>>
    >> > > >     >>>> On 03.04.2020 10:27, Etienne Robinet wrote:
    >> > > >     >>>>> Hi Christian,
    >> > > >     >>>>> you mean the code used in the Camel route?
It is an
    >> > blueprint:
    >> > > >     >>>>>
    >> > > >     >>>>> <?xml version="1.0" encoding="UTF-8"?>
    >> > > >     >>>>> <blueprint xmlns="
    >> http://www.osgi.org/xmlns/blueprint/v1.0.0
    >> > "
    >> > > >     >>>>>           xmlns:xsi="
    >> > http://www.w3.org/2001/XMLSchema-instance
    >> > > "
    >> > > >     >>>>>           xsi:schemaLocation= "
    >> > > > http://www.osgi.org/xmlns/blueprint/v1.0.0
    >> > > > https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
    >> > > >     >>>>>            http://camel.apache.org/schema/blueprint
    >> > > > http://camel.apache.org/schema/blueprint/camel-blueprint-2.24.2.xsd
    >> ">
    >> > > >     >>>>>
    >> > > >     >>>>>
    >> > > >     >>>>>    <camelContext id="PLC-IoTDB" xmlns="
    >> > > > http://camel.apache.org/schema/blueprint" streamCache="true" >
    >> > > >     >>>>>        <route id="plc-route" >
    >> > > >     >>>>>            <from
    >> > > > uri="timer://plcFetch?fixedRate=true&period=1000"/>
    >> > > >     >>>>>            <pollEnrich>
    >> > > >     >>>>>                <simple>plc4x:s7:tcp://
    >> > > > 192.168.178.10?address=#fields</simple>
    >> > > >     >>>>>            </pollEnrich>
    >> > > >     >>>>>            <log message="${body}"/>
    >> > > >     >>>>>            <to uri="mock:test?retainLast=10"/>
    >> > > >     >>>>>        </route>
    >> > > >     >>>>>    </camelContext>
    >> > > >     >>>>>
    >> > > >     >>>>>
    >> > > >     >>>>>    <bean id="fields" class="java.util.ArrayList">
    >> > > >     >>>>>        <argument>
    >> > > >     >>>>>            <list>
    >> > > >     >>>>>               <bean
    >> class="org.apache.plc4x.camel.TagData">
    >> > > >     >>>>>                   <argument index="0"
value="IntTest"/>
    >> > > >     >>>>>                   <argument index="1"
    >> > value="%DB1.DBW254:INT"/>
    >> > > >     >>>>>               </bean>
    >> > > >     >>>>>               <bean
    >> class="org.apache.plc4x.camel.TagData">
    >> > > >     >>>>>                   <argument index="0"
value="StringTest"/>
    >> > > >     >>>>>                   <argument index="1"
    >> > > value="%DB1.DBX0:STRING"/>
    >> > > >     >>>>>               </bean>
    >> > > >     >>>>>            </list>
    >> > > >     >>>>>        </argument>
    >> > > >     >>>>>    </bean>
    >> > > >     >>>>> </blueprint>
    >> > > >     >>>>>
    >> > > >     >>>>> This code used to wrok actually, I just
wanted to test the
    >> > new
    >> > > > TagData of the integration. This is the bundling in the pom, these
    >> > > imports
    >> > > > had to be there before too
    >> > > >     >>>>>
    >> > > >     >>>>> <plugin>
    >> > > >     >>>>>                <groupId>org.apache.felix</groupId>
    >> > > >     >>>>>
    >> <artifactId>maven-bundle-plugin</artifactId>
    >> > > >     >>>>>                <version>4.2.1</version>
    >> > > >     >>>>>                <extensions>true</extensions>
    >> > > >     >>>>>                <configuration>
    >> > > >     >>>>>                    <instructions>
    >> > > >     >>>>>
    >> > > > <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
    >> > > >     >>>>>
    >> > > > <Bundle-Version>${project.version}</Bundle-Version>
    >> > > >     >>>>>                        <Export-Package>
    >> > > >     >>>>>                           *;version=${project.version}
    >> > > >     >>>>>                        </Export-Package>
    >> > > >     >>>>>                        <Import-Package>
    >> > > >     >>>>>
    >> > org.apache.plc4x.java.spi.transport,
    >> > > >     >>>>>
    >> > org.apache.plc4x.java.s7.readwrite,
    >> > > >     >>>>>                            *
    >> > > >     >>>>>                        </Import-Package>
    >> > > >     >>>>>                    </instructions>
    >> > > >     >>>>>                </configuration>
    >> > > >     >>>>>            </plugin>
    >> > > >     >>>>>
    >> > > >     >>>>>
    >> > > >     >>>>> Etienne
    >> > > >     >>>>>
    >> > > >     >>>>> On 2020/04/03 08:17:45, Christian Schneider
<
    >> > > > chris@die-schneider.net> wrote:
    >> > > >     >>>>>> The code in plc4x directly uses the
class (not a String
    >> of
    >> > the
    >> > > > name). This
    >> > > >     >>>>>> is good. Normally such a class reference
should work
    >> fine.
    >> > > >     >>>>>>
    >> > > >     >>>>>> Can you show your code as a complete
example?
    >> > > >     >>>>>>
    >> > > >     >>>>>> Christian
    >> > > >     >>>>>>
    >> > > >     >>>>>>
    >> > > >     >>>>>> Am Fr., 3. Apr. 2020 um 09:58 Uhr
schrieb Julian
    >> Feinauer <
    >> > > >     >>>>>> j.feinauer@pragmaticminds.de>:
    >> > > >     >>>>>>
    >> > > >     >>>>>>> I am off with my knowledge.
    >> > > >     >>>>>>> You could ask the Karaf friends
(#karaf in Slack). They
    >> are
    >> > > > all OSGi
    >> > > >     >>>>>>> experts and very friendly and
helpful.
    >> > > >     >>>>>>> Or perhaps Christian has an idea
here?
    >> > > >     >>>>>>>
    >> > > >     >>>>>>> Best
    >> > > >     >>>>>>> Julian
    >> > > >     >>>>>>>
    >> > > >     >>>>>>> Am 03.04.20, 09:50 schrieb "Etienne
Robinet" <
    >> > > > erobinet@apache.org>:
    >> > > >     >>>>>>>
    >> > > >     >>>>>>>    Hi again,
    >> > > >     >>>>>>>    I've been struggling with
this issue for 2 days
    >> now... I
    >> > > > still don't
    >> > > >     >>>>>>> get it why it can not find classes.
here is the current
    >> > > > problem:
    >> > > >     >>>>>>>    https://i.imgur.com/LtZMdsu.png
    >> > > >     >>>>>>>
    >> > > >     >>>>>>>    We can see that the classes
are available and
    >> exported,
    >> > I
    >> > > > don't know
    >> > > >     >>>>>>> why the Camel Context can't find
it. I even tried to
    >> add an
    >> > > > Activator to my
    >> > > >     >>>>>>> bundle, and load these classes
there and it works! But
    >> not
    >> > in
    >> > > > the
    >> > > >     >>>>>>> blueprint. If anyone had any
idea on where the problem
    >> > is...
    >> > > >     >>>>>>>
    >> > > >     >>>>>>>    Etienne
    >> > > >     >>>>>>>
    >> > > >     >>>>>>>    On 2020/04/01 01:31:15, Niclas
Hedhman <
    >> > > niclas@hedhman.org>
    >> > > > wrote:
    >> > > >     >>>>>>>> It happens that OSGi classloading
result in the wrong
    >> > NCDFE
    >> > > > and that
    >> > > >     >>>>>>> one of
    >> > > >     >>>>>>>> the classes "used" (i.e.
return type, parameter,
    >> throws,
    >> > > > extends,
    >> > > >     >>>>>>>> implements) in the reported
class is not visible by the
    >> > > > classloader.
    >> > > >     >>>>>>> And
    >> > > >     >>>>>>>> occasionally, it is a "diamond
problem", i.e. that the
    >> > > > Constraints
    >> > > >     >>>>>>> (IIRC,
    >> > > >     >>>>>>>> see chapter 3.8 in OSGi spec)
can't be satisfied.
    >> > > >     >>>>>>>>
    >> > > >     >>>>>>>> Sorry that I don't have time
to dig into the actual
    >> > > situation
    >> > > > here,
    >> > > >     >>>>>>> but I
    >> > > >     >>>>>>>> thought I could share some
of my past (dark)
    >> history....
    >> > ;-)
    >> > > >     >>>>>>>>
    >> > > >     >>>>>>>> Cheers
    >> > > >     >>>>>>>> Niclas
    >> > > >     >>>>>>>>
    >> > > >     >>>>>>>> On Wed, Apr 1, 2020 at 12:43
AM Christofer Dutz <
    >> > > >     >>>>>>> christofer.dutz@c-ware.de>
    >> > > >     >>>>>>>> wrote:
    >> > > >     >>>>>>>>
    >> > > >     >>>>>>>>> Hi all,
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>> But If I search for uses
of that class, it's only in
    >> the
    >> > > >     >>>>>>>>>
    >> org.apache.plc4x.java.spi.connection.NettyChannelFactory
    >> > > > which is
    >> > > >     >>>>>>> in the
    >> > > >     >>>>>>>>> SPI module.
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>> So I am not sure where
this is accessed directly from
    >> the
    >> > > > outside.
    >> > > >     >>>>>>> I know
    >> > > >     >>>>>>>>> every driver would use
the NettyChannelFactory, but
    >> that
    >> > > > shouldn't
    >> > > >     >>>>>>> be an
    >> > > >     >>>>>>>>> OSGi type problem as
the SPI classes should be able to
    >> > > access
    >> > > >     >>>>>>> their own
    >> > > >     >>>>>>>>> classes.
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>> Chris
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>> Am 31.03.20, 16:07 schrieb
"Etienne Robinet" <
    >> > > > 43823@etu.he2b.be>:
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>>    Hi,
    >> > > >     >>>>>>>>>    From the log the class
is called outside the SPI by
    >> > the
    >> > > >     >>>>>>> transport
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>>    Etienne
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>>> Le 31 mars 2020 à
15:24, Julian Feinauer <
    >> > > >     >>>>>>>>> j.feinauer@pragmaticminds.de>
a écrit :
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>> Hi,
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>> yes, if ist only
needed internally its fine.But why
    >> does
    >> > > >     >>>>>>> someone
    >> > > >     >>>>>>>>> then get a Class Not
Found Exception?
    >> > > >     >>>>>>>>>> This is usually a
hint to some class loader issue in
    >> > OSGi
    >> > > >     >>>>>>> which is
    >> > > >     >>>>>>>>> related to exports/ imports.
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>> J
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>> Am 31.03.20, 15:23
schrieb "Christofer Dutz" <
    >> > > >     >>>>>>>>> christofer.dutz@c-ware.de>:
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>   As this package
is only referenced from within SPI,
    >> > > >     >>>>>>> couldn't we
    >> > > >     >>>>>>>>> just exclude it from
the package exports?
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>   Chris
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>   Am 31.03.20, 15:17
schrieb "Julian Feinauer" <
    >> > > >     >>>>>>>>> j.feinauer@pragmaticminds.de>:
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>       Hi,
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>       the issue is
that if we export it, then we
    >> break
    >> > > >     >>>>>>> Nettys OSGi
    >> > > >     >>>>>>>>> integration as we get
a split package situation (two
    >> > > bundles
    >> > > >     >>>>>>> exporting the
    >> > > >     >>>>>>>>> same package, which is
forbidden in OSGi).
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>       So I see no
easy solution (but had to do the
    >> same
    >> > > >     >>>>>>> once as
    >> > > >     >>>>>>>>> Netty is pretty... private).
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>       J
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>       Am 31.03.20,
15:15 schrieb "Christofer Dutz" <
    >> > > >     >>>>>>>>> christofer.dutz@c-ware.de>:
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>           Hi all,
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>           I just
discussed this issue with Etienne
    >> and I
    >> > > >     >>>>>>> thought it
    >> > > >     >>>>>>>>> was important for all,
so I asked him to bring it
    >> here.
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>           In my effort
to get the EmbeddedChannel
    >> > working
    >> > > >     >>>>>>> as a full
    >> > > >     >>>>>>>>> "transport" module, I
had to override the Netty
    >> Bootstrap
    >> > > >     >>>>>>> mechanism.
    >> > > >     >>>>>>>>>>           Unfortunately
in order to do so, I need to
    >> > call
    >> > > >     >>>>>>> "init"
    >> > > >     >>>>>>>>> from the derived class.
Unfortunately this is package
    >> > > > private in
    >> > > >     >>>>>>> Netty so I
    >> > > >     >>>>>>>>> had
    >> > > >     >>>>>>>>>>           To add
it to the same package.
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>           Would it
help to just not export these
    >> > packages
    >> > > >     >>>>>>> to OSGi?
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>           But I'm
also open for alternatives (Please
    >> > none
    >> > > >     >>>>>>> involving
    >> > > >     >>>>>>>>> mega-evil reflection
hackery).
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>           Chris
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>           Am 31.03.20,
15:10 schrieb "Etienne
    >> Robinet" <
    >> > > >     >>>>>>>>> erobinet@apache.org>:
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>               Hi
all,
    >> > > >     >>>>>>>>>>               I've
been working on the Camel
    >> Component
    >> > and
    >> > > >     >>>>>>> decided
    >> > > >     >>>>>>>>> to test it inside Karaf,
but I noticed that I've got
    >> this
    >> > > > error
    >> > > >     >>>>>>> now:
    >> > > >     >>>>>>>>>>               https://i.imgur.com/kUZPwZ5.png
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>               Seems
like this class is not exported
    >> by
    >> > the
    >> > > >     >>>>>>> bundle
    >> > > >     >>>>>>>>> so it can not be found.
Anyone has an idea on how we
    >> > could
    >> > > > solve
    >> > > >     >>>>>>> this?
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>               Etienne
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>>
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>>
    >> > > >     >>>>>>>>
    >> > > >     >>>>>>>
    >> > > >     >>>>>>>
    >> > > >     >>>>>>>
    >> > > >     >>>>>>
    >> > > >     >>>>>> --
    >> > > >     >>>>>> --
    >> > > >     >>>>>> Christian Schneider
    >> > > >     >>>>>> http://www.liquid-reality.de
    >> > > >     >>>>>>
    >> > > >     >>>>>> Computer Scientist
    >> > > >     >>>>>> http://www.adobe.com
    >> > > >     >>>>>>
    >> > > >     >>>>
    >> > > >     >>>
    >> > > >
    >> > > >
    >> > > >
    >> > >
    >> >
    >>
    >

Mime
View raw message