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 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  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:
> >
> > 
> > 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;>
> >
> >
> > http://camel.apache.org/schema/blueprint; streamCache="true" >
> > 
> > 
> > 
> > plc4x:s7:tcp://192.168.178.10?address=#fields
> 
> > 
> > 
> > 
> > 
> > 
> >
> >
> > 
> > 
> > 
> >
> >
> >
> >
> >
> >
> >
> >
> > 
> > 
> > 
> > 
> >
> > 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
> >
> >  
> > org.apache.felix
> > maven-bundle-plugin
> > 4.2.1
> > true
> > 
> > 
> >
>  ${project.artifactId}
> >
>  ${project.version}
> > 
> >*;version=${project.version}
> > 
> > 
> > org.apache.plc4x.java.spi.transport,
> > org.apache.plc4x.java.s7.readwrite,
> > *
> > 
> > 
> > 
> > 
> >
> >
> > Etienne
> >
> > On 2020/04/03 08:17:45, Christian Schneider 
> 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" :
> >>>
> >>> Hi again,
> >>> I've been struggling with this issue for 2 days now... I still
> 

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 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:
> 
> 
> 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;>
> 
> 
>  xmlns="http://camel.apache.org/schema/blueprint; streamCache="true" >
> 
> 
> 
> plc4x:s7:tcp://192.168.178.10?address=#fields
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
>
>
>
>
>
>
>
> 
> 
> 
> 
> 
> 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
> 
>  
> org.apache.felix
> maven-bundle-plugin
> 4.2.1
> true
> 
> 
> 
> ${project.artifactId}
> ${project.version}
> 
>*;version=${project.version}
> 
> 
> org.apache.plc4x.java.spi.transport,
> org.apache.plc4x.java.s7.readwrite,
> *
> 
> 
> 
> 
> 
> 
> Etienne
> 
> On 2020/04/03 08:17:45, Christian Schneider  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" :
>>>
>>> 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  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 

Re: [DISCUSS] Make libpcap mandatory?

2020-04-06 Thread Christofer Dutz
Let's not introduce yet another way to do such things ... these annotations 
seem to work fine and we/I've used them all over the place to make the 
testsuite runnable in all sorts of different scenarios.

So-far we have:
- RequireInternetConnection
- RequireNonCaptureAllDns
- RequirePcap
- RequirePcapNg


Chris


Am 06.04.20, 12:08 schrieb "Googlemail OS" 
:

Also one can use „assumeThat()“ in junit for such things.

> Am 06.04.2020 um 10:25 schrieb Julian Feinauer 
:
> 
> Nice, then thats the way to go!
> 
> Am 06.04.20, 10:21 schrieb "Christofer Dutz" :
> 
>I've already got an annotation you can use:
>@RequirePcap together with a Junit Condition, that skips the test if 
the condition is not met ... just noticed a bug in my condition however __ ... 
just fixing it.
> 
>Chris
> 
> 
>Am 06.04.20, 10:11 schrieb "Julian Feinauer" 
:
> 
>Hey,
> 
>I would not choose 1, as you say.
>Perhaps we can make this tests conditional (dont know how easy 
this is with junit5) an das you say, only allow releases with libpcap.
> 
>Julian
> 
>Am 06.04.20, 10:07 schrieb "Christofer Dutz" 
:
> 
>Hi,
> 
>I’m currently working on the prerequisiteCheck for my new 
plc4c module and am testing on empty OSes (OSes without any installed 
additional software)
>I noticed there are tests like the Raw-Socket test that 
naturally fail if you don’t have libpcap (or the windows counterpart installed) 
…
> 
>We now have two options:
> 
>  1.  Make libpcap mandatory
>  2.  Disable any test that is libpcap related
> 
>1) is the more secure version, but I think some people might 
have objections to installing libpcap on their systems.
> 
>How about automatically disabling these tests and to have a 
check in the prerequisiteChecks to not allow doing an “apache-release” without 
libpcap?
> 
>Got any other ideas?
> 
>Chris
> 
> 
> 
> 
> 
> 




[BUILD-STABLE]: Job 'PLC4X/PLC4X/develop [develop] [826]'

2020-04-06 Thread Apache Jenkins Server
BUILD-STABLE: Job 'PLC4X/PLC4X/develop [develop] [826]':

Is back to normal.

[BUILD-UNSTABLE]: Job 'PLC4X/PLC4X/develop [develop] [822]'

2020-04-06 Thread Apache Jenkins Server
BUILD-UNSTABLE: Job 'PLC4X/PLC4X/develop [develop] [822]':

Check console output at "https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/822/;>PLC4X/PLC4X/develop
 [develop] [822]"

[BUILD-UNSTABLE]: Job 'PLC4X/PLC4X/develop [develop] [821]'

