Hi Daniel,
On Tue, Feb 23, 2016 at 2:24 PM, Daniel Stoch <[email protected]> wrote: > Hi Martin, > > I have checked IInitializer initializations in previous Wicket > versions (6.21.0 and lower) and it seems that there also not > everything works under OSGi. > The resources containing initializers are searched in > initializeComponents() using: > > getApplicationSettings().getClassResolver().getResources("wicket.properties") > > For our apps org.apache.wicket.extensions.Initializer is not always > returned by this call, because the default implementation > AbstractClassResolver.getResources() in some cases does not return it. > This have never been problem because we are not using > UploadProgressBar component, which is initialized in this Initializer > and we do not using any other IInitializers. > But the main org.apache.wicket.Initializer is always found because it > resides in the same bundle (jar) where Application.class is. > > So my conclusion is that even in previous Wicket versions IInitializer > logic may fail under OSGi. > 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). > > For 6.22.0 to initialize main org.apache.wicket.Initializer and avoid > logging errors, I have changed Application.initInitializers() call to: > final ServiceLoader<IInitializer> serviceLoaderInitializers = > ServiceLoader.load(IInitializer.class, > IInitializer.class.getClassLoader()); > and it works, because it does not use TCCL (Thread Context Class Loader). > > But this is an only fast hack which works ok in our apps because we do > not use other IInitializers but may fail in other apps. > I'll try to think about a better solution. > > > PS. If someone is interested there is a good article about Java TCCL, > which was introduced by Sun as a hack for another problems (among > others: lack of modularity in Java) and leads to such problems as > current one: > http://njbartlett.name/2012/10/23/dreaded-thread-context-classloader.html > > -- > Daniel > > > On Mon, Feb 22, 2016 at 2:07 PM, Martin Grigorov <[email protected]> > wrote: > > Hi Daniel, > > > > Damn! > > Before making this change someone with OSGi expertize asserted that > > ServiceLoader is working in OSGi. > > We even had a discussion before making this change here at dev@. > > > > At the moment OSGi looks like the Portlet support in Wicket 1.4 - no one > > from the developers uses the technology and it is hard (impossible) for > us > > to support it. > > It should be possible to make this pluggable. I guess it was not made > this > > way because this is core functionality that would break Wicket if custom > > implementation make something wrong. > > But I see no other way than make it pluggable and let OSGi users like you > > deal with the differences in OSGi environment. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Mon, Feb 22, 2016 at 12:50 PM, Daniel Stoch <[email protected]> > > wrote: > > > >> Hi, > >> > >> I have just upgraded our project form 6.21.0 to 6.22.0. It seems that > >> changes from WICKET-6030 generates such errors during application > >> start: > >> > >> Exception in bottom level event dispatcher: > >> org.apache.wicket.IInitializer: Provider > >> org.apache.wicket.extensions.Initializer not found > >> java.util.ServiceConfigurationError: org.apache.wicket.IInitializer: > >> Provider org.apache.wicket.extensions.Initializer not found > >> at java.util.ServiceLoader.fail(ServiceLoader.java:239) > >> at java.util.ServiceLoader.access$300(ServiceLoader.java:185) > >> at > >> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:372) > >> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > >> at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > >> at > org.apache.wicket.Application.initInitializers(Application.java:620) > >> at > >> org.apache.wicket.Application.initializeComponents(Application.java:525) > >> at > org.apache.wicket.Application.initApplication(Application.java:829) > >> at > >> org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:427) > >> at > >> > org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:271) > >> > >> > >> The problem was introduced by usage of: > >> ServiceLoader.load(IInitializer.class) and it is better described > >> here: > >> http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html > >> > >> > http://coderthoughts.blogspot.com/2011/08/javautilserviceloader-in-osgi.html > >> > >> In modular and dynamic environments such static service loading is > >> always problematic. For now I am investigating how to fix this in our > >> project and maybe in Wicket core too. Maybe you also will have some > >> ideas (eg. allow to define a custom IInitializer loading mechanism and > >> then use a OSGi service registry)? > >> > >> -- > >> Best regards, > >> Daniel Stoch > >> >
