Having multiple *.items configuration files results in duplicate item binding processing.

[GoogleCodeExporter]

When multiple *.items configuration files exist, the items from the first file 
which is processed are reprocessed when the second file is processed.  The 
items for both the first and second file are reprocessed when a third file is 
processed, and so on..
This behaviour has been noticed in version 1.1.

Below you can see sample log output from a set up with 3 item configuration 
files, each containing a single item.

00:35:09.818 DEBUG o.o.b.d.i.DmxGenericBindingProvider[:106] - Binding item: 
item_in_file_3
00:35:09.820 INFO  o.o.m.c.i.f.FolderObserver[:163] - Loaded file 
'item_file_3.items'
00:35:09.822 DEBUG o.o.b.d.i.DmxGenericBindingProvider[:106] - Binding item: 
item_in_file_3
00:35:09.823 DEBUG o.o.b.d.i.DmxGenericBindingProvider[:106] - Binding item: 
item_in_file_2
00:35:09.825 INFO  o.o.m.c.i.f.FolderObserver[:163] - Loaded file 
'item_file_2.items'
00:35:09.830 DEBUG o.o.b.d.i.DmxGenericBindingProvider[:106] - Binding item: 
item_in_file_3
00:35:09.832 DEBUG o.o.b.d.i.DmxGenericBindingProvider[:106] - Binding item: 
item_in_file_2
00:35:09.833 DEBUG o.o.b.d.i.DmxGenericBindingProvider[:106] - Binding item: 
item_in_file_1
00:35:09.836 INFO  o.o.m.c.i.f.FolderObserver[:163] - Loaded file 
'item_file_1.items'

In the above example, the item from file 3 is incorrectly processed 3 times. 
The item from file 2 is incorrectly processed twice.

Original issue reported on code.google.com by davy.van...@gmail.com on 24 Dec 2012 at 11:52

[GoogleCodeExporter]

This is not a bug, but a design issue (meaning, it cannot be easily changed 
;-)).

The problem is that the granularity of "changes" is on "ItemProvider" level, 
not on file level. The "GenericItemProvider" is one of these providers, namely 
the one that reads its information from the *.items files. If something changes 
there (and the files are discovered one by one at startup and not all at once), 
the GenericItemProvider informs its listeners about a change in its provided 
item list - so all of them are revisited.

I agree that this behavior is not really nice, but as long as users do not 
create too many items files, this should not be too costly. We could think 
about a refactoring of the GenericItemProvider in future to do more finegraned 
"itemAdded"/"itemRemoved" instead of "allItemsChanged" events, so I leave this 
issue open for future improvements. For the time being, I do not see a high 
prio to deal with it.

Original comment by kai.openhab on 26 Dec 2012 at 9:35

• Changed state: Accepted
• Added labels: Version-later

[GoogleCodeExporter]

Since the workaround is really easy (just use one file), a low priority seems 
appropriate. I just ran into the issue and it seemed important enough to flag 
so that it is documented somewhere and the next developer who is new to openHab 
doesn't need to wonder so long on why his code is not working as expected ;-)

Original comment by davy.van...@gmail.com on 26 Dec 2012 at 9:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by teichsta on 12 Jul 2013 at 2:05

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Issue moved to https://bugs.eclipse.org/bugs/show_bug.cgi?id=423465

Original comment by kai.openhab on 6 Dec 2013 at 5:58

• Changed state: Invalid