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

On 29/09/2011 13:28, Thomas Diesler wrote:

> |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.

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 >