[jboss-as7-dev] Exposing OSGi runtime bundle management through the Detyped API

[Thomas Diesler]

If you do code completion on

[standalone at localhost:9999 /] /subsystem=datasources:

you see a number of generic but also some specific operations. One 
advantage of the latter is that they can be described

add                          get-installed-driver         
installed-drivers-list       read-attribute
read-children-names          read-children-resources      
read-children-types          read-operation-description
read-operation-names         read-resource                
read-resource-description    validate-address
write-attribute

The osgi subsystem should also offer these context specific operations 
(e.g. list-bundles). 'ls bundle' is no good because it would only 
produces a meaningless list of bundle id's. In comparison with 
'installed-drivers-list' you get meaningful output like this

[standalone at localhost:9999 /] /subsystem=datasources:installed-drivers-list
{
     "outcome" => "success",
     "result" => [{
         "driver-name" => "h2",
         "deployment-name" => undefined,
         "driver-module-name" => "com.h2database.h2",
         "module-slot" => "main",
         "driver-datasource-class-name" => "",
         "driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource",
         "driver-class-name" => "org.h2.Driver",
         "driver-major-version" => 1,
         "driver-minor-version" => 2,
         "jdbc-compliant" => true
     }]
}

Hence the preference of a context specific read operation over the 
generic one.

cheers
-thomas


On 09/29/2011 02:48 PM, David Bosschaert wrote:
> On 29/09/2011 13:28, Thomas Diesler wrote:
>> |I'd prefer an operation 'list-bundles' with every bundle being an 
>> addressable resource. |
>
> No sure I follow this completely...
> So you have bundles as addressable resources:
> /subsystem=osgi/bundle=0
> /subsystem=osgi/bundle=1
> /subsystem=osgi/bundle=2
> etc...
>
> and then you'd like an operation
> /subsystem=osgi:list-bundles
> ?
>
> Isn't that what you get when you call
> /subsystem=osgi:read-children-names(child-type=bundle)
> or simply in the CLI
> ls bundle
> ?
>
>> |The attributes you mention are fine for a start, however please have 
>> a look at BUNDLE_TYPE 
>> <http://www.osgi.org/javadoc/r4v42/org/osgi/jmx/framework/BundleStateMBean.html#BUNDLE_TYPE> 
>> and check whether you want to support one or the other as well. The 
>> list of supported attributes can always be expanded.
>> |
>
> Yeah I wanted to start small and add more later on, but thinking more 
> about it, exposing the bundle's start level should probably go in the 
> first round.
>
>> |Strictly speaking the start-level is not a property of the 
>> framework, but of the StartLevel service. It'd be better to model 
>> that service as an addressable resource. In future there will 
>> probably be more services
>>
>> /subsystem=osgi/service=startlevel:write-attribute(name=startlevel,value=5) 
>>
>> |
>
> That depends on how you look at it :) up until core 4.2 it's exposed 
> through the Start Level service. From core 4.3 start level is actually 
> an API on the Framework (you need to adapt bundle 0 to get the start 
> level API) so for the future it might actually be more consistent to 
> represent this as a property of the framework. (BTW the Start Level 
> services will still be supported for BW compatibility).
>
>> |For consistency the bundle operations should be called start/stop |
>> |
>> ||/subsystem=osgi/bundle=1:start
>> ||/subsystem=osgi/bundle=1:stop
>> |
>
> The reason why I suggested start-bundle and stop-bundle is that start 
> and stop are highly generic and I was worried that in the future there 
> might be global operations called start and stop. Hence I added the 
> -bundle suffix.
>
>> |
>> Are you planning to support start options?
>>
>> |
>
> Ultimately yes, but not in the initial cut. Most people don't use 
> those AFAIK.
>
>> |Glad you considered domain mode ;-)
>>
>> cheers
>> -thomas
>> |||
> Thanks for the feedback!
>
> David
>
>> On 09/28/2011 05:57 PM, David Bosschaert wrote:
>>> Hi all,
>>>
>>> I'm planning to add some runtime management via the Detyped API to the
>>> OSGi subsystem. After getting some staring point input from Brian and
>>> Thomas I wrote a page on how an initial implementation could look like.
>>>
>>> Any feedback appreciated:
>>> http://community.jboss.org/wiki/OSGiRuntimeManagementUsingDetypedAPI
>>>
>>> Cheers,
>>>
>>> David
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> -- 
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Thomas Diesler
>> JBoss OSGi Lead
>> JBoss, a division of Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx