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

Reply via email to