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