plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: SPI Module - OSGi Bundle
Date Tue, 05 May 2020 03:24:45 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message