OSGi - Revision history

JaroslavTulach at 07:35, 27 September 2012

2012-09-27T07:35:50Z

←Older revision		Revision as of 07:35, 27 September 2012
Line 11:		Line 11:
	I believe it makes sense to tell a module that it is going to be used or that it is used no more. Of course, I prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!		I believe it makes sense to tell a module that it is going to be used or that it is used no more. Of course, I prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

-	That would be a dangerous situation. It would mean one cannot put any initialization logic into the ''activator/installer'' at all. Peter Kriens spent significant amount of his time and patience to explain me the rationale behind this behavior and possible fix:	+	That would be a dangerous situation. It would mean one cannot put any initialization logic into the ''activator/installer'' at all. [[Peter Kriens]] spent significant amount of his time and patience to explain me the rationale behind this behavior and possible fix:
	# Just add '''Activation-Policy: lazy''' into your bundle which performs important initialization in ''BundleActivator'' and it is guaranteed that as soon as somebody loads a class from your bundle, it is going to be started		# Just add '''Activation-Policy: lazy''' into your bundle which performs important initialization in ''BundleActivator'' and it is guaranteed that as soon as somebody loads a class from your bundle, it is going to be started
	# This is not the default to keep things backward compatible - OK, I can understand the value of [[BackwardCompatibility]]. Through at this case it might have been better to change the semantics when the [[PropertyFiles\|bundle manifest version]] was changed to two (or change it to three). The [[NetBeans]] {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''use'' a module (by having a [[dependency]] on it and trying to get enabled). Although it is recommended to use [[Declarative Programming\|declarative registrations]], when ''activator/installer'' is present calling it as soon as the bundle is being ''used'' is the natural/expected behavior.		# This is not the default to keep things backward compatible - OK, I can understand the value of [[BackwardCompatibility]]. Through at this case it might have been better to change the semantics when the [[PropertyFiles\|bundle manifest version]] was changed to two (or change it to three). The [[NetBeans]] {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''use'' a module (by having a [[dependency]] on it and trying to get enabled). Although it is recommended to use [[Declarative Programming\|declarative registrations]], when ''activator/installer'' is present calling it as soon as the bundle is being ''used'' is the natural/expected behavior.

JaroslavTulach: /* Start/Stop a Bundle */

2012-01-11T15:09:35Z

Start/Stop a Bundle

←Older revision		Revision as of 15:09, 11 January 2012
Line 9:		Line 9:
	=== Start/Stop a Bundle ===		=== Start/Stop a Bundle ===

-	I believe it ~~make~~ sense to tell a module that it is going to be used or that it is ~~no longer being~~ used. Of course, I'd prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!	+	I believe it makes sense to tell a module that it is going to be used or that it is used no more. Of course, I prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

-	~~What kind of crazy idea is that?~~ It ~~basically means I~~ cannot put any initialization logic into the ''activator/installer'' at all. ~~I need~~ to ~~be ready for somebody using my module without starting~~ me~~! I really don~~'~~t get~~ the ~~purpose~~ of ~~this construct~~ at ~~all~~. The [[NetBeans]] {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''~~enable~~'' a module~~, or ''use it''~~ (by having a [[dependency]] on it and trying to get enabled). ~~This sounds logical~~ to me.	+	That would be a dangerous situation. It would mean one cannot put any initialization logic into the ''activator/installer'' at all. Peter Kriens spent significant amount of his time and patience to explain me the rationale behind this behavior and possible fix:
		+	# Just add '''Activation-Policy: lazy''' into your bundle which performs important initialization in ''BundleActivator'' and it is guaranteed that as soon as somebody loads a class from your bundle, it is going to be started
		+	# This is not the default to keep things backward compatible - OK, I can understand the value of [[BackwardCompatibility]]. Through at this case it might have been better to change the semantics when the [[PropertyFiles\|bundle manifest version]] was changed to two (or change it to three). The [[NetBeans]] {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''use'' a module (by having a [[dependency]] on it and trying to get enabled). Although it is recommended to use [[Declarative Programming\|declarative registrations]], when ''activator/installer'' is present calling it as soon as the bundle is being ''used'' is the natural/expected behavior.
		+	# Peter (as far as I understand) rather advocates splitting the [[API]] and the implementation into separate bundles however. The service should rather be registered by independent implementation. I still don't know how my code using the [[API]] will force the system to initialize the implementation too, but I expect the answer to be [[OSGi]] ''declarative services'' (which I am not familiar with).

