Jackrabbit Oak
  1. Jackrabbit Oak
  2. OAK-17

Modularisation and configuration concept

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.19
    • Component/s: core, jcr
    • Labels:
      None

      Description

      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

        Issue Links

          Activity

          Show
          Michael Dürig added a comment - See also http://markmail.org/message/e6bna3v7xbgfutjf
          Hide
          Michael Dürig added a comment -

          An excerpt from the discussion at [1]. See also OAK-87.

          Instead of saying that we support "OSGi" and "non-OSGi" deployments, I'd like 
          to set the baseline to "plain Java". It should be possible to construct any Oak
          configuration with nothing but normal constructors, setters and (where needed) 
          simple lifecycle methods like init()/close(). No interpretation of XML files or
          evencustom "configuration URLs" should be needed for such a setup.
          
          As long as that's possible, it'll be easy to support any kinds of more advanced
          deployment and configuration mechanisms, be they OSGi or not. 
          

          [1] http://markmail.org/message/2n4bbbehwl66m5b7

          Show
          Michael Dürig added a comment - An excerpt from the discussion at [1] . See also OAK-87 . Instead of saying that we support "OSGi" and "non-OSGi" deployments, I'd like to set the baseline to "plain Java". It should be possible to construct any Oak configuration with nothing but normal constructors, setters and (where needed) simple lifecycle methods like init()/close(). No interpretation of XML files or evencustom "configuration URLs" should be needed for such a setup. As long as that's possible, it'll be easy to support any kinds of more advanced deployment and configuration mechanisms, be they OSGi or not. [1] http://markmail.org/message/2n4bbbehwl66m5b7
          Hide
          Michael Marth added a comment -

          Given Chetan Mehrotra's work I think we can close or defer this. Tobias Bocanegra, wdyt?

          Show
          Michael Marth added a comment - Given Chetan Mehrotra 's work I think we can close or defer this. Tobias Bocanegra , wdyt?
          Hide
          Michael Dürig added a comment -

          Chetan Mehrotra, for completeness sake, could you add a link to your work here?

          Show
          Michael Dürig added a comment - Chetan Mehrotra , for completeness sake, could you add a link to your work here?
          Hide
          Tobias Bocanegra added a comment -

          assigning to chetan so he can close it. thanks.

          Show
          Tobias Bocanegra added a comment - assigning to chetan so he can close it. thanks.
          Hide
          Chetan Mehrotra added a comment -

          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.

          Show
          Chetan Mehrotra added a comment - 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.
          Hide
          Alex Parvulescu added a comment -

          Bulk close for the 0.19 release.

          Show
          Alex Parvulescu added a comment - Bulk close for the 0.19 release.

            People

            • Assignee:
              Chetan Mehrotra
              Reporter:
              Michael Dürig
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development