| Flexibility of framework and supplied types [message #1800675] |
Fri, 04 January 2019 18:39  |
Eclipse User |
|
|
|
Dear Eclipse SmartHome developers,
I made a small experiment with completely new type which does not exist in framework core. It worked fine until I implemented first proof of concept binding which used new kind of data.
It turned out that ESH does not like it and core fails to do its job:
Creation of ESH-Event failed, because one of the registered event factories has thrown an exception: Error getting class for simple name: 'XyzType' using package name 'org.eclipse.smarthome.core.library.types.'.
For sake of example lets assume that XyzType is a ComplexType which is not relevant for framework core and is useful in several situations and specific bindings. From my understanding after providing several-ish SPI interface implementations whole thing should go just seamlessly.
I created new kind of Item (XyzItem) and appropriate factory without troubles, but then none of state changes actually worked because of above coming from:
at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:183) ~[?:?]
at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseType(ItemEventFactory.java:158) ~[?:?]
at org.eclipse.smarthome.core.items.events.ItemEventFactory.getState(ItemEventFactory.java:136) ~[?:?]
at org.eclipse.smarthome.core.items.events.ItemEventFactory.createStateEvent(ItemEventFactory.java:116) ~[?:?]
at org.eclipse.smarthome.core.items.events.ItemEventFactory.createEventByType(ItemEventFactory.java:80) ~[?:?]
at org.eclipse.smarthome.core.events.AbstractEventFactory.createEvent(AbstractEventFactory.java:51) ~[?:?]
at org.eclipse.smarthome.core.internal.events.EventHandler.createESHEvent(EventHandler.java:121) ~[?:?]
at org.eclipse.smarthome.core.internal.events.EventHandler.handleEvent(EventHandler.java:95) ~[?:?]
at org.eclipse.smarthome.core.internal.events.EventHandler.handleEvent(EventHandler.java:72) ~[?:?]
at org.eclipse.smarthome.core.internal.events.ThreadedEventHandler.lambda$0(ThreadedEventHandler.java:67) ~[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.ClassNotFoundException: org.eclipse.smarthome.core.library.types.XyzType cannot be found by org.eclipse.smarthome.core_0.10.0
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:484) ~[?:?]
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395) ~[?:?]
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387) ~[?:?]
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
at java.lang.Class.forName0(Native Method) ~[?:?]
at java.lang.Class.forName(Class.java:264) ~[?:?]
at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:179) ~[?:?]
... 10 more
I found many places where org.eclipse.smarthome.core.types.TypeParser is used and breaks modularity principles. Each place where this type is used is locked down to only core types and will not accept any additional extension despite of theoretical possibility to supply new kinds of data.
There are many more places which keep strange logic, for example ItemsResource.postItemCommand:
if ("toggle".equalsIgnoreCase(value) && (item instanceof SwitchItem || item instanceof RollershutterItem)) {
if (OnOffType.ON.equals(item.getStateAs(OnOffType.class))) {
command = OnOffType.OFF;
}
if (OnOffType.OFF.equals(item.getStateAs(OnOffType.class))) {
command = OnOffType.ON;
}
if (UpDownType.UP.equals(item.getStateAs(UpDownType.class))) {
command = UpDownType.DOWN;
}
if (UpDownType.DOWN.equals(item.getStateAs(UpDownType.class))) {
command = UpDownType.UP;
}
} else {
command = TypeParser.parseCommand(item.getAcceptedCommandTypes(), value);
}
My major question is - are there any plans to tackle these bad smells? :-)
Cheers,
Lukasz
|
|
|
| Re: Flexibility of framework and supplied types [message #1801124 is a reply to message #1800675] |
Mon, 14 January 2019 05:02  |
| Eclipse User |
|
|
|
When the type system had been introduced 9 years ago, its originally idea was to be extensible.
But due to many different reasons, this never worked out and the type system since then became a static part of the core framework and is not meant to be extended.
As an alternative, String or Number items should be used in conjunction with state descriptions.
|
|
|
Powered by
FUDForum. Page generated in 0.06576 seconds
Home