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