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