Community
Participate
Working Groups
DS has several updates described in RFC 134 which has to be implemented
The current version of RFC 134 is already implemented. However I expect that this RFC will be updated by adding one or few more things.
Am I to assume that RFC 134 is implemented in M4?
(In reply to comment #2) > Am I to assume that RFC 134 is implemented in M4? Yes. The current version of the RFC is implemented in M4
I think the RFC is pretty much final, and the spec writing is going to start soon. Should we close this bug and mark the milestone M4. We can open another bug if additional changes are needed.
(In reply to comment #4) > I think the RFC is pretty much final I still need to make some changes to the RFC based upon some open bugs in OSGi's bugzilla.
in i0128 (and before it seems) the OSGi draft spec says "The signature for the activate and deactivate methods is: p ro tec ted vo id <me thod-name>(<a rgumen t s> ) ; <arguments> can be zero or more arguments. For the activate method each argument must be of one of the following types: ● ComponentContext – the Component Context for the component ● BundleContext – the Bundle Context of the component's bundle ● Map – the Component Properties from ComponentContext.getProperties. It seems however that a component with activate() or activate(Map) does not get activated. I did not try BundleContext. This is quite a blocker for the design of our Equinox book example.
(In reply to comment #6) > It seems however that a component with activate() or activate(Map) does not get > activated. I did not try BundleContext. This is quite a blocker for the > design of our Equinox book example. In my tests this works fine. Does your component has name space v1.1? Only components with name space v.1.1 can take advantage of the new features in DS spec. If your name space is correct I would need a test example to reproduce the problem.
It seems that using the v1.1.0 schema fixed the problem that Jeff was having. Thanks Stoyan. So I've been trying to think of ways to reduce problems such as this. Here are some ideas that may or may not prove helpful. 1. The DS CommandProvider commands (list/component) could mention the schema for each <component>. 2. When an XML document is parsed and the SCR cannot find any DS components it issues the following warning in the console: WARNING 5 [SCR] No components were found while processing component definition file bundleentry://5488661.6/OSGI-INF/component.xml Maybe this could be improved to mention the supported schemas that the SCR is looking for. As the message stands you really have to understand why no components were found. 3. When a schema is specified (or when the default is in force), it would be helpful if the SCR could complain when it sees XML that is compatible with a different version of the schema. This sort of runtime checking could clearly be expensive, so maybe this is something that you do when the debug tracing is enabled.
OK, so it seems that the SCR already does a pretty good job of spotting attributes that do not conform with the specified schema. This is what I was suggesting in 3. above. For example, when I tried to incorrectly use the <component> element's "activate" attribute from v1.1.0 with a v1.0.0 component I got these helpful messages: ERROR 5 [SCR] Error occurred while processing start tag of XML 'bundleentry://5488661.6/OSGI-INF/component.xml' in bundle org.eclipse.soda.sat.tutorial.01.customer_1.0.0 [6]! The error is: The component is according to namespace v1.0.0 and must not have 'activate' tag set, at line 2 WARNING 5 [SCR] No components were found while processing component definition file bundleentry://5488661.6/OSGI-INF/component.xml The only thing I noticed here was that this checking is only enforced when you specify the v1.0.0 schema, where as you do not get the errors when you omit the xmlns completely and rely on the default schema.
(In reply to comment #8) > 1. The DS CommandProvider commands (list/component) could mention the > schema for each <component>. I agree we need to add this information. I would prefer to add it only to the "component" command - the schema version that is used by a component is a detail IMHO. > > 2. When an XML document is parsed and the SCR cannot find any DS components it > issues the following warning in the console: > > WARNING 5 [SCR] No components were found while processing component > definition file bundleentry://5488661.6/OSGI-INF/component.xml > > Maybe this could be improved to mention the supported schemas that the > SCR is looking for. As the message stands you really have to understand > why no components were found. Now you receive ERROR message when there is something wrong with the a component. This error message precedes the warning message stating no components were found. I think there is no need to mention again the reason in the warning? > > 3. When a schema is specified (or when the default is in force), it would be > helpful if the SCR could complain when it sees XML that is compatible with > a different version of the schema. This sort of runtime checking could > clearly be expensive, so maybe this is something that you do when the debug > tracing is enabled. Already done as you found out :)
(In reply to comment #9) > The only thing I noticed here was that this checking is only enforced when you > specify the v1.0.0 schema, where as you do not get the errors when you omit the > xmlns completely and rely on the default schema. That's because I assume the default schema is already the new v1.1 :) It is not mention yet in the DS spec - I have opened a bug to add this clarification (see https://www.osgi.org/members/bugzilla/show_bug.cgi?id=934)
Thank you Stoyan, that's wonderful. Get theses things sorted out now will really improve the usability of DS and the Equinox implementation.
All changes in RFC 134 are implemented in DS
