[
https://issues.apache.org/jira/browse/OAK-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269488#comment-13269488
]
Michael Dürig commented on OAK-17:
----------------------------------
An excerpt from the discussion at [1]. See also OAK-87.
{noformat}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.
{noformat}
[1] http://markmail.org/message/2n4bbbehwl66m5b7
> 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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
