jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Plain Java as deployment/configuration platform (Was: [jira] [Created] (OAK-87) Declarative services and OSGi configuration)
Date Mon, 07 May 2012 10:29:58 GMT

OK, I think I understand. Yes, it should be possible to use that approach,
even thought I would prefer if most JCR applications don't actually
hardcode the storage *classes* within the source code of the application,
because this would complicate using a different JCR implementation. You
would have to re-compile the application just because you want to use a
different storage backend. As an example, the JDBC API doesn't require an
application to hardcode any implementation specific classes (the database
driver *classes*) within the application. Instead, the driver is loaded
using the service loader, and the database URL is used to open the
connection. The database URL is a string, and typically not hardcoded in
the application. I like the database URL mechanism, because it's a simple
and flexible solution.


On 5/7/12 11:43 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>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
>Jukka Zitting

View raw message