-	~~Obviously these misconceptions complicate~~ the [[OSGiAndNetBeans]] bridge. Basically it means ~~there is no~~ 1:1 mapping between ''enabling'' a module in the [[NetBeans]] sense and ''starting'' a bundle in the [[OSGi]] sense. As we discover more and more [[OSGi]] based systems (like [[JDeveloper]]), we need to add more and more flexibility to cover all the possible ways people deal with the dichotomy between ''used'' and ''started''. [[OSGi]] is ~~more~~ flexible~~, but not logical~~.	+	Possibly [[Eclipse]] is using [[OSGi]] in wrong way. The [[singleton]] initialization in activator complicates the [[OSGiAndNetBeans]] bridge. Basically it means we don't have 1:1 mapping between ''enabling'' a module in the [[NetBeans]] sense and ''starting'' a bundle in the [[OSGi]] sense. As we discover more and more [[OSGi]] based systems (like [[JDeveloper]]), we need to add more and more flexibility to cover all the possible ways people deal with the dichotomy between ''used'' and ''started''. [[OSGi]] is very flexible and people tend to use it in many ''innovative'' ways.
		+
		+	At least I know now: the suitable fix is to use '''Activation-Policy: lazy'''. The only question remains: How do I convince [[Eclipse]] to modify their core bundle manifests to include this tag?

	=== Stopping Order ===		=== Stopping Order ===

JaroslavTulach: /* Range Dependencies */

2012-01-09T10:10:49Z

Range Dependencies

←Older revision		Revision as of 10:10, 9 January 2012
Line 29:		Line 29:
	On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed\|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.		On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed\|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.

-	Looking from this point of view: [[OSGi]] high shot (decision to use powerful [[dependency]] system) missed the sweet spot (produced underspecified system with corners full of bad consequences).	+	Looking from this point of view: [[OSGi]]'s high shot (decision to use powerful [[dependency]] system) missed the sweet spot (produced underspecified system with corners full of bad consequences).

	== Executive Summary ==		== Executive Summary ==

JaroslavTulach: /* Range Dependencies */

2012-01-09T10:03:08Z

Range Dependencies

←Older revision		Revision as of 10:03, 9 January 2012
Line 25:		Line 25:
	=== Range Dependencies ===		=== Range Dependencies ===

-	One of characteristics of [[OSGi]] is use of [[RangeDependencies]] which seems like a clever good idea supporting [[cluelessness]] in its way, but if not done properly it is just a way to mess around with [[NP-Complete]] problems. And yes, there are such problems in [[OSGi]] as demonstrated by [[Equinox]] coming with a [[3SAT]] solver.	+	One of the characteristics of [[OSGi]] is use of [[RangeDependencies]] which seems like a clever good idea supporting [[cluelessness]] in its way, but if not done properly it is just a way to mess around with [[NP-Complete]] problems. And yes, there are such problems in [[OSGi]] as demonstrated by [[Equinox]] coming with a [[3SAT]] solver.

	On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed\|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.		On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed\|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.

-	Looking from this point of view: [[OSGi]] ~~shooted~~ high (~~decided~~ to use powerful [[dependency]] system)~~, but~~ missed the sweet spot (produced underspecified system with corners full of bad consequences).	+	Looking from this point of view: [[OSGi]] high shot (decision to use powerful [[dependency]] system) missed the sweet spot (produced underspecified system with corners full of bad consequences).

	== Executive Summary ==		== Executive Summary ==

JaroslavTulach: /* Range Dependencies */

2012-01-09T10:01:09Z

Range Dependencies

←Older revision		Revision as of 10:01, 9 January 2012
Line 25:		Line 25:
	=== Range Dependencies ===		=== Range Dependencies ===

-	One of characteristics of [[OSGi]] is use of [[RangeDependencies]] which seems like a clever good idea supporting [[cluelessness]] in its way, but ~~at the end~~ it is just a way to [[NP-Complete]] problems. ~~An example when simple~~, ~~less powerful systems would~~ be ~~more effective~~. Looking from this point of view: [[OSGi]] ~~is over designed~~.	+	One of characteristics of [[OSGi]] is use of [[RangeDependencies]] which seems like a clever good idea supporting [[cluelessness]] in its way, but if not done properly it is just a way to mess around with [[NP-Complete]] problems. And yes, there are such problems in [[OSGi]] as demonstrated by [[Equinox]] coming with a [[3SAT]] solver.
		+
		+	On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed\|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.
		+
		+	Looking from this point of view: [[OSGi]] shooted high (decided to use powerful [[dependency]] system), but missed the sweet spot (produced underspecified system with corners full of bad consequences).

	== Executive Summary ==		== Executive Summary ==

JaroslavTulach at 08:37, 25 November 2011

2011-11-25T08:37:22Z

