You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2014/03/18 17:16:43 UTC

[jira] [Resolved] (OAK-17) Modularisation and configuration concept

     [ https://issues.apache.org/jira/browse/OAK-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chetan Mehrotra resolved OAK-17.
--------------------------------

    Resolution: Fixed

So far Oak fullfills the requirement as captured in excerpt above and Oak can be configured programatically.

The support for pojo-sr is being tracked in OAK-1522 which should enable OSGi support outside of OSGi container.  



> Modularisation and configuration concept
> ----------------------------------------
>
>                 Key: OAK-17
>                 URL: https://issues.apache.org/jira/browse/OAK-17
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: core, jcr
>            Reporter: Michael Dürig
>            Assignee: Chetan Mehrotra
>             Fix For: 0.19
>
>
> We need to come up with a concept for modularisation and configuration. There is some initial discussion on the list [1]. While we need to make sure that we are interoperable with OSGi, I don't think we should use OSGi itself for the lower granular pieces. That is, for certain subsystems of oak-jcr or oak-core for example. Still we need a way for handling dependencies between and configuration of implementation classes. In the case of oak-jcr there is the GlobalContext class. This is basically poor man's dependency injection and I'd like to get rid of it as soon as we have a better solution. What I'd like to have on that level is compile time dependency injection such that we get loose coupling between implementation classes but don't get the additional complexity from run time dependency injection (aka OSGi).
> [1] http://markmail.org/thread/hpssa4r6brlt5cwa



--
This message was sent by Atlassian JIRA
(v6.2#6252)