Community
Participate
Working Groups
Build Identifier: 20100617-1415 When I try to run the "HelloWorld" test from package org.eclipse.e4.xwt.tests.style.css I get the following exception: Warning - could not initialize CSS styling : org.eclipse.e4.xwt.css.CSSEngineNotFoundException: java.lang.reflect.InvocationTargetException java.lang.NullPointerException at org.eclipse.e4.xwt.css.AbstractCSSStyle.applyStyle(AbstractCSSStyle.java:189) at org.eclipse.e4.xwt.javabean.ResourceLoader.applyStyles(ResourceLoader.java:889) at org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:587) at org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:463) at org.eclipse.e4.xwt.javabean.ResourceLoader.createCLRElement(ResourceLoader.java:365) at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:619) at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:676) at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:646) at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:842) at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:775) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:769) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:721) at org.eclipse.e4.xwt.XWT.open(XWT.java:416) The HelloWorld application starts but no style is applied at all. Reproducible: Always Steps to Reproduce: 1. Run HelloWorld.java from org.eclipse.e4.xwt.tests.style.css
Hi, I have studied the problem and it's not XWT-CSS problem. The problem comes from with CSS engine which can NOT be used into NO OSGi context. I notice that CSS engine was modified to be extensible by using Eclipse Extension Point : * org.eclipse.e4.ui.css.swt : register ICSSPropertyHandler with extension point. See CSSSWTEngineImpl#initializeCSSPropertyHandlers(); IExtensionRegistry registry = RegistryFactory.getRegistry() return null into NO OSGi context. * org.eclipse.e4.ui.css.core : register element provider. See CSSEngineImpl constructor. So the only way to configure CSS engine is done with Extension Point. It means that CSS engine can be used into OSGi context (can be used only with Equinox). I don't know the E4 strategy, but before this update (configure CSS engine with extension point), CSS engine was able to into NO OSGi context. Regards Angelo
We should simply add a NULL-Check to the CSS-Engine.
(In reply to comment #2) > We should simply add a NULL-Check to the CSS-Engine. Hi Tom, Yes it's the first step but after there are another problems like : * element provider is null * ICSSPropertyHandler is not registered. So none styles can be applied. Angelo
Well to ensure that we can deal with a none-OSGi-env we need a suite of tests to ensure this - I'm not sure yet how feasable it is though. Frankly our main target are OSGi-Envs and systems where an application made up from different plug-ins (bundles) but because we need to redesign certain parts in this respect anyways (e.g. the current handling of (image)-resources is completely wrong) we could take none-OSGi-Envs into account. Probably the best solution when we want to run in NONE-OSGi is to use Declarative-Services instead of extension points because it makes us free from OSGi-Dependencies.
Tom, Could you elaborate how Declarative Services can be used to solve this usecase? I have a similar requirement in another area (Sapphire), but I have thought that Declarative Services is still an OSGi-specific construct. The other thing to consider is the singleton requirement. Don't know about Declarative Services, but certainly for the extensions registry, the price of extensibility is that the bundle must be a singleton. This is not a big deal for bundles delivering end-user features, but can be a big limitation for frameworks. For instance, if you could concurrently support multiple versions of a framework in the same installation, then API management becomes much easier. Some clients can use a new version, others can use an older version and transition at their own schedule. OSGi has no problems with this scenario, but extensibility is difficult. That's because, none of the extension systems that I've seen allow the contributor to specify which version of the bundle the extension is for. Don't know if this is a relevant consideration for e4/xwt. So far, I have been thinking of going back to Java roots and relying on basic class loader tricks where you look for all resources at a specific path. In OSGi world, you would then use fragments to contribute extensions. Not exactly the "best practice" from OSGi perspective, but has the big advantage that your extension mechanism doesn't know anything about OSGi and only relies on basic Java facilities. My $0.02, in case it helps.
(In reply to comment #5) Hi Konstantin, > So far, I have been thinking of going back to Java roots and relying on basic > class loader tricks where you look for all resources at a specific path. In > OSGi world, you would then use fragments to contribute extensions. Not exactly > the "best practice" from OSGi perspective, but has the big advantage that your > extension mechanism doesn't know anything about OSGi and only relies on basic > Java facilities. > Thank a lot for this suggestion. I had the same idea than you about that. We could have even use the existing plugin.xml from org.eclipse.e4.ui.css.swt and develop our own parser to parse the extension-point.
(In reply to comment #5) > Tom, > > Could you elaborate how Declarative Services can be used to solve this usecase? > I have a similar requirement in another area (Sapphire), but I have thought > that Declarative Services is still an OSGi-specific construct. > Well to some extend yes but you get no compile time dependencies and in an plain old Java-Programm you can fake what equinox-ds does. > The other thing to consider is the singleton requirement. Don't know about > Declarative Services, but certainly for the extensions registry, the price of > extensibility is that the bundle must be a singleton. This is not a big deal Tom can correct me but I think DS does NOT have this limitation. > for bundles delivering end-user features, but can be a big limitation for > frameworks. For instance, if you could concurrently support multiple versions > of a framework in the same installation, then API management becomes much > easier. Some clients can use a new version, others can use an older version and > transition at their own schedule. OSGi has no problems with this scenario, but > extensibility is difficult. That's because, none of the extension systems that > I've seen allow the contributor to specify which version of the bundle the > extension is for. Don't know if this is a relevant consideration for e4/xwt. > > So far, I have been thinking of going back to Java roots and relying on basic > class loader tricks where you look for all resources at a specific path. In > OSGi world, you would then use fragments to contribute extensions. Not exactly > the "best practice" from OSGi perspective, but has the big advantage that your > extension mechanism doesn't know anything about OSGi and only relies on basic > Java facilities. You can have the best of both worlds. I'll attach an example in the next few minutes. > > My $0.02, in case it helps.
Created attachment 176203 [details] Example how to use DS-Information in OSGi and Plain-Java-Programs I've hacked this together in the last hour or so - so don't blame me for bad code, not treating of corner cases, ... . Attached you'll find a set of PDE-Projects (I use them even for standard java-programs as well) who demonstrate the useage of DS in general and how one can even use this information to build a extension system in Plain Old Java Programms (don't know why people still don't simply use OSGi but anyways). It also uses Eclipse 4.0 DI (when running in OSGi-Context) and Guice when running as a plain Java programm.
