plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: SPI Module - OSGi Bundle
Date Wed, 06 May 2020 13:57:31 GMT
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