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 <l...@code-house.org> 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<PlcDriver> reg;
> >
> > @Override
> > public void start( BundleContext context ) throws Exception {
> > Hashtable<String, String> 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 <nic...@hedhman.org> 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
<l...@code-house.org>
> >> 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 driver does not have to have a XML
> >>>> descriptor which registers service. Quite many third parties
might be
> >>>> supplying drivers without any or with limited knowledge of OSGi.
> >>>> Do drivers have to be a service? Well, it they can still be a
valid
> >> OSGi
> >>>> service, registered using any other way! OSGi aware driver
manager
> uses
> >>>> OSGi services instead of static list own classloader to find
> >>>> META-INF/services entries:
> >>>>
> >>>>
> >>
>
https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> >>>>
> >>>> JDBC JARs are handled in such a way already in pax-jdbc. Take a
look
> >> here:
> >>>>
> >>>>
> >>
>
https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> >>>> Same or very similar code can be found in apache-camel, which
brought
> >>>> hundreds of components to OSGi, so I believe their way can be
seen as
> >>>> high level guide.
> >>>> What Etienne did is a pattern implementation.
> >>>>
> >>>> With regard to capabilities/requirements - this is a resolver
puzzle.
> >> It
> >>>> relies on additional information. As an unbaptized,
non-religious osgi
> >>>> guy (I take it as a tool and not act of faith), I often do skip
it. I
> >> do
> >>>> find it useful, however quite often problematic and hard to
understand
> >>>> (yet another non-trivial syntax in manifest to follow). On older
> >>>> runtimes capabilities are not even considered. For never ones
there
> are
> >>>> already existing namespaces:
> >>>> https://www.osgi.org/capability-namespaces-reference/
> >>>> including, one for services:
> >>>>
> >>
>
https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> >>>> My point is that capabilities are used to attest that runtime
will
> >>>> consist all necessary things in place after provisioning
operation. It
> >>>> does not say HOW given capabilities should be made, cause
resolver is
> >>>> hit before bundle gets active. It is a safety check. I'm fine
with
> >>>> having one, however we need to make it right to do not narrow
use of
> >>>> driver bundles only with our own extender.
> >>>>
> >>>> Beside the point, I am not sure if plc4x-api is a best place for
osgi
> >>>> specific logic. That is a standard dilema to address in how we
want to
> >>>> treat osgi and non-osgi users. :-)
> >>>>
> >>>> Cheers!
> >>>> Łukasz
> >>>>
> >>>> On 05.05.2020 12:34, Julian Feinauer wrote:
> >>>>> 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 ("plc4x-protocol": "s7") or
something.
> >>>>>
> >>>>> I did it witht he driver maanger mostly fort he ease as first
> >> approach.
> >>>>>
> >>>>> Julian
> >>>>>
> >>>>> Am 05.05.20, 12:30 schrieb "Niclas Hedhman"
<nic...@hedhman.org>:
> >>>>>
> >>>>> 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 <
> >> nic...@hedhman.org>
> >>>> 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 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 declare the
service
> >>>> itself?
> >>>>> >>
> >>>>> >> Le mar. 5 mai 2020 à 05:25, Niclas Hedhman <
> >> nic...@hedhman.org>
> >>>> a écrit :
> >>>>> >>
> >>>>> >> > 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
> >>>> Driver/Transport.
> >>>>> >> And
> >>>>> >> > I assume you do so to limit code in the
drivers/transports.
> >>>>> >> >
> >>>>> >> > Another way would be to make two generic
BundleActivator in
> >>>> this bundle
> >>>>> >> and
> >>>>> >> > have each driver/transport just declare them in the
> >> manifest.
> >>>> That
> >>>>> >> would be
> >>>>> >> > a bit more conventional.
> >>>>> >> >
> >>>>> >> > // Niclas
> >>>>> >> >
> >>>>> >> > On Tue, May 5, 2020 at 11:06 AM Robinet, Etienne <
> >>>> 43...@etu.he2b.be>
> >>>>> >> > wrote:
> >>>>> >> >
> >>>>> >> > > 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 on
> >>>>> >> > the
> >>>>> >> > > code:
> >>>>> >> > >
> >>>>> >> > > API Activator:
> >>>>> >> > >
> >>>>> >> > >
> >>>>> >> >
> >>>>> >>
> >>>>
> >>
>
https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java
> >>>>> >> > > SPI Activator:
> >>>>> >> > >
> >>>>> >> > >
> >>>>> >> >
> >>>>> >>
> >>>>
> >>
>
https://github.com/apache/plc4x/blob/feature/osgi/plc4j/spi/src/main/java/org/apache/plc4x/java/osgi/SpiActivator.java
> >>>>> >> > >
> >>>>> >> > > If everything is alright, I could merge this today.
> >>>>> >> > >
> >>>>> >> > > Etienne
> >>>>> >> > >
> >>>>> >> > > Le mar. 7 avr. 2020 à 17:52, Christofer Dutz <
> >>>>> >> christofer.d...@c-ware.de>
> >>>>> >> > a
> >>>>> >> > > écrit :
> >>>>> >> > >
> >>>>> >> > > > 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
> >>>> change, I
> >>>>> >> > moved
> >>>>> >> > > > these classes to the test-transport module
> >>>>> >> > > > and extended NettyChannelFactory with a
createBootstrap
> >>>> method
> >>>>> >> which is
> >>>>> >> > > > simply overridden in TestTransport.
> >>>>> >> > > >
> >>>>> >> > > > So please give everything a try if it now works as
> >> planned.
> >>>>> >> > > >
> >>>>> >> > > > Chris
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > > > Am 07.04.20, 17:36 schrieb "Etienne Robinet" <
> >>>> 43...@etu.he2b.be>:
> >>>>> >> > > >
> >>>>> >> > > > 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 <
> >>>> l...@code-house.org>
> >>>>> >> a
> >>>>> >> > > > écrit :
> >>>>> >> > > > >
> >>>>> >> > > > > 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:
> >>>>> >> > > > >> 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 again because
this
> >> class
> >>>> is not
> >>>>> >> > > exported
> >>>>> >> > > > (I think?) by the SPI, but is used by one of the
> >> dependency
> >>>>> >> (io.netty).
> >>>>> >> > > > >> Any ideas on how to solve this?
> >>>>> >> > > > >>
> >>>>> >> > > > >> Etienne
> >>>>> >> > > > >>
> >>>>> >> > > > >>> On 2020/04/07 06:53:54, Etienne Robinet <
> >>>>> >> erobi...@apache.org>
> >>>>> >> > > > wrote:
> >>>>> >> > > > >>> 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 <
> >>>> l...@code-house.org
> >>>>> >> >
> >>>>> >> > > > wrote:
> >>>>> >> > > > >>>> 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
> >>>>> >> > > > >>>>>>
> >>>>> >> > > > >>>>
> >>>>> >> > > > >>>
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > > >
> >>>>> >> > >
> >>>>> >> >
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>
> >>>
> >>
> >
>