←Older revision		Revision as of 08:37, 25 November 2011
Line 38:		Line 38:

	<comments/>		<comments/>
		+
		+	== Defending [[OSGi]] ==
		+
		+	Accusing [[OSGi]] deficiencies generated some interesting [[Talk:OSGi\|comments and observations]]. I am including them here.
		+
		+	{{:Talk:OSGi}}

JaroslavTulach: /* Start/Stop a Bundle */

2011-11-13T18:34:21Z

Start/Stop a Bundle

←Older revision		Revision as of 18:34, 13 November 2011
Line 9:		Line 9:
	=== Start/Stop a Bundle ===		=== Start/Stop a Bundle ===

-	I believe it make sense to tell a module that it is going to be used or that it is no longer being used. Of course, I'd prefer [[Declarative Programming]], but sometimes there is just no other way ~~of solving the problem that~~ parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!	+	I believe it make sense to tell a module that it is going to be used or that it is no longer being used. Of course, I'd prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

	What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.		What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.

194.78.220.235: /* Start/Stop a Bundle */

2011-11-13T18:02:17Z

Start/Stop a Bundle

←Older revision		Revision as of 18:02, 13 November 2011
Line 9:		Line 9:
	=== Start/Stop a Bundle ===		=== Start/Stop a Bundle ===

-	I believe it make sense to tell a module that it is going to be used or it is ~~used~~ no longer. Of course, I'd ~~rather preffer~~ [[Declarative Programming]], but sometimes there is just no way ~~around. Parts~~ of infrastructure need to be turned on programmatically. Thus it is makes sense to have a '''BundleActivator''' or {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} (in the [[NetBeans]] case). However then one finds ~~out~~ that people can use an [[OSGi]] bundle without starting it!	+	I believe it make sense to tell a module that it is going to be used or that it is no longer being used. Of course, I'd prefer [[Declarative Programming]], but sometimes there is just no other way of solving the problem that parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

	What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.		What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB\|org-openide-modules\|org/openide/modules\|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.

194.78.220.235: /* OSGi Weirdness */

2011-11-13T18:00:04Z

OSGi Weirdness

←Older revision		Revision as of 18:00, 13 November 2011
Line 3:		Line 3:
	== [[OSGi]] Weirdness ==		== [[OSGi]] Weirdness ==

-	[[OSGi]] and [[NetBeans Runtime Container]] are similar, however the devil lies, as always, in the details! From time to time I manage to learn more about [[OSGi]] and then I just cannot help ~~wondering~~ what ~~was~~ the motivation behind designing such behavior! Maybe this is all caused by my preoccupation (as a designer of the [[NetBeans]] system), but I just cannot overcome the feeling that certain design decisions in [[OSGi]] are just weird.	+	[[OSGi]] and [[NetBeans Runtime Container]] are similar, however the devil lies, as always, in the details! From time to time I manage to learn more about [[OSGi]] and then I just cannot help but wonder what the motivation was behind designing such behavior! Maybe this is all caused by my preoccupation (as a designer of the [[NetBeans]] system), but I just cannot overcome the feeling that certain design decisions in [[OSGi]] are just weird.

	I'll nitpick on [[OSGi]] here, hoping somebody will be able to explain the history and possibly also the rationale behind these (mis)behaviors.		I'll nitpick on [[OSGi]] here, hoping somebody will be able to explain the history and possibly also the rationale behind these (mis)behaviors.

194.78.220.235: /* OSGi Weirdness */

2011-11-13T17:59:26Z

OSGi Weirdness

←Older revision		Revision as of 17:59, 13 November 2011
Line 3:		Line 3:
	== [[OSGi]] Weirdness ==		== [[OSGi]] Weirdness ==

-	[[OSGi]] and [[NetBeans Runtime Container]] are similar, however the devil lies, as always, in the details! From time to time I manage to learn more about [[OSGi]] and then I just cannot help wondering what was the motivation ~~to design~~ such behavior! Maybe this is all caused by my preoccupation (as a designer of the [[NetBeans]] system), but I just cannot overcome the feeling that certain design decisions in [[OSGi]] are just weird.	+	[[OSGi]] and [[NetBeans Runtime Container]] are similar, however the devil lies, as always, in the details! From time to time I manage to learn more about [[OSGi]] and then I just cannot help wondering what was the motivation behind designing such behavior! Maybe this is all caused by my preoccupation (as a designer of the [[NetBeans]] system), but I just cannot overcome the feeling that certain design decisions in [[OSGi]] are just weird.

	I'll nitpick on [[OSGi]] here, hoping somebody will be able to explain the history and possibly also the rationale behind these (mis)behaviors.		I'll nitpick on [[OSGi]] here, hoping somebody will be able to explain the history and possibly also the rationale behind these (mis)behaviors.