[
https://issues.apache.org/jira/browse/OAK-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16380079#comment-16380079
]
Francesco Mari commented on OAK-6770:
-------------------------------------
The work is in progress in [this branch on
GitHub|https://github.com/francescomari/jackrabbit-oak/tree/OAK-6770]. The
patch is currently functional, but there are some loose ends.
Because of how the names of the methods of the annotations are mapped to the
attribute names (see 105.15.2 from the OSGi Compendium), it is not possible to
expose {{"primary.allowed-client-ip-ranges"}}. This attribute has been exposed
as {{"primary.allowed.client.ip.ranges"}}. This issue can be solved by
configuration. Moreover, it is possible to add additional logic in
{{StandbyStoreService}} to detect if the old property has been set. In this
case, the code will use the values from the old property and print a warning
message.
The property {{customSegmentStore}}, used in both {{SegmentNodeStoreService}}
and {{SegmentNodeStoreFactory}}, was not exposed via Metatype when the
unpatched code was deployed, but it is exposed now. This might be a bug
somewhere, I'm currently unable to explain this behaviour.
The patch currently changes the minimum amount of code to get rid of the old
annotations and to use the new standard OSGi ones. This means that the code
that actually reads the configuration data still uses the {{ComponentContext}}
to manually access the attributes. This approach has the benefit of being
minimally disruptive, but maintains the verbosity of the old approach.
I'm positive that the verbosity of the old approach can't be completely
removed. {{SegmentNodeStoreService}} and its helper {{Configuration}} have
quite some custom code to read the configuration data. For example, every
configuration property is looked up using
{{OsgiUtil#lookupConfigurationThenFramework}}, giving the possibility to
provide default values in the framework properties for every proeprty in the
component configuration. Moreover, for the cache sizes, we rely on default
values read from the system properties. This logic is easily implemented if the
property names are available in {{SegmentNodeStoreService}}, so it is not
possible use the Metatype annotation as the only way to access the
configuration.
As a side note, the problem outlined in the previoius paragraph implies that
{{SegmentNodeStoreService}} needs to maintain a definition of the property
names twice, in the {{SegmentNodeStoreService}} as string, and in
{{SegmentNodeStoreServiceConfiguration}} as method names. A change in one set
of property names has to be reflected in the other, keeping in mind the name
mapping rules mentioned above.
Moreover, I couldn't find a simple way to automatically test the effect of my
changes. I had to semi-automatically validate the Metatype resource and, for
good measure, perform manual testing on a real deployment scenario.
I don't see the advantage of switching to the new annotations. The logic in
{{SegmentNodeStoreService}} has been written to rely on property names being
available. The new approach to Metatype hides this information from the code,
and makes the implementation more convoluted. What is the *real* advantage of
this migration? I see the value of the new annotations in simpler components.
Can the new and old annotation live alongside each other?
> Convert oak-segment-tar to OSGi R6 annotations
> ----------------------------------------------
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
> Reporter: Robert Munteanu
> Assignee: Francesco Mari
> Priority: Minor
> Labels: osgi
> Fix For: 1.9.0, 1.10
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
