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

Reply via email to