Konrad Windszus wrote > With the commit https://fisheye6.atlassian.com/changelog/sling?cs=1767036 > ResourceResolver was migrated from SCR to OSGi component/metatype > annotations. This looks really nice and clean except for the ID of the > attribute entry is always(!) generated from the annotated method name, which > leads to weird method names like resource_resolver_searchpath() (which is > converted to id resource.resolver.searchpath, according to > https://osgi.org/javadoc/r6/enterprise/org/osgi/service/metatype/annotations/AttributeDefinition.html). > Is there really no way to decouple the generated ID from the method name? I > would have expected that it is possible to override the id by some attribute > on the annotation @AttributeDefinition. > Would it be worth to consider that for the next update to metatype spec?
There are two things to consider here, first of all the property name is resource.resolver.searchpath, so this is the value that needs to go into metatype info and into the component xml. To avoid any additional mapping (aka an additional attribute on the annotation), there is the mapping rule on how to map a property name to the method name in the component property type, which is then replacing the dots with underscore. While this might look ugly, I don't see any real problem with that - we're taking about configurations and they don't have to win any beauty price. Now, if you want to have a nice method name, this would require to change two specs, metatype and declarative services and you would need to specify this mapping twice, once for metatype and once for the component properties. I think so far everyone was happy with this approach. If you think its worth considering this please open a bug for that on the OSGi bugzilla instance. We can then look into this and decide on what to do Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
