Hi Julian, yes, you're right of course. The second approach I described is really just creating metatype information.
Please note that with R7 you can put the @Activate annotation on a field which has a component property type; in many cases no need for an activate method anymore Regards Carsten Julian Sedding wrote > Hi Carsten > > IIRC the second way you describe did not work for me. I was rather > surprised when I first encountered it. But reading the spec seemed to > confirm my understanding. > > According to my understanding and experiments, your first bullet is > required to get default values of type annotations into the DS > descriptor. Your second bullet gets everything into the MetaType > descriptor. > > Of course once you got a configuration for your DS component, you can > still read it's properties, even if the defaults are not in the DS > descriptor. > > Regards > Julian > > > > On Fri, May 18, 2018 at 2:57 PM, Carsten Ziegeler <[email protected]> > wrote: >> I haven't followed everything in this thread, but there are basically >> two ways: >> >> - use a component property type (annotation) in the activate method and >> annotate it with @Activate >> >> - generate metatype information to describe the component property type >> so you use the ObjectClassDefinition annotation on the type and >> AttributeDefinition annotation on the properties and then link it to the >> component using the @Designate annotation. >> >> One of those two ways is sufficient, however if you do the second option >> you must likely do the first as well. >> >> But in any case you need to specify this to the tooling in some way. >> >> Regards >> >> Carsten >> >> >> Daniel Klco wrote >>> Thanks for the clarification Julian and the tool is great! I wish I had >>> known about it when I was manually diffing the configuration values for >>> Auth Form. >>> >>> On Fri, May 18, 2018 at 4:48 AM, Julian Sedding <[email protected]> wrote: >>> >>>> I think the chain of events is slightly different than what Jason >>>> wrote, but the end result is the same. >>>> >>>> Properties from configuration annotations are only included in the XML >>>> if the configuration annotation is used in the signature of the >>>> activate/deactivate methods (maybe modified as well, possibly others). >>>> >>>> Now, in this case, the activate method was not recognized and thus the >>>> config annotation was not referenced from any of the lifecycle method >>>> signature. Ergo: no properties in the XML. >>>> >>>> Regards >>>> Julian >>>> >>>> >>>> PS: I wrote a small commandline tool that helps diffing bundles before >>>> and after the annotation refactoring (or any other changes done to >>>> DS/MetaType). It's far from perfect, but already helped me avoid some >>>> bugs. PRs welcome of course! >>>> https://github.com/jsedding/osgi-ds-metatype-diff >>>> >>>> >>>> On Fri, May 18, 2018 at 4:56 AM, Daniel Klco <[email protected]> wrote: >>>>> That was the problem, thanks Jason! 10 internet points and a meme to you >>>>> for being awesome! >>>>> >>>>> https://imgflip.com/i/2aicpi >>>>> >>>>> Thanks, >>>>> Dan >>>>> >>>>> On Thu, May 17, 2018 at 5:40 PM, Jason E Bailey <[email protected]> wrote: >>>>> >>>>>> So this is odd, I built the project and checked out the >>>>>> FormAuthenticationHandler.xml that was built in the OSGI-INF directory >>>> and >>>>>> it only defined a deactivate method. >>>>>> >>>>>> I added the @Activate annotation and it added the definition that stated >>>>>> the activate method was 'activate' and it also added all the property >>>>>> defaults. >>>>>> >>>>>> I'm suspecting that the plugin is looking for the activate declaration >>>> and >>>>>> if it isn't there it's not defining the properties, even through the >>>> OSGi >>>>>> container is properly identifying the activate method. >>>>>> >>>>>> - Jason >>>>>> >>>>>> On Thu, May 17, 2018, at 4:18 PM, Daniel Klco wrote: >>>>>>> Good thought, unfortunately the same result. >>>>>>> >>>>>>> On Thu, May 17, 2018 at 12:40 PM, Jason E Bailey <[email protected]> >>>> wrote: >>>>>>> >>>>>>>> Your using constants in the default value, have you tried replacing >>>>>> those >>>>>>>> with literals? I believe, as a compile time annotation, the >>>> constants >>>>>>>> aren't initialized. >>>>>>>> >>>>>>>> - Jason >>>>>>>> >>>>>>>> On Thu, May 17, 2018, at 1:43 PM, Daniel Klco wrote: >>>>>>>>> Team, >>>>>>>>> >>>>>>>>> I've been trying to figure this out and can't seem to crack it so >>>> I >>>>>> was >>>>>>>>> hoping someone might have some insight. >>>>>>>>> >>>>>>>>> I'm trying to update Sling Auth Forms to OSGi R6 as per: >>>>>>>>> https://issues.apache.org/jira/browse/SLING-7671 >>>>>>>>> >>>>>>>>> I've got everything converted over and it works if I specify a >>>>>>>>> configuration. However, with the Apache Felix SCR annotations this >>>>>>>> service >>>>>>>>> registered immediately with a configuration with the default >>>> values, >>>>>> so >>>>>>>>> there's clearly some difference I'm missing. I've tried changing >>>>>>>> everything >>>>>>>>> I can think of to get the default values from the configuration >>>> to be >>>>>>>>> registered when the component is starts, but every time I get >>>>>> something >>>>>>>>> like this: >>>>>>>>> >>>>>>>>> 17.05.2018 10:22:47.084 *INFO* [Background Update >>>>>>>>> org.apache.sling.auth.form (84)] org.apache.sling.auth.form >>>> Service >>>>>>>>> [org.apache.sling.auth.form.FormAuthenticationHandler,1169, >>>>>>>>> [org.apache.sling.auth.core.spi.AuthenticationHandler]] >>>> ServiceEvent >>>>>>>>> REGISTERED >>>>>>>>> 17.05.2018 10:22:47.085 *DEBUG* [Background Update >>>>>>>>> org.apache.sling.auth.form (84)] >>>>>>>>> org.apache.sling.auth.form.impl.FormAuthenticationHandler >>>> Activating >>>>>>>> with >>>>>>>>> configuration >>>>>>>>> org.apache.sling.auth.form.impl.FormAuthenticationHandlerConfig : >>>>>>>>> {jaas_realmName=null, form_onexpire_login=false, jaas_ranking=0, >>>>>>>>> jaas_controlFlag=null, form_auth_storage=null, useInclude=false, >>>>>>>>> annotationType=null, form_credentials_name=null, >>>>>> form_token_file=null, >>>>>>>>> service_ranking=0, path=[Ljava.lang.String;@5b1b6745, >>>>>>>> form_login_form=null, >>>>>>>>> form_token_fastseed=false, hashCode=0, equals=false, >>>> toString=null, >>>>>>>>> form_auth_name=null, form_auth_timeout=0, >>>>>> form_default_cookie_domain=nul >>>>>>>> l} >>>>>>>>> and properties {} >>>>>>>>> 17.05.2018 10:22:47.085 *ERROR* [Background Update >>>>>>>>> org.apache.sling.auth.form (84)] org.apache.sling.auth.form bundle >>>>>>>>> org.apache.sling.auth.form:1.0.9.SNAPSHOT >>>>>>>>> (84)[org.apache.sling.auth.form.FormAuthenticationHandler(316)] : >>>>>> The >>>>>>>>> activate method has thrown an exception (java.lang. >>>>>> NullPointerException) >>>>>>>>> >>>>>>>>> It seems like this should work based on other examples I've seen >>>>>> online, >>>>>>>>> specifically: >>>>>>>>> >>>>>>>>> https://github.com/nateyolles/aem-osgi-annotation-demo >>>>>>>>> >>>>>>>>> So far I have tried: >>>>>>>>> >>>>>>>>> - Specifying the configuration pid >>>>>>>>> - Trying annotation defaultvalue vs method default >>>>>>>>> - Changing the start level of the bundle >>>>>>>>> - Changing to a single activate parameter >>>>>>>>> - Trying required / optional configuration binding >>>>>>>>> >>>>>>>>> The only thing that did work was specifying a configuration node >>>> in >>>>>> the >>>>>>>>> bundle content configuration, but this seems hacky. >>>>>>>>> >>>>>>>>> I've checked the code in to Auth Form: >>>>>>>>> https://github.com/apache/sling-org-apache-sling-auth-form >>>>>>>>> >>>>>>>>> If anyone could take a few minutes to review or has any thoughts / >>>>>> ideas >>>>>>>> / >>>>>>>>> suggestions I'd really appreciate it as I'm at a roadblock. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dan >>>>>>>> >>>>>> >>>> >>> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] -- Carsten Ziegeler Adobe Research Switzerland [email protected]
