-
-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modified finder discovery schema to make future finders easier to create #3924
Conversation
Signed-off-by: Mark Herwege <[email protected]>
Signed-off-by: Mark Herwege <[email protected]>
@andrewfg @J-N-K @kaikreuzer Could you please have a look at this? |
Signed-off-by: Mark Herwege <[email protected]>
Signed-off-by: Mark Herwege <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally it looks good.
But I think the string "mdnsServiceType" should be a constant.
Also I have not actually tested yet on a full build.
@@ -148,6 +149,12 @@ && propertyMatches(matchProperties, APPLICATION, service.getApplication()) | |||
return result; | |||
} | |||
|
|||
private String getMdnsServiceType(AddonDiscoveryMethod method) { | |||
String param = method.getParameters().stream().filter(p -> "mdnsServiceType".equals(p.getName())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"mdnsServiceType" should be a constant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -103,12 +104,12 @@ private void setupAddonInfos() { | |||
AddonDiscoveryMethod hp = new AddonDiscoveryMethod().setServiceType(AddonFinderConstants.SERVICE_TYPE_MDNS) | |||
.setMatchProperties( | |||
List.of(new AddonMatchProperty("rp", ".*"), new AddonMatchProperty("ty", "hp (.*)"))) | |||
.setMdnsServiceType("_printer._tcp.local."); | |||
.setParameters(List.of(new AddonParameter("mdnsServiceType", "_printer._tcp.local."))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
addonInfos.add(AddonInfo.builder("hpprinter", "binding").withName("HP").withDescription("HP Printer") | ||
.withDiscoveryMethods(List.of(hp)).build()); | ||
|
||
AddonDiscoveryMethod hue = new AddonDiscoveryMethod().setServiceType(AddonFinderConstants.SERVICE_TYPE_MDNS) | ||
.setMdnsServiceType("_hue._tcp.local."); | ||
.setParameters(List.of(new AddonParameter("mdnsServiceType", "_hue._tcp.local."))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -125,13 +126,13 @@ private void setupMockAddonInfoProvider() { | |||
AddonDiscoveryMethod hp = new AddonDiscoveryMethod().setServiceType(AddonFinderConstants.SERVICE_TYPE_MDNS) | |||
.setMatchProperties( | |||
List.of(new AddonMatchProperty("rp", ".*"), new AddonMatchProperty("ty", "hp (.*)"))) | |||
.setMdnsServiceType("_printer._tcp.local."); | |||
.setParameters(List.of(new AddonParameter("mdnsServiceType", "_printer._tcp.local."))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, but with local constant. Otherwise an import of MDNSAddonFinder is required. This would create a circular import.
|
||
AddonDiscoveryMethod hue1 = new AddonDiscoveryMethod().setServiceType(AddonFinderConstants.SERVICE_TYPE_UPNP) | ||
.setMatchProperties(List.of(new AddonMatchProperty("modelName", "Philips hue bridge"))); | ||
|
||
AddonDiscoveryMethod hue2 = new AddonDiscoveryMethod().setServiceType(AddonFinderConstants.SERVICE_TYPE_MDNS) | ||
.setMdnsServiceType("_hue._tcp.local."); | ||
.setParameters(List.of(new AddonParameter("mdnsServiceType", "_hue._tcp.local."))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, but with local constant. Otherwise an import of MDNSAddonFinder is required. This would create a circular import.
assertEquals(1, parameters.size()); | ||
AddonParameter parameter = parameters.get(0); | ||
assertNotNull(parameter); | ||
assertEquals("mdnsServiceType", parameter.getName()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"mdnsServiceType" should be a constant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left as is, as this would also require a local constant and the exact name of the parameter is not relevant for the test.
@@ -67,7 +60,7 @@ private AddonInfoProvider createAddonInfoProvider0() { | |||
|
|||
private AddonInfoProvider createAddonInfoProvider1() { | |||
AddonDiscoveryMethod discoveryMethod = new AddonDiscoveryMethod().setServiceType("mdns") | |||
.setMdnsServiceType("_hue._tcp.local."); | |||
.setParameters(List.of(new AddonParameter("mdnsServiceType", "_hue._tcp.local."))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"mdnsServiceType" should be a constant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left as is, as this would also require a local constant and the exact name of the parameter is not relevant for the test.
Signed-off-by: Mark Herwege <[email protected]>
Signed-off-by: Mark Herwege <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I have just one question: would it make sense to also have a more generic expression than |
@J-N-K what is your use case? what do you mean? |
I have nothing special in mind. I was just wondering if some new service could use something different than a regex (e.g. glob-like matching) and |
IMHO a regex would cover all potential use cases. |
Regex is self explaining. Calling it pattern will require external documentation and I don’t see anything that cannot be covered by a regex. So I vote for keeping it as is. |
I tested this locally with a full build (including this PR and the add-on PR). I receive the same add-on suggestions as before, so this is working as expected. |
Signed-off-by: Holger Friedrich <[email protected]>
Signed-off-by: Holger Friedrich <[email protected]>
Signed-off-by: Kai Kreuzer <[email protected]>
FTR: xsd has been updated on the website with openhab/website@f3d354d. |
Signed-off-by: Holger Friedrich <[email protected]>
Signed-off-by: Holger Friedrich <[email protected]>
In the add-on schema, we currently have a special field for mDNS discovery:
mdns-service-type
.As noted in #3920, new add-on finders may also require special parameters. Rather than extending the schema each time, this PR changes the schema to include a parameter section and adapts the mDNS finder to read the
mdnsServiceType
from a parameter.While not strictly necessary to make this change for the 4.1 release, it would be good to do it now to avoid future changes in the schema.
The proposed schema section then becomes:
A follow-up PR will be created to change the addon.xml files in the addons repository.
This PR is code complete but requires a full build for testing.
EDIT: Full build done and tested. All is still behaving as expected. Tests run through fine.