Eclipse Community Forums: Eclipse SmartHome » Flexibility of framework and supplied types

Help

Home

Home » Archived » Eclipse SmartHome » Flexibility of framework and supplied types

Show: Today's Messages :: Show Polls :: Message Navigator

Flexibility of framework and supplied types [message #1800675]

Fri, 04 January 2019 23:39

Lukasz Dywicki

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

Report message to a moderator

Re: Flexibility of framework and supplied types [message #1801124 is a reply to message #1800675]

Mon, 14 January 2019 10:02

Kai Kreuzer

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.

Report message to a moderator

Previous Topic:	Swipe functionality for Dimmer/volume controls
Next Topic:	Swipe functionality for Dimmer/volume controls

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 03:42:31 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter