Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4DDCE9EA7 for ; Wed, 11 Apr 2012 15:55:43 +0000 (UTC) Received: (qmail 71260 invoked by uid 500); 11 Apr 2012 15:55:43 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 71214 invoked by uid 500); 11 Apr 2012 15:55:43 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 71205 invoked by uid 99); 11 Apr 2012 15:55:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 15:55:43 +0000 X-ASF-Spam-Status: No, hits=-0.6 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.18.1.183] (HELO exprod6og102.obsmtp.com) (64.18.1.183) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 15:55:33 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKT4WpX8XpRIvWBh9V0ijlXs7018gv+gk1@postini.com; Wed, 11 Apr 2012 08:55:12 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q3BFr5J0025851 for ; Wed, 11 Apr 2012 08:53:05 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q3BFt5Yt005277 for ; Wed, 11 Apr 2012 08:55:09 -0700 (PDT) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 11 Apr 2012 08:55:07 -0700 Received: from susi.local (10.136.134.56) by eurhub01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.192.1; Wed, 11 Apr 2012 16:55:05 +0100 Message-ID: <4F85A959.3020402@apache.org> Date: Wed, 11 Apr 2012 16:55:05 +0100 From: =?ISO-8859-1?Q?Michael_D=FCrig?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Subject: Re: MicroKernel.getInstance References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 11.4.12 16:36, Jukka Zitting wrote: > Hi, > > On Wed, Apr 11, 2012 at 3:32 PM, Thomas Mueller wrote: >>>> Do you think this is not needed? >>> >>> Exactly. >> >> So, it is not needed? >> >>> Only the code that creates the MicroKernel instance should ever call >>> dispose() >> >> So, it is needed? >> >> Sorry I don't understand. > > AFAICT all cases where we actually need to start up MicroKernel > instances (instead of just accessing one) already know which > implementation class to construct and how to dispose it once no longer > needed. Thus I don't see the need for a generic interface for either > starting up or disposing MicroKernels. Not sure whether this really is the case. However the number of different Microkernel implementations is definitely low and the current way of acquiring them via the MicroKernelFactory seems over engineered. I suggest to remove the MicroKernelFactory and use standard constructor calls as you proposed for now. Further down the line we should probably rethink the issue of modularisation, dependency injection and configuration within a broader scope anyway which might make this issue obsolete. See also OAK-17. Michael > > Do you know of cases where we would need such a generic interface? The > only case I know of is the MultiMkTestBase class, which I think is > better handled with the new MicroKernelFixture mechanism in oak-it-mk. > > BR, > > Jukka Zitting