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 > > > >>>>>> > > > >>>> > > > >>> > > > > > > > > > > > >
