> > We already have other ways to get at this information with things like > the command line Shell, the programmatic DomainNode APIs, and the > Maven plugin. The JMX GSoC project will likely also provide another > way to get at the information. So it would be really good if where > possible they all worked in similar ways providing similar commands, > and also share as much code as possible.
+1 I've already stumbled across this and posted about it. I.e. there was some function (for getting the domain composite IIRC) that I just wanted to re-use. It was embedded in the DomainNode. Now we have two different node implementations which use the underlying Tuscany SPIs. It would be a shame to repeat this reporting type code in each of them > > What would be the best way to that? I think its good and useful to > have freedom to just play around experimenting with different commands > and that will lead to finding ones we think are useful, could we then > put those on a wiki page or something? Sounds OK to me. I really don't have a feel for what will and won't be useful. We've just go to try some things, be prepared to lets some die and support those that are useful. I'm sure the useful ones will find their ways into all of our various user interfaces eventually. > > For example, it looks like getting installed contributions is already > on all of these, above you have: > > contribution/ -> get a list of installed contributions (atom/rss?) > > the Shell has a command "installed" which displays the installed > contribution URIs on the console, and on Node there is a method doing > similar: "List<String> getInstalledContributionURIs()" > > Can we come up with a set of commands that we all agree are useful? I think it we can come up with a common API/SPI the result can then be rendered in lots of ways. In the shell, on a web page, in a management tool. Part of the tension for me here comes from having two Node APIs. I don't mind as they do different things in as much as the original one is our atomic node which just runs a single composite while the domain node better reflects the OASIS spec domain APIs (can we though not call then both node as it confuses me). How about we look at providing some base where we can collect together any common reporting operations? > > ...ant > -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com