Have you checked that the MANIFEST.MF looks good? On Tue, Apr 7, 2020, 21:39 Etienne Robinet <erobi...@apache.org> 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 > > > >> > > > > > >
