Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse SmartHome » Flexibility of framework and supplied types
Flexibility of framework and supplied types [message #1800675] Fri, 04 January 2019 23:39 Go to next message
Lukasz Dywicki is currently offline Lukasz DywickiFriend
Messages: 34
Registered: July 2009
Member
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 10:02 Go to previous message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
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.
Previous Topic:Swipe functionality for Dimmer/volume controls
Next Topic:Swipe functionality for Dimmer/volume controls
Goto Forum:
  


Current Time: Fri Feb 28 06:48:15 GMT 2020

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

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

Back to the top