Return-Path: Delivered-To: apmail-incubator-ace-dev-archive@minotaur.apache.org Received: (qmail 56833 invoked from network); 15 Jul 2009 15:18:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 15 Jul 2009 15:18:54 -0000 Received: (qmail 91291 invoked by uid 500); 15 Jul 2009 15:19:03 -0000 Delivered-To: apmail-incubator-ace-dev-archive@incubator.apache.org Received: (qmail 91271 invoked by uid 500); 15 Jul 2009 15:19:03 -0000 Mailing-List: contact ace-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ace-dev@incubator.apache.org Delivered-To: mailing list ace-dev@incubator.apache.org Received: (qmail 91261 invoked by uid 99); 15 Jul 2009 15:19:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jul 2009 15:19:03 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of karlpauls@gmail.com designates 72.14.220.154 as permitted sender) Received: from [72.14.220.154] (HELO fg-out-1718.google.com) (72.14.220.154) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jul 2009 15:18:54 +0000 Received: by fg-out-1718.google.com with SMTP id l27so950375fgb.3 for ; Wed, 15 Jul 2009 08:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=EOoqVb69ilRahE5bGViQ3vX3hVsLD2nuaryIBopy1CY=; b=XuY7iz8H0rEOuITQnSf5DMPEqATJGO9lspVAT8PJaDWG9mQt0xtTyZNKcA9kjE6EKA s4Tmlb47nG4F1MIHa/UnN5LfHc4568WlUODOQp73zvrsCLxHMkXYo3WvwM7qhfhHDozo 9Z6Rd9VxSivit+vKONRxT01tHMLBHSwT6OgQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ZlN6nJPM17441/8F73TPpOk6slFpddg52dycysFxJtSHDxsss+H6MefOuHcGV8XsMF jUM8uErrF8pG2WzYkFkrEIvwjbapw/uW4wUf0PoL4RHOX2Bk0ou0G8Vh06mGexihZJa+ akZ+6oiPe/vgQ5aoi3qGnQKXEWMKUeQ1Z6jGI= MIME-Version: 1.0 Received: by 10.86.84.12 with SMTP id h12mr5026777fgb.21.1247671113949; Wed, 15 Jul 2009 08:18:33 -0700 (PDT) In-Reply-To: <7A5837CEF4D4834E97721F3BCC46D7F71BEC79072A@darth-malak.gx.local> References: <7A5837CEF4D4834E97721F3BCC46D7F71BEC7906B4@darth-malak.gx.local> <81CDDB03-496F-4EA6-8690-9B5231AB58BA@luminis.nl> <7A5837CEF4D4834E97721F3BCC46D7F71BEC79072A@darth-malak.gx.local> Date: Wed, 15 Jul 2009 17:18:33 +0200 Message-ID: <487a994c0907150818vc541f81m86d5573e18cb997a@mail.gmail.com> Subject: Re: deployment, cache and startlevels From: Karl Pauls To: ace-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Jul 15, 2009 at 5:15 PM, Bram de Kruijff wrote: > Marcel wrote: > >> The OSGi spec states that bundles and their states are persisted and >> restored when starting up again, so cleaning the cache is something >> you should not normally do. It is used more often during development, >> because then you often try to launch a framework with bundles that >> might still have serious bugs in them, causing updates to fail, etc. >> In a production environment I would say you don't need to clear the >> cache on every launch. > > I was afraid you were going to say that :P As I recall we were experiencing > some strange wiring issues a long time ago. These were 'resolved' by > clearing the cache at startup. I guess we kind of kept it once it was in > place also because with many updates the bundlecache has a nasty habbit > of getting very(!) big with lots of bundle versions that just sit there > doing nothing sensible. Maybe I don't want a clean but rather a garbage > collector :) The framework will clean-up the versions on refresh and on restarts. So all you have to do is to do refreshs at the right moments (which the deployment admin will do for you if you use ace). regards, Karl >> DA and start levels are separate concepts. One thing you could do is >> to actually provide some kind of "configuration information" that >> determines the start levels of the bundles. That configuration >> information could then be deployed as part of the same deployment >> package and sent to a bundle that translates this information into >> instructions for the start level service. We did not implement such a >> thing yet, but that should not be hard. > > Aha! Thanks for clearing that up :) I guess that should be done using > a Resource Processor of some sort? If I feel lucky later on this week > I'll have a look at this. > > Regards, > Bram > > -- Karl Pauls karlpauls@gmail.com