If you do code completion on
[standalone@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@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...
> 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(a)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