I detected, that a split package is located in the ozone layer jar.
com.vaadin.terminal.gwt.server.DontPushWebBrowser
Since OSGi can not handle such issues, i am getting an error:
java.lang.IllegalAccessError: tried to access method com.vaadin.terminal.gwt.server.WebBrowser.updateClientSideDetails(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Z)V from class com.vaadin.terminal.gwt.server.DontPushWebBrowser
at com.vaadin.terminal.gwt.server.DontPushWebBrowser.updateClientSideDetails(DontPushWebBrowser.java:42) ~[na:na]
at org.vaadin.dontpush.server.BroadcasterVaadinSocket.updateBrowserProperties(BroadcasterVaadinSocket.java:183) ~[na:na]
It would be really kind if you could change the package of DontPushWebBrowser.class. But the drawback is, that WebBrowser#updateClientSideDetails is package protected.
How can we solve that problem?
As a workaround i changed the visibility in my local workspace.
As you guessed it is due to the package private methods why I put that class in such an odd package. The correct fix would be to fix Vaadin itself. In the mean time maybe there could be some reflect magic as a workaround? If you can come up with a workaround I’m happy to commit your patch.
there is no workaround availble. The only way to handle that isue in a valueable time is to change the visibility of the methods.
I tried to change the DontPushWebBrowser that way to implement Terminal directly, but the Webapp context and the servlet have strong deps to the WebBrowser instead of the Terminal.
What do you think, is there a way to change the visibilty of the package protected method in the near future? Or do you think this will not be done for 6.7 and 6.8?
I could do it right away, but then again we’d lose compatibility with bit older release. Quite small issue from my point of view with this kind of cutting edge technology, but…
One more workaround that came to my mind: we we could “copy paste” extend the class? All relevant API methods are non-final, so we could have own updateClientSider… methods and fields that contain actual fields. Not very forward compatible, but we can return to use the default implementation once we can expect all users have upgraded to version that has protected (instead of package private) update methods. What do you think?