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