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]

Reply via email to