Martin, As far I know it will not help, cause of classloader visibility. ServiceLoader call without given context will use TCCL which could be everything but app classloader during initialization. Making service loader working properly under OSGi requires some extra steps (ie. via aries-spi-fly or geronimo-osgi-locator/registry).
Long time ago I’ve written an improved osgi integration for wicket which is much simpler than pax-wicket. It is something between wicket stuff and pax: https://github.com/Code-House/wicket-osgi <https://github.com/Code-House/wicket-osgi> It is based on initializers. :-) Best regards, Lukasz — [email protected] Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org > Wiadomość napisana przez Martin Grigorov <[email protected]> w dniu 14 mar > 2016, o godz. 22:51: > > Hi, > > With [1] I've made a change in Wicket to use IClassResolver to find all > IInitializer impls. > Could this help for friendlier OSGi usage ? > Is it OK to find all impls by interface class in OSGi environment ? > > The only problem is that you have to register OsgiClassResolver in > MyApplication#internalInit(), not in #init(). > > 1. > https://git1-us-west.apache.org/repos/asf?p=wicket.git;a=commit;h=39f897aa > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, Feb 29, 2016 at 7:35 PM, Łukasz Dywicki <[email protected]> wrote: > >> FYI there is pax-wicket project which is intended to support OSGi based >> deployments for Wicket. >> >> Cheers, >> Lukasz >> — >> [email protected] >> Twitter: ldywicki >> Blog: http://dywicki.pl >> Code-House - http://code-house.org >> >>> Wiadomość napisana przez Daniel Stoch <[email protected]> w dniu >> 23 lut 2016, o godz. 15:01: >>> >>> On Tue, Feb 23, 2016 at 2:33 PM, Martin Grigorov <[email protected]> >> wrote: >>> >>>> >>>> Please check >>>> >> https://github.com/wicketstuff/core/blob/master/wicket-osgi-parent/wicket-osgi/src/main/java/org/wicketstuff/osgi/OsgiClassResolver.java >>>> (or its wicket-6.x version). >>> >>> But I think this implementation is incorrect and it can work only >>> under special conditions. It assumes that class of my application has >>> access to all classes: so bundle should contains: >>> DynamicImport-Package: *. >>> But even when I add such line to MANIFEST.MF with my application >>> bundle, the situation is the same like using my own implementation of >>> IClassResolver: some IInitializers are not found at all. >>> >>> So even with OsgiClassResolver it does not work as it is designed. >>> >>> -- >>> Daniel >> >>
