Thanks, Lukasz! https://git1-us-west.apache.org/repos/asf?p=wicket.git;a=commit;h=36cb5824
@Daniel: Could you please take a look at the suggestion and comment whether it will work ? Or even better test it before 6.23.0 is out. Thanks! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Mar 16, 2016 at 5:54 PM, Łukasz Dywicki <[email protected]> wrote: > 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 > >>>> > >>>> > >> > >> > >
