felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Resources administration / Virtual Bundle
Date Fri, 16 Dec 2011 15:21:10 GMT
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


Mime
View raw message