As for the META-INF/services, that is a standard JDK feature, known as the ServiceLoader, unrelated to OSGi.
@Component is a sign of the Declarative Services that Łukasz asked about, but it requires compile-time support to work as expected. Under the hood, DS is still doing the normal song and dance of OSGi core services. // Niclas On Tue, Apr 7, 2020 at 11:56 AM Robinet, Etienne <43...@etu.he2b.be> wrote: > Hi Lukasz, > thank you very much for your help, I will look into this today. > For the drivers as services, isn't that already the case? I know that for > S7 and EIP at least, > the yhave the osgi.cmpn dependency and the @Component annotation for the > class, as well as a file with the implemented Driver class (with the Driver > interface file name) under main/resources/META-INF/services ( > > https://github.com/apache/plc4x/blob/develop/plc4j/drivers/eip/src/main/resources/META-INF/services/org.apache.plc4x.java.api.PlcDriver > ) > . Is that something else? > Etienne > > Le lun. 6 avr. 2020 à 22:28, Łukasz Dywicki <l...@code-house.org> a écrit > : > > > 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 > > >> > > >
