jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Plain Java as deployment/configuration platform (Was: [jira] [Created] (OAK-87) Declarative services and OSGi configuration)
Date Mon, 07 May 2012 09:43:09 GMT
Hi,

On Mon, May 7, 2012 at 9:02 AM, Thomas Mueller <mueller@adobe.com> wrote:
> I guess you wanted to write "non-OSGi" instead of "plain Java"?

Essentially yes, but there's a subtle point here. Let me explain.

A specific "non-OSGi" setup could be something like repository.xml
-based configuration mechanism we have in Jackrabbit 2.x. Even though
it's possible deploy Jackrabbit 2.x in OSGi, J2EE and other kinds of
environments, the wiring and configuration of internal components is
only really possible through the repository.xml file. This leads to
inflexibility and workarounds like we've seen in JCR-1412 [1].

So 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 even custom
"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.

Apache Tika is a good example of such a design in action. Out of the
box Tika supports OSGi deployments, the Java SPI mechanism, and custom
"tika-config.xml" configuration files. And people have wired Tika in
to all kinds of other configurations. None of this is really necessary
for using Tika, as you can just as well simply construct a collection
of Tika components and wire them together plain Java code.

PS. Note that this only covers one aspect of a component model. The
other one is to design component interfaces in a way that makes them
easy to compose and allows dynamic deployment environments like OSGi
to add or remove components at runtime.

[1] https://issues.apache.org/jira/browse/JCR-1412

BR,

Jukka Zitting

Mime
View raw message