Martin, I think it will work, but to be extra safe I would pass application class loader to service loader call. In case of OSGi webapp lifecycle may be affected if it’s not packaged as a WAR but installed as JAR registering servlet. In case of bundle/jar deployment activation/bootstrap of module will start with context of mechanism starting it. For example it can be aries or spring startup handler which parses configuration before application is reached by Jetty/Tomcat. This is quite opposite to typical webapp start where container already assembled classpath and configuration is started inside a WAR by filter or lifecycle listener.
Cheers, Łukasz — Apache Karaf Committer & PMC Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org > Wiadomość napisana przez Martin Grigorov <[email protected]> w dniu 16 mar > 2016, o godz. 17:38: > > Hi Lukasz, > > Thanks for helping! > > The ServiceLoader impl is in DefaultClassResolver which is used *by > default*, i.e. in normal servlet containers. > In OSGi environments the application developer could provide > OsgiClassResolver that will use OSGi APIs to find the impls of a class > (IInitializer in this case). Would that work ? > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Mar 16, 2016 at 5:24 PM, Łukasz Dywicki <[email protected]> wrote: > >> 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 >>>> >>>> >> >>
