Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » e(fx)clipse » "unknown protocol: dyndata" after upgrade to 3.1.0
"unknown protocol: dyndata" after upgrade to 3.1.0 [message #1778279] Tue, 12 December 2017 15:29 Go to next message
Selim Dincer is currently offline Selim DincerFriend
Messages: 13
Registered: November 2017
Junior Member
Hey,

We have a product that was running on efxclipse v2.3.0. I recently updated the target platform to 3.1.0 since I believe a version later than 3.0.0 is required for proper java 9 support(?).
We were using the URLDynamicDataStreamHandler to load stylesheets. After upgrading to 3.1.0 I get following exception for the URL
dyndata:bundleresource://65.fwk1206883981:1/css/customization-stylesheet.css?efx_DynamicDataHandlerId=efx_DynamicDataHandlerId&theme=theme.dark&colorCategory=bla.bla.app


java.lang.IllegalStateException: Failed to create URL 'dyndata:bundleresource://65.fwk1206883981:1/css/customization-stylesheet.css?efx_DynamicDataHandlerId=efx_DynamicDataHandlerId&theme=theme.light&colorCategory=bla.bla.app'
	at org.eclipse.fx.core.URLDynamicDataStreamHandler.createDynamicDataStreamURL(URLDynamicDataStreamHandler.java:91)

...

Caused by: java.net.MalformedURLException: unknown protocol: dyndata
	at java.net.URL.<init>(Unknown Source)
	at java.net.URL.<init>(Unknown Source)
	at java.net.URL.<init>(Unknown Source)
	at org.eclipse.fx.core.URLDynamicDataStreamHandler.createDynamicDataStreamURL(URLDynamicDataStreamHandler.java:89)


Unfortunately I couldn't find any documentation on this feature anywhere. How can I register the proper handler for the dyndata protocol?
Thanks!

Selim
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1778302 is a reply to message #1778279] Tue, 12 December 2017 21:31 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Are you running on Java9 or Java8?
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1778338 is a reply to message #1778302] Wed, 13 December 2017 09:36 Go to previous messageGo to next message
Selim Dincer is currently offline Selim DincerFriend
Messages: 13
Registered: November 2017
Junior Member
It's still running on 8u151. I wanted to get it working there before starting with 9.
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1778874 is a reply to message #1778338] Fri, 22 December 2017 18:51 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
I guess you need to debug a bit:
* Put a break-point into DynamicDataStreamHandler#getProtocol() is it called?
* When is it a called? Who calls it?

The registration should happen in "DefaultThemeManager"s constructor. Is the DefaultThemeManager instantiated?

Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1778973 is a reply to message #1778874] Wed, 27 December 2017 09:51 Go to previous messageGo to next message
Selim Dincer is currently offline Selim DincerFriend
Messages: 13
Registered: November 2017
Junior Member
Hey Thomas,

as you said the DefaultThemeManager calls DynamicDataStreamHandler#getProtocol() but the exception is logged before, so maybe something with the order of the registration was changed.
I will try to investigate further.

Thanks!
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1779063 is a reply to message #1778973] Sun, 31 December 2017 20:04 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Well in 3.1 the upstream platform adopted felix-scr as the DS implementation - so yes there might be changes! I'm not really happy how the registration is done today - we should find a better way anyways in 4.0 or even 3.x
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1779150 is a reply to message #1779063] Wed, 03 January 2018 09:17 Go to previous messageGo to next message
Selim Dincer is currently offline Selim DincerFriend
Messages: 13
Registered: November 2017
Junior Member
Hey Thomas,

indeed with a target platform of v3.0.0 the issue is resolved... Maybe we'll stick with this for now.

Thanks
Selim
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1779165 is a reply to message #1779150] Wed, 03 January 2018 12:05 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
3.0.0 does not fully support Java9 and we should definately find out why the URL is used before the theme-mangager has been started the URL you show indicates you load some CSS
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1779177 is a reply to message #1779165] Wed, 03 January 2018 15:43 Go to previous messageGo to next message
Selim Dincer is currently offline Selim DincerFriend
Messages: 13
Registered: November 2017
Junior Member
Hey,

From the release notes it looks like only this FXCanvas is not supported? Is there anything else that is known to not work?

Is there a way to request an instance of DefaultThemeManager before the Themes are being created? I don't know who requests the creation of the themes but my idea would be to just request an instance of DefaultThemeManager before?
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1779198 is a reply to message #1779177] Wed, 03 January 2018 18:24 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
The important Java9 changes are in the platform/equinox parts we inherit from upstream projects!
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1780297 is a reply to message #1779198] Fri, 19 January 2018 16:41 Go to previous messageGo to next message
Selim Dincer is currently offline Selim DincerFriend
Messages: 13
Registered: November 2017
Junior Member
Hey,
the framework is apparently trying to load our theme class (which uses the dynamic data stream feature) before the DefaultThemeManager is constructed. Is this a bug maybe (since it worked pre 3.1.0)?

Our theme looks like this:
import bli.bla.blubb.BrandingTheme;
import org.eclipse.fx.ui.services.theme.Theme;

@Component(service = { Theme.class, BrandingTheme.class })
public class DarkTheme extends AbstractTheme implements BrandingTheme {


and the components xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="bli.bla.blubb.DarkTheme">
   <service>
      <provide interface="org.eclipse.fx.ui.services.theme.Theme"/>
      <provide interface="bli.bla.blubb..BrandingTheme"/>
   </service>
   <reference bind="registerMultiURLStylesheet" cardinality="0..n" interface="org.eclipse.fx.ui.services.theme.MultiURLStylesheet" name="registerMultiURLStylesheet" policy="dynamic" unbind="unregisterMultiURLStylesheet"/>
   <reference bind="registerStylesheet" cardinality="0..n" interface="org.eclipse.fx.ui.services.theme.Stylesheet" name="registerStylesheet" policy="dynamic" unbind="unregisterStylesheet"/>
   <implementation class="bli.bla.blubb.DarkTheme"/>
</scr:component>


"JavaFX Application Thread@2342" prio=5 tid=0x1d nid=NA runnable
  java.lang.Thread.State: RUNNABLE
                  at org.eclipse.fx.ui.theme.internal.DefaultThemeManager.<init>(DefaultThemeManager.java:58)
                  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
                  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
                  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
                  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
                  at java.lang.Class.newInstance(Class.java:442)
                  at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:237)
                  at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109)
                  at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906)
                  at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879)
                  at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823)
                  at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)
                  at java.security.AccessController.doPrivileged(AccessController.java:-1)
                  at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)
                  at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)
                  at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)
                  at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508)
                  - locked <0xf8d> (a org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse)
                  at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)
                  at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624)
                  at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.lookup(EclipseContextOSGi.java:85)
                  at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.containsKey(EclipseContextOSGi.java:61)
                  at org.eclipse.e4.core.internal.contexts.EclipseContext.containsKey(EclipseContext.java:154)
                  at org.eclipse.e4.core.internal.contexts.EclipseContext.containsKey(EclipseContext.java:145)
                  at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:69)
                  at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:111)
                  at org.eclipse.e4.core.internal.contexts.EclipseContext.runAndTrack(EclipseContext.java:337)
                  at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier.get(ContextObjectSupplier.java:170)
                  at org.eclipse.e4.core.internal.di.InjectorImpl.resolveArgs(InjectorImpl.java:529)
                  at org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:457)
                  at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:113)
                  at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:399)
                  at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:318)
                  at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
                  at org.eclipse.fx.ui.workbench.fx.E4Application.preLifecycle(E4Application.java:260)
                  at org.eclipse.fx.ui.workbench.base.AbstractE4Application.createE4Workbench(AbstractE4Application.java:226)
                  at org.eclipse.fx.ui.workbench.fx.E4Application.initE4Workbench(E4Application.java:358)
                  at org.eclipse.fx.ui.workbench.fx.E4Application$1.run(E4Application.java:215)
                  at org.eclipse.fx.ui.workbench.fx.E4Application.jfxStart(E4Application.java:253)
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1780322 is a reply to message #1780297] Sat, 20 January 2018 01:00 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hm can you show the Full stacktrace from the first post as well because i don't understand why the URL content gets accessed
Re: "unknown protocol: dyndata" after upgrade to 3.1.0 [message #1782795 is a reply to message #1778279] Thu, 01 March 2018 14:29 Go to previous message
Selim Dincer is currently offline Selim DincerFriend
Messages: 13
Registered: November 2017
Junior Member
I was able to work around the issue by adding following code to the constructor of our themes:

synchronized (workAroundComplete) {
	// we don't need to do this twice
	if (workAroundComplete.compareAndSet(false, true)) {
		// register handlers for custom protocols (especially "dyndata")
		for (URLStreamHandler handler : ServiceUtils.getServiceList(URLStreamHandler.class)) {
			Hashtable<String, Object> t = new Hashtable<>();
			t.put(URLConstants.URL_HANDLER_PROTOCOL, new String[] { handler.getProtocol() });
			BundleContext bundleContext = FrameworkUtil.getBundle(getClass()).getBundleContext();
			bundleContext.registerService("org.osgi.service.url.URLStreamHandlerService",
					new DelegatingURLStreamHandlerService(handler), t);
		}
	}
}


This is essentially what the DefaultThemeManager is doing, except I am making sure it is done before my themes provide their dynamic urls.
Previous Topic:DnDAddon with CleanUpAddon Destroying Part Stacks
Next Topic:rcp 4 with javafx application ,how to use SystemMenuBar on macOS
Goto Forum:
  


Current Time: Wed Dec 04 16:42:02 GMT 2024

Powered by FUDForum. Page generated in 0.05026 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top