plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: SPI Module - OSGi Bundle
Date Fri, 08 May 2020 07:54:34 GMT
As mentioned elsewhere, the generic activators could go in a separate
bundle for OSGi use only. That applies to both this approach and Lukasz'
one.

// Niclas

On Fri, May 8, 2020 at 2:08 PM Christofer Dutz <christofer.dutz@c-ware.de>
wrote:

> Hi Niclas,
>
> If your suggested path doesn't limit the framework decisions a user has,
> then I have no objections.
>
> Indiens I am not that deep into osgi to have a well founded opinion.
>
> The api will probably never be a pure api module as it contains the driver
> manager, which I wouldn't want to put into a separate module.
>
> Chris
> ________________________________
> Von: Niclas Hedhman <niclas@hedhman.org>
> Gesendet: Freitag, 8. Mai 2020 05:12
> An: dev@plc4x.apache.org <dev@plc4x.apache.org>
> Betreff: Re: SPI Module - OSGi Bundle
>
> Both approaches are independent of OSGi framework implementations, which is
> part of the beauty of OSGi.
>
> Lukasz puts more value on some dogmatic principle ("only interfaces in
> API"), whereas I have forwarded how an OSGi bundle producer is expected to
> provide it, and how an OSGi bundle consumer would expect to see it and the
> added benefit that default behavior can be overridden. Lukasz uses my own
> work-around (for JDBC drivers) to show me that is the way things are done.
> It is not, it was a necessary hack for that time to get around the legacy
> JDBC drivers out in the open, all of them without OSGi manifests.
>
> As I said, I have no skin in the game. Only providing independent advice,
> as a former OSGi expert and a keen interest in PLC4X.
>
> // Niclas
>
>
> On Thu, May 7, 2020 at 9:13 PM Christofer Dutz <christofer.dutz@c-ware.de>
> wrote:
>
> > Hi folks,
> >
> > so if there is an option that doesn't tie our API and Drivers to a
> > specific OSGi framework, I would prefer that.
> >
> > Chris
> >
> > Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> > j.feinauer@pragmaticminds.de>:
> >
> >     I would say that there are arguments for both cases (as ist often
> with
> > OSGi, IMHO).
> >     So I see them not as right or wrong but as to different styles or
> > approaches that I woudl leave up to you to decide.
> >
> >     IMHO
> >     Julian
> >
> >     Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43823@etu.he2b.be>:
> >
> >         Hi guys,
> >         As I am really not an expert, which approach should we use?
> >
> >         Etienne
> >
> >         Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <luke@code-house.org>
> > a écrit :
> >
> >         > Hey Niclas,
> >         > While this code seems straight I don't think it is needed, and
> > valid in
> >         > our case.
> >         > Main benefit of extender and extender based patterns is
> > centralized
> >         > processing of drivers.
> >         > I am keen to keep only interfaces in the API packages and
> > bundles and
> >         > move active parts of code (such base classes) to another place.
> > It is
> >         > necessary to avoid creation of implementation dependency. And
> > that's
> >         > what is in fact, promoted by shared activator class.
> >         >
> >         > Best,
> >         > Łukasz
> >         >
> >         >
> >         > On 06.05.2020 13:47, Niclas Hedhman wrote:
> >         > > My suggestion was;
> >         > > 1. Don't do the BundleTracker classes, and instead change to
> a
> > bundle
> >         > > activator for each.
> >         > > 2. Add the "Bundle-Activator:
> > org.apache.plc4x.java.osgi.DriverActivator"
> >         > > to the driver META/MANIFEST.MF
> >         > > 3. Do the equivalent for the Transports.
> >         > >
> >         > > public class DriverActivator implements BundleActivator {
> >         > >
> >         > >     private ServiceRegistration<PlcDriver> reg;
> >         > >
> >         > >     @Override
> >         > >     public void start( BundleContext context ) throws
> > Exception {
> >         > >         Hashtable<String, String> props = new Hashtable<>();
> >         > >         props.put( OsgiDriverManager.PROTOCOL_CODE,
> >         > driver.getProtocolCode() );
> >         > >         props.put( OsgiDriverManager.PROTOCOL_NAME,
> >         > driver.getProtocolName() );
> >         > >         reg = context.registerService( PlcDriver.class,
> > driver, props );
> >         > >     }
> >         > >
> >         > >     @Override
> >         > >     public void stop( BundleContext context ) {
> >         > >         context.unregisterService( reg );
> >         > >     }
> >         > > }
> >         > >
> >         > >
> >         > >
> >         > >
> >         > >
> >         > >
> >         > >
> >         > >
> >         > >
> >         > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> > erobinet@apache.org>
> >         > wrote:
> >         > >
> >         > >> Hi all,
> >         > >> So concretely what changes should be done so that a
> > Driver/Transport
> >         > >> declares itself his service? Beside the changes in the
> > manifest?
> >         > >> Etienne
> >         > >> On 2020/05/06 01:26:42, Niclas Hedhman <niclas@hedhman.org>
> > wrote:
> >         > >>> Łukasz,
> >         > >>>
> >         > >>> the reason I say it is not very OSGi-y, is that the
> > principle of OSGi
> >         > is
> >         > >>> that the bundle handles its own service registrations. In
> > the case of
> >         > >> JDBC
> >         > >>> (I initiated that spec, and I am the founder of OPS4J as
> > well as Pax
> >         > >>> subproject, 2005), it needed to address the problem that
> > JDBC drivers
> >         > >>> existed and changing their build and/or manifests was
> > decided to be
> >         > "not
> >         > >>> viable". The approach there is a work-around for legacy
> > code, which I
> >         > and
> >         > >>> Stuart McCulloch basically invented. IIRC, this happened in
> > 2007.
> >         > >>>
> >         > >>> I didn't suggest that bundles require Declarative Services.
> > I suggested
> >         > >>> that the "inside of the loop" in Etienne's code is put into
> > an
> >         > Activator,
> >         > >>> the code residing in the API and SPI bundles respectively,
> > and that
> >         > each
> >         > >>> driver/transport has a "Bundle-Activator: ....." in the
> > manifest
> >         > >>> referencing respective activator. It is not more intrusive
> > than the
> >         > >>> Export-Package, Import-Package that will be required
> anyway.
> >         > >>>
> >         > >>> Advantages; It is more in the spirit of OSGi. But
> > importantly, the
> >         > >>> driver/transport is now an active bundle, rather than a
> > library bundle,
> >         > >> and
> >         > >>> in theory the start/stop of a bundle could (there might be
> > other
> >         > reasons
> >         > >>> why not) turn it on/off in runtime. If special needs pop
> up,
> > maybe to
> >         > >>> deploy for the OpenHAB project, it is possible to override
> > the
> >         > >>> driver/transport with hacking the API/SPI bundles.
> >         > >>>
> >         > >>> And I can't see any disadvantages other than "need to
> rework
> > a bit of
> >         > >> code".
> >         > >>>
> >         > >>> But I don't have skin in the game. Not in OSGi, not here,
> so
> > take my
> >         > >>> recommendations into consideration or throw them away. I
> > just got the
> >         > >>> impression that you didn't really get what I suggested.
> >         > >>>
> >         > >>>
> >         > >>> // Niclas
> >         > >>>
> >         > >>>
> >         > >>>
> >         > >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki <
> > luke@code-house.org>
> >         > >> wrote:
> >         > >>>
> >         > >>>> Hey Etienne, that's awesome piece of work. I can test it!
> > :-)
> >         > >>>>
> >         > >>>> I believe that's what Etienne code does it in a valid OSGi
> > way. And I
> >         > >> do
> >         > >>>> believe not because he mentioned me by name, but due to
> > below
> >         > >>>> argumentation.
> >         > >>>>
> >         > >>>> Proposed code uses extender pattern to grab specific
> > META-INF/services
> >         > >>>> entries and register them in OSGi service registry. If you
> > will take a
> >         > >>>> look on following line:
> >         > >>>>
> >         > >>>>
> >         > >>
> >         >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> >         > >>>> you will find that bundle is an jar which changes state to
> > ACTIVE.
> >         > >>>> Additionally that bundle classloader is used to find
> > services and that
> >         > >>>> bundle context is used to register services. In the end
> > service which
> >         > >>>> appears looks like one registered by driver/transport
> > module.
> >         > >>>>
> >         > >>>> The main point for above implementation is basic - getting
> > the
> >         > standard
> >         > >>>> PLC4X driver JAR working in OSGi without forcing it to
> > knowing too
> >         > much
> >         > >>>> about OSGi. Driver needs to ship manifest with
> import/export
> >         > statements
> >         > >>>> and that's it. Additionally driver does not have to have a
> > XML
> >         > >>>> descriptor which registers service. Quite many third
> > parties might be
> >         > >>>> supplying drivers without any or with limited knowledge of
> > OSGi.
> >         > >>>> Do drivers have to be a service? Well, it they can still
> be
> > a valid
> >         > >> OSGi
> >         > >>>> service, registered using any other way! OSGi aware driver
> > manager
> >         > uses
> >         > >>>> OSGi services instead of static list own classloader to
> find
> >         > >>>> META-INF/services entries:
> >         > >>>>
> >         > >>>>
> >         > >>
> >         >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> >         > >>>>
> >         > >>>> JDBC JARs are handled in such a way already in pax-jdbc.
> > Take a look
> >         > >> here:
> >         > >>>>
> >         > >>>>
> >         > >>
> >         >
> >
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> >         > >>>> Same or very similar code can be found in apache-camel,
> > which brought
> >         > >>>> hundreds of components to OSGi, so I believe their way can
> > be seen as
> >         > >>>> high level guide.
> >         > >>>> What Etienne did is a pattern implementation.
> >         > >>>>
> >         > >>>> With regard to capabilities/requirements - this is a
> > resolver puzzle.
> >         > >> It
> >         > >>>> relies on additional information. As an unbaptized,
> > non-religious osgi
> >         > >>>> guy (I take it as a tool and not act of faith), I often do
> > skip it. I
> >         > >> do
> >         > >>>> find it useful, however quite often problematic and hard
> to
> > understand
> >         > >>>> (yet another non-trivial syntax in manifest to follow). On
> > older
> >         > >>>> runtimes capabilities are not even considered. For never
> > ones there
> >         > are
> >         > >>>> already existing namespaces:
> >         > >>>> https://www.osgi.org/capability-namespaces-reference/
> >         > >>>> including, one for services:
> >         > >>>>
> >         > >>
> >         >
> >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> >         > >>>> My point is that capabilities are used to attest that
> > runtime will
> >         > >>>> consist all necessary things in place after provisioning
> > operation. It
> >         > >>>> does not say HOW given capabilities should be made, cause
> > resolver is
> >         > >>>> hit before bundle gets active. It is a safety check. I'm
> > fine with
> >         > >>>> having one, however we need to make it right to do not
> > narrow use of
> >         > >>>> driver bundles only with our own extender.
> >         > >>>>
> >         > >>>> Beside the point, I am not sure if plc4x-api is a best
> > place for osgi
> >         > >>>> specific logic. That is a standard dilema to address in
> how
> > we want to
> >         > >>>> treat osgi and non-osgi users. :-)
> >         > >>>>
> >         > >>>> Cheers!
> >         > >>>> Łukasz
> >         > >>>>
> >         > >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> >         > >>>>> Hi Etienne and Niclas,
> >         > >>>>>
> >         > >>>>> indeed we could orient (again) on how JDBC does that in
> > OSGi.
> >         > >>>>> They really focus on "late binding" so that you resolve
> > the driver
> >         > >>>> directly when you need it.
> >         > >>>>> In theory, there is no such thing as a DriverManager in
> > OSGi but
> >         > >> only a
> >         > >>>> PlcDriver with the capability ("plc4x-protocol": "s7") or
> > something.
> >         > >>>>>
> >         > >>>>> I did it witht he driver maanger mostly fort he ease as
> > first
> >         > >> approach.
> >         > >>>>>
> >         > >>>>> Julian
> >         > >>>>>
> >         > >>>>> Am 05.05.20, 12:30 schrieb "Niclas Hedhman" <
> > niclas@hedhman.org>:
> >         > >>>>>
> >         > >>>>>     Also, just in case, a custom activator is ever
> > required, it can
> >         > >> be
> >         > >>>>>     overridden easily without breaking the over all
> design
> >         > >>>>>
> >         > >>>>>     On Tue, May 5, 2020 at 6:27 PM Niclas Hedhman <
> >         > >> niclas@hedhman.org>
> >         > >>>> wrote:
> >         > >>>>>
> >         > >>>>>     > Yes, that's what I mean, because that is what you
> > have inside
> >         > >> the
> >         > >>>> loop, so
> >         > >>>>>     > it should work.
> >         > >>>>>     >
> >         > >>>>>     > On Tue, May 5, 2020 at 11:50 AM Robinet, Etienne <
> >         > >>>> 43823@etu.he2b.be>
> >         > >>>>>     > wrote:
> >         > >>>>>     >
> >         > >>>>>     >> Hi Niclas,
> >         > >>>>>     >> thanks for the feedback. So you mean to make the
> > Activator in
> >         > >>>> API/SPI
> >         > >>>>>     >> generic so every Driver would call it and declare
> > the service
> >         > >>>> itself?
> >         > >>>>>     >>
> >         > >>>>>     >> Le mar. 5 mai 2020 à 05:25, Niclas Hedhman <
> >         > >> niclas@hedhman.org>
> >         > >>>> a écrit :
> >         > >>>>>     >>
> >         > >>>>>     >> > What you are doing is not particularly OSGi-y...
> > The
> >         > >> expected
> >         > >>>> way to do
> >         > >>>>>     >> > this is to have each bundle register their
> > PlcDriver or
> >         > >>>> Transport to the
> >         > >>>>>     >> > OSGi service registry.
> >         > >>>>>     >> >
> >         > >>>>>     >> > That said, what you have done is otherwise fine,
> > as you
> >         > >>>> basically
> >         > >>>>>     >> trying to
> >         > >>>>>     >> > centralize the BundleActivators away from
> > respective
> >         > >>>> Driver/Transport.
> >         > >>>>>     >> And
> >         > >>>>>     >> > I assume you do so to limit code in the
> > drivers/transports.
> >         > >>>>>     >> >
> >         > >>>>>     >> > Another way would be to make two generic
> > BundleActivator in
> >         > >>>> this bundle
> >         > >>>>>     >> and
> >         > >>>>>     >> > have each driver/transport just declare them in
> > the
> >         > >> manifest.
> >         > >>>> That
> >         > >>>>>     >> would be
> >         > >>>>>     >> > a bit more conventional.
> >         > >>>>>     >> >
> >         > >>>>>     >> > // Niclas
> >         > >>>>>     >> >
> >         > >>>>>     >> > On Tue, May 5, 2020 at 11:06 AM Robinet,
> Etienne <
> >         > >>>> 43823@etu.he2b.be>
> >         > >>>>>     >> > wrote:
> >         > >>>>>     >> >
> >         > >>>>>     >> > > Hi all,
> >         > >>>>>     >> > > With the change of Christofer this problem got
> > solved.
> >         > >>>> Nonetheless, I
> >         > >>>>>     >> > kept
> >         > >>>>>     >> > > the work I did (inspired by the work of
> Lukasz)
> > to make an
> >         > >>>> Activator
> >         > >>>>>     >> for
> >         > >>>>>     >> > > API (Driver Services) and SPI (Transport
> > Services). I also
> >         > >>>> tested it,
> >         > >>>>>     >> but
> >         > >>>>>     >> > > as I am pretty new to this, if anyone could
> > just give me a
> >         > >>>> feedback on
> >         > >>>>>     >> > the
> >         > >>>>>     >> > > code:
> >         > >>>>>     >> > >
> >         > >>>>>     >> > > API Activator:
> >         > >>>>>     >> > >
> >         > >>>>>     >> > >
> >         > >>>>>     >> >
> >         > >>>>>     >>
> >         > >>>>
> >         > >>
> >         >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java
> >         > >>>>>     >> > > SPI Activator:
> >         > >>>>>     >> > >
> >         > >>>>>     >> > >
> >         > >>>>>     >> >
> >         > >>>>>     >>
> >         > >>>>
> >         > >>
> >         >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/spi/src/main/java/org/apache/plc4x/java/osgi/SpiActivator.java
> >         > >>>>>     >> > >
> >         > >>>>>     >> > > If everything is alright, I could merge this
> > today.
> >         > >>>>>     >> > >
> >         > >>>>>     >> > > Etienne
> >         > >>>>>     >> > >
> >         > >>>>>     >> > > Le mar. 7 avr. 2020 à 17:52, Christofer Dutz <
> >         > >>>>>     >> christofer.dutz@c-ware.de>
> >         > >>>>>     >> > a
> >         > >>>>>     >> > > écrit :
> >         > >>>>>     >> > >
> >         > >>>>>     >> > > > Hi folks,
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > > I just pushed a change that might get rid of
> > this error.
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > > I added the Plc4xBootstrap in an attempt to
> > get the
> >         > >>>> TestTransport
> >         > >>>>>     >> > > working.
> >         > >>>>>     >> > > > For some reasons the netty folks created the
> >         > >> EmbeddedChannel
> >         > >>>>>     >> > differently
> >         > >>>>>     >> > > > than the rest.
> >         > >>>>>     >> > > > However as the TestTransport is the only one
> > needing
> >         > >> this
> >         > >>>> change, I
> >         > >>>>>     >> > moved
> >         > >>>>>     >> > > > these classes to the test-transport module
> >         > >>>>>     >> > > > and extended NettyChannelFactory with a
> > createBootstrap
> >         > >>>> method
> >         > >>>>>     >> which is
> >         > >>>>>     >> > > > simply overridden in TestTransport.
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > > So please give everything a try if it now
> > works as
> >         > >> planned.
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > > Chris
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > > Am 07.04.20, 17:36 schrieb "Etienne
> Robinet" <
> >         > >>>> 43823@etu.he2b.be>:
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > >     Hi all,
> >         > >>>>>     >> > > >     I’ve checked the Manifest. If I put the
> >         > >>>> Embed-Dependency to the
> >         > >>>>>     >> > > > plc4j-spi artifact  it does not find the
> > Transport
> >         > >> Service.
> >         > >>>> And if I
> >         > >>>>>     >> > dont
> >         > >>>>>     >> > > > it does not find the Plc4xBootstrap.
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > >     Etienne ROBINET
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > >     > Le 7 avr. 2020 à 16:48, Łukasz
> Dywicki <
> >         > >>>> luke@code-house.org>
> >         > >>>>>     >> a
> >         > >>>>>     >> > > > écrit :
> >         > >>>>>     >> > > >     >
> >         > >>>>>     >> > > >     > I was updating my local checkout
> > yesterday. Can't
> >         > >>>> promise if I
> >         > >>>>>     >> > will
> >         > >>>>>     >> > > > be
> >         > >>>>>     >> > > >     > able to help, but will give a try with
> > 0.7
> >         > >> snapshot.
> >         > >>>>>     >> > > >     >
> >         > >>>>>     >> > > >     > Best,
> >         > >>>>>     >> > > >     > Łukasz
> >         > >>>>>     >> > > >     >
> >         > >>>>>     >> > > >     >
> >         > >>>>>     >> > > >     >> On 07.04.2020 15:39, Etienne Robinet
> > wrote:
> >         > >>>>>     >> > > >     >> Hi again,
> >         > >>>>>     >> > > >     >> I've been looking at this issue all
> > day, and I am
> >         > >>>> back to the
> >         > >>>>>     >> > > > initial error:
> >         > >>>>>     >> > > >     >> https://i.imgur.com/LLfan8H.png
> >         > >>>>>     >> > > >     >>
> >         > >>>>>     >> > > >     >> The difference is I used and
> Activator
> > for API
> >         > >> and
> >         > >>>> SPI to
> >         > >>>>>     >> > register
> >         > >>>>>     >> > > > the driver and transports Service, which are
> > then
> >         > >> loaded by
> >         > >>>> the
> >         > >>>>>     >> custom
> >         > >>>>>     >> > > > blueprint. The error now is caused again
> > because this
> >         > >> class
> >         > >>>> is not
> >         > >>>>>     >> > > exported
> >         > >>>>>     >> > > > (I think?) by the SPI, but is used by one of
> > the
> >         > >> dependency
> >         > >>>>>     >> (io.netty).
> >         > >>>>>     >> > > >     >> Any ideas on how to solve this?
> >         > >>>>>     >> > > >     >>
> >         > >>>>>     >> > > >     >> Etienne
> >         > >>>>>     >> > > >     >>
> >         > >>>>>     >> > > >     >>> On 2020/04/07 06:53:54, Etienne
> > Robinet <
> >         > >>>>>     >> erobinet@apache.org>
> >         > >>>>>     >> > > > wrote:
> >         > >>>>>     >> > > >     >>> Hi all,
> >         > >>>>>     >> > > >     >>> the faulty ClassLoader is the
> >         > >>>>>     >> > > > BundleDelegatingClassLoader(plc4x-test
> > [191]). Which
> >         > >> means
> >         > >>>> that the
> >         > >>>>>     >> > > custom
> >         > >>>>>     >> > > > bundle can not find the class right?
> >         > >>>>>     >> > > >     >>>
> >         > >>>>>     >> > > >     >>> I'm sorry if it's a silly question
> > but I am
> >         > >> pretty
> >         > >>>> new to
> >         > >>>>>     >> this.
> >         > >>>>>     >> > > >     >>>
> >         > >>>>>     >> > > >     >>> Etienne
> >         > >>>>>     >> > > >     >>>
> >         > >>>>>     >> > > >     >>> On 2020/04/06 20:28:17, Łukasz
> > Dywicki <
> >         > >>>> luke@code-house.org
> >         > >>>>>     >> >
> >         > >>>>>     >> > > > wrote:
> >         > >>>>>     >> > > >     >>>> I haven't used Camel for a while,
> > but to me it
> >         > >>>> seems to be
> >         > >>>>>     >> a
> >         > >>>>>     >> > > > problem
> >         > >>>>>     >> > > >     >>>> caused by caller's classloader.
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >     >>>> See that in stack trace you have a
> > thread
> >         > >> which is
> >         > >>>> started
> >         > >>>>>     >> by
> >         > >>>>>     >> > > > camel, so
> >         > >>>>>     >> > > >     >>>> there are 3 or even 4 classloaders
> > to be
> >         > >>>> considered:
> >         > >>>>>     >> > > >     >>>> - plc4x, definitely not a faulty
> one
> >         > >>>>>     >> > > >     >>>> - netty, could be troublesome but
> > unlikely to
> >         > >> be
> >         > >>>> used
> >         > >>>>>     >> > > >     >>>> - camel-core, or component itself
> >         > >>>>>     >> > > >     >>>> - custom bundle which started the
> > route
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >     >>>> Anything beside last one which
> knows
> > all the
> >         > >>>> dependencies
> >         > >>>>>     >> will
> >         > >>>>>     >> > > > blow up
> >         > >>>>>     >> > > >     >>>> whole universe. Here is why - only
> > the custom
> >         > >>>> bundle knows
> >         > >>>>>     >> all
> >         > >>>>>     >> > > the
> >         > >>>>>     >> > > >     >>>> dependencies necessary to run logic
> > and can be
> >         > >>>> used to fix
> >         > >>>>>     >> > > messed
> >         > >>>>>     >> > > > up
> >         > >>>>>     >> > > >     >>>> classpath. In most of the cases,
> > that's the
> >         > >>>> "trick" you
> >         > >>>>>     >> have
> >         > >>>>>     >> > to
> >         > >>>>>     >> > > > make in
> >         > >>>>>     >> > > >     >>>> order to get OSGi happy.
> >         > >>>>>     >> > > >     >>>> Camel component may not, and should
> > not depend
> >         > >> on
> >         > >>>> specific
> >         > >>>>>     >> > > driver,
> >         > >>>>>     >> > > >     >>>> however in your case it does.
> > Possibly due to
> >         > >> new
> >         > >>>> APIs in
> >         > >>>>>     >> > > > transport
> >         > >>>>>     >> > > >     >>>> layer its shouldn't be used for
> > adhoc fixes.
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >     >>>> We can try to turn drivers into
> > services (see
> >         > >> here
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > >
> >         > >>>>>     >> >
> >         > >>>>>     >>
> >         > >>>>
> >         > >>
> >         >
> >
> https://github.com/splatch/plc4x/commit/5ce379cf8d2f5dc91fdfb6d8a8e2c0531906e69f
> >         > >>>>>     >> > > > )
> >         > >>>>>     >> > > >     >>>> in order to cut concrete class
> > dependency and
> >         > >> rely
> >         > >>>> on
> >         > >>>>>     >> isolated
> >         > >>>>>     >> > > > APIs.
> >         > >>>>>     >> > > >     >>>> This code was done before new
> > abstractions over
> >         > >>>> netty were
> >         > >>>>>     >> > > > introduced,
> >         > >>>>>     >> > > >     >>>> but it should cut in half API and
> > caller side
> >         > >> (not
> >         > >>>> sure if
> >         > >>>>>     >> > we're
> >         > >>>>>     >> > > > on
> >         > >>>>>     >> > > >     >>>> declarative services).
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >     >>>> My tip to you Etienne - please
> > verify which
> >         > >> class
> >         > >>>> loader is
> >         > >>>>>     >> > used
> >         > >>>>>     >> > > > in your
> >         > >>>>>     >> > > >     >>>> polling cycle. You can do that by
> > making
> >         > >>>> breakpoint in
> >         > >>>>>     >> faulty
> >         > >>>>>     >> > > > method of
> >         > >>>>>     >> > > >     >>>> S7Driver and evaluating expression
> >         > >>>>>     >> > > >     >>>>
> >         > >> "Thread.currentThread().getContextClassLoader()".
> >         > >>>>>     >> > > >     >>>> Once you know that you can either
> fix
> >         > >> classloading
> >         > >>>> in the
> >         > >>>>>     >> > > calling
> >         > >>>>>     >> > > > class
> >         > >>>>>     >> > > >     >>>> loader or override classloader for
> > thread to
> >         > >>>> proper one.
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >     >>>> Best,
> >         > >>>>>     >> > > >     >>>> Łukasz
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >     >>>> On 03.04.2020 10:27, Etienne
> Robinet
> > wrote:
> >         > >>>>>     >> > > >     >>>>> Hi Christian,
> >         > >>>>>     >> > > >     >>>>> you mean the code used in the
> Camel
> > route? It
> >         > >> is
> >         > >>>> an
> >         > >>>>>     >> > blueprint:
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>> <?xml version="1.0"
> > encoding="UTF-8"?>
> >         > >>>>>     >> > > >     >>>>> <blueprint xmlns="
> >         > >>>>>     >> http://www.osgi.org/xmlns/blueprint/v1.0.0
> >         > >>>>>     >> > "
> >         > >>>>>     >> > > >     >>>>>           xmlns:xsi="
> >         > >>>>>     >> > http://www.w3.org/2001/XMLSchema-instance
> >         > >>>>>     >> > > "
> >         > >>>>>     >> > > >     >>>>>           xsi:schemaLocation= "
> >         > >>>>>     >> > > > http://www.osgi.org/xmlns/blueprint/v1.0.0
> >         > >>>>>     >> > > >
> >         > >> https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>> http://camel.apache.org/schema/blueprint
> >         > >>>>>     >> > > >
> >         > >>>>
> > http://camel.apache.org/schema/blueprint/camel-blueprint-2.24.2.xsd
> >         > >>>>>     >> ">
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>>    <camelContext id="PLC-IoTDB"
> > xmlns="
> >         > >>>>>     >> > > > http://camel.apache.org/schema/blueprint"
> >         > >>>> streamCache="true" >
> >         > >>>>>     >> > > >     >>>>>        <route id="plc-route" >
> >         > >>>>>     >> > > >     >>>>>            <from
> >         > >>>>>     >> > > >
> > uri="timer://plcFetch?fixedRate=true&period=1000"/>
> >         > >>>>>     >> > > >     >>>>>            <pollEnrich>
> >         > >>>>>     >> > > >     >>>>>
> > <simple>plc4x:s7:tcp://
> >         > >>>>>     >> > > > 192.168.178.10?address=#fields</simple>
> >         > >>>>>     >> > > >     >>>>>            </pollEnrich>
> >         > >>>>>     >> > > >     >>>>>            <log
> message="${body}"/>
> >         > >>>>>     >> > > >     >>>>>            <to
> > uri="mock:test?retainLast=10"/>
> >         > >>>>>     >> > > >     >>>>>        </route>
> >         > >>>>>     >> > > >     >>>>>    </camelContext>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>>    <bean id="fields"
> >         > >> class="java.util.ArrayList">
> >         > >>>>>     >> > > >     >>>>>        <argument>
> >         > >>>>>     >> > > >     >>>>>            <list>
> >         > >>>>>     >> > > >     >>>>>               <bean
> >         > >>>>>     >> class="org.apache.plc4x.camel.TagData">
> >         > >>>>>     >> > > >     >>>>>                   <argument
> > index="0"
> >         > >>>> value="IntTest"/>
> >         > >>>>>     >> > > >     >>>>>                   <argument
> > index="1"
> >         > >>>>>     >> > value="%DB1.DBW254:INT"/>
> >         > >>>>>     >> > > >     >>>>>               </bean>
> >         > >>>>>     >> > > >     >>>>>               <bean
> >         > >>>>>     >> class="org.apache.plc4x.camel.TagData">
> >         > >>>>>     >> > > >     >>>>>                   <argument
> > index="0"
> >         > >>>> value="StringTest"/>
> >         > >>>>>     >> > > >     >>>>>                   <argument
> > index="1"
> >         > >>>>>     >> > > value="%DB1.DBX0:STRING"/>
> >         > >>>>>     >> > > >     >>>>>               </bean>
> >         > >>>>>     >> > > >     >>>>>            </list>
> >         > >>>>>     >> > > >     >>>>>        </argument>
> >         > >>>>>     >> > > >     >>>>>    </bean>
> >         > >>>>>     >> > > >     >>>>> </blueprint>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>> This code used to wrok actually, I
> > just
> >         > >> wanted to
> >         > >>>> test the
> >         > >>>>>     >> > new
> >         > >>>>>     >> > > > TagData of the integration. This is the
> > bundling in the
> >         > >>>> pom, these
> >         > >>>>>     >> > > imports
> >         > >>>>>     >> > > > had to be there before too
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>> <plugin>
> >         > >>>>>     >> > > >     >>>>>
> >         > >> <groupId>org.apache.felix</groupId>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> <artifactId>maven-bundle-plugin</artifactId>
> >         > >>>>>     >> > > >     >>>>>
> > <version>4.2.1</version>
> >         > >>>>>     >> > > >     >>>>>
> > <extensions>true</extensions>
> >         > >>>>>     >> > > >     >>>>>                <configuration>
> >         > >>>>>     >> > > >     >>>>>                    <instructions>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >
> >         > >>>>
> > <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >
> > <Bundle-Version>${project.version}</Bundle-Version>
> >         > >>>>>     >> > > >     >>>>>
> > <Export-Package>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>  *;version=${project.version}
> >         > >>>>>     >> > > >     >>>>>
> > </Export-Package>
> >         > >>>>>     >> > > >     >>>>>
> > <Import-Package>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > org.apache.plc4x.java.spi.transport,
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > org.apache.plc4x.java.s7.readwrite,
> >         > >>>>>     >> > > >     >>>>>                            *
> >         > >>>>>     >> > > >     >>>>>
> > </Import-Package>
> >         > >>>>>     >> > > >     >>>>>                    </instructions>
> >         > >>>>>     >> > > >     >>>>>                </configuration>
> >         > >>>>>     >> > > >     >>>>>            </plugin>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>> Etienne
> >         > >>>>>     >> > > >     >>>>>
> >         > >>>>>     >> > > >     >>>>> On 2020/04/03 08:17:45, Christian
> > Schneider <
> >         > >>>>>     >> > > > chris@die-schneider.net> wrote:
> >         > >>>>>     >> > > >     >>>>>> The code in plc4x directly uses
> > the class
> >         > >> (not a
> >         > >>>> String
> >         > >>>>>     >> of
> >         > >>>>>     >> > the
> >         > >>>>>     >> > > > name). This
> >         > >>>>>     >> > > >     >>>>>> is good. Normally such a class
> > reference
> >         > >> should
> >         > >>>> work
> >         > >>>>>     >> fine.
> >         > >>>>>     >> > > >     >>>>>>
> >         > >>>>>     >> > > >     >>>>>> Can you show your code as a
> > complete example?
> >         > >>>>>     >> > > >     >>>>>>
> >         > >>>>>     >> > > >     >>>>>> Christian
> >         > >>>>>     >> > > >     >>>>>>
> >         > >>>>>     >> > > >     >>>>>>
> >         > >>>>>     >> > > >     >>>>>> Am Fr., 3. Apr. 2020 um 09:58 Uhr
> > schrieb
> >         > >> Julian
> >         > >>>>>     >> Feinauer <
> >         > >>>>>     >> > > >     >>>>>> j.feinauer@pragmaticminds.de>:
> >         > >>>>>     >> > > >     >>>>>>
> >         > >>>>>     >> > > >     >>>>>>> I am off with my knowledge.
> >         > >>>>>     >> > > >     >>>>>>> You could ask the Karaf friends
> > (#karaf in
> >         > >>>> Slack). They
> >         > >>>>>     >> are
> >         > >>>>>     >> > > > all OSGi
> >         > >>>>>     >> > > >     >>>>>>> experts and very friendly and
> > helpful.
> >         > >>>>>     >> > > >     >>>>>>> Or perhaps Christian has an idea
> > here?
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>> Best
> >         > >>>>>     >> > > >     >>>>>>> Julian
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>> Am 03.04.20, 09:50 schrieb
> > "Etienne
> >         > >> Robinet" <
> >         > >>>>>     >> > > > erobinet@apache.org>:
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>    Hi again,
> >         > >>>>>     >> > > >     >>>>>>>    I've been struggling with
> this
> > issue for
> >         > >> 2
> >         > >>>> days
> >         > >>>>>     >> now... I
> >         > >>>>>     >> > > > still don't
> >         > >>>>>     >> > > >     >>>>>>> get it why it can not find
> > classes. here is
> >         > >> the
> >         > >>>> current
> >         > >>>>>     >> > > > problem:
> >         > >>>>>     >> > > >     >>>>>>>
> > https://i.imgur.com/LtZMdsu.png
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>    We can see that the classes
> are
> >         > >> available and
> >         > >>>>>     >> exported,
> >         > >>>>>     >> > I
> >         > >>>>>     >> > > > don't know
> >         > >>>>>     >> > > >     >>>>>>> why the Camel Context can't find
> > it. I even
> >         > >>>> tried to
> >         > >>>>>     >> add an
> >         > >>>>>     >> > > > Activator to my
> >         > >>>>>     >> > > >     >>>>>>> bundle, and load these classes
> > there and it
> >         > >>>> works! But
> >         > >>>>>     >> not
> >         > >>>>>     >> > in
> >         > >>>>>     >> > > > the
> >         > >>>>>     >> > > >     >>>>>>> blueprint. If anyone had any
> idea
> > on where
> >         > >> the
> >         > >>>> problem
> >         > >>>>>     >> > is...
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>    Etienne
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>    On 2020/04/01 01:31:15,
> Niclas
> > Hedhman <
> >         > >>>>>     >> > > niclas@hedhman.org>
> >         > >>>>>     >> > > > wrote:
> >         > >>>>>     >> > > >     >>>>>>>> It happens that OSGi
> > classloading result in
> >         > >>>> the wrong
> >         > >>>>>     >> > NCDFE
> >         > >>>>>     >> > > > and that
> >         > >>>>>     >> > > >     >>>>>>> one of
> >         > >>>>>     >> > > >     >>>>>>>> the classes "used" (i.e. return
> > type,
> >         > >>>> parameter,
> >         > >>>>>     >> throws,
> >         > >>>>>     >> > > > extends,
> >         > >>>>>     >> > > >     >>>>>>>> implements) in the reported
> > class is not
> >         > >>>> visible by the
> >         > >>>>>     >> > > > classloader.
> >         > >>>>>     >> > > >     >>>>>>> And
> >         > >>>>>     >> > > >     >>>>>>>> occasionally, it is a "diamond
> > problem",
> >         > >> i.e.
> >         > >>>> that the
> >         > >>>>>     >> > > > Constraints
> >         > >>>>>     >> > > >     >>>>>>> (IIRC,
> >         > >>>>>     >> > > >     >>>>>>>> see chapter 3.8 in OSGi spec)
> > can't be
> >         > >>>> satisfied.
> >         > >>>>>     >> > > >     >>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>> Sorry that I don't have time to
> > dig into
> >         > >> the
> >         > >>>> actual
> >         > >>>>>     >> > > situation
> >         > >>>>>     >> > > > here,
> >         > >>>>>     >> > > >     >>>>>>> but I
> >         > >>>>>     >> > > >     >>>>>>>> thought I could share some of
> my
> > past
> >         > >> (dark)
> >         > >>>>>     >> history....
> >         > >>>>>     >> > ;-)
> >         > >>>>>     >> > > >     >>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>> Cheers
> >         > >>>>>     >> > > >     >>>>>>>> Niclas
> >         > >>>>>     >> > > >     >>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>> On Wed, Apr 1, 2020 at 12:43 AM
> > Christofer
> >         > >>>> Dutz <
> >         > >>>>>     >> > > >     >>>>>>> christofer.dutz@c-ware.de>
> >         > >>>>>     >> > > >     >>>>>>>> wrote:
> >         > >>>>>     >> > > >     >>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>> Hi all,
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>> But If I search for uses of
> > that class,
> >         > >> it's
> >         > >>>> only in
> >         > >>>>>     >> the
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >>
> > org.apache.plc4x.java.spi.connection.NettyChannelFactory
> >         > >>>>>     >> > > > which is
> >         > >>>>>     >> > > >     >>>>>>> in the
> >         > >>>>>     >> > > >     >>>>>>>>> SPI module.
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>> So I am not sure where this is
> > accessed
> >         > >>>> directly from
> >         > >>>>>     >> the
> >         > >>>>>     >> > > > outside.
> >         > >>>>>     >> > > >     >>>>>>> I know
> >         > >>>>>     >> > > >     >>>>>>>>> every driver would use the
> >         > >>>> NettyChannelFactory, but
> >         > >>>>>     >> that
> >         > >>>>>     >> > > > shouldn't
> >         > >>>>>     >> > > >     >>>>>>> be an
> >         > >>>>>     >> > > >     >>>>>>>>> OSGi type problem as the SPI
> > classes
> >         > >> should
> >         > >>>> be able to
> >         > >>>>>     >> > > access
> >         > >>>>>     >> > > >     >>>>>>> their own
> >         > >>>>>     >> > > >     >>>>>>>>> classes.
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>> Chris
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>> Am 31.03.20, 16:07 schrieb
> > "Etienne
> >         > >> Robinet" <
> >         > >>>>>     >> > > > 43823@etu.he2b.be>:
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>    Hi,
> >         > >>>>>     >> > > >     >>>>>>>>>    From the log the class is
> > called
> >         > >> outside
> >         > >>>> the SPI by
> >         > >>>>>     >> > the
> >         > >>>>>     >> > > >     >>>>>>> transport
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>    Etienne
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>> Le 31 mars 2020 à 15:24,
> > Julian Feinauer
> >         > >> <
> >         > >>>>>     >> > > >     >>>>>>>>> j.feinauer@pragmaticminds.de>
> > a écrit :
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>> Hi,
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>> yes, if ist only needed
> > internally its
> >         > >>>> fine.But why
> >         > >>>>>     >> does
> >         > >>>>>     >> > > >     >>>>>>> someone
> >         > >>>>>     >> > > >     >>>>>>>>> then get a Class Not Found
> > Exception?
> >         > >>>>>     >> > > >     >>>>>>>>>> This is usually a hint to
> some
> > class
> >         > >> loader
> >         > >>>> issue in
> >         > >>>>>     >> > OSGi
> >         > >>>>>     >> > > >     >>>>>>> which is
> >         > >>>>>     >> > > >     >>>>>>>>> related to exports/ imports.
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>> J
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>> Am 31.03.20, 15:23 schrieb
> > "Christofer
> >         > >> Dutz"
> >         > >>>> <
> >         > >>>>>     >> > > >     >>>>>>>>> christofer.dutz@c-ware.de>:
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>   As this package is only
> > referenced from
> >         > >>>> within SPI,
> >         > >>>>>     >> > > >     >>>>>>> couldn't we
> >         > >>>>>     >> > > >     >>>>>>>>> just exclude it from the
> > package exports?
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>   Chris
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>   Am 31.03.20, 15:17 schrieb
> > "Julian
> >         > >>>> Feinauer" <
> >         > >>>>>     >> > > >     >>>>>>>>> j.feinauer@pragmaticminds.de
> >:
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>       Hi,
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>       the issue is that if we
> > export it,
> >         > >>>> then we
> >         > >>>>>     >> break
> >         > >>>>>     >> > > >     >>>>>>> Nettys OSGi
> >         > >>>>>     >> > > >     >>>>>>>>> integration as we get a split
> > package
> >         > >>>> situation (two
> >         > >>>>>     >> > > bundles
> >         > >>>>>     >> > > >     >>>>>>> exporting the
> >         > >>>>>     >> > > >     >>>>>>>>> same package, which is
> > forbidden in OSGi).
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>       So I see no easy
> > solution (but had
> >         > >> to
> >         > >>>> do the
> >         > >>>>>     >> same
> >         > >>>>>     >> > > >     >>>>>>> once as
> >         > >>>>>     >> > > >     >>>>>>>>> Netty is pretty... private).
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>       J
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>       Am 31.03.20, 15:15
> > schrieb
> >         > >> "Christofer
> >         > >>>> Dutz" <
> >         > >>>>>     >> > > >     >>>>>>>>> christofer.dutz@c-ware.de>:
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>           Hi all,
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>           I just discussed
> > this issue
> >         > >> with
> >         > >>>> Etienne
> >         > >>>>>     >> and I
> >         > >>>>>     >> > > >     >>>>>>> thought it
> >         > >>>>>     >> > > >     >>>>>>>>> was important for all, so I
> > asked him to
> >         > >>>> bring it
> >         > >>>>>     >> here.
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>           In my effort to get
> > the
> >         > >>>> EmbeddedChannel
> >         > >>>>>     >> > working
> >         > >>>>>     >> > > >     >>>>>>> as a full
> >         > >>>>>     >> > > >     >>>>>>>>> "transport" module, I had to
> > override the
> >         > >>>> Netty
> >         > >>>>>     >> Bootstrap
> >         > >>>>>     >> > > >     >>>>>>> mechanism.
> >         > >>>>>     >> > > >     >>>>>>>>>>           Unfortunately in
> > order to do
> >         > >> so, I
> >         > >>>> need to
> >         > >>>>>     >> > call
> >         > >>>>>     >> > > >     >>>>>>> "init"
> >         > >>>>>     >> > > >     >>>>>>>>> from the derived class.
> > Unfortunately
> >         > >> this is
> >         > >>>> package
> >         > >>>>>     >> > > > private in
> >         > >>>>>     >> > > >     >>>>>>> Netty so I
> >         > >>>>>     >> > > >     >>>>>>>>> had
> >         > >>>>>     >> > > >     >>>>>>>>>>           To add it to the
> > same package.
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>           Would it help to
> > just not
> >         > >> export
> >         > >>>> these
> >         > >>>>>     >> > packages
> >         > >>>>>     >> > > >     >>>>>>> to OSGi?
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>           But I'm also open
> for
> >         > >> alternatives
> >         > >>>> (Please
> >         > >>>>>     >> > none
> >         > >>>>>     >> > > >     >>>>>>> involving
> >         > >>>>>     >> > > >     >>>>>>>>> mega-evil reflection hackery).
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>           Chris
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>           Am 31.03.20, 15:10
> > schrieb
> >         > >> "Etienne
> >         > >>>>>     >> Robinet" <
> >         > >>>>>     >> > > >     >>>>>>>>> erobinet@apache.org>:
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>               Hi all,
> >         > >>>>>     >> > > >     >>>>>>>>>>               I've been
> > working on the
> >         > >> Camel
> >         > >>>>>     >> Component
> >         > >>>>>     >> > and
> >         > >>>>>     >> > > >     >>>>>>> decided
> >         > >>>>>     >> > > >     >>>>>>>>> to test it inside Karaf, but I
> > noticed
> >         > >> that
> >         > >>>> I've got
> >         > >>>>>     >> this
> >         > >>>>>     >> > > > error
> >         > >>>>>     >> > > >     >>>>>>> now:
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>> https://i.imgur.com/kUZPwZ5.png
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>               Seems like this
> > class is
> >         > >> not
> >         > >>>> exported
> >         > >>>>>     >> by
> >         > >>>>>     >> > the
> >         > >>>>>     >> > > >     >>>>>>> bundle
> >         > >>>>>     >> > > >     >>>>>>>>> so it can not be found. Anyone
> > has an
> >         > >> idea on
> >         > >>>> how we
> >         > >>>>>     >> > could
> >         > >>>>>     >> > > > solve
> >         > >>>>>     >> > > >     >>>>>>> this?
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>               Etienne
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>>
> >         > >>>>>     >> > > >     >>>>>>
> >         > >>>>>     >> > > >     >>>>>> --
> >         > >>>>>     >> > > >     >>>>>> --
> >         > >>>>>     >> > > >     >>>>>> Christian Schneider
> >         > >>>>>     >> > > >     >>>>>> http://www.liquid-reality.de
> >         > >>>>>     >> > > >     >>>>>>
> >         > >>>>>     >> > > >     >>>>>> Computer Scientist
> >         > >>>>>     >> > > >     >>>>>> http://www.adobe.com
> >         > >>>>>     >> > > >     >>>>>>
> >         > >>>>>     >> > > >     >>>>
> >         > >>>>>     >> > > >     >>>
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > > >
> >         > >>>>>     >> > >
> >         > >>>>>     >> >
> >         > >>>>>     >>
> >         > >>>>>     >
> >         > >>>>>
> >         > >>>>
> >         > >>>
> >         > >>
> >         > >
> >         >
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message