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