Community
Participate
Working Groups
Created attachment 174730 [details] Example bundles, illustrating the behavior of ds commands The main drawback of the current DS commands is that they show mostly the static information from the declarative service xml. If for example the bind method name is misspelled in the xml and cannot be found at runtime the component state is unsatisfied but from the detailed information provided one cannot say what the actual problem is; one only sees that there are no instances created for this component, therefore something is wrong. It is even worse if there is an error in the DS xml or the most common mistake you simply forget to put the xml in the OSGI-INF - the commands act as if there is no DS component provided by your bundle. We collected such problematic scenarios that gave us hard time in debugging and reading traces. Based on them we suggest the following supportability enhancements in the existing DS shell commands: • If there is no instance created for a DS component the "comp" command should show the runtime issues which turned up during the resolving process of the component. These issues can be: o bind method is not found in the class implementing the component. o bind method throws exception when called. o activate method throws exception when called. • "ls <bundle id>" command can be extended to check the specified bundle for: o Missing service declaration xml although such service is defined in the MANIFEST.MF o Any issues found in xml parsing – missing component name or implementation class, etc. • "comp" command can show the actual instances of the references bound to a component instance. It will be very helpful especially when the cardinality 0…n or 1…n is used the reference can be resolved by binding both one and ten instances of the referred services but for the service developer both cases are not equal. Of course this additional information is available as logs and traces of the DS runtime but in an environoment with tens of declarative services with dynamic references among them it is very hard to read those traces. Moreover in order to check the traces you need to restart the equinox or at least the bundle because the initial resolving of the services happens during the start of the bundles. Examples: There are several example bundles that illustrate the behavior of the DS commands ("comp" and "ls") in case of broken DS declarations or activation. Bundle DS_Properties_Invalid_Type_1.0.0 has 2 xmls describing components and 2 issues - the specified properties file is missing and the value of a property is missing. Bundle DS_Wrong_Comp_1.0.0 has no component name specified in the DS xml. Bundle DS_Wrong_Tag_1.0.0 has an unknown tag "references" in its DS xml. Bundle DS_Failing_Activate_1.0.0 has a component which activate method throws java.lang.IllegalStateException. Bundle DS_Missing_XML_Declaration_1.0.0 has 2 service components specified in MANIFEST.MF; one of the xmls is missing, the other points to a component which bind method throws NullPointerException. Bundle DS_Wrong_Bind_Method_1.0.0 has a misspelled bind method in its DS xml. Bundle DS_With_Many_References_1.0.0 has a component which specifies dependencies 1..n to org.eclipse.osgi.framework.console.CommandProvider. This bundle should demonstrate the need to have the list of all the reference instances bound to a component instance. Bundle HelloBundle_1.0.0 registers a service which is used by most of the other bundles.
Created attachment 174731 [details] Proposed patch implementing the described enhancements The patch proposes implementation for the enhancements described above. The changes made in ServiceComponent and ComponentReference allow collecting of any runtime issues during activation of a component. This way the SCRCommandProvider can print this runtime issues in case there is no instances created for the specified component. The changes made in DeclarationParser allow throwing of the exceptions that have occurred during the DS xml parsing instead of just tracing them. This way the SCRCommandProvider can trigger parsing of the DS xml for a bundle that has no registered components. There are changes in the SCRCommandProvider to show all the reference objects bound to a component instance.
Created attachment 174732 [details] DS bundle with the proposed changes applied
Created attachment 182905 [details] Refined patch Lazar, thanks for the provided patch and the test bundles! I have reviewed the patch and now I provide slightly modified one with the following changes: ServiceComponent: Old: public HashSet componentIssues = new HashSet(11); New: public HashSet componentIssues = new HashSet(1, 1); I am initializing the componentIssues hashset with values that would consume minimum memory DeclarationParser: Replaced the usage of constructor IllegalArgumentException(String, Throwable) - it is available since JDK1.5 It is replaced with RuntimeException(String, Throwable) SCRCommandProvider: - Replaced the usage of Arrays.toString(Object[]) - it is available since JDK1.5
(In reply to comment #3) > Created an attachment (id=182905) [details] > Refined patch > > Lazar, thanks for the provided patch and the test bundles! > > I have reviewed the patch and now I provide slightly modified one with the > following changes: > > ServiceComponent: > Old: > public HashSet componentIssues = new HashSet(11); > New: > public HashSet componentIssues = new HashSet(1, 1); > I am initializing the componentIssues hashset with values that would consume > minimum memory > > DeclarationParser: > Replaced the usage of constructor IllegalArgumentException(String, Throwable) - > it is available since JDK1.5 > It is replaced with RuntimeException(String, Throwable) > > SCRCommandProvider: > - Replaced the usage of Arrays.toString(Object[]) - it is available since > JDK1.5 Stoyan, thanks for the corrections!
The patch is released to HEAD
