Fix sensorsystem issues #267
Conversation
… into fix-sensorsystem
…n/osh-core into fix-sensorsystem" This reverts commit 5d74f38, reversing changes made to aa5d581.
sensorhub-core/src/main/java/org/sensorhub/impl/sensor/SensorSystem.java
Show resolved
Hide resolved
| @@ -100,8 +100,7 @@ protected void doFinishRegister(ISystemDriver driver) throws DataStoreException | |||
| { | |||
| for (var member: ((ISystemGroupDriver<?>)driver).getMembers().values()) | |||
| { | |||
| if (!(member instanceof IModule<?>)) // don't register submodules as they'll register themselves | |||
| doRegisterMember(member, driver.getCurrentDescription().getValidTime()); | |||
| doRegisterMember(member, driver.getCurrentDescription().getValidTime()); | |||
There was a problem hiding this comment.
I don't think you need to change this here.
If the system members are themselves modules they should register themselves when they are started.
Was this not working?
I'm thinking there might be an issue when the UID of a member does not match the wildcard of the database that handles the parent. In that case the subsystems might end up in a different database than the parent and that's not good. Did you run into this?
There was a problem hiding this comment.
I removed that line because you would have to restart all submodules before they are registered to the database. So it is a similar fix to registering the top level modules that were started before the database is created.
Also, members cannot be in a different database than the parent, but I did see this issue where you can register a wildcard to one database, and then register a member of the wildcard to another database, and no error is thrown. This appears to have already been an issue.
In the image, I have a database that takes "...system:systems1:*" and then I am allowed to add a different database with "...system:systems1:system2"
I could create an issue for this or if you have advice on how to handle this I could include it in the PR.
Changed from <module name, module> to <module id, module> because problems occurred when modules had default name
This fixes 2 main issues and amends a minor issue:
Configuration of submodules will not save
CONFIG_CHANGEDmodule event, it will update the config with the new subsystem config.Submodules do not show up when OSH starts
Minor Changes for System driver database
withNoParent()systems to enforce parent system managing subsystemsdoRegisterMember()checks if submodule already has a handler and updates it if so