plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject [EU-FOSSA 2 2019 Hackathon] Improved OSGi and Apache Karaf integration
Date Mon, 06 May 2019 15:20:00 GMT
Dear all,
I had pleasure to meet PLC4X representatives in past weekend (4-5 May
2019) thanks to EU FOSSA 2 event. Thanks to time given to work on
Karaf-PLC4X integration I reached a point where I will be able to submit
first contribution to your project. In below mail I will briefly
describe what been done (from technical perspective) and what are
questions which needs to be answered in order to finalize OSGi support.

Things which I found during FOSSA was that:
- Generated feature sets were failing, modbus and ethernet-ip been
problematic due to some weird slf4j dance.
- `PlcDriverManager` does not work under OSGi out of the box.

I solved first one by turning feature sets in manually maintained file
which gives a complete control over how features are structured, what
are common parts and so on. Second issue with driver manager requires a
moment to introduce you to a case.
I turned every single `PlcDriver` into OSGi service. Trick is fairly
simple - each and every bundle which gets started is checked for
presence of `PlcDriver` META-INF/services entries. Any driver found
there will be registered as OSGi service:
https://github.com/ConnectorIO/plc4x/blob/eufossa/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/Activator.java#L70

When connection attempt is made a special kind of driver manager which
is OSGi aware look up for matching service:
https://github.com/ConnectorIO/plc4x/blob/eufossa/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62

For ease of use I decided to register `OsgiDriverManager` as OSGi
service:
https://github.com/ConnectorIO/plc4x/blob/eufossa/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/Activator.java#L49
This means that as soon as plc4x-api is installed within OSGi framework
a matching service will be present waiting for other bundles which would
like to obtain connections. However, a general recommendation for OSGi
support is to defined interface which is used by service implementer and
later used by service consumer. Currently *PlcDriverManager* is a class
so I had to declare a `DriverManager` interface which I used only for
OSGi related testing.
I believe what such separation would be helpful for project and all AOP
related frameworks which could be used with typical Spring/Java EE
setups. I know these days mocking frameworks are quite powerful and do
not require interface, yet such separation adds additional boundary to
project APIs/SPIs.

Are you up for:
1) Declaring new interface to represent `PlcDriverManager` functionality?
2) Renaming existing `PlcDriverManager` to `BasicPlcDriverManager`?
3) Moving `BasicDriverManager` to new module `plc4x/plc4j/core`?
4) Creation of plc4j/osgi module where OSGi integration will be kept?

Steps 2 and 3 will turn plc4j/api into interface only module, meaning a
proper API bundle. :-) I am aware that it will have impact on existing
java code thus would like to hear what is your opinion.

Kind regards,
Łukasz
--
http://connectorio.com

Mime
View raw message