You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by "Robinet, Etienne" <43...@etu.he2b.be> on 2020/05/05 03:06:22 UTC
Re: SPI Module - OSGi Bundle
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 <ch...@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" <43...@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 <lu...@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 <er...@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 <lu...@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 <ni...@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
> >>>>>>
> >>>>
> >>>
>
>
>
Re: SPI Module - OSGi Bundle
Posted by "Robinet, Etienne" <43...@etu.he2b.be>.
Hi all,
I did these changes on my branche. I tested it in Karaf and it works fine.
https://github.com/apache/plc4x/tree/feature/osgi
BR
Le ven. 8 mai 2020 à 10:24, Niclas Hedhman <ni...@hedhman.org> a écrit :
> Yes, that is what I suggest
>
> On Fri, May 8, 2020, 16:19 Robinet, Etienne <43...@etu.he2b.be> wrote:
>
> > Hello,
> > so if I understand correctly, I should create a new module for the OSGi
> > bundle, containing generic Activators that would be mentioned in the
> > Driver/Transport MANIFEST?
> > Etienne
> >
> > Le ven. 8 mai 2020 à 09:55, Niclas Hedhman <ni...@hedhman.org> a écrit
> :
> >
> > > As mentioned elsewhere, the generic activators could go in a separate
> > > bundle for OSGi use only. That applies to both this approach and
> Lukasz'
> > > one.
> > >
> > > // Niclas
> > >
> > > On Fri, May 8, 2020 at 2:08 PM Christofer Dutz <
> > christofer.dutz@c-ware.de>
> > > wrote:
> > >
> > > > Hi Niclas,
> > > >
> > > > If your suggested path doesn't limit the framework decisions a user
> > has,
> > > > then I have no objections.
> > > >
> > > > Indiens I am not that deep into osgi to have a well founded opinion.
> > > >
> > > > The api will probably never be a pure api module as it contains the
> > > driver
> > > > manager, which I wouldn't want to put into a separate module.
> > > >
> > > > Chris
> > > > ________________________________
> > > > Von: Niclas Hedhman <ni...@hedhman.org>
> > > > Gesendet: Freitag, 8. Mai 2020 05:12
> > > > An: dev@plc4x.apache.org <de...@plc4x.apache.org>
> > > > Betreff: Re: SPI Module - OSGi Bundle
> > > >
> > > > Both approaches are independent of OSGi framework implementations,
> > which
> > > is
> > > > part of the beauty of OSGi.
> > > >
> > > > Lukasz puts more value on some dogmatic principle ("only interfaces
> in
> > > > API"), whereas I have forwarded how an OSGi bundle producer is
> expected
> > > to
> > > > provide it, and how an OSGi bundle consumer would expect to see it
> and
> > > the
> > > > added benefit that default behavior can be overridden. Lukasz uses my
> > own
> > > > work-around (for JDBC drivers) to show me that is the way things are
> > > done.
> > > > It is not, it was a necessary hack for that time to get around the
> > legacy
> > > > JDBC drivers out in the open, all of them without OSGi manifests.
> > > >
> > > > As I said, I have no skin in the game. Only providing independent
> > advice,
> > > > as a former OSGi expert and a keen interest in PLC4X.
> > > >
> > > > // Niclas
> > > >
> > > >
> > > > On Thu, May 7, 2020 at 9:13 PM Christofer Dutz <
> > > christofer.dutz@c-ware.de>
> > > > wrote:
> > > >
> > > > > Hi folks,
> > > > >
> > > > > so if there is an option that doesn't tie our API and Drivers to a
> > > > > specific OSGi framework, I would prefer that.
> > > > >
> > > > > Chris
> > > > >
> > > > > Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> > > > > j.feinauer@pragmaticminds.de>:
> > > > >
> > > > > I would say that there are arguments for both cases (as ist
> often
> > > > with
> > > > > OSGi, IMHO).
> > > > > So I see them not as right or wrong but as to different styles
> or
> > > > > approaches that I woudl leave up to you to decide.
> > > > >
> > > > > IMHO
> > > > > Julian
> > > > >
> > > > > Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <
> 43823@etu.he2b.be
> > >:
> > > > >
> > > > > Hi guys,
> > > > > As I am really not an expert, which approach should we use?
> > > > >
> > > > > Etienne
> > > > >
> > > > > Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <
> > > luke@code-house.org>
> > > > > a écrit :
> > > > >
> > > > > > Hey Niclas,
> > > > > > While this code seems straight I don't think it is
> needed,
> > > and
> > > > > valid in
> > > > > > our case.
> > > > > > Main benefit of extender and extender based patterns is
> > > > > centralized
> > > > > > processing of drivers.
> > > > > > I am keen to keep only interfaces in the API packages and
> > > > > bundles and
> > > > > > move active parts of code (such base classes) to another
> > > place.
> > > > > It is
> > > > > > necessary to avoid creation of implementation dependency.
> > And
> > > > > that's
> > > > > > what is in fact, promoted by shared activator class.
> > > > > >
> > > > > > Best,
> > > > > > Łukasz
> > > > > >
> > > > > >
> > > > > > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > > > > > My suggestion was;
> > > > > > > 1. Don't do the BundleTracker classes, and instead
> change
> > > to
> > > > a
> > > > > bundle
> > > > > > > activator for each.
> > > > > > > 2. Add the "Bundle-Activator:
> > > > > org.apache.plc4x.java.osgi.DriverActivator"
> > > > > > > to the driver META/MANIFEST.MF
> > > > > > > 3. Do the equivalent for the Transports.
> > > > > > >
> > > > > > > public class DriverActivator implements
> BundleActivator {
> > > > > > >
> > > > > > > private ServiceRegistration<PlcDriver> reg;
> > > > > > >
> > > > > > > @Override
> > > > > > > public void start( BundleContext context ) throws
> > > > > Exception {
> > > > > > > Hashtable<String, String> props = new
> > > Hashtable<>();
> > > > > > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > > > > > driver.getProtocolCode() );
> > > > > > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > > > > > driver.getProtocolName() );
> > > > > > > reg = context.registerService( PlcDriver.class,
> > > > > driver, props );
> > > > > > > }
> > > > > > >
> > > > > > > @Override
> > > > > > > public void stop( BundleContext context ) {
> > > > > > > context.unregisterService( reg );
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> > > > > erobinet@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > >> Hi all,
> > > > > > >> So concretely what changes should be done so that a
> > > > > Driver/Transport
> > > > > > >> declares itself his service? Beside the changes in the
> > > > > manifest?
> > > > > > >> Etienne
> > > > > > >> On 2020/05/06 01:26:42, Niclas Hedhman <
> > > niclas@hedhman.org>
> > > > > wrote:
> > > > > > >>> Łukasz,
> > > > > > >>>
> > > > > > >>> the reason I say it is not very OSGi-y, is that the
> > > > > principle of OSGi
> > > > > > is
> > > > > > >>> that the bundle handles its own service
> registrations.
> > In
> > > > > the case of
> > > > > > >> JDBC
> > > > > > >>> (I initiated that spec, and I am the founder of OPS4J
> > as
> > > > > well as Pax
> > > > > > >>> subproject, 2005), it needed to address the problem
> > that
> > > > > JDBC drivers
> > > > > > >>> existed and changing their build and/or manifests was
> > > > > decided to be
> > > > > > "not
> > > > > > >>> viable". The approach there is a work-around for
> legacy
> > > > > code, which I
> > > > > > and
> > > > > > >>> Stuart McCulloch basically invented. IIRC, this
> > happened
> > > in
> > > > > 2007.
> > > > > > >>>
> > > > > > >>> I didn't suggest that bundles require Declarative
> > > Services.
> > > > > I suggested
> > > > > > >>> that the "inside of the loop" in Etienne's code is
> put
> > > into
> > > > > an
> > > > > > Activator,
> > > > > > >>> the code residing in the API and SPI bundles
> > > respectively,
> > > > > and that
> > > > > > each
> > > > > > >>> driver/transport has a "Bundle-Activator: ....." in
> the
> > > > > manifest
> > > > > > >>> referencing respective activator. It is not more
> > > intrusive
> > > > > than the
> > > > > > >>> Export-Package, Import-Package that will be required
> > > > anyway.
> > > > > > >>>
> > > > > > >>> Advantages; It is more in the spirit of OSGi. But
> > > > > importantly, the
> > > > > > >>> driver/transport is now an active bundle, rather
> than a
> > > > > library bundle,
> > > > > > >> and
> > > > > > >>> in theory the start/stop of a bundle could (there
> might
> > > be
> > > > > other
> > > > > > reasons
> > > > > > >>> why not) turn it on/off in runtime. If special needs
> > pop
> > > > up,
> > > > > maybe to
> > > > > > >>> deploy for the OpenHAB project, it is possible to
> > > override
> > > > > the
> > > > > > >>> driver/transport with hacking the API/SPI bundles.
> > > > > > >>>
> > > > > > >>> And I can't see any disadvantages other than "need to
> > > > rework
> > > > > a bit of
> > > > > > >> code".
> > > > > > >>>
> > > > > > >>> But I don't have skin in the game. Not in OSGi, not
> > here,
> > > > so
> > > > > take my
> > > > > > >>> recommendations into consideration or throw them
> away.
> > I
> > > > > just got the
> > > > > > >>> impression that you didn't really get what I
> suggested.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> // Niclas
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <
> > > > > luke@code-house.org>
> > > > > > >> wrote:
> > > > > > >>>
> > > > > > >>>> Hey Etienne, that's awesome piece of work. I can
> test
> > > it!
> > > > > :-)
> > > > > > >>>>
> > > > > > >>>> I believe that's what Etienne code does it in a
> valid
> > > OSGi
> > > > > way. And I
> > > > > > >> do
> > > > > > >>>> believe not because he mentioned me by name, but due
> > to
> > > > > below
> > > > > > >>>> argumentation.
> > > > > > >>>>
> > > > > > >>>> Proposed code uses extender pattern to grab specific
> > > > > META-INF/services
> > > > > > >>>> entries and register them in OSGi service registry.
> If
> > > you
> > > > > will take a
> > > > > > >>>> look on following line:
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > > > > > >>>> you will find that bundle is an jar which changes
> > state
> > > to
> > > > > ACTIVE.
> > > > > > >>>> Additionally that bundle classloader is used to find
> > > > > services and that
> > > > > > >>>> bundle context is used to register services. In the
> > end
> > > > > service which
> > > > > > >>>> appears looks like one registered by
> driver/transport
> > > > > module.
> > > > > > >>>>
> > > > > > >>>> The main point for above implementation is basic -
> > > getting
> > > > > the
> > > > > > standard
> > > > > > >>>> PLC4X driver JAR working in OSGi without forcing it
> to
> > > > > knowing too
> > > > > > much
> > > > > > >>>> about OSGi. Driver needs to ship manifest with
> > > > import/export
> > > > > > statements
> > > > > > >>>> and that's it. Additionally driver does not have to
> > > have a
> > > > > XML
> > > > > > >>>> descriptor which registers service. Quite many third
> > > > > parties might be
> > > > > > >>>> supplying drivers without any or with limited
> > knowledge
> > > of
> > > > > OSGi.
> > > > > > >>>> Do drivers have to be a service? Well, it they can
> > still
> > > > be
> > > > > a valid
> > > > > > >> OSGi
> > > > > > >>>> service, registered using any other way! OSGi aware
> > > driver
> > > > > manager
> > > > > > uses
> > > > > > >>>> OSGi services instead of static list own classloader
> > to
> > > > find
> > > > > > >>>> META-INF/services entries:
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> > > > > > >>>>
> > > > > > >>>> JDBC JARs are handled in such a way already in
> > pax-jdbc.
> > > > > Take a look
> > > > > > >> here:
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> > > > > > >>>> Same or very similar code can be found in
> > apache-camel,
> > > > > which brought
> > > > > > >>>> hundreds of components to OSGi, so I believe their
> way
> > > can
> > > > > be seen as
> > > > > > >>>> high level guide.
> > > > > > >>>> What Etienne did is a pattern implementation.
> > > > > > >>>>
> > > > > > >>>> With regard to capabilities/requirements - this is a
> > > > > resolver puzzle.
> > > > > > >> It
> > > > > > >>>> relies on additional information. As an unbaptized,
> > > > > non-religious osgi
> > > > > > >>>> guy (I take it as a tool and not act of faith), I
> > often
> > > do
> > > > > skip it. I
> > > > > > >> do
> > > > > > >>>> find it useful, however quite often problematic and
> > hard
> > > > to
> > > > > understand
> > > > > > >>>> (yet another non-trivial syntax in manifest to
> > follow).
> > > On
> > > > > older
> > > > > > >>>> runtimes capabilities are not even considered. For
> > never
> > > > > ones there
> > > > > > are
> > > > > > >>>> already existing namespaces:
> > > > > > >>>>
> https://www.osgi.org/capability-namespaces-reference/
> > > > > > >>>> including, one for services:
> > > > > > >>>>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> > > > > > >>>> My point is that capabilities are used to attest
> that
> > > > > runtime will
> > > > > > >>>> consist all necessary things in place after
> > provisioning
> > > > > operation. It
> > > > > > >>>> does not say HOW given capabilities should be made,
> > > cause
> > > > > resolver is
> > > > > > >>>> hit before bundle gets active. It is a safety check.
> > I'm
> > > > > fine with
> > > > > > >>>> having one, however we need to make it right to do
> not
> > > > > narrow use of
> > > > > > >>>> driver bundles only with our own extender.
> > > > > > >>>>
> > > > > > >>>> Beside the point, I am not sure if plc4x-api is a
> best
> > > > > place for osgi
> > > > > > >>>> specific logic. That is a standard dilema to address
> > in
> > > > how
> > > > > we want to
> > > > > > >>>> treat osgi and non-osgi users. :-)
> > > > > > >>>>
> > > > > > >>>> Cheers!
> > > > > > >>>> Łukasz
> > > > > > >>>>
> > > > > > >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> > > > > > >>>>> 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>:
> > > > > > >>>>> >> > > > >>>>>>>>>>
> > > > > > >>>>> >> > > > >>>>>>>>>>
>
Re: SPI Module - OSGi Bundle
Posted by Niclas Hedhman <ni...@hedhman.org>.
Yes, that is what I suggest
On Fri, May 8, 2020, 16:19 Robinet, Etienne <43...@etu.he2b.be> wrote:
> Hello,
> so if I understand correctly, I should create a new module for the OSGi
> bundle, containing generic Activators that would be mentioned in the
> Driver/Transport MANIFEST?
> Etienne
>
> Le ven. 8 mai 2020 à 09:55, Niclas Hedhman <ni...@hedhman.org> a écrit :
>
> > As mentioned elsewhere, the generic activators could go in a separate
> > bundle for OSGi use only. That applies to both this approach and Lukasz'
> > one.
> >
> > // Niclas
> >
> > On Fri, May 8, 2020 at 2:08 PM Christofer Dutz <
> christofer.dutz@c-ware.de>
> > wrote:
> >
> > > Hi Niclas,
> > >
> > > If your suggested path doesn't limit the framework decisions a user
> has,
> > > then I have no objections.
> > >
> > > Indiens I am not that deep into osgi to have a well founded opinion.
> > >
> > > The api will probably never be a pure api module as it contains the
> > driver
> > > manager, which I wouldn't want to put into a separate module.
> > >
> > > Chris
> > > ________________________________
> > > Von: Niclas Hedhman <ni...@hedhman.org>
> > > Gesendet: Freitag, 8. Mai 2020 05:12
> > > An: dev@plc4x.apache.org <de...@plc4x.apache.org>
> > > Betreff: Re: SPI Module - OSGi Bundle
> > >
> > > Both approaches are independent of OSGi framework implementations,
> which
> > is
> > > part of the beauty of OSGi.
> > >
> > > Lukasz puts more value on some dogmatic principle ("only interfaces in
> > > API"), whereas I have forwarded how an OSGi bundle producer is expected
> > to
> > > provide it, and how an OSGi bundle consumer would expect to see it and
> > the
> > > added benefit that default behavior can be overridden. Lukasz uses my
> own
> > > work-around (for JDBC drivers) to show me that is the way things are
> > done.
> > > It is not, it was a necessary hack for that time to get around the
> legacy
> > > JDBC drivers out in the open, all of them without OSGi manifests.
> > >
> > > As I said, I have no skin in the game. Only providing independent
> advice,
> > > as a former OSGi expert and a keen interest in PLC4X.
> > >
> > > // Niclas
> > >
> > >
> > > On Thu, May 7, 2020 at 9:13 PM Christofer Dutz <
> > christofer.dutz@c-ware.de>
> > > wrote:
> > >
> > > > Hi folks,
> > > >
> > > > so if there is an option that doesn't tie our API and Drivers to a
> > > > specific OSGi framework, I would prefer that.
> > > >
> > > > Chris
> > > >
> > > > Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> > > > j.feinauer@pragmaticminds.de>:
> > > >
> > > > I would say that there are arguments for both cases (as ist often
> > > with
> > > > OSGi, IMHO).
> > > > So I see them not as right or wrong but as to different styles or
> > > > approaches that I woudl leave up to you to decide.
> > > >
> > > > IMHO
> > > > Julian
> > > >
> > > > Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43823@etu.he2b.be
> >:
> > > >
> > > > Hi guys,
> > > > As I am really not an expert, which approach should we use?
> > > >
> > > > Etienne
> > > >
> > > > Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <
> > luke@code-house.org>
> > > > a écrit :
> > > >
> > > > > Hey Niclas,
> > > > > While this code seems straight I don't think it is needed,
> > and
> > > > valid in
> > > > > our case.
> > > > > Main benefit of extender and extender based patterns is
> > > > centralized
> > > > > processing of drivers.
> > > > > I am keen to keep only interfaces in the API packages and
> > > > bundles and
> > > > > move active parts of code (such base classes) to another
> > place.
> > > > It is
> > > > > necessary to avoid creation of implementation dependency.
> And
> > > > that's
> > > > > what is in fact, promoted by shared activator class.
> > > > >
> > > > > Best,
> > > > > Łukasz
> > > > >
> > > > >
> > > > > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > > > > My suggestion was;
> > > > > > 1. Don't do the BundleTracker classes, and instead change
> > to
> > > a
> > > > bundle
> > > > > > activator for each.
> > > > > > 2. Add the "Bundle-Activator:
> > > > org.apache.plc4x.java.osgi.DriverActivator"
> > > > > > to the driver META/MANIFEST.MF
> > > > > > 3. Do the equivalent for the Transports.
> > > > > >
> > > > > > public class DriverActivator implements BundleActivator {
> > > > > >
> > > > > > private ServiceRegistration<PlcDriver> reg;
> > > > > >
> > > > > > @Override
> > > > > > public void start( BundleContext context ) throws
> > > > Exception {
> > > > > > Hashtable<String, String> props = new
> > Hashtable<>();
> > > > > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > > > > driver.getProtocolCode() );
> > > > > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > > > > driver.getProtocolName() );
> > > > > > reg = context.registerService( PlcDriver.class,
> > > > driver, props );
> > > > > > }
> > > > > >
> > > > > > @Override
> > > > > > public void stop( BundleContext context ) {
> > > > > > context.unregisterService( reg );
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> > > > erobinet@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >> So concretely what changes should be done so that a
> > > > Driver/Transport
> > > > > >> declares itself his service? Beside the changes in the
> > > > manifest?
> > > > > >> Etienne
> > > > > >> On 2020/05/06 01:26:42, Niclas Hedhman <
> > niclas@hedhman.org>
> > > > wrote:
> > > > > >>> Łukasz,
> > > > > >>>
> > > > > >>> the reason I say it is not very OSGi-y, is that the
> > > > principle of OSGi
> > > > > is
> > > > > >>> that the bundle handles its own service registrations.
> In
> > > > the case of
> > > > > >> JDBC
> > > > > >>> (I initiated that spec, and I am the founder of OPS4J
> as
> > > > well as Pax
> > > > > >>> subproject, 2005), it needed to address the problem
> that
> > > > JDBC drivers
> > > > > >>> existed and changing their build and/or manifests was
> > > > decided to be
> > > > > "not
> > > > > >>> viable". The approach there is a work-around for legacy
> > > > code, which I
> > > > > and
> > > > > >>> Stuart McCulloch basically invented. IIRC, this
> happened
> > in
> > > > 2007.
> > > > > >>>
> > > > > >>> I didn't suggest that bundles require Declarative
> > Services.
> > > > I suggested
> > > > > >>> that the "inside of the loop" in Etienne's code is put
> > into
> > > > an
> > > > > Activator,
> > > > > >>> the code residing in the API and SPI bundles
> > respectively,
> > > > and that
> > > > > each
> > > > > >>> driver/transport has a "Bundle-Activator: ....." in the
> > > > manifest
> > > > > >>> referencing respective activator. It is not more
> > intrusive
> > > > than the
> > > > > >>> Export-Package, Import-Package that will be required
> > > anyway.
> > > > > >>>
> > > > > >>> Advantages; It is more in the spirit of OSGi. But
> > > > importantly, the
> > > > > >>> driver/transport is now an active bundle, rather than a
> > > > library bundle,
> > > > > >> and
> > > > > >>> in theory the start/stop of a bundle could (there might
> > be
> > > > other
> > > > > reasons
> > > > > >>> why not) turn it on/off in runtime. If special needs
> pop
> > > up,
> > > > maybe to
> > > > > >>> deploy for the OpenHAB project, it is possible to
> > override
> > > > the
> > > > > >>> driver/transport with hacking the API/SPI bundles.
> > > > > >>>
> > > > > >>> And I can't see any disadvantages other than "need to
> > > rework
> > > > a bit of
> > > > > >> code".
> > > > > >>>
> > > > > >>> But I don't have skin in the game. Not in OSGi, not
> here,
> > > so
> > > > take my
> > > > > >>> recommendations into consideration or throw them away.
> I
> > > > just got the
> > > > > >>> impression that you didn't really get what I suggested.
> > > > > >>>
> > > > > >>>
> > > > > >>> // Niclas
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <
> > > > luke@code-house.org>
> > > > > >> wrote:
> > > > > >>>
> > > > > >>>> Hey Etienne, that's awesome piece of work. I can test
> > it!
> > > > :-)
> > > > > >>>>
> > > > > >>>> I believe that's what Etienne code does it in a valid
> > OSGi
> > > > way. And I
> > > > > >> do
> > > > > >>>> believe not because he mentioned me by name, but due
> to
> > > > below
> > > > > >>>> argumentation.
> > > > > >>>>
> > > > > >>>> Proposed code uses extender pattern to grab specific
> > > > META-INF/services
> > > > > >>>> entries and register them in OSGi service registry. If
> > you
> > > > will take a
> > > > > >>>> look on following line:
> > > > > >>>>
> > > > > >>>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > > > > >>>> you will find that bundle is an jar which changes
> state
> > to
> > > > ACTIVE.
> > > > > >>>> Additionally that bundle classloader is used to find
> > > > services and that
> > > > > >>>> bundle context is used to register services. In the
> end
> > > > service which
> > > > > >>>> appears looks like one registered by driver/transport
> > > > module.
> > > > > >>>>
> > > > > >>>> The main point for above implementation is basic -
> > getting
> > > > the
> > > > > standard
> > > > > >>>> PLC4X driver JAR working in OSGi without forcing it to
> > > > knowing too
> > > > > much
> > > > > >>>> about OSGi. Driver needs to ship manifest with
> > > import/export
> > > > > statements
> > > > > >>>> and that's it. Additionally driver does not have to
> > have a
> > > > XML
> > > > > >>>> descriptor which registers service. Quite many third
> > > > parties might be
> > > > > >>>> supplying drivers without any or with limited
> knowledge
> > of
> > > > OSGi.
> > > > > >>>> Do drivers have to be a service? Well, it they can
> still
> > > be
> > > > a valid
> > > > > >> OSGi
> > > > > >>>> service, registered using any other way! OSGi aware
> > driver
> > > > manager
> > > > > uses
> > > > > >>>> OSGi services instead of static list own classloader
> to
> > > find
> > > > > >>>> META-INF/services entries:
> > > > > >>>>
> > > > > >>>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> > > > > >>>>
> > > > > >>>> JDBC JARs are handled in such a way already in
> pax-jdbc.
> > > > Take a look
> > > > > >> here:
> > > > > >>>>
> > > > > >>>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> > > > > >>>> Same or very similar code can be found in
> apache-camel,
> > > > which brought
> > > > > >>>> hundreds of components to OSGi, so I believe their way
> > can
> > > > be seen as
> > > > > >>>> high level guide.
> > > > > >>>> What Etienne did is a pattern implementation.
> > > > > >>>>
> > > > > >>>> With regard to capabilities/requirements - this is a
> > > > resolver puzzle.
> > > > > >> It
> > > > > >>>> relies on additional information. As an unbaptized,
> > > > non-religious osgi
> > > > > >>>> guy (I take it as a tool and not act of faith), I
> often
> > do
> > > > skip it. I
> > > > > >> do
> > > > > >>>> find it useful, however quite often problematic and
> hard
> > > to
> > > > understand
> > > > > >>>> (yet another non-trivial syntax in manifest to
> follow).
> > On
> > > > older
> > > > > >>>> runtimes capabilities are not even considered. For
> never
> > > > ones there
> > > > > are
> > > > > >>>> already existing namespaces:
> > > > > >>>> https://www.osgi.org/capability-namespaces-reference/
> > > > > >>>> including, one for services:
> > > > > >>>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> > > > > >>>> My point is that capabilities are used to attest that
> > > > runtime will
> > > > > >>>> consist all necessary things in place after
> provisioning
> > > > operation. It
> > > > > >>>> does not say HOW given capabilities should be made,
> > cause
> > > > resolver is
> > > > > >>>> hit before bundle gets active. It is a safety check.
> I'm
> > > > fine with
> > > > > >>>> having one, however we need to make it right to do not
> > > > narrow use of
> > > > > >>>> driver bundles only with our own extender.
> > > > > >>>>
> > > > > >>>> Beside the point, I am not sure if plc4x-api is a best
> > > > place for osgi
> > > > > >>>> specific logic. That is a standard dilema to address
> in
> > > how
> > > > we want to
> > > > > >>>> treat osgi and non-osgi users. :-)
> > > > > >>>>
> > > > > >>>> Cheers!
> > > > > >>>> Łukasz
> > > > > >>>>
> > > > > >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> > > > > >>>>> 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>:
> > > > > >>>>> >> > > > >>>>>>>>>>
> > > > > >>>>> >> > > > >>>>>>>>>>
Re: SPI Module - OSGi Bundle
Posted by "Robinet, Etienne" <43...@etu.he2b.be>.
Hello,
so if I understand correctly, I should create a new module for the OSGi
bundle, containing generic Activators that would be mentioned in the
Driver/Transport MANIFEST?
Etienne
Le ven. 8 mai 2020 à 09:55, Niclas Hedhman <ni...@hedhman.org> a écrit :
> As mentioned elsewhere, the generic activators could go in a separate
> bundle for OSGi use only. That applies to both this approach and Lukasz'
> one.
>
> // Niclas
>
> On Fri, May 8, 2020 at 2:08 PM Christofer Dutz <ch...@c-ware.de>
> wrote:
>
> > Hi Niclas,
> >
> > If your suggested path doesn't limit the framework decisions a user has,
> > then I have no objections.
> >
> > Indiens I am not that deep into osgi to have a well founded opinion.
> >
> > The api will probably never be a pure api module as it contains the
> driver
> > manager, which I wouldn't want to put into a separate module.
> >
> > Chris
> > ________________________________
> > Von: Niclas Hedhman <ni...@hedhman.org>
> > Gesendet: Freitag, 8. Mai 2020 05:12
> > An: dev@plc4x.apache.org <de...@plc4x.apache.org>
> > Betreff: Re: SPI Module - OSGi Bundle
> >
> > Both approaches are independent of OSGi framework implementations, which
> is
> > part of the beauty of OSGi.
> >
> > Lukasz puts more value on some dogmatic principle ("only interfaces in
> > API"), whereas I have forwarded how an OSGi bundle producer is expected
> to
> > provide it, and how an OSGi bundle consumer would expect to see it and
> the
> > added benefit that default behavior can be overridden. Lukasz uses my own
> > work-around (for JDBC drivers) to show me that is the way things are
> done.
> > It is not, it was a necessary hack for that time to get around the legacy
> > JDBC drivers out in the open, all of them without OSGi manifests.
> >
> > As I said, I have no skin in the game. Only providing independent advice,
> > as a former OSGi expert and a keen interest in PLC4X.
> >
> > // Niclas
> >
> >
> > On Thu, May 7, 2020 at 9:13 PM Christofer Dutz <
> christofer.dutz@c-ware.de>
> > wrote:
> >
> > > Hi folks,
> > >
> > > so if there is an option that doesn't tie our API and Drivers to a
> > > specific OSGi framework, I would prefer that.
> > >
> > > Chris
> > >
> > > Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> > > j.feinauer@pragmaticminds.de>:
> > >
> > > I would say that there are arguments for both cases (as ist often
> > with
> > > OSGi, IMHO).
> > > So I see them not as right or wrong but as to different styles or
> > > approaches that I woudl leave up to you to decide.
> > >
> > > IMHO
> > > Julian
> > >
> > > Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
> > >
> > > Hi guys,
> > > As I am really not an expert, which approach should we use?
> > >
> > > Etienne
> > >
> > > Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <
> luke@code-house.org>
> > > a écrit :
> > >
> > > > Hey Niclas,
> > > > While this code seems straight I don't think it is needed,
> and
> > > valid in
> > > > our case.
> > > > Main benefit of extender and extender based patterns is
> > > centralized
> > > > processing of drivers.
> > > > I am keen to keep only interfaces in the API packages and
> > > bundles and
> > > > move active parts of code (such base classes) to another
> place.
> > > It is
> > > > necessary to avoid creation of implementation dependency. And
> > > that's
> > > > what is in fact, promoted by shared activator class.
> > > >
> > > > Best,
> > > > Łukasz
> > > >
> > > >
> > > > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > > > My suggestion was;
> > > > > 1. Don't do the BundleTracker classes, and instead change
> to
> > a
> > > bundle
> > > > > activator for each.
> > > > > 2. Add the "Bundle-Activator:
> > > org.apache.plc4x.java.osgi.DriverActivator"
> > > > > to the driver META/MANIFEST.MF
> > > > > 3. Do the equivalent for the Transports.
> > > > >
> > > > > public class DriverActivator implements BundleActivator {
> > > > >
> > > > > private ServiceRegistration<PlcDriver> reg;
> > > > >
> > > > > @Override
> > > > > public void start( BundleContext context ) throws
> > > Exception {
> > > > > Hashtable<String, String> props = new
> Hashtable<>();
> > > > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > > > driver.getProtocolCode() );
> > > > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > > > driver.getProtocolName() );
> > > > > reg = context.registerService( PlcDriver.class,
> > > driver, props );
> > > > > }
> > > > >
> > > > > @Override
> > > > > public void stop( BundleContext context ) {
> > > > > context.unregisterService( reg );
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> > > erobinet@apache.org>
> > > > wrote:
> > > > >
> > > > >> Hi all,
> > > > >> So concretely what changes should be done so that a
> > > Driver/Transport
> > > > >> declares itself his service? Beside the changes in the
> > > manifest?
> > > > >> Etienne
> > > > >> On 2020/05/06 01:26:42, Niclas Hedhman <
> niclas@hedhman.org>
> > > wrote:
> > > > >>> Łukasz,
> > > > >>>
> > > > >>> the reason I say it is not very OSGi-y, is that the
> > > principle of OSGi
> > > > is
> > > > >>> that the bundle handles its own service registrations. In
> > > the case of
> > > > >> JDBC
> > > > >>> (I initiated that spec, and I am the founder of OPS4J as
> > > well as Pax
> > > > >>> subproject, 2005), it needed to address the problem that
> > > JDBC drivers
> > > > >>> existed and changing their build and/or manifests was
> > > decided to be
> > > > "not
> > > > >>> viable". The approach there is a work-around for legacy
> > > code, which I
> > > > and
> > > > >>> Stuart McCulloch basically invented. IIRC, this happened
> in
> > > 2007.
> > > > >>>
> > > > >>> I didn't suggest that bundles require Declarative
> Services.
> > > I suggested
> > > > >>> that the "inside of the loop" in Etienne's code is put
> into
> > > an
> > > > Activator,
> > > > >>> the code residing in the API and SPI bundles
> respectively,
> > > and that
> > > > each
> > > > >>> driver/transport has a "Bundle-Activator: ....." in the
> > > manifest
> > > > >>> referencing respective activator. It is not more
> intrusive
> > > than the
> > > > >>> Export-Package, Import-Package that will be required
> > anyway.
> > > > >>>
> > > > >>> Advantages; It is more in the spirit of OSGi. But
> > > importantly, the
> > > > >>> driver/transport is now an active bundle, rather than a
> > > library bundle,
> > > > >> and
> > > > >>> in theory the start/stop of a bundle could (there might
> be
> > > other
> > > > reasons
> > > > >>> why not) turn it on/off in runtime. If special needs pop
> > up,
> > > maybe to
> > > > >>> deploy for the OpenHAB project, it is possible to
> override
> > > the
> > > > >>> driver/transport with hacking the API/SPI bundles.
> > > > >>>
> > > > >>> And I can't see any disadvantages other than "need to
> > rework
> > > a bit of
> > > > >> code".
> > > > >>>
> > > > >>> But I don't have skin in the game. Not in OSGi, not here,
> > so
> > > take my
> > > > >>> recommendations into consideration or throw them away. I
> > > just got the
> > > > >>> impression that you didn't really get what I suggested.
> > > > >>>
> > > > >>>
> > > > >>> // Niclas
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <
> > > luke@code-house.org>
> > > > >> wrote:
> > > > >>>
> > > > >>>> Hey Etienne, that's awesome piece of work. I can test
> it!
> > > :-)
> > > > >>>>
> > > > >>>> I believe that's what Etienne code does it in a valid
> OSGi
> > > way. And I
> > > > >> do
> > > > >>>> believe not because he mentioned me by name, but due to
> > > below
> > > > >>>> argumentation.
> > > > >>>>
> > > > >>>> Proposed code uses extender pattern to grab specific
> > > META-INF/services
> > > > >>>> entries and register them in OSGi service registry. If
> you
> > > will take a
> > > > >>>> look on following line:
> > > > >>>>
> > > > >>>>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > > > >>>> you will find that bundle is an jar which changes state
> to
> > > ACTIVE.
> > > > >>>> Additionally that bundle classloader is used to find
> > > services and that
> > > > >>>> bundle context is used to register services. In the end
> > > service which
> > > > >>>> appears looks like one registered by driver/transport
> > > module.
> > > > >>>>
> > > > >>>> The main point for above implementation is basic -
> getting
> > > the
> > > > standard
> > > > >>>> PLC4X driver JAR working in OSGi without forcing it to
> > > knowing too
> > > > much
> > > > >>>> about OSGi. Driver needs to ship manifest with
> > import/export
> > > > statements
> > > > >>>> and that's it. Additionally driver does not have to
> have a
> > > XML
> > > > >>>> descriptor which registers service. Quite many third
> > > parties might be
> > > > >>>> supplying drivers without any or with limited knowledge
> of
> > > OSGi.
> > > > >>>> Do drivers have to be a service? Well, it they can still
> > be
> > > a valid
> > > > >> OSGi
> > > > >>>> service, registered using any other way! OSGi aware
> driver
> > > manager
> > > > uses
> > > > >>>> OSGi services instead of static list own classloader to
> > find
> > > > >>>> META-INF/services entries:
> > > > >>>>
> > > > >>>>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> > > > >>>>
> > > > >>>> JDBC JARs are handled in such a way already in pax-jdbc.
> > > Take a look
> > > > >> here:
> > > > >>>>
> > > > >>>>
> > > > >>
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> > > > >>>> Same or very similar code can be found in apache-camel,
> > > which brought
> > > > >>>> hundreds of components to OSGi, so I believe their way
> can
> > > be seen as
> > > > >>>> high level guide.
> > > > >>>> What Etienne did is a pattern implementation.
> > > > >>>>
> > > > >>>> With regard to capabilities/requirements - this is a
> > > resolver puzzle.
> > > > >> It
> > > > >>>> relies on additional information. As an unbaptized,
> > > non-religious osgi
> > > > >>>> guy (I take it as a tool and not act of faith), I often
> do
> > > skip it. I
> > > > >> do
> > > > >>>> find it useful, however quite often problematic and hard
> > to
> > > understand
> > > > >>>> (yet another non-trivial syntax in manifest to follow).
> On
> > > older
> > > > >>>> runtimes capabilities are not even considered. For never
> > > ones there
> > > > are
> > > > >>>> already existing namespaces:
> > > > >>>> https://www.osgi.org/capability-namespaces-reference/
> > > > >>>> including, one for services:
> > > > >>>>
> > > > >>
> > > >
> > >
> >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> > > > >>>> My point is that capabilities are used to attest that
> > > runtime will
> > > > >>>> consist all necessary things in place after provisioning
> > > operation. It
> > > > >>>> does not say HOW given capabilities should be made,
> cause
> > > resolver is
> > > > >>>> hit before bundle gets active. It is a safety check. I'm
> > > fine with
> > > > >>>> having one, however we need to make it right to do not
> > > narrow use of
> > > > >>>> driver bundles only with our own extender.
> > > > >>>>
> > > > >>>> Beside the point, I am not sure if plc4x-api is a best
> > > place for osgi
> > > > >>>> specific logic. That is a standard dilema to address in
> > how
> > > we want to
> > > > >>>> treat osgi and non-osgi users. :-)
> > > > >>>>
> > > > >>>> Cheers!
> > > > >>>> Łukasz
> > > > >>>>
> > > > >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> > > > >>>>> 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
> > > > >>>>> >> > > > >>>>>>
> > > > >>>>> >> > > > >>>>
> > > > >>>>> >> > > > >>>
> > > > >>>>> >> > > >
> > > > >>>>> >> > > >
> > > > >>>>> >> > > >
> > > > >>>>> >> > >
> > > > >>>>> >> >
> > > > >>>>> >>
> > > > >>>>> >
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> >
>
Re: SPI Module - OSGi Bundle
Posted by Niclas Hedhman <ni...@hedhman.org>.
As mentioned elsewhere, the generic activators could go in a separate
bundle for OSGi use only. That applies to both this approach and Lukasz'
one.
// Niclas
On Fri, May 8, 2020 at 2:08 PM Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi Niclas,
>
> If your suggested path doesn't limit the framework decisions a user has,
> then I have no objections.
>
> Indiens I am not that deep into osgi to have a well founded opinion.
>
> The api will probably never be a pure api module as it contains the driver
> manager, which I wouldn't want to put into a separate module.
>
> Chris
> ________________________________
> Von: Niclas Hedhman <ni...@hedhman.org>
> Gesendet: Freitag, 8. Mai 2020 05:12
> An: dev@plc4x.apache.org <de...@plc4x.apache.org>
> Betreff: Re: SPI Module - OSGi Bundle
>
> Both approaches are independent of OSGi framework implementations, which is
> part of the beauty of OSGi.
>
> Lukasz puts more value on some dogmatic principle ("only interfaces in
> API"), whereas I have forwarded how an OSGi bundle producer is expected to
> provide it, and how an OSGi bundle consumer would expect to see it and the
> added benefit that default behavior can be overridden. Lukasz uses my own
> work-around (for JDBC drivers) to show me that is the way things are done.
> It is not, it was a necessary hack for that time to get around the legacy
> JDBC drivers out in the open, all of them without OSGi manifests.
>
> As I said, I have no skin in the game. Only providing independent advice,
> as a former OSGi expert and a keen interest in PLC4X.
>
> // Niclas
>
>
> On Thu, May 7, 2020 at 9:13 PM Christofer Dutz <ch...@c-ware.de>
> wrote:
>
> > Hi folks,
> >
> > so if there is an option that doesn't tie our API and Drivers to a
> > specific OSGi framework, I would prefer that.
> >
> > Chris
> >
> > Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> > j.feinauer@pragmaticminds.de>:
> >
> > I would say that there are arguments for both cases (as ist often
> with
> > OSGi, IMHO).
> > So I see them not as right or wrong but as to different styles or
> > approaches that I woudl leave up to you to decide.
> >
> > IMHO
> > Julian
> >
> > Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
> >
> > Hi guys,
> > As I am really not an expert, which approach should we use?
> >
> > Etienne
> >
> > Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <lu...@code-house.org>
> > a écrit :
> >
> > > Hey Niclas,
> > > While this code seems straight I don't think it is needed, and
> > valid in
> > > our case.
> > > Main benefit of extender and extender based patterns is
> > centralized
> > > processing of drivers.
> > > I am keen to keep only interfaces in the API packages and
> > bundles and
> > > move active parts of code (such base classes) to another place.
> > It is
> > > necessary to avoid creation of implementation dependency. And
> > that's
> > > what is in fact, promoted by shared activator class.
> > >
> > > Best,
> > > Łukasz
> > >
> > >
> > > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > > My suggestion was;
> > > > 1. Don't do the BundleTracker classes, and instead change to
> a
> > bundle
> > > > activator for each.
> > > > 2. Add the "Bundle-Activator:
> > org.apache.plc4x.java.osgi.DriverActivator"
> > > > to the driver META/MANIFEST.MF
> > > > 3. Do the equivalent for the Transports.
> > > >
> > > > public class DriverActivator implements BundleActivator {
> > > >
> > > > private ServiceRegistration<PlcDriver> reg;
> > > >
> > > > @Override
> > > > public void start( BundleContext context ) throws
> > Exception {
> > > > Hashtable<String, String> props = new Hashtable<>();
> > > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > > driver.getProtocolCode() );
> > > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > > driver.getProtocolName() );
> > > > reg = context.registerService( PlcDriver.class,
> > driver, props );
> > > > }
> > > >
> > > > @Override
> > > > public void stop( BundleContext context ) {
> > > > context.unregisterService( reg );
> > > > }
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> > erobinet@apache.org>
> > > wrote:
> > > >
> > > >> Hi all,
> > > >> So concretely what changes should be done so that a
> > Driver/Transport
> > > >> declares itself his service? Beside the changes in the
> > manifest?
> > > >> Etienne
> > > >> On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org>
> > wrote:
> > > >>> Łukasz,
> > > >>>
> > > >>> the reason I say it is not very OSGi-y, is that the
> > principle of OSGi
> > > is
> > > >>> that the bundle handles its own service registrations. In
> > the case of
> > > >> JDBC
> > > >>> (I initiated that spec, and I am the founder of OPS4J as
> > well as Pax
> > > >>> subproject, 2005), it needed to address the problem that
> > JDBC drivers
> > > >>> existed and changing their build and/or manifests was
> > decided to be
> > > "not
> > > >>> viable". The approach there is a work-around for legacy
> > code, which I
> > > and
> > > >>> Stuart McCulloch basically invented. IIRC, this happened in
> > 2007.
> > > >>>
> > > >>> I didn't suggest that bundles require Declarative Services.
> > I suggested
> > > >>> that the "inside of the loop" in Etienne's code is put into
> > an
> > > Activator,
> > > >>> the code residing in the API and SPI bundles respectively,
> > and that
> > > each
> > > >>> driver/transport has a "Bundle-Activator: ....." in the
> > manifest
> > > >>> referencing respective activator. It is not more intrusive
> > than the
> > > >>> Export-Package, Import-Package that will be required
> anyway.
> > > >>>
> > > >>> Advantages; It is more in the spirit of OSGi. But
> > importantly, the
> > > >>> driver/transport is now an active bundle, rather than a
> > library bundle,
> > > >> and
> > > >>> in theory the start/stop of a bundle could (there might be
> > other
> > > reasons
> > > >>> why not) turn it on/off in runtime. If special needs pop
> up,
> > maybe to
> > > >>> deploy for the OpenHAB project, it is possible to override
> > the
> > > >>> driver/transport with hacking the API/SPI bundles.
> > > >>>
> > > >>> And I can't see any disadvantages other than "need to
> rework
> > a bit of
> > > >> code".
> > > >>>
> > > >>> But I don't have skin in the game. Not in OSGi, not here,
> so
> > take my
> > > >>> recommendations into consideration or throw them away. I
> > just got the
> > > >>> impression that you didn't really get what I suggested.
> > > >>>
> > > >>>
> > > >>> // Niclas
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <
> > luke@code-house.org>
> > > >> wrote:
> > > >>>
> > > >>>> Hey Etienne, that's awesome piece of work. I can test it!
> > :-)
> > > >>>>
> > > >>>> I believe that's what Etienne code does it in a valid OSGi
> > way. And I
> > > >> do
> > > >>>> believe not because he mentioned me by name, but due to
> > below
> > > >>>> argumentation.
> > > >>>>
> > > >>>> Proposed code uses extender pattern to grab specific
> > META-INF/services
> > > >>>> entries and register them in OSGi service registry. If you
> > will take a
> > > >>>> look on following line:
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > > >>>> you will find that bundle is an jar which changes state to
> > ACTIVE.
> > > >>>> Additionally that bundle classloader is used to find
> > services and that
> > > >>>> bundle context is used to register services. In the end
> > service which
> > > >>>> appears looks like one registered by driver/transport
> > module.
> > > >>>>
> > > >>>> The main point for above implementation is basic - getting
> > the
> > > standard
> > > >>>> PLC4X driver JAR working in OSGi without forcing it to
> > knowing too
> > > much
> > > >>>> about OSGi. Driver needs to ship manifest with
> import/export
> > > statements
> > > >>>> and that's it. Additionally driver does not have to have a
> > XML
> > > >>>> descriptor which registers service. Quite many third
> > parties might be
> > > >>>> supplying drivers without any or with limited knowledge of
> > OSGi.
> > > >>>> Do drivers have to be a service? Well, it they can still
> be
> > a valid
> > > >> OSGi
> > > >>>> service, registered using any other way! OSGi aware driver
> > manager
> > > uses
> > > >>>> OSGi services instead of static list own classloader to
> find
> > > >>>> META-INF/services entries:
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> > > >>>>
> > > >>>> JDBC JARs are handled in such a way already in pax-jdbc.
> > Take a look
> > > >> here:
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> > > >>>> Same or very similar code can be found in apache-camel,
> > which brought
> > > >>>> hundreds of components to OSGi, so I believe their way can
> > be seen as
> > > >>>> high level guide.
> > > >>>> What Etienne did is a pattern implementation.
> > > >>>>
> > > >>>> With regard to capabilities/requirements - this is a
> > resolver puzzle.
> > > >> It
> > > >>>> relies on additional information. As an unbaptized,
> > non-religious osgi
> > > >>>> guy (I take it as a tool and not act of faith), I often do
> > skip it. I
> > > >> do
> > > >>>> find it useful, however quite often problematic and hard
> to
> > understand
> > > >>>> (yet another non-trivial syntax in manifest to follow). On
> > older
> > > >>>> runtimes capabilities are not even considered. For never
> > ones there
> > > are
> > > >>>> already existing namespaces:
> > > >>>> https://www.osgi.org/capability-namespaces-reference/
> > > >>>> including, one for services:
> > > >>>>
> > > >>
> > >
> >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> > > >>>> My point is that capabilities are used to attest that
> > runtime will
> > > >>>> consist all necessary things in place after provisioning
> > operation. It
> > > >>>> does not say HOW given capabilities should be made, cause
> > resolver is
> > > >>>> hit before bundle gets active. It is a safety check. I'm
> > fine with
> > > >>>> having one, however we need to make it right to do not
> > narrow use of
> > > >>>> driver bundles only with our own extender.
> > > >>>>
> > > >>>> Beside the point, I am not sure if plc4x-api is a best
> > place for osgi
> > > >>>> specific logic. That is a standard dilema to address in
> how
> > we want to
> > > >>>> treat osgi and non-osgi users. :-)
> > > >>>>
> > > >>>> Cheers!
> > > >>>> Łukasz
> > > >>>>
> > > >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> > > >>>>> 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
> > > >>>>> >> > > > >>>>>>
> > > >>>>> >> > > > >>>>
> > > >>>>> >> > > > >>>
> > > >>>>> >> > > >
> > > >>>>> >> > > >
> > > >>>>> >> > > >
> > > >>>>> >> > >
> > > >>>>> >> >
> > > >>>>> >>
> > > >>>>> >
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
> >
> >
> >
>
Re: SPI Module - OSGi Bundle
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Niclas,
If your suggested path doesn't limit the framework decisions a user has, then I have no objections.
Indiens I am not that deep into osgi to have a well founded opinion.
The api will probably never be a pure api module as it contains the driver manager, which I wouldn't want to put into a separate module.
Chris
________________________________
Von: Niclas Hedhman <ni...@hedhman.org>
Gesendet: Freitag, 8. Mai 2020 05:12
An: dev@plc4x.apache.org <de...@plc4x.apache.org>
Betreff: Re: SPI Module - OSGi Bundle
Both approaches are independent of OSGi framework implementations, which is
part of the beauty of OSGi.
Lukasz puts more value on some dogmatic principle ("only interfaces in
API"), whereas I have forwarded how an OSGi bundle producer is expected to
provide it, and how an OSGi bundle consumer would expect to see it and the
added benefit that default behavior can be overridden. Lukasz uses my own
work-around (for JDBC drivers) to show me that is the way things are done.
It is not, it was a necessary hack for that time to get around the legacy
JDBC drivers out in the open, all of them without OSGi manifests.
As I said, I have no skin in the game. Only providing independent advice,
as a former OSGi expert and a keen interest in PLC4X.
// Niclas
On Thu, May 7, 2020 at 9:13 PM Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi folks,
>
> so if there is an option that doesn't tie our API and Drivers to a
> specific OSGi framework, I would prefer that.
>
> Chris
>
> Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> j.feinauer@pragmaticminds.de>:
>
> I would say that there are arguments for both cases (as ist often with
> OSGi, IMHO).
> So I see them not as right or wrong but as to different styles or
> approaches that I woudl leave up to you to decide.
>
> IMHO
> Julian
>
> Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
>
> Hi guys,
> As I am really not an expert, which approach should we use?
>
> Etienne
>
> Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <lu...@code-house.org>
> a écrit :
>
> > Hey Niclas,
> > While this code seems straight I don't think it is needed, and
> valid in
> > our case.
> > Main benefit of extender and extender based patterns is
> centralized
> > processing of drivers.
> > I am keen to keep only interfaces in the API packages and
> bundles and
> > move active parts of code (such base classes) to another place.
> It is
> > necessary to avoid creation of implementation dependency. And
> that's
> > what is in fact, promoted by shared activator class.
> >
> > Best,
> > Łukasz
> >
> >
> > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > My suggestion was;
> > > 1. Don't do the BundleTracker classes, and instead change to a
> bundle
> > > activator for each.
> > > 2. Add the "Bundle-Activator:
> org.apache.plc4x.java.osgi.DriverActivator"
> > > to the driver META/MANIFEST.MF
> > > 3. Do the equivalent for the Transports.
> > >
> > > public class DriverActivator implements BundleActivator {
> > >
> > > private ServiceRegistration<PlcDriver> reg;
> > >
> > > @Override
> > > public void start( BundleContext context ) throws
> Exception {
> > > Hashtable<String, String> props = new Hashtable<>();
> > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > driver.getProtocolCode() );
> > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > driver.getProtocolName() );
> > > reg = context.registerService( PlcDriver.class,
> driver, props );
> > > }
> > >
> > > @Override
> > > public void stop( BundleContext context ) {
> > > context.unregisterService( reg );
> > > }
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> erobinet@apache.org>
> > wrote:
> > >
> > >> Hi all,
> > >> So concretely what changes should be done so that a
> Driver/Transport
> > >> declares itself his service? Beside the changes in the
> manifest?
> > >> Etienne
> > >> On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org>
> wrote:
> > >>> Łukasz,
> > >>>
> > >>> the reason I say it is not very OSGi-y, is that the
> principle of OSGi
> > is
> > >>> that the bundle handles its own service registrations. In
> the case of
> > >> JDBC
> > >>> (I initiated that spec, and I am the founder of OPS4J as
> well as Pax
> > >>> subproject, 2005), it needed to address the problem that
> JDBC drivers
> > >>> existed and changing their build and/or manifests was
> decided to be
> > "not
> > >>> viable". The approach there is a work-around for legacy
> code, which I
> > and
> > >>> Stuart McCulloch basically invented. IIRC, this happened in
> 2007.
> > >>>
> > >>> I didn't suggest that bundles require Declarative Services.
> I suggested
> > >>> that the "inside of the loop" in Etienne's code is put into
> an
> > Activator,
> > >>> the code residing in the API and SPI bundles respectively,
> and that
> > each
> > >>> driver/transport has a "Bundle-Activator: ....." in the
> manifest
> > >>> referencing respective activator. It is not more intrusive
> than the
> > >>> Export-Package, Import-Package that will be required anyway.
> > >>>
> > >>> Advantages; It is more in the spirit of OSGi. But
> importantly, the
> > >>> driver/transport is now an active bundle, rather than a
> library bundle,
> > >> and
> > >>> in theory the start/stop of a bundle could (there might be
> other
> > reasons
> > >>> why not) turn it on/off in runtime. If special needs pop up,
> maybe to
> > >>> deploy for the OpenHAB project, it is possible to override
> the
> > >>> driver/transport with hacking the API/SPI bundles.
> > >>>
> > >>> And I can't see any disadvantages other than "need to rework
> a bit of
> > >> code".
> > >>>
> > >>> But I don't have skin in the game. Not in OSGi, not here, so
> take my
> > >>> recommendations into consideration or throw them away. I
> just got the
> > >>> impression that you didn't really get what I suggested.
> > >>>
> > >>>
> > >>> // Niclas
> > >>>
> > >>>
> > >>>
> > >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <
> luke@code-house.org>
> > >> wrote:
> > >>>
> > >>>> Hey Etienne, that's awesome piece of work. I can test it!
> :-)
> > >>>>
> > >>>> I believe that's what Etienne code does it in a valid OSGi
> way. And I
> > >> do
> > >>>> believe not because he mentioned me by name, but due to
> below
> > >>>> argumentation.
> > >>>>
> > >>>> Proposed code uses extender pattern to grab specific
> META-INF/services
> > >>>> entries and register them in OSGi service registry. If you
> will take a
> > >>>> look on following line:
> > >>>>
> > >>>>
> > >>
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > >>>> you will find that bundle is an jar which changes state to
> ACTIVE.
> > >>>> Additionally that bundle classloader is used to find
> services and that
> > >>>> bundle context is used to register services. In the end
> service which
> > >>>> appears looks like one registered by driver/transport
> module.
> > >>>>
> > >>>> The main point for above implementation is basic - getting
> the
> > standard
> > >>>> PLC4X driver JAR working in OSGi without forcing it to
> knowing too
> > much
> > >>>> about OSGi. Driver needs to ship manifest with import/export
> > statements
> > >>>> and that's it. Additionally driver does not have to have a
> XML
> > >>>> descriptor which registers service. Quite many third
> parties might be
> > >>>> supplying drivers without any or with limited knowledge of
> OSGi.
> > >>>> Do drivers have to be a service? Well, it they can still be
> a valid
> > >> OSGi
> > >>>> service, registered using any other way! OSGi aware driver
> manager
> > uses
> > >>>> OSGi services instead of static list own classloader to find
> > >>>> META-INF/services entries:
> > >>>>
> > >>>>
> > >>
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> > >>>>
> > >>>> JDBC JARs are handled in such a way already in pax-jdbc.
> Take a look
> > >> here:
> > >>>>
> > >>>>
> > >>
> >
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> > >>>> Same or very similar code can be found in apache-camel,
> which brought
> > >>>> hundreds of components to OSGi, so I believe their way can
> be seen as
> > >>>> high level guide.
> > >>>> What Etienne did is a pattern implementation.
> > >>>>
> > >>>> With regard to capabilities/requirements - this is a
> resolver puzzle.
> > >> It
> > >>>> relies on additional information. As an unbaptized,
> non-religious osgi
> > >>>> guy (I take it as a tool and not act of faith), I often do
> skip it. I
> > >> do
> > >>>> find it useful, however quite often problematic and hard to
> understand
> > >>>> (yet another non-trivial syntax in manifest to follow). On
> older
> > >>>> runtimes capabilities are not even considered. For never
> ones there
> > are
> > >>>> already existing namespaces:
> > >>>> https://www.osgi.org/capability-namespaces-reference/
> > >>>> including, one for services:
> > >>>>
> > >>
> >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> > >>>> My point is that capabilities are used to attest that
> runtime will
> > >>>> consist all necessary things in place after provisioning
> operation. It
> > >>>> does not say HOW given capabilities should be made, cause
> resolver is
> > >>>> hit before bundle gets active. It is a safety check. I'm
> fine with
> > >>>> having one, however we need to make it right to do not
> narrow use of
> > >>>> driver bundles only with our own extender.
> > >>>>
> > >>>> Beside the point, I am not sure if plc4x-api is a best
> place for osgi
> > >>>> specific logic. That is a standard dilema to address in how
> we want to
> > >>>> treat osgi and non-osgi users. :-)
> > >>>>
> > >>>> Cheers!
> > >>>> Łukasz
> > >>>>
> > >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> > >>>>> 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
> > >>>>> >> > > > >>>>>>
> > >>>>> >> > > > >>>>
> > >>>>> >> > > > >>>
> > >>>>> >> > > >
> > >>>>> >> > > >
> > >>>>> >> > > >
> > >>>>> >> > >
> > >>>>> >> >
> > >>>>> >>
> > >>>>> >
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
>
>
Re: SPI Module - OSGi Bundle
Posted by Niclas Hedhman <ni...@hedhman.org>.
Both approaches are independent of OSGi framework implementations, which is
part of the beauty of OSGi.
Lukasz puts more value on some dogmatic principle ("only interfaces in
API"), whereas I have forwarded how an OSGi bundle producer is expected to
provide it, and how an OSGi bundle consumer would expect to see it and the
added benefit that default behavior can be overridden. Lukasz uses my own
work-around (for JDBC drivers) to show me that is the way things are done.
It is not, it was a necessary hack for that time to get around the legacy
JDBC drivers out in the open, all of them without OSGi manifests.
As I said, I have no skin in the game. Only providing independent advice,
as a former OSGi expert and a keen interest in PLC4X.
// Niclas
On Thu, May 7, 2020 at 9:13 PM Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi folks,
>
> so if there is an option that doesn't tie our API and Drivers to a
> specific OSGi framework, I would prefer that.
>
> Chris
>
> Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> j.feinauer@pragmaticminds.de>:
>
> I would say that there are arguments for both cases (as ist often with
> OSGi, IMHO).
> So I see them not as right or wrong but as to different styles or
> approaches that I woudl leave up to you to decide.
>
> IMHO
> Julian
>
> Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
>
> Hi guys,
> As I am really not an expert, which approach should we use?
>
> Etienne
>
> Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <lu...@code-house.org>
> a écrit :
>
> > Hey Niclas,
> > While this code seems straight I don't think it is needed, and
> valid in
> > our case.
> > Main benefit of extender and extender based patterns is
> centralized
> > processing of drivers.
> > I am keen to keep only interfaces in the API packages and
> bundles and
> > move active parts of code (such base classes) to another place.
> It is
> > necessary to avoid creation of implementation dependency. And
> that's
> > what is in fact, promoted by shared activator class.
> >
> > Best,
> > Łukasz
> >
> >
> > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > My suggestion was;
> > > 1. Don't do the BundleTracker classes, and instead change to a
> bundle
> > > activator for each.
> > > 2. Add the "Bundle-Activator:
> org.apache.plc4x.java.osgi.DriverActivator"
> > > to the driver META/MANIFEST.MF
> > > 3. Do the equivalent for the Transports.
> > >
> > > public class DriverActivator implements BundleActivator {
> > >
> > > private ServiceRegistration<PlcDriver> reg;
> > >
> > > @Override
> > > public void start( BundleContext context ) throws
> Exception {
> > > Hashtable<String, String> props = new Hashtable<>();
> > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > driver.getProtocolCode() );
> > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > driver.getProtocolName() );
> > > reg = context.registerService( PlcDriver.class,
> driver, props );
> > > }
> > >
> > > @Override
> > > public void stop( BundleContext context ) {
> > > context.unregisterService( reg );
> > > }
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> erobinet@apache.org>
> > wrote:
> > >
> > >> Hi all,
> > >> So concretely what changes should be done so that a
> Driver/Transport
> > >> declares itself his service? Beside the changes in the
> manifest?
> > >> Etienne
> > >> On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org>
> wrote:
> > >>> Łukasz,
> > >>>
> > >>> the reason I say it is not very OSGi-y, is that the
> principle of OSGi
> > is
> > >>> that the bundle handles its own service registrations. In
> the case of
> > >> JDBC
> > >>> (I initiated that spec, and I am the founder of OPS4J as
> well as Pax
> > >>> subproject, 2005), it needed to address the problem that
> JDBC drivers
> > >>> existed and changing their build and/or manifests was
> decided to be
> > "not
> > >>> viable". The approach there is a work-around for legacy
> code, which I
> > and
> > >>> Stuart McCulloch basically invented. IIRC, this happened in
> 2007.
> > >>>
> > >>> I didn't suggest that bundles require Declarative Services.
> I suggested
> > >>> that the "inside of the loop" in Etienne's code is put into
> an
> > Activator,
> > >>> the code residing in the API and SPI bundles respectively,
> and that
> > each
> > >>> driver/transport has a "Bundle-Activator: ....." in the
> manifest
> > >>> referencing respective activator. It is not more intrusive
> than the
> > >>> Export-Package, Import-Package that will be required anyway.
> > >>>
> > >>> Advantages; It is more in the spirit of OSGi. But
> importantly, the
> > >>> driver/transport is now an active bundle, rather than a
> library bundle,
> > >> and
> > >>> in theory the start/stop of a bundle could (there might be
> other
> > reasons
> > >>> why not) turn it on/off in runtime. If special needs pop up,
> maybe to
> > >>> deploy for the OpenHAB project, it is possible to override
> the
> > >>> driver/transport with hacking the API/SPI bundles.
> > >>>
> > >>> And I can't see any disadvantages other than "need to rework
> a bit of
> > >> code".
> > >>>
> > >>> But I don't have skin in the game. Not in OSGi, not here, so
> take my
> > >>> recommendations into consideration or throw them away. I
> just got the
> > >>> impression that you didn't really get what I suggested.
> > >>>
> > >>>
> > >>> // Niclas
> > >>>
> > >>>
> > >>>
> > >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <
> luke@code-house.org>
> > >> wrote:
> > >>>
> > >>>> Hey Etienne, that's awesome piece of work. I can test it!
> :-)
> > >>>>
> > >>>> I believe that's what Etienne code does it in a valid OSGi
> way. And I
> > >> do
> > >>>> believe not because he mentioned me by name, but due to
> below
> > >>>> argumentation.
> > >>>>
> > >>>> Proposed code uses extender pattern to grab specific
> META-INF/services
> > >>>> entries and register them in OSGi service registry. If you
> will take a
> > >>>> look on following line:
> > >>>>
> > >>>>
> > >>
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > >>>> you will find that bundle is an jar which changes state to
> ACTIVE.
> > >>>> Additionally that bundle classloader is used to find
> services and that
> > >>>> bundle context is used to register services. In the end
> service which
> > >>>> appears looks like one registered by driver/transport
> module.
> > >>>>
> > >>>> The main point for above implementation is basic - getting
> the
> > standard
> > >>>> PLC4X driver JAR working in OSGi without forcing it to
> knowing too
> > much
> > >>>> about OSGi. Driver needs to ship manifest with import/export
> > statements
> > >>>> and that's it. Additionally driver does not have to have a
> XML
> > >>>> descriptor which registers service. Quite many third
> parties might be
> > >>>> supplying drivers without any or with limited knowledge of
> OSGi.
> > >>>> Do drivers have to be a service? Well, it they can still be
> a valid
> > >> OSGi
> > >>>> service, registered using any other way! OSGi aware driver
> manager
> > uses
> > >>>> OSGi services instead of static list own classloader to find
> > >>>> META-INF/services entries:
> > >>>>
> > >>>>
> > >>
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> > >>>>
> > >>>> JDBC JARs are handled in such a way already in pax-jdbc.
> Take a look
> > >> here:
> > >>>>
> > >>>>
> > >>
> >
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> > >>>> Same or very similar code can be found in apache-camel,
> which brought
> > >>>> hundreds of components to OSGi, so I believe their way can
> be seen as
> > >>>> high level guide.
> > >>>> What Etienne did is a pattern implementation.
> > >>>>
> > >>>> With regard to capabilities/requirements - this is a
> resolver puzzle.
> > >> It
> > >>>> relies on additional information. As an unbaptized,
> non-religious osgi
> > >>>> guy (I take it as a tool and not act of faith), I often do
> skip it. I
> > >> do
> > >>>> find it useful, however quite often problematic and hard to
> understand
> > >>>> (yet another non-trivial syntax in manifest to follow). On
> older
> > >>>> runtimes capabilities are not even considered. For never
> ones there
> > are
> > >>>> already existing namespaces:
> > >>>> https://www.osgi.org/capability-namespaces-reference/
> > >>>> including, one for services:
> > >>>>
> > >>
> >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> > >>>> My point is that capabilities are used to attest that
> runtime will
> > >>>> consist all necessary things in place after provisioning
> operation. It
> > >>>> does not say HOW given capabilities should be made, cause
> resolver is
> > >>>> hit before bundle gets active. It is a safety check. I'm
> fine with
> > >>>> having one, however we need to make it right to do not
> narrow use of
> > >>>> driver bundles only with our own extender.
> > >>>>
> > >>>> Beside the point, I am not sure if plc4x-api is a best
> place for osgi
> > >>>> specific logic. That is a standard dilema to address in how
> we want to
> > >>>> treat osgi and non-osgi users. :-)
> > >>>>
> > >>>> Cheers!
> > >>>> Łukasz
> > >>>>
> > >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> > >>>>> 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
> > >>>>> >> > > > >>>>>>
> > >>>>> >> > > > >>>>
> > >>>>> >> > > > >>>
> > >>>>> >> > > >
> > >>>>> >> > > >
> > >>>>> >> > > >
> > >>>>> >> > >
> > >>>>> >> >
> > >>>>> >>
> > >>>>> >
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
>
>
Re: SPI Module - OSGi Bundle
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi folks,
so if there is an option that doesn't tie our API and Drivers to a specific OSGi framework, I would prefer that.
Chris
Am 07.05.20, 12:35 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
I would say that there are arguments for both cases (as ist often with OSGi, IMHO).
So I see them not as right or wrong but as to different styles or approaches that I woudl leave up to you to decide.
IMHO
Julian
Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
Hi guys,
As I am really not an expert, which approach should we use?
Etienne
Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <lu...@code-house.org> a écrit :
> Hey Niclas,
> While this code seems straight I don't think it is needed, and valid in
> our case.
> Main benefit of extender and extender based patterns is centralized
> processing of drivers.
> I am keen to keep only interfaces in the API packages and bundles and
> move active parts of code (such base classes) to another place. It is
> necessary to avoid creation of implementation dependency. And that's
> what is in fact, promoted by shared activator class.
>
> Best,
> Łukasz
>
>
> On 06.05.2020 13:47, Niclas Hedhman wrote:
> > My suggestion was;
> > 1. Don't do the BundleTracker classes, and instead change to a bundle
> > activator for each.
> > 2. Add the "Bundle-Activator: org.apache.plc4x.java.osgi.DriverActivator"
> > to the driver META/MANIFEST.MF
> > 3. Do the equivalent for the Transports.
> >
> > public class DriverActivator implements BundleActivator {
> >
> > private ServiceRegistration<PlcDriver> reg;
> >
> > @Override
> > public void start( BundleContext context ) throws Exception {
> > Hashtable<String, String> props = new Hashtable<>();
> > props.put( OsgiDriverManager.PROTOCOL_CODE,
> driver.getProtocolCode() );
> > props.put( OsgiDriverManager.PROTOCOL_NAME,
> driver.getProtocolName() );
> > reg = context.registerService( PlcDriver.class, driver, props );
> > }
> >
> > @Override
> > public void stop( BundleContext context ) {
> > context.unregisterService( reg );
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <er...@apache.org>
> wrote:
> >
> >> Hi all,
> >> So concretely what changes should be done so that a Driver/Transport
> >> declares itself his service? Beside the changes in the manifest?
> >> Etienne
> >> On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org> wrote:
> >>> Łukasz,
> >>>
> >>> the reason I say it is not very OSGi-y, is that the principle of OSGi
> is
> >>> that the bundle handles its own service registrations. In the case of
> >> JDBC
> >>> (I initiated that spec, and I am the founder of OPS4J as well as Pax
> >>> subproject, 2005), it needed to address the problem that JDBC drivers
> >>> existed and changing their build and/or manifests was decided to be
> "not
> >>> viable". The approach there is a work-around for legacy code, which I
> and
> >>> Stuart McCulloch basically invented. IIRC, this happened in 2007.
> >>>
> >>> I didn't suggest that bundles require Declarative Services. I suggested
> >>> that the "inside of the loop" in Etienne's code is put into an
> Activator,
> >>> the code residing in the API and SPI bundles respectively, and that
> each
> >>> driver/transport has a "Bundle-Activator: ....." in the manifest
> >>> referencing respective activator. It is not more intrusive than the
> >>> Export-Package, Import-Package that will be required anyway.
> >>>
> >>> Advantages; It is more in the spirit of OSGi. But importantly, the
> >>> driver/transport is now an active bundle, rather than a library bundle,
> >> and
> >>> in theory the start/stop of a bundle could (there might be other
> reasons
> >>> why not) turn it on/off in runtime. If special needs pop up, maybe to
> >>> deploy for the OpenHAB project, it is possible to override the
> >>> driver/transport with hacking the API/SPI bundles.
> >>>
> >>> And I can't see any disadvantages other than "need to rework a bit of
> >> code".
> >>>
> >>> But I don't have skin in the game. Not in OSGi, not here, so take my
> >>> recommendations into consideration or throw them away. I just got the
> >>> impression that you didn't really get what I suggested.
> >>>
> >>>
> >>> // Niclas
> >>>
> >>>
> >>>
> >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <lu...@code-house.org>
> >> wrote:
> >>>
> >>>> Hey Etienne, that's awesome piece of work. I can test it! :-)
> >>>>
> >>>> I believe that's what Etienne code does it in a valid OSGi way. And I
> >> do
> >>>> believe not because he mentioned me by name, but due to below
> >>>> argumentation.
> >>>>
> >>>> Proposed code uses extender pattern to grab specific META-INF/services
> >>>> entries and register them in OSGi service registry. If you will take a
> >>>> look on following line:
> >>>>
> >>>>
> >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> >>>> you will find that bundle is an jar which changes state to ACTIVE.
> >>>> Additionally that bundle classloader is used to find services and that
> >>>> bundle context is used to register services. In the end service which
> >>>> appears looks like one registered by driver/transport module.
> >>>>
> >>>> The main point for above implementation is basic - getting the
> standard
> >>>> PLC4X driver JAR working in OSGi without forcing it to knowing too
> much
> >>>> about OSGi. Driver needs to ship manifest with import/export
> statements
> >>>> and that's it. Additionally driver does not have to have a XML
> >>>> descriptor which registers service. Quite many third parties might be
> >>>> supplying drivers without any or with limited knowledge of OSGi.
> >>>> Do drivers have to be a service? Well, it they can still be a valid
> >> OSGi
> >>>> service, registered using any other way! OSGi aware driver manager
> uses
> >>>> OSGi services instead of static list own classloader to find
> >>>> META-INF/services entries:
> >>>>
> >>>>
> >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> >>>>
> >>>> JDBC JARs are handled in such a way already in pax-jdbc. Take a look
> >> here:
> >>>>
> >>>>
> >>
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> >>>> Same or very similar code can be found in apache-camel, which brought
> >>>> hundreds of components to OSGi, so I believe their way can be seen as
> >>>> high level guide.
> >>>> What Etienne did is a pattern implementation.
> >>>>
> >>>> With regard to capabilities/requirements - this is a resolver puzzle.
> >> It
> >>>> relies on additional information. As an unbaptized, non-religious osgi
> >>>> guy (I take it as a tool and not act of faith), I often do skip it. I
> >> do
> >>>> find it useful, however quite often problematic and hard to understand
> >>>> (yet another non-trivial syntax in manifest to follow). On older
> >>>> runtimes capabilities are not even considered. For never ones there
> are
> >>>> already existing namespaces:
> >>>> https://www.osgi.org/capability-namespaces-reference/
> >>>> including, one for services:
> >>>>
> >>
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> >>>> My point is that capabilities are used to attest that runtime will
> >>>> consist all necessary things in place after provisioning operation. It
> >>>> does not say HOW given capabilities should be made, cause resolver is
> >>>> hit before bundle gets active. It is a safety check. I'm fine with
> >>>> having one, however we need to make it right to do not narrow use of
> >>>> driver bundles only with our own extender.
> >>>>
> >>>> Beside the point, I am not sure if plc4x-api is a best place for osgi
> >>>> specific logic. That is a standard dilema to address in how we want to
> >>>> treat osgi and non-osgi users. :-)
> >>>>
> >>>> Cheers!
> >>>> Łukasz
> >>>>
> >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> >>>>> 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" <ni...@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
> >>>>> >> > > > >>>>>>
> >>>>> >> > > > >>>>
> >>>>> >> > > > >>>
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > >
> >>>>> >> >
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: SPI Module - OSGi Bundle
Posted by Julian Feinauer <j....@pragmaticminds.de>.
I would say that there are arguments for both cases (as ist often with OSGi, IMHO).
So I see them not as right or wrong but as to different styles or approaches that I woudl leave up to you to decide.
IMHO
Julian
Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
Hi guys,
As I am really not an expert, which approach should we use?
Etienne
Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <lu...@code-house.org> a écrit :
> Hey Niclas,
> While this code seems straight I don't think it is needed, and valid in
> our case.
> Main benefit of extender and extender based patterns is centralized
> processing of drivers.
> I am keen to keep only interfaces in the API packages and bundles and
> move active parts of code (such base classes) to another place. It is
> necessary to avoid creation of implementation dependency. And that's
> what is in fact, promoted by shared activator class.
>
> Best,
> Łukasz
>
>
> On 06.05.2020 13:47, Niclas Hedhman wrote:
> > My suggestion was;
> > 1. Don't do the BundleTracker classes, and instead change to a bundle
> > activator for each.
> > 2. Add the "Bundle-Activator: org.apache.plc4x.java.osgi.DriverActivator"
> > to the driver META/MANIFEST.MF
> > 3. Do the equivalent for the Transports.
> >
> > public class DriverActivator implements BundleActivator {
> >
> > private ServiceRegistration<PlcDriver> reg;
> >
> > @Override
> > public void start( BundleContext context ) throws Exception {
> > Hashtable<String, String> props = new Hashtable<>();
> > props.put( OsgiDriverManager.PROTOCOL_CODE,
> driver.getProtocolCode() );
> > props.put( OsgiDriverManager.PROTOCOL_NAME,
> driver.getProtocolName() );
> > reg = context.registerService( PlcDriver.class, driver, props );
> > }
> >
> > @Override
> > public void stop( BundleContext context ) {
> > context.unregisterService( reg );
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <er...@apache.org>
> wrote:
> >
> >> Hi all,
> >> So concretely what changes should be done so that a Driver/Transport
> >> declares itself his service? Beside the changes in the manifest?
> >> Etienne
> >> On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org> wrote:
> >>> Łukasz,
> >>>
> >>> the reason I say it is not very OSGi-y, is that the principle of OSGi
> is
> >>> that the bundle handles its own service registrations. In the case of
> >> JDBC
> >>> (I initiated that spec, and I am the founder of OPS4J as well as Pax
> >>> subproject, 2005), it needed to address the problem that JDBC drivers
> >>> existed and changing their build and/or manifests was decided to be
> "not
> >>> viable". The approach there is a work-around for legacy code, which I
> and
> >>> Stuart McCulloch basically invented. IIRC, this happened in 2007.
> >>>
> >>> I didn't suggest that bundles require Declarative Services. I suggested
> >>> that the "inside of the loop" in Etienne's code is put into an
> Activator,
> >>> the code residing in the API and SPI bundles respectively, and that
> each
> >>> driver/transport has a "Bundle-Activator: ....." in the manifest
> >>> referencing respective activator. It is not more intrusive than the
> >>> Export-Package, Import-Package that will be required anyway.
> >>>
> >>> Advantages; It is more in the spirit of OSGi. But importantly, the
> >>> driver/transport is now an active bundle, rather than a library bundle,
> >> and
> >>> in theory the start/stop of a bundle could (there might be other
> reasons
> >>> why not) turn it on/off in runtime. If special needs pop up, maybe to
> >>> deploy for the OpenHAB project, it is possible to override the
> >>> driver/transport with hacking the API/SPI bundles.
> >>>
> >>> And I can't see any disadvantages other than "need to rework a bit of
> >> code".
> >>>
> >>> But I don't have skin in the game. Not in OSGi, not here, so take my
> >>> recommendations into consideration or throw them away. I just got the
> >>> impression that you didn't really get what I suggested.
> >>>
> >>>
> >>> // Niclas
> >>>
> >>>
> >>>
> >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <lu...@code-house.org>
> >> wrote:
> >>>
> >>>> Hey Etienne, that's awesome piece of work. I can test it! :-)
> >>>>
> >>>> I believe that's what Etienne code does it in a valid OSGi way. And I
> >> do
> >>>> believe not because he mentioned me by name, but due to below
> >>>> argumentation.
> >>>>
> >>>> Proposed code uses extender pattern to grab specific META-INF/services
> >>>> entries and register them in OSGi service registry. If you will take a
> >>>> look on following line:
> >>>>
> >>>>
> >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> >>>> you will find that bundle is an jar which changes state to ACTIVE.
> >>>> Additionally that bundle classloader is used to find services and that
> >>>> bundle context is used to register services. In the end service which
> >>>> appears looks like one registered by driver/transport module.
> >>>>
> >>>> The main point for above implementation is basic - getting the
> standard
> >>>> PLC4X driver JAR working in OSGi without forcing it to knowing too
> much
> >>>> about OSGi. Driver needs to ship manifest with import/export
> statements
> >>>> and that's it. Additionally driver does not have to have a XML
> >>>> descriptor which registers service. Quite many third parties might be
> >>>> supplying drivers without any or with limited knowledge of OSGi.
> >>>> Do drivers have to be a service? Well, it they can still be a valid
> >> OSGi
> >>>> service, registered using any other way! OSGi aware driver manager
> uses
> >>>> OSGi services instead of static list own classloader to find
> >>>> META-INF/services entries:
> >>>>
> >>>>
> >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> >>>>
> >>>> JDBC JARs are handled in such a way already in pax-jdbc. Take a look
> >> here:
> >>>>
> >>>>
> >>
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> >>>> Same or very similar code can be found in apache-camel, which brought
> >>>> hundreds of components to OSGi, so I believe their way can be seen as
> >>>> high level guide.
> >>>> What Etienne did is a pattern implementation.
> >>>>
> >>>> With regard to capabilities/requirements - this is a resolver puzzle.
> >> It
> >>>> relies on additional information. As an unbaptized, non-religious osgi
> >>>> guy (I take it as a tool and not act of faith), I often do skip it. I
> >> do
> >>>> find it useful, however quite often problematic and hard to understand
> >>>> (yet another non-trivial syntax in manifest to follow). On older
> >>>> runtimes capabilities are not even considered. For never ones there
> are
> >>>> already existing namespaces:
> >>>> https://www.osgi.org/capability-namespaces-reference/
> >>>> including, one for services:
> >>>>
> >>
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> >>>> My point is that capabilities are used to attest that runtime will
> >>>> consist all necessary things in place after provisioning operation. It
> >>>> does not say HOW given capabilities should be made, cause resolver is
> >>>> hit before bundle gets active. It is a safety check. I'm fine with
> >>>> having one, however we need to make it right to do not narrow use of
> >>>> driver bundles only with our own extender.
> >>>>
> >>>> Beside the point, I am not sure if plc4x-api is a best place for osgi
> >>>> specific logic. That is a standard dilema to address in how we want to
> >>>> treat osgi and non-osgi users. :-)
> >>>>
> >>>> Cheers!
> >>>> Łukasz
> >>>>
> >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> >>>>> 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" <ni...@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
> >>>>> >> > > > >>>>>>
> >>>>> >> > > > >>>>
> >>>>> >> > > > >>>
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > >
> >>>>> >> >
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: SPI Module - OSGi Bundle
Posted by "Robinet, Etienne" <43...@etu.he2b.be>.
Hi guys,
As I am really not an expert, which approach should we use?
Etienne
Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <lu...@code-house.org> a écrit :
> Hey Niclas,
> While this code seems straight I don't think it is needed, and valid in
> our case.
> Main benefit of extender and extender based patterns is centralized
> processing of drivers.
> I am keen to keep only interfaces in the API packages and bundles and
> move active parts of code (such base classes) to another place. It is
> necessary to avoid creation of implementation dependency. And that's
> what is in fact, promoted by shared activator class.
>
> Best,
> Łukasz
>
>
> On 06.05.2020 13:47, Niclas Hedhman wrote:
> > My suggestion was;
> > 1. Don't do the BundleTracker classes, and instead change to a bundle
> > activator for each.
> > 2. Add the "Bundle-Activator: org.apache.plc4x.java.osgi.DriverActivator"
> > to the driver META/MANIFEST.MF
> > 3. Do the equivalent for the Transports.
> >
> > public class DriverActivator implements BundleActivator {
> >
> > private ServiceRegistration<PlcDriver> reg;
> >
> > @Override
> > public void start( BundleContext context ) throws Exception {
> > Hashtable<String, String> props = new Hashtable<>();
> > props.put( OsgiDriverManager.PROTOCOL_CODE,
> driver.getProtocolCode() );
> > props.put( OsgiDriverManager.PROTOCOL_NAME,
> driver.getProtocolName() );
> > reg = context.registerService( PlcDriver.class, driver, props );
> > }
> >
> > @Override
> > public void stop( BundleContext context ) {
> > context.unregisterService( reg );
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <er...@apache.org>
> wrote:
> >
> >> Hi all,
> >> So concretely what changes should be done so that a Driver/Transport
> >> declares itself his service? Beside the changes in the manifest?
> >> Etienne
> >> On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org> wrote:
> >>> Łukasz,
> >>>
> >>> the reason I say it is not very OSGi-y, is that the principle of OSGi
> is
> >>> that the bundle handles its own service registrations. In the case of
> >> JDBC
> >>> (I initiated that spec, and I am the founder of OPS4J as well as Pax
> >>> subproject, 2005), it needed to address the problem that JDBC drivers
> >>> existed and changing their build and/or manifests was decided to be
> "not
> >>> viable". The approach there is a work-around for legacy code, which I
> and
> >>> Stuart McCulloch basically invented. IIRC, this happened in 2007.
> >>>
> >>> I didn't suggest that bundles require Declarative Services. I suggested
> >>> that the "inside of the loop" in Etienne's code is put into an
> Activator,
> >>> the code residing in the API and SPI bundles respectively, and that
> each
> >>> driver/transport has a "Bundle-Activator: ....." in the manifest
> >>> referencing respective activator. It is not more intrusive than the
> >>> Export-Package, Import-Package that will be required anyway.
> >>>
> >>> Advantages; It is more in the spirit of OSGi. But importantly, the
> >>> driver/transport is now an active bundle, rather than a library bundle,
> >> and
> >>> in theory the start/stop of a bundle could (there might be other
> reasons
> >>> why not) turn it on/off in runtime. If special needs pop up, maybe to
> >>> deploy for the OpenHAB project, it is possible to override the
> >>> driver/transport with hacking the API/SPI bundles.
> >>>
> >>> And I can't see any disadvantages other than "need to rework a bit of
> >> code".
> >>>
> >>> But I don't have skin in the game. Not in OSGi, not here, so take my
> >>> recommendations into consideration or throw them away. I just got the
> >>> impression that you didn't really get what I suggested.
> >>>
> >>>
> >>> // Niclas
> >>>
> >>>
> >>>
> >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <lu...@code-house.org>
> >> wrote:
> >>>
> >>>> Hey Etienne, that's awesome piece of work. I can test it! :-)
> >>>>
> >>>> I believe that's what Etienne code does it in a valid OSGi way. And I
> >> do
> >>>> believe not because he mentioned me by name, but due to below
> >>>> argumentation.
> >>>>
> >>>> Proposed code uses extender pattern to grab specific META-INF/services
> >>>> entries and register them in OSGi service registry. If you will take a
> >>>> look on following line:
> >>>>
> >>>>
> >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> >>>> you will find that bundle is an jar which changes state to ACTIVE.
> >>>> Additionally that bundle classloader is used to find services and that
> >>>> bundle context is used to register services. In the end service which
> >>>> appears looks like one registered by driver/transport module.
> >>>>
> >>>> The main point for above implementation is basic - getting the
> standard
> >>>> PLC4X driver JAR working in OSGi without forcing it to knowing too
> much
> >>>> about OSGi. Driver needs to ship manifest with import/export
> statements
> >>>> and that's it. Additionally driver does not have to have a XML
> >>>> descriptor which registers service. Quite many third parties might be
> >>>> supplying drivers without any or with limited knowledge of OSGi.
> >>>> Do drivers have to be a service? Well, it they can still be a valid
> >> OSGi
> >>>> service, registered using any other way! OSGi aware driver manager
> uses
> >>>> OSGi services instead of static list own classloader to find
> >>>> META-INF/services entries:
> >>>>
> >>>>
> >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> >>>>
> >>>> JDBC JARs are handled in such a way already in pax-jdbc. Take a look
> >> here:
> >>>>
> >>>>
> >>
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> >>>> Same or very similar code can be found in apache-camel, which brought
> >>>> hundreds of components to OSGi, so I believe their way can be seen as
> >>>> high level guide.
> >>>> What Etienne did is a pattern implementation.
> >>>>
> >>>> With regard to capabilities/requirements - this is a resolver puzzle.
> >> It
> >>>> relies on additional information. As an unbaptized, non-religious osgi
> >>>> guy (I take it as a tool and not act of faith), I often do skip it. I
> >> do
> >>>> find it useful, however quite often problematic and hard to understand
> >>>> (yet another non-trivial syntax in manifest to follow). On older
> >>>> runtimes capabilities are not even considered. For never ones there
> are
> >>>> already existing namespaces:
> >>>> https://www.osgi.org/capability-namespaces-reference/
> >>>> including, one for services:
> >>>>
> >>
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> >>>> My point is that capabilities are used to attest that runtime will
> >>>> consist all necessary things in place after provisioning operation. It
> >>>> does not say HOW given capabilities should be made, cause resolver is
> >>>> hit before bundle gets active. It is a safety check. I'm fine with
> >>>> having one, however we need to make it right to do not narrow use of
> >>>> driver bundles only with our own extender.
> >>>>
> >>>> Beside the point, I am not sure if plc4x-api is a best place for osgi
> >>>> specific logic. That is a standard dilema to address in how we want to
> >>>> treat osgi and non-osgi users. :-)
> >>>>
> >>>> Cheers!
> >>>> Łukasz
> >>>>
> >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> >>>>> 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" <ni...@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
> >>>>> >> > > > >>>>>>
> >>>>> >> > > > >>>>
> >>>>> >> > > > >>>
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > >
> >>>>> >> >
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: SPI Module - OSGi Bundle
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey Niclas,
While this code seems straight I don't think it is needed, and valid in
our case.
Main benefit of extender and extender based patterns is centralized
processing of drivers.
I am keen to keep only interfaces in the API packages and bundles and
move active parts of code (such base classes) to another place. It is
necessary to avoid creation of implementation dependency. And that's
what is in fact, promoted by shared activator class.
Best,
Łukasz
On 06.05.2020 13:47, Niclas Hedhman wrote:
> My suggestion was;
> 1. Don't do the BundleTracker classes, and instead change to a bundle
> activator for each.
> 2. Add the "Bundle-Activator: org.apache.plc4x.java.osgi.DriverActivator"
> to the driver META/MANIFEST.MF
> 3. Do the equivalent for the Transports.
>
> public class DriverActivator implements BundleActivator {
>
> private ServiceRegistration<PlcDriver> reg;
>
> @Override
> public void start( BundleContext context ) throws Exception {
> Hashtable<String, String> props = new Hashtable<>();
> props.put( OsgiDriverManager.PROTOCOL_CODE, driver.getProtocolCode() );
> props.put( OsgiDriverManager.PROTOCOL_NAME, driver.getProtocolName() );
> reg = context.registerService( PlcDriver.class, driver, props );
> }
>
> @Override
> public void stop( BundleContext context ) {
> context.unregisterService( reg );
> }
> }
>
>
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <er...@apache.org> wrote:
>
>> Hi all,
>> So concretely what changes should be done so that a Driver/Transport
>> declares itself his service? Beside the changes in the manifest?
>> Etienne
>> On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org> wrote:
>>> Łukasz,
>>>
>>> the reason I say it is not very OSGi-y, is that the principle of OSGi is
>>> that the bundle handles its own service registrations. In the case of
>> JDBC
>>> (I initiated that spec, and I am the founder of OPS4J as well as Pax
>>> subproject, 2005), it needed to address the problem that JDBC drivers
>>> existed and changing their build and/or manifests was decided to be "not
>>> viable". The approach there is a work-around for legacy code, which I and
>>> Stuart McCulloch basically invented. IIRC, this happened in 2007.
>>>
>>> I didn't suggest that bundles require Declarative Services. I suggested
>>> that the "inside of the loop" in Etienne's code is put into an Activator,
>>> the code residing in the API and SPI bundles respectively, and that each
>>> driver/transport has a "Bundle-Activator: ....." in the manifest
>>> referencing respective activator. It is not more intrusive than the
>>> Export-Package, Import-Package that will be required anyway.
>>>
>>> Advantages; It is more in the spirit of OSGi. But importantly, the
>>> driver/transport is now an active bundle, rather than a library bundle,
>> and
>>> in theory the start/stop of a bundle could (there might be other reasons
>>> why not) turn it on/off in runtime. If special needs pop up, maybe to
>>> deploy for the OpenHAB project, it is possible to override the
>>> driver/transport with hacking the API/SPI bundles.
>>>
>>> And I can't see any disadvantages other than "need to rework a bit of
>> code".
>>>
>>> But I don't have skin in the game. Not in OSGi, not here, so take my
>>> recommendations into consideration or throw them away. I just got the
>>> impression that you didn't really get what I suggested.
>>>
>>>
>>> // Niclas
>>>
>>>
>>>
>>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <lu...@code-house.org>
>> wrote:
>>>
>>>> Hey Etienne, that's awesome piece of work. I can test it! :-)
>>>>
>>>> I believe that's what Etienne code does it in a valid OSGi way. And I
>> do
>>>> believe not because he mentioned me by name, but due to below
>>>> argumentation.
>>>>
>>>> Proposed code uses extender pattern to grab specific META-INF/services
>>>> entries and register them in OSGi service registry. If you will take a
>>>> look on following line:
>>>>
>>>>
>> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
>>>> you will find that bundle is an jar which changes state to ACTIVE.
>>>> Additionally that bundle classloader is used to find services and that
>>>> bundle context is used to register services. In the end service which
>>>> appears looks like one registered by driver/transport module.
>>>>
>>>> The main point for above implementation is basic - getting the standard
>>>> PLC4X driver JAR working in OSGi without forcing it to knowing too much
>>>> about OSGi. Driver needs to ship manifest with import/export statements
>>>> and that's it. Additionally driver does not have to have a XML
>>>> descriptor which registers service. Quite many third parties might be
>>>> supplying drivers without any or with limited knowledge of OSGi.
>>>> Do drivers have to be a service? Well, it they can still be a valid
>> OSGi
>>>> service, registered using any other way! OSGi aware driver manager uses
>>>> OSGi services instead of static list own classloader to find
>>>> META-INF/services entries:
>>>>
>>>>
>> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
>>>>
>>>> JDBC JARs are handled in such a way already in pax-jdbc. Take a look
>> here:
>>>>
>>>>
>> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
>>>> Same or very similar code can be found in apache-camel, which brought
>>>> hundreds of components to OSGi, so I believe their way can be seen as
>>>> high level guide.
>>>> What Etienne did is a pattern implementation.
>>>>
>>>> With regard to capabilities/requirements - this is a resolver puzzle.
>> It
>>>> relies on additional information. As an unbaptized, non-religious osgi
>>>> guy (I take it as a tool and not act of faith), I often do skip it. I
>> do
>>>> find it useful, however quite often problematic and hard to understand
>>>> (yet another non-trivial syntax in manifest to follow). On older
>>>> runtimes capabilities are not even considered. For never ones there are
>>>> already existing namespaces:
>>>> https://www.osgi.org/capability-namespaces-reference/
>>>> including, one for services:
>>>>
>> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
>>>> My point is that capabilities are used to attest that runtime will
>>>> consist all necessary things in place after provisioning operation. It
>>>> does not say HOW given capabilities should be made, cause resolver is
>>>> hit before bundle gets active. It is a safety check. I'm fine with
>>>> having one, however we need to make it right to do not narrow use of
>>>> driver bundles only with our own extender.
>>>>
>>>> Beside the point, I am not sure if plc4x-api is a best place for osgi
>>>> specific logic. That is a standard dilema to address in how we want to
>>>> treat osgi and non-osgi users. :-)
>>>>
>>>> Cheers!
>>>> Łukasz
>>>>
>>>> On 05.05.2020 12:34, Julian Feinauer wrote:
>>>>> 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" <ni...@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
>>>>> >> > > > >>>>>>
>>>>> >> > > > >>>>
>>>>> >> > > > >>>
>>>>> >> > > >
>>>>> >> > > >
>>>>> >> > > >
>>>>> >> > >
>>>>> >> >
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>
>>
>
Re: SPI Module - OSGi Bundle
Posted by Niclas Hedhman <ni...@hedhman.org>.
My suggestion was;
1. Don't do the BundleTracker classes, and instead change to a bundle
activator for each.
2. Add the "Bundle-Activator: org.apache.plc4x.java.osgi.DriverActivator"
to the driver META/MANIFEST.MF
3. Do the equivalent for the Transports.
public class DriverActivator implements BundleActivator {
private ServiceRegistration<PlcDriver> reg;
@Override
public void start( BundleContext context ) throws Exception {
Hashtable<String, String> props = new Hashtable<>();
props.put( OsgiDriverManager.PROTOCOL_CODE, driver.getProtocolCode() );
props.put( OsgiDriverManager.PROTOCOL_NAME, driver.getProtocolName() );
reg = context.registerService( PlcDriver.class, driver, props );
}
@Override
public void stop( BundleContext context ) {
context.unregisterService( reg );
}
}
On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <er...@apache.org> wrote:
> Hi all,
> So concretely what changes should be done so that a Driver/Transport
> declares itself his service? Beside the changes in the manifest?
> Etienne
> On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org> wrote:
> > Łukasz,
> >
> > the reason I say it is not very OSGi-y, is that the principle of OSGi is
> > that the bundle handles its own service registrations. In the case of
> JDBC
> > (I initiated that spec, and I am the founder of OPS4J as well as Pax
> > subproject, 2005), it needed to address the problem that JDBC drivers
> > existed and changing their build and/or manifests was decided to be "not
> > viable". The approach there is a work-around for legacy code, which I and
> > Stuart McCulloch basically invented. IIRC, this happened in 2007.
> >
> > I didn't suggest that bundles require Declarative Services. I suggested
> > that the "inside of the loop" in Etienne's code is put into an Activator,
> > the code residing in the API and SPI bundles respectively, and that each
> > driver/transport has a "Bundle-Activator: ....." in the manifest
> > referencing respective activator. It is not more intrusive than the
> > Export-Package, Import-Package that will be required anyway.
> >
> > Advantages; It is more in the spirit of OSGi. But importantly, the
> > driver/transport is now an active bundle, rather than a library bundle,
> and
> > in theory the start/stop of a bundle could (there might be other reasons
> > why not) turn it on/off in runtime. If special needs pop up, maybe to
> > deploy for the OpenHAB project, it is possible to override the
> > driver/transport with hacking the API/SPI bundles.
> >
> > And I can't see any disadvantages other than "need to rework a bit of
> code".
> >
> > But I don't have skin in the game. Not in OSGi, not here, so take my
> > recommendations into consideration or throw them away. I just got the
> > impression that you didn't really get what I suggested.
> >
> >
> > // Niclas
> >
> >
> >
> > On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <lu...@code-house.org>
> wrote:
> >
> > > Hey Etienne, that's awesome piece of work. I can test it! :-)
> > >
> > > I believe that's what Etienne code does it in a valid OSGi way. And I
> do
> > > believe not because he mentioned me by name, but due to below
> > > argumentation.
> > >
> > > Proposed code uses extender pattern to grab specific META-INF/services
> > > entries and register them in OSGi service registry. If you will take a
> > > look on following line:
> > >
> > >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > > you will find that bundle is an jar which changes state to ACTIVE.
> > > Additionally that bundle classloader is used to find services and that
> > > bundle context is used to register services. In the end service which
> > > appears looks like one registered by driver/transport module.
> > >
> > > The main point for above implementation is basic - getting the standard
> > > PLC4X driver JAR working in OSGi without forcing it to knowing too much
> > > about OSGi. Driver needs to ship manifest with import/export statements
> > > and that's it. Additionally driver does not have to have a XML
> > > descriptor which registers service. Quite many third parties might be
> > > supplying drivers without any or with limited knowledge of OSGi.
> > > Do drivers have to be a service? Well, it they can still be a valid
> OSGi
> > > service, registered using any other way! OSGi aware driver manager uses
> > > OSGi services instead of static list own classloader to find
> > > META-INF/services entries:
> > >
> > >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> > >
> > > JDBC JARs are handled in such a way already in pax-jdbc. Take a look
> here:
> > >
> > >
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> > > Same or very similar code can be found in apache-camel, which brought
> > > hundreds of components to OSGi, so I believe their way can be seen as
> > > high level guide.
> > > What Etienne did is a pattern implementation.
> > >
> > > With regard to capabilities/requirements - this is a resolver puzzle.
> It
> > > relies on additional information. As an unbaptized, non-religious osgi
> > > guy (I take it as a tool and not act of faith), I often do skip it. I
> do
> > > find it useful, however quite often problematic and hard to understand
> > > (yet another non-trivial syntax in manifest to follow). On older
> > > runtimes capabilities are not even considered. For never ones there are
> > > already existing namespaces:
> > > https://www.osgi.org/capability-namespaces-reference/
> > > including, one for services:
> > >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> > > My point is that capabilities are used to attest that runtime will
> > > consist all necessary things in place after provisioning operation. It
> > > does not say HOW given capabilities should be made, cause resolver is
> > > hit before bundle gets active. It is a safety check. I'm fine with
> > > having one, however we need to make it right to do not narrow use of
> > > driver bundles only with our own extender.
> > >
> > > Beside the point, I am not sure if plc4x-api is a best place for osgi
> > > specific logic. That is a standard dilema to address in how we want to
> > > treat osgi and non-osgi users. :-)
> > >
> > > Cheers!
> > > Łukasz
> > >
> > > On 05.05.2020 12:34, Julian Feinauer wrote:
> > > > 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" <ni...@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
> > > > >> > > > >>>>>>
> > > > >> > > > >>>>
> > > > >> > > > >>>
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: SPI Module - OSGi Bundle
Posted by Etienne Robinet <er...@apache.org>.
Hi all,
So concretely what changes should be done so that a Driver/Transport declares itself his service? Beside the changes in the manifest?
Etienne
On 2020/05/06 01:26:42, Niclas Hedhman <ni...@hedhman.org> wrote:
> Łukasz,
>
> the reason I say it is not very OSGi-y, is that the principle of OSGi is
> that the bundle handles its own service registrations. In the case of JDBC
> (I initiated that spec, and I am the founder of OPS4J as well as Pax
> subproject, 2005), it needed to address the problem that JDBC drivers
> existed and changing their build and/or manifests was decided to be "not
> viable". The approach there is a work-around for legacy code, which I and
> Stuart McCulloch basically invented. IIRC, this happened in 2007.
>
> I didn't suggest that bundles require Declarative Services. I suggested
> that the "inside of the loop" in Etienne's code is put into an Activator,
> the code residing in the API and SPI bundles respectively, and that each
> driver/transport has a "Bundle-Activator: ....." in the manifest
> referencing respective activator. It is not more intrusive than the
> Export-Package, Import-Package that will be required anyway.
>
> Advantages; It is more in the spirit of OSGi. But importantly, the
> driver/transport is now an active bundle, rather than a library bundle, and
> in theory the start/stop of a bundle could (there might be other reasons
> why not) turn it on/off in runtime. If special needs pop up, maybe to
> deploy for the OpenHAB project, it is possible to override the
> driver/transport with hacking the API/SPI bundles.
>
> And I can't see any disadvantages other than "need to rework a bit of code".
>
> But I don't have skin in the game. Not in OSGi, not here, so take my
> recommendations into consideration or throw them away. I just got the
> impression that you didn't really get what I suggested.
>
>
> // Niclas
>
>
>
> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <lu...@code-house.org> wrote:
>
> > Hey Etienne, that's awesome piece of work. I can test it! :-)
> >
> > I believe that's what Etienne code does it in a valid OSGi way. And I do
> > believe not because he mentioned me by name, but due to below
> > argumentation.
> >
> > Proposed code uses extender pattern to grab specific META-INF/services
> > entries and register them in OSGi service registry. If you will take a
> > look on following line:
> >
> > https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > you will find that bundle is an jar which changes state to ACTIVE.
> > Additionally that bundle classloader is used to find services and that
> > bundle context is used to register services. In the end service which
> > appears looks like one registered by driver/transport module.
> >
> > The main point for above implementation is basic - getting the standard
> > PLC4X driver JAR working in OSGi without forcing it to knowing too much
> > about OSGi. Driver needs to ship manifest with import/export statements
> > and that's it. Additionally driver does not have to have a XML
> > descriptor which registers service. Quite many third parties might be
> > supplying drivers without any or with limited knowledge of OSGi.
> > Do drivers have to be a service? Well, it they can still be a valid OSGi
> > service, registered using any other way! OSGi aware driver manager uses
> > OSGi services instead of static list own classloader to find
> > META-INF/services entries:
> >
> > https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> >
> > JDBC JARs are handled in such a way already in pax-jdbc. Take a look here:
> >
> > https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> > Same or very similar code can be found in apache-camel, which brought
> > hundreds of components to OSGi, so I believe their way can be seen as
> > high level guide.
> > What Etienne did is a pattern implementation.
> >
> > With regard to capabilities/requirements - this is a resolver puzzle. It
> > relies on additional information. As an unbaptized, non-religious osgi
> > guy (I take it as a tool and not act of faith), I often do skip it. I do
> > find it useful, however quite often problematic and hard to understand
> > (yet another non-trivial syntax in manifest to follow). On older
> > runtimes capabilities are not even considered. For never ones there are
> > already existing namespaces:
> > https://www.osgi.org/capability-namespaces-reference/
> > including, one for services:
> > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> > My point is that capabilities are used to attest that runtime will
> > consist all necessary things in place after provisioning operation. It
> > does not say HOW given capabilities should be made, cause resolver is
> > hit before bundle gets active. It is a safety check. I'm fine with
> > having one, however we need to make it right to do not narrow use of
> > driver bundles only with our own extender.
> >
> > Beside the point, I am not sure if plc4x-api is a best place for osgi
> > specific logic. That is a standard dilema to address in how we want to
> > treat osgi and non-osgi users. :-)
> >
> > Cheers!
> > Łukasz
> >
> > On 05.05.2020 12:34, Julian Feinauer wrote:
> > > 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" <ni...@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 <ni...@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 <ni...@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
> > > >> > > > >>>>>>
> > > >> > > > >>>>
> > > >> > > > >>>
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: SPI Module - OSGi Bundle
Posted by Niclas Hedhman <ni...@hedhman.org>.
Łukasz,
the reason I say it is not very OSGi-y, is that the principle of OSGi is
that the bundle handles its own service registrations. In the case of JDBC
(I initiated that spec, and I am the founder of OPS4J as well as Pax
subproject, 2005), it needed to address the problem that JDBC drivers
existed and changing their build and/or manifests was decided to be "not
viable". The approach there is a work-around for legacy code, which I and
Stuart McCulloch basically invented. IIRC, this happened in 2007.
I didn't suggest that bundles require Declarative Services. I suggested
that the "inside of the loop" in Etienne's code is put into an Activator,
the code residing in the API and SPI bundles respectively, and that each
driver/transport has a "Bundle-Activator: ....." in the manifest
referencing respective activator. It is not more intrusive than the
Export-Package, Import-Package that will be required anyway.
Advantages; It is more in the spirit of OSGi. But importantly, the
driver/transport is now an active bundle, rather than a library bundle, and
in theory the start/stop of a bundle could (there might be other reasons
why not) turn it on/off in runtime. If special needs pop up, maybe to
deploy for the OpenHAB project, it is possible to override the
driver/transport with hacking the API/SPI bundles.
And I can't see any disadvantages other than "need to rework a bit of code".
But I don't have skin in the game. Not in OSGi, not here, so take my
recommendations into consideration or throw them away. I just got the
impression that you didn't really get what I suggested.
// Niclas
On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <lu...@code-house.org> wrote:
> Hey Etienne, that's awesome piece of work. I can test it! :-)
>
> I believe that's what Etienne code does it in a valid OSGi way. And I do
> believe not because he mentioned me by name, but due to below
> argumentation.
>
> Proposed code uses extender pattern to grab specific META-INF/services
> entries and register them in OSGi service registry. If you will take a
> look on following line:
>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> you will find that bundle is an jar which changes state to ACTIVE.
> Additionally that bundle classloader is used to find services and that
> bundle context is used to register services. In the end service which
> appears looks like one registered by driver/transport module.
>
> The main point for above implementation is basic - getting the standard
> PLC4X driver JAR working in OSGi without forcing it to knowing too much
> about OSGi. Driver needs to ship manifest with import/export statements
> and that's it. Additionally driver does not have to have a XML
> descriptor which registers service. Quite many third parties might be
> supplying drivers without any or with limited knowledge of OSGi.
> Do drivers have to be a service? Well, it they can still be a valid OSGi
> service, registered using any other way! OSGi aware driver manager uses
> OSGi services instead of static list own classloader to find
> META-INF/services entries:
>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
>
> JDBC JARs are handled in such a way already in pax-jdbc. Take a look here:
>
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> Same or very similar code can be found in apache-camel, which brought
> hundreds of components to OSGi, so I believe their way can be seen as
> high level guide.
> What Etienne did is a pattern implementation.
>
> With regard to capabilities/requirements - this is a resolver puzzle. It
> relies on additional information. As an unbaptized, non-religious osgi
> guy (I take it as a tool and not act of faith), I often do skip it. I do
> find it useful, however quite often problematic and hard to understand
> (yet another non-trivial syntax in manifest to follow). On older
> runtimes capabilities are not even considered. For never ones there are
> already existing namespaces:
> https://www.osgi.org/capability-namespaces-reference/
> including, one for services:
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> My point is that capabilities are used to attest that runtime will
> consist all necessary things in place after provisioning operation. It
> does not say HOW given capabilities should be made, cause resolver is
> hit before bundle gets active. It is a safety check. I'm fine with
> having one, however we need to make it right to do not narrow use of
> driver bundles only with our own extender.
>
> Beside the point, I am not sure if plc4x-api is a best place for osgi
> specific logic. That is a standard dilema to address in how we want to
> treat osgi and non-osgi users. :-)
>
> Cheers!
> Łukasz
>
> On 05.05.2020 12:34, Julian Feinauer wrote:
> > 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" <ni...@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 <ni...@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 <ni...@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
> > >> > > > >>>>>>
> > >> > > > >>>>
> > >> > > > >>>
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: SPI Module - OSGi Bundle
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey Etienne, that's awesome piece of work. I can test it! :-)
I believe that's what Etienne code does it in a valid OSGi way. And I do
believe not because he mentioned me by name, but due to below argumentation.
Proposed code uses extender pattern to grab specific META-INF/services
entries and register them in OSGi service registry. If you will take a
look on following line:
https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
you will find that bundle is an jar which changes state to ACTIVE.
Additionally that bundle classloader is used to find services and that
bundle context is used to register services. In the end service which
appears looks like one registered by driver/transport module.
The main point for above implementation is basic - getting the standard
PLC4X driver JAR working in OSGi without forcing it to knowing too much
about OSGi. Driver needs to ship manifest with import/export statements
and that's it. Additionally driver does not have to have a XML
descriptor which registers service. Quite many third parties might be
supplying drivers without any or with limited knowledge of OSGi.
Do drivers have to be a service? Well, it they can still be a valid OSGi
service, registered using any other way! OSGi aware driver manager uses
OSGi services instead of static list own classloader to find
META-INF/services entries:
https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
JDBC JARs are handled in such a way already in pax-jdbc. Take a look here:
https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
Same or very similar code can be found in apache-camel, which brought
hundreds of components to OSGi, so I believe their way can be seen as
high level guide.
What Etienne did is a pattern implementation.
With regard to capabilities/requirements - this is a resolver puzzle. It
relies on additional information. As an unbaptized, non-religious osgi
guy (I take it as a tool and not act of faith), I often do skip it. I do
find it useful, however quite often problematic and hard to understand
(yet another non-trivial syntax in manifest to follow). On older
runtimes capabilities are not even considered. For never ones there are
already existing namespaces:
https://www.osgi.org/capability-namespaces-reference/
including, one for services:
https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
My point is that capabilities are used to attest that runtime will
consist all necessary things in place after provisioning operation. It
does not say HOW given capabilities should be made, cause resolver is
hit before bundle gets active. It is a safety check. I'm fine with
having one, however we need to make it right to do not narrow use of
driver bundles only with our own extender.
Beside the point, I am not sure if plc4x-api is a best place for osgi
specific logic. That is a standard dilema to address in how we want to
treat osgi and non-osgi users. :-)
Cheers!
Łukasz
On 05.05.2020 12:34, Julian Feinauer wrote:
> 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" <ni...@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 <ni...@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 <43...@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 <ni...@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 <43...@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" <43...@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 <lu...@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
> >> > > > >>>>>>
> >> > > > >>>>
> >> > > > >>>
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: SPI Module - OSGi Bundle
Posted by Julian Feinauer <j....@pragmaticminds.de>.
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" <ni...@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 <ni...@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 <43...@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 <ni...@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 <43...@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" <43...@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 <lu...@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
>> > > > >>>>>>
>> > > > >>>>
>> > > > >>>
>> > > >
>> > > >
>> > > >
>> > >
>> >
>>
>
Re: SPI Module - OSGi Bundle
Posted by Niclas Hedhman <ni...@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 <ni...@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 <43...@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 <ni...@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 <43...@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" <43...@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 <lu...@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
>> > > > >>>>>>
>> > > > >>>>
>> > > > >>>
>> > > >
>> > > >
>> > > >
>> > >
>> >
>>
>
Re: SPI Module - OSGi Bundle
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 <43...@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 <ni...@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 <43...@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" <43...@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 <lu...@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 <lu...@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
> > > > >>>>>>
> > > > >>>>
> > > > >>>
> > > >
> > > >
> > > >
> > >
> >
>
Re: SPI Module - OSGi Bundle
Posted by "Robinet, Etienne" <43...@etu.he2b.be>.
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 <ni...@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 <43...@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 <ch...@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" <43...@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 <lu...@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 <er...@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 <lu...@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
> > > >>>>>>
> > > >>>>
> > > >>>
> > >
> > >
> > >
> >
>
Re: SPI Module - OSGi Bundle
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 <43...@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 <ch...@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" <43...@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 <lu...@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 <er...@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 <lu...@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
> > >>>>>>
> > >>>>
> > >>>
> >
> >
> >
>