Re: SPI Module - OSGi Bundle
Hi Niclas,
If your suggested path doesn't limit the framework decisions a user 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
manager, which I wouldn't want to put 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 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 would expect to see it and the
added benefit that default behavior can be overridden. Lukasz uses my own
work-around (for JDBC drivers) to show me that is the way things are done.
It is not, it was a necessary hack for that time to get around the legacy
JDBC drivers out in the open, all of them without OSGi manifests.
As I said, I have no skin in the game. Only providing independent advice,
as a former OSGi expert and a keen interest in PLC4X.
// Niclas
On Thu, May 7, 2020 at 9:13 PM Christofer Dutz
wrote:
> 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" <
> j.feina...@pragmaticminds.de>:
>
> 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,
> 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
> 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 classes) to another place.
> It is
> > necessary to avoid creation of implementation dependency. And
> that's
> > what is in fact, promoted by shared activator class.
> >
> > Best,
> > Łukasz
> >
> >
> > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > 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 BundleActivator {
> > >
> > > private ServiceRegistration reg;
> > >
> > > @Override
> > > public void start( BundleContext context ) throws
> Exception {
> > > Hashtable props = new Hashtable<>();
> > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > driver.getProtocolCode() );
> > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > driver.getProtocolName() );
> > > reg = context.registerService( PlcDriver.class,
> driver, props );
> > > }
> > >
> > > @Override
> > > public void stop( BundleContext context ) {
> > > context.unregisterService( reg );
> > > }
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> erobi...@apache.org>
> > wrote:
> > >
> > >> 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 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
> > >>> existed and changing their build and/or manifests was
> decided to be
> > "not
> > >>> viable". The approa
Re: SPI Module - OSGi Bundle
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 would expect to see it and the
added benefit that default behavior can be overridden. Lukasz uses my own
work-around (for JDBC drivers) to show me that is the way things are done.
It is not, it was a necessary hack for that time to get around the legacy
JDBC drivers out in the open, all of them without OSGi manifests.
As I said, I have no skin in the game. Only providing independent advice,
as a former OSGi expert and a keen interest in PLC4X.
// Niclas
On Thu, May 7, 2020 at 9:13 PM Christofer Dutz
wrote:
> 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" <
> j.feina...@pragmaticminds.de>:
>
> 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,
> 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
> 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 classes) to another place.
> It is
> > necessary to avoid creation of implementation dependency. And
> that's
> > what is in fact, promoted by shared activator class.
> >
> > Best,
> > Łukasz
> >
> >
> > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > 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 BundleActivator {
> > >
> > > private ServiceRegistration reg;
> > >
> > > @Override
> > > public void start( BundleContext context ) throws
> Exception {
> > > Hashtable props = new Hashtable<>();
> > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > driver.getProtocolCode() );
> > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > driver.getProtocolName() );
> > > reg = context.registerService( PlcDriver.class,
> driver, props );
> > > }
> > >
> > > @Override
> > > public void stop( BundleContext context ) {
> > > context.unregisterService( reg );
> > > }
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> erobi...@apache.org>
> > wrote:
> > >
> > >> 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 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
> > >>> existed and changing their build and/or manifests was
> decided to be
> > "not
> > >>> viable". The approach there is a work-around for legacy
> code, which I
> > and
> > >>> Stuart McCulloch basically invented. IIRC, this happened in
> 2007.
> > >>>
> > >>> I didn't suggest that bundles require Declarative Services.
> I suggested
> > >>> that the "inside of the loop" in Etienne's code is put into
> an
> > Activator,
> > >>> the code residing in the API and SPI bundles respectively,
> and that
> > each
> > >>> dri
[jira] [Created] (PLC4X-196) Apache NiFi integration should allow Expression Language
Turker TUNALI created PLC4X-196: --- Summary: Apache NiFi integration should allow Expression Language Key: PLC4X-196 URL: https://issues.apache.org/jira/browse/PLC4X-196 Project: Apache PLC4X Issue Type: New Feature Components: Integration-NiFi Affects Versions: 0.7.0 Reporter: Turker TUNALI Apache NiFi integration should allow to use Expression Language for PLC connection string and PLC resource address string. We sometimes need to get data from 100 different addresses. Current processors doesn't allow us to create those strings on the fly. So we need to enter them manually or we need utilize NiFi API to create flows automatically. If those parameters allows us to use expression language, we can read a list from csv file or from database and then we can read them in a loop in Apache NiFi. So it will be very handy feature to dynamically specify the connection string and the address string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: SPI Module - OSGi Bundle
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? Etienne > Le 7 mai 2020 à 15:13, Christofer Dutz a écrit : >
[GitHub] [plc4x] ottobackwards opened a new pull request #151: add CODE_CONVENTIONS
ottobackwards opened a new pull request #151: URL: https://github.com/apache/plc4x/pull/151 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: SPI Module - OSGi Bundle
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 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,
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 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 classes) to another place. It is
> necessary to avoid creation of implementation dependency. And that's
> what is in fact, promoted by shared activator class.
>
> Best,
> Łukasz
>
>
> On 06.05.2020 13:47, Niclas Hedhman wrote:
> > 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 BundleActivator {
> >
> > private ServiceRegistration reg;
> >
> > @Override
> > public void start( BundleContext context ) throws Exception {
> > Hashtable props = new Hashtable<>();
> > props.put( OsgiDriverManager.PROTOCOL_CODE,
> driver.getProtocolCode() );
> > props.put( OsgiDriverManager.PROTOCOL_NAME,
> driver.getProtocolName() );
> > reg = context.registerService( PlcDriver.class, driver,
props );
> > }
> >
> > @Override
> > public void stop( BundleContext context ) {
> > context.unregisterService( reg );
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet
> wrote:
> >
> >> 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 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
> >>> existed and changing their build and/or manifests was decided to
be
> "not
> >>> viable". The approach there is a work-around for legacy code,
which I
> and
> >>> Stuart McCulloch basically invented. IIRC, this happened in 2007.
> >>>
> >>> I didn't suggest that bundles require Declarative Services. I
suggested
> >>> that the "inside of the loop" in Etienne's code is put into an
> Activator,
> >>> the code residing in the API and SPI bundles respectively, and
that
> each
> >>> driver/transport has a "Bundle-Activator: ." in the manifest
> >>> referencing respective activator. It is not more intrusive than
the
> >>> Export-Package, Import-Package that will be required anyway.
> >>>
> >>> Advantages; It is more in the spirit of OSGi. But importantly, the
> >>> driver/transport is now an active bundle, rather than a library
bundle,
> >> and
> >>> in theory the start/stop of a bundle could (there might be other
> reasons
> >>> why not) turn it on/off in runtime. If special needs pop up,
maybe to
> >>> deploy for the OpenHAB project, it is possible to override the
> >>> driver/transport with hacking the API/SPI bundles.
> >>>
> >>> And I can't see any disadvantages other than "need to rework a
bit of
> >> code".
> >>>
> >>> But I don't have skin in the game. Not in OSGi, not here, so take
my
> >>> recommendations into consideration or throw them away. I just got
the
> >>> impression that you didn't really get
Re: [Introduction] Christofer Dutz
Hi guys, I'm Etienne, 24 years old (2 weeks until 25) and I'm currently studying Computer Science with a focus on Industrial IT in Brussels. I'm in my last semester and doing an Internship in Luxembourg, the country I live in, where I have been assigned to work with PLC and monitoring data using Open-source software. I really enjoy being part of this project and plan on continuing even after my internship. I initially studied 3 years in Luxembourg to become a teacher when I decided to turn things around and follow my second option : IT (Maths, Physics and IT were my main topics in highschool) . I decided to go abroad to Brussel as most Luxembourgish students go there and I have already gone there a few times. My father is an Engineer and studied material physics. He has 2 sons, one likes maths, physics and computers and one hates all of them. Guess I'm the first one. I was born in Amiens, France and I'm french, but we moved to Luxembourg in 2000 when I was 5 so I have only a few memories left from my time in France. I'm a big Gaming Enthusiast and have been playing video games since I was a kid, but now I mainly play 1 game only. Beside that, I like experimenting in my kitchen which will always make my girlfriend angry because I don't clean up. I also like every kind of beer (almost) you can find but my heart sticks to belgian beers and German "Helles" due to my Erasmus I did in 2015 where I went to Munich for 6 months. Or maybe my love for beers & cocktails comes from the fact that I have been bartending for over 2 years along my studies (on the weekend) and I kind of enjoy bars. Had to stop in January due to an unplanned but very loved daughter I got on February which now fills my life with joy. Still looking forward to when bars open again tho. Cheers, Etienne Le jeu. 7 mai 2020 à 12:32, Julian Feinauer a écrit : > Hey friends, > > first, thanks for starting this excellent initiaive (we should probably > place the texts even on the "team" part oft he homepage). > > I am Julian, 32 years old, married to my lovely wide Constanze and have > three kids (two of them know toddy personally and like him, the third is > too small, yet). > We live in Kirchheim which is about 40km south of Stuttgart and at the > "Schwäbische Alb" a very nice and rural area. > I studied math and I really am mathematician by heart. I did my PhD in an > applied math project and worked (together with my fellow Tim) on lithium > ion batteries for mobile applications at a Daimler. But I felt too young > and dynamic to stay in a corporate, thus I started a company. > > We initially foused on data analysis and BI stuff but moved more and more > to technical data and ended up in the "digitalization" or "Industrie 4.0" > world. We joined the PLC4X project pretty early as we decided to abandon > our home made stack to polish PLC4X for our purposes. Thus, we have it in > production since way over a year now and have a lot of hands on experience > (especially Tim). Thus, we often focus on "boring" things like scraper, > pools and stability related stuff (like Netty) and do not so much implement > new drivers (AB Ethernet we did together with Chris). But as we are really > deep in the community and love it we do way more in the project then we > would probably need for our business application, solely : ) > > But generally speaking, you can always ping us with usage scenario > questions (mostly Siemens S7) and integrations. Currently we see ourselves > as the main maintainers oft he 0.6 branch at least until one can migrate > safely and stable to 0.7 (when it will be out) as we have too much stuff in > production nowadays to play games (Cesar may surely know what happens when > stuff in production does not work as expected... : D). > > So, thanks all of you for making our little community so lovely and > enyojable. I feel very happy tob e part o fit and to hang out with you > guys. And we are really making an impact, more and more! > Julian > > > Am 07.05.20, 11:36 schrieb "Strljic, Matthias Milan" < > matthias.strl...@isw.uni-stuttgart.de>: > > Hi, > > I am a research assistant at the University of Stuttgart at the > Institute of Control Engineering (ISW) and work there in the areas of > communication/service concepts for automation systems and cloud > manufacturing. > Among other things with projects like RetroNet I got in contact with > several older automation protocols (ADS, S7, Profinet/bus..) and also more > recent ones like OPC UA and their diversity despite the common goal. That's > how I got to know Chris, Julian and the initial PLC4X crew :) > > Before that I completed a study in software engineering. My main > programming language would be Java, but I already had a lot of stacks in my > hands (Javascript, C++, Python, Go, C#, Ada, PHP). > > I like to sharpen knives and sometimes distil some schnapps. So if > someone wants to forget a bug, you can choose between 40 - 80% alcohol > content and 5 flavours ;) If
Re: SPI Module - OSGi Bundle
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,
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 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 classes) to another place. It is
> necessary to avoid creation of implementation dependency. And that's
> what is in fact, promoted by shared activator class.
>
> Best,
> Łukasz
>
>
> On 06.05.2020 13:47, Niclas Hedhman wrote:
> > 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 BundleActivator {
> >
> > private ServiceRegistration reg;
> >
> > @Override
> > public void start( BundleContext context ) throws Exception {
> > Hashtable props = new Hashtable<>();
> > props.put( OsgiDriverManager.PROTOCOL_CODE,
> driver.getProtocolCode() );
> > props.put( OsgiDriverManager.PROTOCOL_NAME,
> driver.getProtocolName() );
> > reg = context.registerService( PlcDriver.class, driver, props );
> > }
> >
> > @Override
> > public void stop( BundleContext context ) {
> > context.unregisterService( reg );
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet
> wrote:
> >
> >> 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 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
> >>> existed and changing their build and/or manifests was decided to be
> "not
> >>> viable". The approach there is a work-around for legacy code, which I
> and
> >>> Stuart McCulloch basically invented. IIRC, this happened in 2007.
> >>>
> >>> I didn't suggest that bundles require Declarative Services. I
suggested
> >>> that the "inside of the loop" in Etienne's code is put into an
> Activator,
> >>> the code residing in the API and SPI bundles respectively, and that
> each
> >>> driver/transport has a "Bundle-Activator: ." in the manifest
> >>> referencing respective activator. It is not more intrusive than the
> >>> Export-Package, Import-Package that will be required anyway.
> >>>
> >>> Advantages; It is more in the spirit of OSGi. But importantly, the
> >>> driver/transport is now an active bundle, rather than a library
bundle,
> >> and
> >>> in theory the start/stop of a bundle could (there might be other
> reasons
> >>> why not) turn it on/off in runtime. If special needs pop up, maybe to
> >>> deploy for the OpenHAB project, it is possible to override the
> >>> driver/transport with hacking the API/SPI bundles.
> >>>
> >>> And I can't see any disadvantages other than "need to rework a bit of
> >> code".
> >>>
> >>> But I don't have skin in the game. Not in OSGi, not here, so take my
> >>> recommendations into consideration or throw them away. I just got the
> >>> impression that you didn't really get what I suggested.
> >>>
> >>>
> >>> // Niclas
> >>>
> >>>
> >>>
> >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki
> >> wrote:
> >>>
> 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 register them in OSGi service registry. If you will ta
Re: [Introduction] Christofer Dutz
Hey friends, first, thanks for starting this excellent initiaive (we should probably place the texts even on the "team" part oft he homepage). I am Julian, 32 years old, married to my lovely wide Constanze and have three kids (two of them know toddy personally and like him, the third is too small, yet). We live in Kirchheim which is about 40km south of Stuttgart and at the "Schwäbische Alb" a very nice and rural area. I studied math and I really am mathematician by heart. I did my PhD in an applied math project and worked (together with my fellow Tim) on lithium ion batteries for mobile applications at a Daimler. But I felt too young and dynamic to stay in a corporate, thus I started a company. We initially foused on data analysis and BI stuff but moved more and more to technical data and ended up in the "digitalization" or "Industrie 4.0" world. We joined the PLC4X project pretty early as we decided to abandon our home made stack to polish PLC4X for our purposes. Thus, we have it in production since way over a year now and have a lot of hands on experience (especially Tim). Thus, we often focus on "boring" things like scraper, pools and stability related stuff (like Netty) and do not so much implement new drivers (AB Ethernet we did together with Chris). But as we are really deep in the community and love it we do way more in the project then we would probably need for our business application, solely : ) But generally speaking, you can always ping us with usage scenario questions (mostly Siemens S7) and integrations. Currently we see ourselves as the main maintainers oft he 0.6 branch at least until one can migrate safely and stable to 0.7 (when it will be out) as we have too much stuff in production nowadays to play games (Cesar may surely know what happens when stuff in production does not work as expected... : D). So, thanks all of you for making our little community so lovely and enyojable. I feel very happy tob e part o fit and to hang out with you guys. And we are really making an impact, more and more! Julian Am 07.05.20, 11:36 schrieb "Strljic, Matthias Milan" : Hi, I am a research assistant at the University of Stuttgart at the Institute of Control Engineering (ISW) and work there in the areas of communication/service concepts for automation systems and cloud manufacturing. Among other things with projects like RetroNet I got in contact with several older automation protocols (ADS, S7, Profinet/bus..) and also more recent ones like OPC UA and their diversity despite the common goal. That's how I got to know Chris, Julian and the initial PLC4X crew :) Before that I completed a study in software engineering. My main programming language would be Java, but I already had a lot of stacks in my hands (Javascript, C++, Python, Go, C#, Ada, PHP). I like to sharpen knives and sometimes distil some schnapps. So if someone wants to forget a bug, you can choose between 40 - 80% alcohol content and 5 flavours ;) If Toddy leaves some. At the moment I'm working on the OPC UA integration of Milo into PLC4J with the documentation (Pls Toddy stop hurting me! ) and a bridge server for the OPC UA representation of other protocols in an extra integrated OPC UA server. Our institute is quite experienced in TSN and OPC Companion specifications. Therefore I try to integrate the project into publicly funded research projects to make PLC4X more known and to support the community. Greetings Matthias Von: Christofer Dutz Gesendet: Dienstag, 5. Mai 2020 13:23:42 An: dev@plc4x.apache.org Betreff: [Introduction] Christofer Dutz Hi all, I have noticed that our tram has grown quite a bit in the last year and most of you I have never met personally. We have been discussing a lot of things here on the list and on slack, but I only have little background on who you folks actually are. So I would like to ask anyone interested to just introduce himself in this thread. I’ll start: My name is Christofer Dutz, I’m currently 42 years old and studied computer-science at the University of Darmstadt. I’m the son of an Electro-Engineer and therefore already had contact with all of this automation stuff when I was a kid, but somehow lost contact when I discovered my interest in computers. Being an IT guy living near Frankfurt (Germany) there is almost no chance to not work for Banks and Insurance companies. So I guess I’ve been working for about 12 different Banks and Insurance companies in the last 15 years. I always like to compare working for a bank like asking Picasso to paint a portrait, but to have him wear a mental-institution restraining jacket and have him paint with a brush in his mouth. End of the first quarter of 2017 it was getting so unbearable for me, that I was thinking about giving up my profession as an IT specialist and even starting to l
AW: [Introduction] Christofer Dutz
Hi, I am a research assistant at the University of Stuttgart at the Institute of Control Engineering (ISW) and work there in the areas of communication/service concepts for automation systems and cloud manufacturing. Among other things with projects like RetroNet I got in contact with several older automation protocols (ADS, S7, Profinet/bus..) and also more recent ones like OPC UA and their diversity despite the common goal. That's how I got to know Chris, Julian and the initial PLC4X crew :) Before that I completed a study in software engineering. My main programming language would be Java, but I already had a lot of stacks in my hands (Javascript, C++, Python, Go, C#, Ada, PHP). I like to sharpen knives and sometimes distil some schnapps. So if someone wants to forget a bug, you can choose between 40 - 80% alcohol content and 5 flavours ;) If Toddy leaves some. At the moment I'm working on the OPC UA integration of Milo into PLC4J with the documentation (Pls Toddy stop hurting me! ) and a bridge server for the OPC UA representation of other protocols in an extra integrated OPC UA server. Our institute is quite experienced in TSN and OPC Companion specifications. Therefore I try to integrate the project into publicly funded research projects to make PLC4X more known and to support the community. Greetings Matthias Von: Christofer Dutz Gesendet: Dienstag, 5. Mai 2020 13:23:42 An: dev@plc4x.apache.org Betreff: [Introduction] Christofer Dutz Hi all, I have noticed that our tram has grown quite a bit in the last year and most of you I have never met personally. We have been discussing a lot of things here on the list and on slack, but I only have little background on who you folks actually are. So I would like to ask anyone interested to just introduce himself in this thread. I’ll start: My name is Christofer Dutz, I’m currently 42 years old and studied computer-science at the University of Darmstadt. I’m the son of an Electro-Engineer and therefore already had contact with all of this automation stuff when I was a kid, but somehow lost contact when I discovered my interest in computers. Being an IT guy living near Frankfurt (Germany) there is almost no chance to not work for Banks and Insurance companies. So I guess I’ve been working for about 12 different Banks and Insurance companies in the last 15 years. I always like to compare working for a bank like asking Picasso to paint a portrait, but to have him wear a mental-institution restraining jacket and have him paint with a brush in his mouth. End of the first quarter of 2017 it was getting so unbearable for me, that I was thinking about giving up my profession as an IT specialist and even starting to learn something new. I was already looking for companies looking for an apprentice as carpenter, when I had another round of self-reflection. Even if I probably would have been good as a carpenter, I still love doing my job, just not for Banks and Insurance companies. I was seeing the same with a lot of my colleagues. It was that time that Industry 4.0 was everywhere … all the problems are easily addressable with open-source and a lot of the skills I have from the banking would have been a perfect match. So I had a look at what’s missing in this big picture and pretty quickly noticed the data-access problem is the biggest barrier and no solution being available or in sight. Luckily at codecentric we have something called “Innovation budget”. Here if you’ve got an idea, you can pitch in some shark-tank-like session with the board and if they like it, you get the funds for doing that. My idea was to build a universal protocol adapter. From the beginning I said I want this to be a true open-source project at Apache. The benefit for codecentric would be to eliminate the barriers to offering IIoT solutions with our large set of professionals in all areas this involves. The board agreed and for the last 3,5 years I have been paid by codecentric to work on Apache PLC4X full-time. Outside of the IT world, I love to do sports with others, so I’m usually in the gym in some workout and TaeBo courses about 3 times a week, I love snowboarding and everything that has anything to do with water. Another huge passion of mine is melodic electronic music, so usually I travel around the Europe visiting different electronic music festivals. I live in a town called Ober-Ramstadt together with my girlfriend Tanja, where we just moved into a house I inherited from my grandpa and which we renovated in 2 years of hard work … and still the work doesn’t end … so some-times I fall off the face of the earth for a few days cause I’m probably digging trenches for the foundation for some wall, or my rain-water system, or … or … or …. Guess the digging never stops. Ok … so I hope this gives you a little impression on who I am and what drives me … it would make me happy to see some of you
Re: SPI Module - OSGi Bundle
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 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 classes) to another place. It is
> necessary to avoid creation of implementation dependency. And that's
> what is in fact, promoted by shared activator class.
>
> Best,
> Łukasz
>
>
> On 06.05.2020 13:47, Niclas Hedhman wrote:
> > 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 BundleActivator {
> >
> > private ServiceRegistration reg;
> >
> > @Override
> > public void start( BundleContext context ) throws Exception {
> > Hashtable props = new Hashtable<>();
> > props.put( OsgiDriverManager.PROTOCOL_CODE,
> driver.getProtocolCode() );
> > props.put( OsgiDriverManager.PROTOCOL_NAME,
> driver.getProtocolName() );
> > reg = context.registerService( PlcDriver.class, driver, props );
> > }
> >
> > @Override
> > public void stop( BundleContext context ) {
> > context.unregisterService( reg );
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet
> wrote:
> >
> >> 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 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
> >>> existed and changing their build and/or manifests was decided to be
> "not
> >>> viable". The approach there is a work-around for legacy code, which I
> and
> >>> Stuart McCulloch basically invented. IIRC, this happened in 2007.
> >>>
> >>> I didn't suggest that bundles require Declarative Services. I suggested
> >>> that the "inside of the loop" in Etienne's code is put into an
> Activator,
> >>> the code residing in the API and SPI bundles respectively, and that
> each
> >>> driver/transport has a "Bundle-Activator: ." in the manifest
> >>> referencing respective activator. It is not more intrusive than the
> >>> Export-Package, Import-Package that will be required anyway.
> >>>
> >>> Advantages; It is more in the spirit of OSGi. But importantly, the
> >>> driver/transport is now an active bundle, rather than a library bundle,
> >> and
> >>> in theory the start/stop of a bundle could (there might be other
> reasons
> >>> why not) turn it on/off in runtime. If special needs pop up, maybe to
> >>> deploy for the OpenHAB project, it is possible to override the
> >>> driver/transport with hacking the API/SPI bundles.
> >>>
> >>> And I can't see any disadvantages other than "need to rework a bit of
> >> code".
> >>>
> >>> But I don't have skin in the game. Not in OSGi, not here, so take my
> >>> recommendations into consideration or throw them away. I just got the
> >>> impression that you didn't really get what I suggested.
> >>>
> >>>
> >>> // Niclas
> >>>
> >>>
> >>>
> >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki
> >> wrote:
> >>>
> 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 register them in OSGi service registry. If you will take a
> look on following line:
>
>
> >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> you will find that bundle is an jar which changes state to ACTIVE.
> Additionally that bundle classloader is used to find services and that
> bundle context is used to register services. In the end service which
> appears looks like one registered by driver/transport module.
>
> The main point for above implementation is basic - getting the
> standard
> PLC4X driver JAR working in OSGi without forcing it to knowing too
> much
> about OSGi. Driver needs to ship manifest with import/export
> statements
> and that's it. Additionally
