Hi, 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.
Regards, Thomas On 5/7/12 11:43 AM, "Jukka Zitting" <[email protected]> wrote: >Hi, > >On Mon, May 7, 2012 at 9:02 AM, Thomas Mueller <[email protected]> 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
