[
https://issues.apache.org/jira/browse/CLEREZZA-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013897#comment-13013897
]
Daniel Spicar commented on CLEREZZA-460:
----------------------------------------
I investigated the problem of duplicated renderlet registration today. The
problem does not lie in the fact of duplicates primarily. The major problem is
that the number of registered renderlets can grow very fast when
bundles/services are started stopped (a refresh in the OSGi framework may call
the activate methods of many other bundles).
I am not sure which rendering specification is chosen when duplicates exist.
But this may also be problematic.
When implementing TypeRenderlets there the OSGi framework takes care of service
registration and unregistration properly. The problem appears when either the
RenderletManagerImpl or the ScalaServerPageService register Renderlets (upon
request from another bundle). Then the Renderlets are registered using the
bundleContext of the RenderletManagerImpl/ScalaServerPageService, and thus they
are not unregistered when the bundle that called the
registerScalaServerPage/registerRenderlet method disappears The corresponding
Renderlets would only be unregistered when the
typerendering.core/typerendering.scalaserpages bundle disappears.
One way of solving this is to check all registered renderlets to prevent
duplication (semantics, add if no equal renderlet exists (what exactly is
equal?), update with new specification when an equal renderlet exists.). But I
think this defeats the purpose of changing to the whiteboard pattern, at least
for Renderlets registered through the named services.
Another approach is to register the renderlets using the bundlecontext of the
bundle that called registerrRenderlet/registerScalaServerPage. I did not test
it but I expect that then the registered renderlets are unregistered when their
bundle disappears. I think this requires a change of the Interface to get that
bundlecontext. This interface change is not very sensible for the deprecated,
old style RenderletManager. Also this will not really prevent duplicates, but
will make sure that each Renderlet registered in a bundle will be unregistered
when that bundle disappears. However another bundle may register the exact same
renderlet again, then duplicates would exist. But this seems to be less of a
problem than uncontrolled growth of registered renderlets that may occur
currently.
Anyway. For now I suggest a quick fix in RenderletManagerImpl that checks all
already registered renderlets before registering new renderlets.
> Use whiteboard pattern for Renderlets
> -------------------------------------
>
> Key: CLEREZZA-460
> URL: https://issues.apache.org/jira/browse/CLEREZZA-460
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Attachments: patch-typerendering-core.diff
>
>
> The current mechanism for renderlets is overly complex. Instead of describing
> renderlets in a graph rendelets should be services that have properties
> indicating the rdf type and the mode-pattern they handle.
> The priority for selecting renderlets should be:
> - type, according to type-priority list
> - length of regex math (the matching regex with the most alphanumeric
> characters wins)
> - startlevel of the bundle providing the service
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
