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
> > > > >> > > > >>>>>>
> > > > >> > > > >>>>
> > > > >> > > > >>>
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
