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

[Brian Stansberry]

Just an FYI, read-children-resources(child-type=bundle) provides output 
similar to the installed-drivers-list op.

I'm not really advocating one way or another here. It seems like a 
resourcing issue -- context specific ops are nice but take effort to create.

On 9/30/11 2:34 AM, Thomas Diesler wrote:
> 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
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat