Re: SPI Module - OSGi Bundle

2020-05-08 Thread Robinet, Etienne
t; has, > > > > then I have no objections. > > > > > > > > Indiens I am not that deep into osgi to have a well founded opinion. > > > > > > > > The api will probably never be a pure api module as it contains the > > > driver > >

Re: SPI Module - OSGi Bundle

2020-05-08 Thread Niclas Hedhman
objections. > > > > > > Indiens I am not that deep into osgi to have a well founded opinion. > > > > > > The api will probably never be a pure api module as it contains the > > driver > > > manager, which I wouldn't want to put into a separate module. >

Re: SPI Module - OSGi Bundle

2020-05-08 Thread Robinet, Etienne
separate module. > > > > Chris > > > > Von: Niclas Hedhman > > Gesendet: Freitag, 8. Mai 2020 05:12 > > An: dev@plc4x.apache.org > > Betreff: Re: SPI Module - OSGi Bundle > > > > Both approaches are independent of O

Re: SPI Module - OSGi Bundle

2020-05-08 Thread Niclas Hedhman
separate module. > > Chris > > Von: Niclas Hedhman > Gesendet: Freitag, 8. Mai 2020 05:12 > An: dev@plc4x.apache.org > Betreff: Re: SPI Module - OSGi Bundle > > Both approaches are independent of OSGi framework implementations, which is > part of the beauty of OSGi. >

Re: SPI Module - OSGi Bundle

2020-05-08 Thread Christofer Dutz
into a separate module. Chris Von: Niclas Hedhman Gesendet: Freitag, 8. Mai 2020 05:12 An: dev@plc4x.apache.org Betreff: Re: SPI Module - OSGi Bundle Both approaches are independent of OSGi framework implementations, which is part of the beauty of OSGi. Lukasz

Re: SPI Module - OSGi Bundle

2020-05-07 Thread Niclas Hedhman
Both approaches are independent of OSGi framework implementations, which is part of the beauty of OSGi. Lukasz puts more value on some dogmatic principle ("only interfaces in API"), whereas I have forwarded how an OSGi bundle producer is expected to provide it, and how an OSGi bundle consumer

Re: SPI Module - OSGi Bundle

2020-05-07 Thread Christofer Dutz
Hi Etienne, I have to admit that I would prefer this option ... but we should also let the others state their opinion. Chris Am 07.05.20, 19:27 schrieb "Etienne Robinet" <43...@etu.he2b.be>: Hi Chris Well then we could create a seperate module to put the Activators we have in it?

Re: SPI Module - OSGi Bundle

2020-05-07 Thread Christofer Dutz
Hi folks, so if there is an option that doesn't tie our API and Drivers to a specific OSGi framework, I would prefer that. Chris Am 07.05.20, 12:35 schrieb "Julian Feinauer" : I would say that there are arguments for both cases (as ist often with OSGi, IMHO). So I see them not as

Re: SPI Module - OSGi Bundle

2020-05-07 Thread Julian Feinauer
I would say that there are arguments for both cases (as ist often with OSGi, IMHO). So I see them not as right or wrong but as to different styles or approaches that I woudl leave up to you to decide. IMHO Julian Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>: Hi guys,

Re: SPI Module - OSGi Bundle

2020-05-07 Thread Robinet, Etienne
Hi guys, As I am really not an expert, which approach should we use? Etienne Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki a écrit : > Hey Niclas, > While this code seems straight I don't think it is needed, and valid in > our case. > Main benefit of extender and extender based patterns is

Re: SPI Module - OSGi Bundle

2020-05-06 Thread Łukasz Dywicki
Hey Niclas, While this code seems straight I don't think it is needed, and valid in our case. Main benefit of extender and extender based patterns is centralized processing of drivers. I am keen to keep only interfaces in the API packages and bundles and move active parts of code (such base

Re: SPI Module - OSGi Bundle

2020-05-06 Thread Niclas Hedhman
My suggestion was; 1. Don't do the BundleTracker classes, and instead change to a bundle activator for each. 2. Add the "Bundle-Activator: org.apache.plc4x.java.osgi.DriverActivator" to the driver META/MANIFEST.MF 3. Do the equivalent for the Transports. public class DriverActivator implements

Re: SPI Module - OSGi Bundle

2020-05-06 Thread Etienne Robinet
Hi all, So concretely what changes should be done so that a Driver/Transport declares itself his service? Beside the changes in the manifest? Etienne On 2020/05/06 01:26:42, Niclas Hedhman wrote: > Łukasz, > > the reason I say it is not very OSGi-y, is that the principle of OSGi is > that the

Re: SPI Module - OSGi Bundle

2020-05-05 Thread Niclas Hedhman
Łukasz, the reason I say it is not very OSGi-y, is that the principle of OSGi is that the bundle handles its own service registrations. In the case of JDBC (I initiated that spec, and I am the founder of OPS4J as well as Pax subproject, 2005), it needed to address the problem that JDBC drivers

Re: SPI Module - OSGi Bundle

2020-05-05 Thread Łukasz Dywicki
Hey Etienne, that's awesome piece of work. I can test it! :-) I believe that's what Etienne code does it in a valid OSGi way. And I do believe not because he mentioned me by name, but due to below argumentation. Proposed code uses extender pattern to grab specific META-INF/services entries and

