plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: SPI Module - OSGi Bundle
Date Thu, 07 May 2020 13:13:40 GMT
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>:
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>               Hi all,
        > >>>>>     >> > > >     >>>>>>>>>>               I've been working on the
        > >> Camel
        > >>>>>     >> Component
        > >>>>>     >> > and
        > >>>>>     >> > > >     >>>>>>> decided
        > >>>>>     >> > > >     >>>>>>>>> to test it inside Karaf, but I noticed
        > >> that
        > >>>> I've got
        > >>>>>     >> this
        > >>>>>     >> > > > error
        > >>>>>     >> > > >     >>>>>>> now:
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>> https://i.imgur.com/kUZPwZ5.png
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>               Seems like this class is
        > >> not
        > >>>> exported
        > >>>>>     >> by
        > >>>>>     >> > the
        > >>>>>     >> > > >     >>>>>>> bundle
        > >>>>>     >> > > >     >>>>>>>>> so it can not be found. Anyone has an
        > >> idea on
        > >>>> how we
        > >>>>>     >> > could
        > >>>>>     >> > > > solve
        > >>>>>     >> > > >     >>>>>>> this?
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>               Etienne
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>>
        > >>>>>     >> > > >     >>>>>>>>
        > >>>>>     >> > > >     >>>>>>>
        > >>>>>     >> > > >     >>>>>>>
        > >>>>>     >> > > >     >>>>>>>
        > >>>>>     >> > > >     >>>>>>
        > >>>>>     >> > > >     >>>>>> --
        > >>>>>     >> > > >     >>>>>> --
        > >>>>>     >> > > >     >>>>>> Christian Schneider
        > >>>>>     >> > > >     >>>>>> http://www.liquid-reality.de
        > >>>>>     >> > > >     >>>>>>
        > >>>>>     >> > > >     >>>>>> Computer Scientist
        > >>>>>     >> > > >     >>>>>> http://www.adobe.com
        > >>>>>     >> > > >     >>>>>>
        > >>>>>     >> > > >     >>>>
        > >>>>>     >> > > >     >>>
        > >>>>>     >> > > >
        > >>>>>     >> > > >
        > >>>>>     >> > > >
        > >>>>>     >> > >
        > >>>>>     >> >
        > >>>>>     >>
        > >>>>>     >
        > >>>>>
        > >>>>
        > >>>
        > >>
        > >
        >


Mime
View raw message