jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Plain Java as deployment/configuration platform (Was: [jira] [Created] (OAK-87) Declarative services and OSGi configuration)
Date Mon, 07 May 2012 11:55:55 GMT

On 7.5.12 12:31, Jukka Zitting wrote:
> Hi,
> On Mon, May 7, 2012 at 12:29 PM, Thomas Mueller<mueller@adobe.com>  wrote:
>> 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.
> Agreed. Each application should use the appropriate mechanisms for
> their deployment platform. An OSGi app should use service references,
> a J2EE app JNDI lookups or dependency injection, etc.
> What I'm trying to achieve is for us to be easily able to support all
> such deployments without trying to force everything to go through a
> single mechanism like the repository.xml in Jackrabbit 2.x. That's my
> biggest concern over the MicroKernelFactory class and the reason why
> I've been trying to reverse the dependency between the MKF and the
> various implementation classes. It's fine to have a utility class like
> the MKF that interprets custom "repository URLs", but having things
> like the log wrapper depend on the MKF essentially hardwires that
> single configuration mechanism to the implementation.

I like that approach very much. I think it is much more flexible than 
having a single mechanism in place which forces things "our way". To 
that end I removed the GlobalContext hack in revision 1334962 which 
served as kind of a reminder to sort these things out.

AFAICS we currently support plain constructor calls and OSGi for setting 
things up. What about also adding support for JSR 330? I think this 
could be done similarly to how OSGi support is being done by putting the 
wiring code into separate package.


>> 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.
> Note that in JDBC the DataSource interface was explicitly introduced
> for "the advantage of making the application code independent of a
> particular JDBC driver and JDBC technology URL." [1]
> Nowadays few JDBC applications acquire their database connections
> directly using DriverManager.getConnection() and a database URL.
> Instead they get a DataSource reference trough JNDI or some other
> deployment-specific mechanism (typically dependency injection) and use
> that to acquire connections.
> Configuring and managing such DataSources is a deployment concern that
> things like J2EE containers have evolved to deal with in quite a bit
> of detail without JDBC client applications having to worry about any
> of that. It's of course also possible for an application to use
> DriverManager.getConnection() or even directly instantiate a
> particular Driver class, but then you lose all the extra flexibility
> and functionality provided by the deployment container.
> To summarize, I think our default component model should look more
> like DataSource than DriverManager in JDBC.
> [1] http://docs.oracle.com/javase/1.3/docs/guide/jdbc/spec2/jdbc2.1.frame3.html
> BR,
> Jukka Zitting

View raw message