Ł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 <l...@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" <nic...@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 <nic...@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 <nic...@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.d...@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 <
> l...@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 <
> >     >> erobi...@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 <
> l...@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 <
> >     >> > > > ch...@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.feina...@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" <
> >     >> > > > erobi...@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 <
> >     >> > > nic...@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.d...@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" <
> >     >> > > > 43...@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.feina...@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.d...@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.feina...@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.d...@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" <
> >     >> > > >     >>>>>>>>> erobi...@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
> >     >> > > >     >>>>>>
> >     >> > > >     >>>>
> >     >> > > >     >>>
> >     >> > > >
> >     >> > > >
> >     >> > > >
> >     >> > >
> >     >> >
> >     >>
> >     >
> >
>

Reply via email to