jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: MicroKernel.getInstance
Date Wed, 11 Apr 2012 08:58:42 GMT
Hi,

I agree, the constructor based solution is not a good one since it not only makes acquisition
harder. It also makes testing harder (in my experience).

Maybe we have to turn this around altogether: Instead of thinking "get it", we should think
"receive it". Aka Inversion of Control, aka Dependency Injecttion.

This would make this even easier (and stabler: (1) livecycle is defined by the set and unset
methods, (2) testing is simplified because the test MK is simply injected, (3) acquisition
comes for free because the MK is just injected, (4) OSGi integration is just syntactic sugar.

Regards
Felix

Am 11.04.2012 um 10:00 schrieb Thomas Mueller:

> Hi,
> 
> We plan to support multiple MK implementations. I think we need to have a
> pluggable solution, a solution that does not require to re-compile the
> program just to be able to use a different MK implementation. Also, I
> would prefer a solution that doesn't require a configuration file
> (repository.xml) or the *need* to use OSGi or JNDI (but use OSGi if
> available).
> 
> What about:
> 
> // replacement for MicroKernelFactory
> // uses the Java ServiceLoader or OSGi if available
> class MicroKernelManagerFactory {
>  MicroKernelManager getManager(String uri);
> }
> 
> // each MK implementation needs to implement this
> interface MicroKernelManager {
>  MicroKernel getMK();
>  void dispose();
> }
> 
> 
> Regards,
> Thomas
> 


Mime
View raw message