On 19/03/14 12:25, Bertrand Delacretaz wrote:
Hi,
On Tue, Mar 18, 2014 at 10:22 PM, Neil Bartlett <[email protected]> wrote:
...Whatever you're trying to do in your special listener, wouldn't it be
better done inside the same bundle as the service?...
You're right, and this is similar to what Bruce suggests - the
bundle's initialization code can look for initializer services using a
whiteboard pattern, and call them before making the actual service
available.
To answer Marcel's question about the use case, the app in question is
Sling-based and uses a content repository service. When upgrading the
app you might need to make some changes to the content before the new
version of the app starts working with the content repository. So yes,
I would suggest to detect such a need in the activator, start a
background job to do it (keep the activator short-lived) and only
publishing the service once the content modifications are complete.
You might even want to proxy your content repo to shield its
implementation from upgrade concerns.
making this part of the content repository service design makes
absolute sense.
David B's hooks suggestion also looks interesting, as a generic way of
talking to services early in the setup phase.
Thanks everybody for the pointers!
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
