Yes, that is what I suggest On Fri, May 8, 2020, 16:19 Robinet, Etienne <43...@etu.he2b.be> wrote:
> Hello, > so if I understand correctly, I should create a new module for the OSGi > bundle, containing generic Activators that would be mentioned in the > Driver/Transport MANIFEST? > Etienne > > Le ven. 8 mai 2020 à 09:55, Niclas Hedhman <nic...@hedhman.org> a écrit : > > > As mentioned elsewhere, the generic activators could go in a separate > > bundle for OSGi use only. That applies to both this approach and Lukasz' > > one. > > > > // Niclas > > > > On Fri, May 8, 2020 at 2:08 PM Christofer Dutz < > christofer.d...@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 <nic...@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.d...@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.feina...@pragmaticminds.de>: > > > > > > > > I would say that there are arguments for both cases (as ist often > > > with > > > > OSGi, IMHO). > > > > So I see them not as right or wrong but as to different styles or > > > > approaches that I woudl leave up to you to decide. > > > > > > > > IMHO > > > > Julian > > > > > > > > Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be > >: > > > > > > > > Hi guys, > > > > As I am really not an expert, which approach should we use? > > > > > > > > Etienne > > > > > > > > Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki < > > l...@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 < > > > > erobi...@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 < > > nic...@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 < > > > > 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>: > > > > > >>>>> >> > > > >>>>>>>>>> > > > > > >>>>> >> > > > >>>>>>>>>>