plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robinet, Etienne" <43...@etu.he2b.be>
Subject Re: SPI Module - OSGi Bundle
Date Tue, 05 May 2020 03:06:22 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message