2020-04-06 Thread Apache Jenkins Server
BUILD-UNSTABLE: Job 'PLC4X/PLC4X/develop [develop] [821]':

Check console output at "https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/821/;>PLC4X/PLC4X/develop
 [develop] [821]"

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [820]'

2020-04-06 Thread Apache Jenkins Server
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [820]':

Check console output at "https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/820/;>PLC4X/PLC4X/develop
 [develop] [820]"

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [819]'

2020-04-06 Thread Apache Jenkins Server
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [819]':

Check console output at "https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/819/;>PLC4X/PLC4X/develop
 [develop] [819]"

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [818]'

2020-04-06 Thread Apache Jenkins Server
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [818]':

Check console output at "https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/818/;>PLC4X/PLC4X/develop
 [develop] [818]"

[jira] [Created] (PLC4X-190) Support for umati: universal machine technology interface

2020-04-06 Thread Lukas Ott (Jira)
Lukas Ott created PLC4X-190:
---

 Summary: Support for umati: universal machine technology interface
 Key: PLC4X-190
 URL: https://issues.apache.org/jira/browse/PLC4X-190
 Project: Apache PLC4X
  Issue Type: New Feature
  Components: Driver-OPC-UA
Reporter: Lukas Ott


As the major plc providers are starting to support OPC-UA they also started to 
standardized the data structures in it with 
[https://opcfoundation.org/markets-collaboration/umati/]

UMATI. As PLC4X aims to connect all kinds of PLCs to one layer a connector or 
mapper from PLC to UMATI (OPC-UA) based format enhances our approach and 
enables all kinds of PLCs to map to UMATI as easily as possible.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [DISCUSS] Make libpcap mandatory?

2020-04-06 Thread Googlemail OS
Also one can use „assumeThat()“ in junit for such things.

> Am 06.04.2020 um 10:25 schrieb Julian Feinauer :
> 
> Nice, then thats the way to go!
> 
> Am 06.04.20, 10:21 schrieb "Christofer Dutz" :
> 
>I've already got an annotation you can use:
>@RequirePcap together with a Junit Condition, that skips the test if the 
> condition is not met ... just noticed a bug in my condition however __ ... 
> just fixing it.
> 
>Chris
> 
> 
>Am 06.04.20, 10:11 schrieb "Julian Feinauer" 
> :
> 
>Hey,
> 
>I would not choose 1, as you say.
>Perhaps we can make this tests conditional (dont know how easy this is 
> with junit5) an das you say, only allow releases with libpcap.
> 
>Julian
> 
>Am 06.04.20, 10:07 schrieb "Christofer Dutz" 
> :
> 
>Hi,
> 
>I’m currently working on the prerequisiteCheck for my new plc4c 
> module and am testing on empty OSes (OSes without any installed additional 
> software)
>I noticed there are tests like the Raw-Socket test that naturally 
> fail if you don’t have libpcap (or the windows counterpart installed) …
> 
>We now have two options:
> 
>  1.  Make libpcap mandatory
>  2.  Disable any test that is libpcap related
> 
>1) is the more secure version, but I think some people might have 
> objections to installing libpcap on their systems.
> 
>How about automatically disabling these tests and to have a check 
> in the prerequisiteChecks to not allow doing an “apache-release” without 
> libpcap?
> 
>Got any other ideas?
> 
>Chris
> 
> 
> 
> 
> 
> 


Re: AW: [DISCUSS] Rename PLC4DOTNET to PLC4CSHARP?

2020-04-06 Thread Łukasz Dywicki
Why not DOTNOT? :-)

Cheers,
Łukasz

On 03.04.2020 16:33, Bjoern Hoeper wrote:
> Some people are masochistic... ;)
> Joking aside I think the more relevant option is F# which could be a good 
> match for some use cases
> 
> -Ursprüngliche Nachricht-
> Von: Christofer Dutz  
> Gesendet: Freitag, 3. April 2020 16:30
> An: dev@plc4x.apache.org
> Betreff: Re: [DISCUSS] Rename PLC4DOTNET to PLC4CSHARP?
> 
> But VB?!?!?!?!
> 
> Am 03.04.20, 16:12 schrieb "Bjoern Hoeper" :
> 
> Hi,
> 
> in my opinion the runtime is the more relevant thing in this context 
> because if you take a .NET Lib you could use it with VB or F# or any other 
> language that is compatible with the .NET Runtime. So the language is only 
> the language in which it is written (which could also be intermixed). 
> Furthermore it is quite common to use something like NET e.g. log4j had an 
> equivalent of log4net.
> 
> Björn
> 
> -Ursprüngliche Nachricht-
> Von: Christofer Dutz  
> Gesendet: Freitag, 3. April 2020 15:43
> An: dev@plc4x.apache.org
> Betreff: [DISCUSS] Rename PLC4DOTNET to PLC4CSHARP?
> 
> Hi,
> 
> I just wanted to bring this to discussion … I have now encountered in 
> several projects that support different languages that the naming convention 
> we follow seems to match:
> 
> 
>   *   C : xyz_c
>   *   C++: xyz_cpp
>   *   Python: xyz_py
> 
> However when it comes to C# we sort of named it “plc4dotnet” … I would 
> propose to change it to “plc4csharp” as this is the language … “dotnet” is 
> sort of more the runtime.
> 
> What do you think?
> 
> Chris
> 
> 
> 
> 


