adamcin commented on PR #31: URL: https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/31#issuecomment-1758809026
> 2. but it think it's very important that this new way of defining OSGi configurations also works together with the current approach of OSGi mock using registerInjectActivateService & co. so it should be possible to define a configuration using the new annotations, and than creating the osgi component instance using registerInjectActivateService without explicitly passing the config data as argument. looking at the unit tests i think this is possible, but only if using the @UpdateConfig annotation, not the @ApplyConfig annotation, and not using the config annotation class itself as annotation? would be good to flesh this out in detail in the documentation/examples. The effects of `@UpdateConfig` are fully reflected in the service component created by `registerInjectActivateService`. Injected config parameters (reflected annotations and values constructed from `@ConfigType` ~~`@ApplyConfig`~~ annotations) don't currently have a way to be fed to `registerInjectActivateService`, but I think it can be done. > 3. what i do not like about the current registerInjectActivateService approach and passing in configuration data is that you have to remember the actual configuration property names and duplicate them as strings in the testing code. that's ugly as there is nice typed annotation class at hand. i would really love to combine registerInjectActivateService with the annotation approach of using the OSGi config annotation directly as annotation of the test class (but without having to inject the configuration than manually!). I think this can also be done elegantly if I add an `@AutoConfig` annotation that just takes a `Class<?> value()` for inferring a component pid. When it is present, any other annotations that are valid component property types are converted to maps and merged into a single dictionary to update the config for the component pid before each test execution. > i'm not so fond of having to place and explicit @Retention(RetentionPolicy.RUNTIME) to the annotation class, though - changing the production code only for unit test purposes is always a red flag for me. I had to convince myself to get over the same kind of resistance to it. But it is an unavoidable necessity if we want to use the config types as annotations, unless we want to get into the business of rewriting bytecode. I haven't been able to come up with any reason why using runtime retention for config annotations would be unsafe or insecure, or have any other kind of observable effect on the code that actually goes to production. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
