Thank you Benjamin and Peter for your comments. I consider development time tools important mainly because
With declarative services in R4, we are like a VLSI programming language that can burn devices on a chip but not produce a picture to see what you have created. Of course tools should fill this gap, but there should be something in the OSGI runtime to show wiring information as well. Right now, all I have is information about which bundles are using a particular service but not which services are using other services. Moreover, this information is only available once the components have been activated (i.e., not before the component is actually used). However, with declarative services all the information for wiring is statically available, which makes it even possible to analyze the wiring at any time after the component declarations are written, not just when the services are running. Nikunj Benjamin Schmaus wrote: > As Peter points out, this is a known issue. The current tools (at > least the ones that I'm aware of) operate at the OSGi framework level, > eg, bundles and services, which makes it difficult to inspect the > system with regard to declarative service components. (DS > notwithstanding these tools work quite well.) > > It would be nice to have some tools available at runtime, such as > additional console commands, for troubleshooting issues with DS > components. For example, the ability to enumerate all DS components > in a given bundle with their status (either activated or not) would be > useful. Maybe something similar to the "bundle <bundleId>" command > that equinox supports could be implemented, eg, "componentStatus > <bundleId>", or maybe the bundle command could also be expanded to > include DS info in its output. > > It would also be nice to have some development-time tools. For > example, it's not uncommon (for me anyway) to forget to add the > Service-Component manifest header, which will definitely prevent your > components from being activated at runtime. It's also relatively > common to forget to add component descriptor files to the build for a > bundle so that the component descriptors aren't included in a bundle's > resulting jar. I could see a specialized "Declarative Services" tab > included in the manifest editor for Eclipse being useful for these > types of problems. > It seems like something similar to the Extension Point editors could > work for creating DS component descriptors. > > - Ben > > On 10/26/06, Peter Kriens <[EMAIL PROTECTED]> wrote: > >> This is a clear problem, declarative services are new and no tools >> have been made so far to debug and help. >> >> However, it should not be that hard to make a tool for the OSGi >> command shell (org.osgi.tools.console.jar in membercvs) that parses >> the declarations and does some analysis? Felix and Equinox also have >> shells that are extendable. (In R5 we will look at creating one >> extension model). >> >> Kind regards, >> >> Peter kriens >> >> >> >> >> NM> Hi folks, >> >> NM> I have started to use declarative services for my project and endured a >> NM> fair amount of pain doing so. The main reason is the lack of good tools >> NM> to find out the wiring problems in my component declarations. >> >> NM> Most of the time the properties of services and target filters on >> NM> references don't match. The end result is that a whole bunch of services >> NM> are never activated and its hard to find out why. This is despite the >> NM> fact that I am only using static properties and no service factories. >> >> NM> How do you deal with similar problems? Its not hard to imagine >> NM> processing all the component declarations in a given set of bundles to >> NM> find out the wiring between components and possibly visualize it. I hope >> NM> others on this mailing list would also benefit from your suggestions and >> NM> tips. >> >> NM> If it helps to know, I am using Eclipse PDE as my IDE and Equinox as my >> NM> OSGI runtime. >> >> NM> Thanks, >> NM> Nikunj >> NM> _______________________________________________ >> NM> OSGi Developer Mail List >> NM> osgi-dev@bundles.osgi.org >> NM> http://bundles.osgi.org/mailman/listinfo/osgi-dev >> >> -- >> Peter Kriens Tel +33467542167 >> 9C, Avenue St. Drézéry AOL,Yahoo: pkriens >> 34160 Beaulieu, France ICQ 255570717 >> Skype pkriens Fax +1 8153772599 >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@bundles.osgi.org >> http://bundles.osgi.org/mailman/listinfo/osgi-dev >> >> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@bundles.osgi.org > http://bundles.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