Re: [DISCUSS] Make libpcap mandatory?

2020-04-06 Thread Julian Feinauer
Nice, then thats the way to go!

Am 06.04.20, 10:21 schrieb "Christofer Dutz" :

I've already got an annotation you can use:
@RequirePcap together with a Junit Condition, that skips the test if the 
condition is not met ... just noticed a bug in my condition however __ ... just 
fixing it.

Chris


Am 06.04.20, 10:11 schrieb "Julian Feinauer" :

Hey,

I would not choose 1, as you say.
Perhaps we can make this tests conditional (dont know how easy this is 
with junit5) an das you say, only allow releases with libpcap.

Julian

Am 06.04.20, 10:07 schrieb "Christofer Dutz" 
:

Hi,

I’m currently working on the prerequisiteCheck for my new plc4c 
module and am testing on empty OSes (OSes without any installed additional 
software)
I noticed there are tests like the Raw-Socket test that naturally 
fail if you don’t have libpcap (or the windows counterpart installed) …

We now have two options:

  1.  Make libpcap mandatory
  2.  Disable any test that is libpcap related

1) is the more secure version, but I think some people might have 
objections to installing libpcap on their systems.

How about automatically disabling these tests and to have a check 
in the prerequisiteChecks to not allow doing an “apache-release” without 
libpcap?

Got any other ideas?

Chris








Re: [DISCUSS] Make libpcap mandatory?

2020-04-06 Thread Christofer Dutz
I've already got an annotation you can use:
@RequirePcap together with a Junit Condition, that skips the test if the 
condition is not met ... just noticed a bug in my condition however __ ... just 
fixing it.

Chris


Am 06.04.20, 10:11 schrieb "Julian Feinauer" :

Hey,

I would not choose 1, as you say.
Perhaps we can make this tests conditional (dont know how easy this is with 
junit5) an das you say, only allow releases with libpcap.

Julian

Am 06.04.20, 10:07 schrieb "Christofer Dutz" :

Hi,

I’m currently working on the prerequisiteCheck for my new plc4c module 
and am testing on empty OSes (OSes without any installed additional software)
I noticed there are tests like the Raw-Socket test that naturally fail 
if you don’t have libpcap (or the windows counterpart installed) …

We now have two options:

  1.  Make libpcap mandatory
  2.  Disable any test that is libpcap related

1) is the more secure version, but I think some people might have 
objections to installing libpcap on their systems.

How about automatically disabling these tests and to have a check in 
the prerequisiteChecks to not allow doing an “apache-release” without libpcap?

Got any other ideas?

Chris






Re: [DISCUSS] Make libpcap mandatory?

2020-04-06 Thread Julian Feinauer
Hey,

I would not choose 1, as you say.
Perhaps we can make this tests conditional (dont know how easy this is with 
junit5) an das you say, only allow releases with libpcap.

Julian

Am 06.04.20, 10:07 schrieb "Christofer Dutz" :

Hi,

I’m currently working on the prerequisiteCheck for my new plc4c module and 
am testing on empty OSes (OSes without any installed additional software)
I noticed there are tests like the Raw-Socket test that naturally fail if 
you don’t have libpcap (or the windows counterpart installed) …

We now have two options:

  1.  Make libpcap mandatory
  2.  Disable any test that is libpcap related

1) is the more secure version, but I think some people might have 
objections to installing libpcap on their systems.

How about automatically disabling these tests and to have a check in the 
prerequisiteChecks to not allow doing an “apache-release” without libpcap?

Got any other ideas?

Chris




[DISCUSS] Make libpcap mandatory?

2020-04-06 Thread Christofer Dutz
Hi,

I’m currently working on the prerequisiteCheck for my new plc4c module and am 
testing on empty OSes (OSes without any installed additional software)
I noticed there are tests like the Raw-Socket test that naturally fail if you 
don’t have libpcap (or the windows counterpart installed) …

We now have two options:

  1.  Make libpcap mandatory
  2.  Disable any test that is libpcap related

1) is the more secure version, but I think some people might have objections to 
installing libpcap on their systems.

How about automatically disabling these tests and to have a check in the 
prerequisiteChecks to not allow doing an “apache-release” without libpcap?

Got any other ideas?

Chris