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