Return-Path: X-Original-To: apmail-felix-users-archive@minotaur.apache.org Delivered-To: apmail-felix-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 16B999219 for ; Fri, 16 Dec 2011 15:21:41 +0000 (UTC) Received: (qmail 60217 invoked by uid 500); 16 Dec 2011 15:21:40 -0000 Delivered-To: apmail-felix-users-archive@felix.apache.org Received: (qmail 60180 invoked by uid 500); 16 Dec 2011 15:21:40 -0000 Mailing-List: contact users-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@felix.apache.org Delivered-To: mailing list users@felix.apache.org Received: (qmail 60172 invoked by uid 99); 16 Dec 2011 15:21:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Dec 2011 15:21:40 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of heavy@ungoverned.org designates 209.85.220.177 as permitted sender) Received: from [209.85.220.177] (HELO mail-vx0-f177.google.com) (209.85.220.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Dec 2011 15:21:32 +0000 Received: by vcbf11 with SMTP id f11so2283680vcb.22 for ; Fri, 16 Dec 2011 07:21:11 -0800 (PST) Received: by 10.220.151.204 with SMTP id d12mr3493040vcw.40.1324048871518; Fri, 16 Dec 2011 07:21:11 -0800 (PST) Received: from Richard-S-Halls-iMac.local (adsl-99-62-222-230.dsl.sgnwmi.sbcglobal.net. [99.62.222.230]) by mx.google.com with ESMTPS id u12sm5576915vde.4.2011.12.16.07.21.10 (version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 07:21:11 -0800 (PST) Message-ID: <4EEB61E6.1090208@ungoverned.org> Date: Fri, 16 Dec 2011 10:21:10 -0500 From: "Richard S. Hall" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: users@felix.apache.org Subject: Re: Resources administration / Virtual Bundle References: <694A6DBD-4FF3-459C-842B-D3E5AEE3D73D@luminis.nl> In-Reply-To: <694A6DBD-4FF3-459C-842B-D3E5AEE3D73D@luminis.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/15/11 17:32 , Marcel Offermans wrote: > Hello Fabian, > > On Dec 6, 2011, at 9:07 AM, Fabian Broekhof wrote: > >> I'm relatively new to Apache Felix. >> We are doing a project for component distribution on an Android platform, >> using Apache Felix and Ace. >> We have the basic distribution working. > Because you and I started discussing this outside of the list, people might need a bit more context. When you say "component distribution on an Android platform" you actually mean you're installing APK's (the native format for Android packages, how apps are packaged) this way. > >> We do have an issue for choosing the right solution for administration of >> all this. >> >> For bundles, we can do a Felix.getBundleContext().getBundles(), and we >> retrieve all bundles. >> Because we have resources (they will factually run on the Android OS), we >> don't have bundles registered. >> >> I read about the Virtual-Bundle concept. This Virtual-Bundle corresponds to >> a resource. So we connect the OSGI runtime world with the Android world. > I think Richard wrote the page on the concept of virtual bundles, I'm sure he can elaborate a little bit on why they were designed and if he thinks this is a good use case for them. Virtual bundles were a concept I prototyped, but they were never fully implemented and do not exist in the Felix framework, nor anywhere else for that matter. > >> Some say this is not the way to do it, because the resource is NO bundle. >> Which is true. > Yeah, that's actually my opinion. Virtual bundles in the end are modelled as bundles because they expose the same things as "real" bundles. Your Android APK files are applications that do not directly interact with the OSGi container, they just happen to be installed / updated / removed from OSGi. Therefore I think you should keep track of them in a separate, custom list instead of adding them as virtual bundles to the list of bundles available in the framework. Technically, what you deploy into the framework doesn't have to strictly be a bundle, depending on your definition of a bundle. For example, using the extender pattern, you could imagine packaging configurations up inside of a JAR file and deploying them into the framework where an extender would pull the configuration information out of the JAR and inject it into the Config Admin service. Is this configuration JAR a bundle? I guess that depends on your definition, but clearly the framework doesn't really do anything with it. So, you could imagine using JAR files to deploy other payload to a running JVM and then have an extender perform some activity based on the lifecycle events of the bundle. For example, the payload of a bundle could be a native app. The extender could natively install the native app when the bundle is installed, natively start it when the bundle is started, and natively uninstall it when the bundle is uninstalled. Is this good or bad? I don't know, but it is clearly an extension of the extender pattern. -> richard > >> I love to know how you think about this subject? >> >> We are also open for better suggestions to how to keep track of our >> resources (which are administered in the resourcestore). Is the alternative >> to build an OSGI service which accesses the resourcestore? > That sounds like a good plan: if Android somewhere already keeps track of them, just expose them as a service. At the same time, if you deploy these APK files via Apache ACE, it will already keep track of what is installed where on the server side. > > Greetings, Marcel > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org