Re: SPI Module - OSGi Bundle

2020-05-05 Thread Julian Feinauer
Hi Etienne and Niclas, indeed we could orient (again) on how JDBC does that in OSGi. They really focus on "late binding" so that you resolve the driver directly when you need it. In theory, there is no such thing as a DriverManager in OSGi but only a PlcDriver with the capability

Re: SPI Module - OSGi Bundle

2020-05-05 Thread Niclas Hedhman
Also, just in case, a custom activator is ever required, it can be overridden easily without breaking the over all design On Tue, May 5, 2020 at 6:27 PM Niclas Hedhman wrote: > Yes, that's what I mean, because that is what you have inside the loop, so > it should work. > > On Tue, May 5, 2020

Re: SPI Module - OSGi Bundle

2020-05-05 Thread Niclas Hedhman
Yes, that's what I mean, because that is what you have inside the loop, so it should work. On Tue, May 5, 2020 at 11:50 AM Robinet, Etienne <43...@etu.he2b.be> wrote: > Hi Niclas, > thanks for the feedback. So you mean to make the Activator in API/SPI > generic so every Driver would call it and

Re: SPI Module - OSGi Bundle

2020-05-04 Thread Robinet, Etienne
Hi Niclas, thanks for the feedback. So you mean to make the Activator in API/SPI generic so every Driver would call it and declare the service itself? Le mar. 5 mai 2020 à 05:25, Niclas Hedhman a écrit : > What you are doing is not particularly OSGi-y... The expected way to do > this is to have

Re: SPI Module - OSGi Bundle

2020-05-04 Thread Niclas Hedhman
What you are doing is not particularly OSGi-y... The expected way to do this is to have each bundle register their PlcDriver or Transport to the OSGi service registry. That said, what you have done is otherwise fine, as you basically trying to centralize the BundleActivators away from respective

Re: SPI Module - OSGi Bundle

2020-05-04 Thread Robinet, Etienne
Hi all, With the change of Christofer this problem got solved. Nonetheless, I kept the work I did (inspired by the work of Lukasz) to make an Activator for API (Driver Services) and SPI (Transport Services). I also tested it, but as I am pretty new to this, if anyone could just give me a feedback

Re: SPI Module - OSGi Bundle

2020-04-07 Thread Christofer Dutz
Hi folks, I just pushed a change that might get rid of this error. I added the Plc4xBootstrap in an attempt to get the TestTransport working. For some reasons the netty folks created the EmbeddedChannel differently than the rest. However as the TestTransport is the only one needing this

Re: SPI Module - OSGi Bundle

2020-04-07 Thread Etienne Robinet
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 a écrit : > > I was updating my local checkout

Re: SPI Module - OSGi Bundle

2020-04-07 Thread Łukasz Dywicki
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: >

Re: SPI Module - OSGi Bundle

2020-04-07 Thread Niclas Hedhman
Have you checked that the MANIFEST.MF looks good? On Tue, Apr 7, 2020, 21: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

Re: SPI Module - OSGi Bundle

2020-04-07 Thread Etienne Robinet
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

Re: SPI Module - OSGi Bundle

2020-04-07 Thread Etienne Robinet
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 wrote: > I haven't used Camel

Re: SPI Module - OSGi Bundle

2020-04-07 Thread Niclas Hedhman
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

Re: SPI Module - OSGi Bundle

2020-04-06 Thread Robinet, Etienne
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

Re: SPI Module - OSGi Bundle

2020-04-06 Thread Łukasz Dywicki
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

Re: SPI Module - OSGi Bundle

2020-04-03 Thread Etienne Robinet
Hi Christian, you mean the code used in the Camel route? It is an blueprint: 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

Re: SPI Module - OSGi Bundle

2020-04-03 Thread Christian Schneider
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

Re: SPI Module - OSGi Bundle

2020-04-03 Thread Julian Feinauer
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" : Hi again, I've been struggling with this issue for

Re: SPI Module - OSGi Bundle

2020-04-03 Thread Etienne Robinet
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

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Niclas Hedhman
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

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Christofer Dutz
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

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Etienne Robinet
Hi Julian, that actually did the trick. But now I am getting the next error. https://i.imgur.com/U7NjmsF.png As you can see, the class it cant find is inside the container, so that is even more weird. Etienne On 2020/03/31 14:09:11, Julian Feinauer wrote: > Hi, > > this is not so optimal. >

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Julian Feinauer
Hi, this is not so optimal. Then one solution would be to embed the SPI bundle inside the transport bundle(s). This can be done with the felix-maven plugin by using the configuration if I remember correctly. Julian Am 31.03.20, 16:07 schrieb "Etienne Robinet" <43...@etu.he2b.be>: Hi,

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Etienne Robinet
Hi, From the log the class is called outside the SPI by the transport Etienne > Le 31 mars 2020 à 15:24, Julian Feinauer 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

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Julian Feinauer
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" : As this package is only referenced

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Christofer Dutz
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" : Hi, the issue is that if we export it, then we break Nettys OSGi integration as we get a split package situation (two

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Julian Feinauer
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

Re: SPI Module - OSGi Bundle

2020-03-31 Thread Christofer Dutz
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

SPI Module - OSGi Bundle

2020-03-31 Thread Etienne Robinet
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