[
https://issues.apache.org/jira/browse/OAK-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14581939#comment-14581939
]
Francesco Mari commented on OAK-2909:
-------------------------------------
[~mduerig], individual issues are easy to fix, and they could provide immediate
benefits to the users. On the other hand, I'm thinking about some broader
solution, in increasing order of impact on the codebase:
- Split the building process in two steps. First, a {{Whiteboard}} instance is
built. Second, the repository is built by reading every dependency from the
{{Whiteboard}}. Pros, it doesn't need a lot of refactoring in production code.
Cons, we rely on an abstraction that only approximates the real needs of the
OSGi execution environment - dynamism, components, lifecycle, and so on.
- Get rid of the {{Whiteboard}}. Production code should explicitly define its
dependencies instead of fetching them from a {{Whiteboard}}. Create an OSGi
layer on top of it that can be evolved independently from production code. Make
sure that production is flexible enough to fulfill the needs of the execution
environent(s) where Oak is supposed to run. Pros, clean separation between
production code and runtime-related code. Cons, trasversal refactoring of the
whole project.
- Write OSGi-ready production code. Production code is written with OSGi in
mind. In case of a standalone deployment (like in {{oak-run}}), an embedded
OSGi framework can be started and initialized. This may also pave the way for a
future modularization effort, where multiple bundles may be created from higly
coupled moodules (like {{oak-core}}). Pros, code optimized for the environment
where Oak actually runs more often. Cons, trasversal refactoring of the whole
project, with optional creation of multiple bundles.
In summary, I will quickly fix individual issues. I will additionally work on a
broader, long-term solution.
> Review and improve Oak and Jcr repository setup
> -----------------------------------------------
>
> Key: OAK-2909
> URL: https://issues.apache.org/jira/browse/OAK-2909
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
> Reporter: Michael Dürig
> Labels: modularization, technical_debt
> Fix For: 1.3.1
>
>
> There is the {{Oak}} and {{Jcr}} builder classes for setting up Oak and Jcr
> repositories. Both builders don't have clear semantics regarding the life
> cycle of the individual components they register. On top of that the
> requirements regarding those life cycles differ depending on whether the
> individual components run within an OSGi container or not. In the former case
> the container would already manage the life cycle so the builder should not.
> IMO we should specify the builders to only be used for non OSGi deployments
> and have the manage the life cycles of the components they instantiate. OTOH
> for OSGi deployments we should leverage OSGi subsystems to properly set
> things up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
