VerificationViaAOP - Revision history

JaroslavTulach at 06:51, 23 March 2009

2009-03-23T06:51:16Z

←Older revision		Revision as of 06:51, 23 March 2009
Line 3:		Line 3:
	Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to [[Java_Monitor\|synchronization and deadlocks]] to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work for everyone running on background. When you are supervising such modular system finding and preventing such ''inverted'' dependencies that violate overall assumptions is one of the biggest priorities.		Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to [[Java_Monitor\|synchronization and deadlocks]] to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work for everyone running on background. When you are supervising such modular system finding and preventing such ''inverted'' dependencies that violate overall assumptions is one of the biggest priorities.

-	:There are various extensions to [[NetBeans]] [[Virtual File System]] library.	+	:There are various extensions to [[NetBeans]] [[Virtual File System]] library,
-	:~~One of them is~~ support for [[CVS]], [[Subversion]] or [[Mercurial]]. ~~Their job~~	+	:including support for [[CVS]], [[Subversion]] or [[Mercurial]]. To deal with VCS
-	:is slightly harder then traditional task of regular file system. ~~Some times~~	+	:is slightly harder then traditional task of regular file system. Sometimes
-	:they need to make decisions and they ~~needed~~ to ask user questions. Indeed this	+	:they need to make decisions and they need to ask user questions. Indeed this
	:was very deadlock prone and needed to be prevented and [[TryCatchRedo\|fixed]].		:was very deadlock prone and needed to be prevented and [[TryCatchRedo\|fixed]].

JaroslavTulach at 09:59, 22 March 2009

2009-03-22T09:59:39Z

←Older revision		Revision as of 09:59, 22 March 2009
Line 1:		Line 1:
-	[[Use Modular Architecture\|Modular applications]] assign its every piece certain role. One module shall provide [[API]] for access to storage, one for displaying wizards, etc. Other modules depend on such [[API]] modules and use them get the data from the storage or display their wizard dialogs. The intuition clearly indicates that by wrapping all the complexity of dealing with storage into a separate module, the overall complexity of the code is simplified.	+	[[Use Modular Architecture\|Modular applications]] assign its every piece certain role. One module shall provide [[API]] for access to ''storage'', one for displaying wizards, etc. Other modules depend on such [[API]] modules and use them get the data from the storage or display their wizard dialogs. The intuition clearly indicates that by wrapping all the complexity of dealing with storage into a separate module, the overall complexity of the code is simplified.

-	Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to [[Java_Monitor\|synchronization and deadlocks]] to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work on everyone running on background. When you are supervising such modular system ~~this~~ is the ~~first thing that you want to prevent~~.	+	Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to [[Java_Monitor\|synchronization and deadlocks]] to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work for everyone running on background. When you are supervising such modular system finding and preventing such ''inverted'' dependencies that violate overall assumptions is one of the biggest priorities.

	:There are various extensions to [[NetBeans]] [[Virtual File System]] library.		:There are various extensions to [[NetBeans]] [[Virtual File System]] library.
Line 7:		Line 7:
	:is slightly harder then traditional task of regular file system. Some times		:is slightly harder then traditional task of regular file system. Some times
	:they need to make decisions and they needed to ask user questions. Indeed this		:they need to make decisions and they needed to ask user questions. Indeed this
-	:was very deadlock prone and needed to prevented and [[TryCatchRedo\|fixed]].	+	:was very deadlock prone and needed to be prevented and [[TryCatchRedo\|fixed]].

	Simplest fix, especially if you own both [[API]]s is to set some '''ThreadLocal''' variable whenever a method from storage [[API]] is on the stack and whenever one tries to show a wizard or dialog verify that this '''ThreadLocal''' is not set. If it is, rise an exception. This is simple, yet it feels like quite a brute force hack than a recommended pattern.		Simplest fix, especially if you own both [[API]]s is to set some '''ThreadLocal''' variable whenever a method from storage [[API]] is on the stack and whenever one tries to show a wizard or dialog verify that this '''ThreadLocal''' is not set. If it is, rise an exception. This is simple, yet it feels like quite a brute force hack than a recommended pattern.

-	As such I was very pleased to see [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini Penchikala's presentation] describing use of [[AOP]] for the same task. Instead polluting ~~the~~ both [[API]] with ''ThreadLocal'' tricks and making them semi-aware of each other (wizard ~~often~~ do not need storage), one can define one or two ''aspects'' externally and achieve the same.	+	As such I was very pleased to see [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini Penchikala's presentation] describing use of [[AOP]] for the same task. Instead polluting both the [[API]]s with '''ThreadLocal''' tricks and making them semi-aware of each other (wizard do not need storage otherwise), one can define one or two ''aspects'' externally and achieve the same.

-	For preventing these kinds of unwanted compile or runtime dependencies the [[AOP]] seems to be perfect. Get more ~~inspication~~ by [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini].	+	For preventing these kinds of unwanted compile or runtime dependencies the [[AOP]] seems to be perfect. Get more inspiration by [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini].

	<comments/>		<comments/>

	[[Category:Tools]]		[[Category:Tools]]

JaroslavTulach: New page: Modular applications assign its every piece certain role. One module shall provide API for access to storage, one for displaying wizards, etc. Other module...

2009-03-22T09:43:20Z

New page: Modular applications assign its every piece certain role. One module shall provide API for access to storage, one for displaying wizards, etc. Other module...

New page

[[Use Modular Architecture|Modular applications]] assign its every piece certain role. One module shall provide [[API]] for access to storage, one for displaying wizards, etc. Other modules depend on such [[API]] modules and use them get the data from the storage or display their wizard dialogs. The intuition clearly indicates that by wrapping all the complexity of dealing with storage into a separate module, the overall complexity of the code is simplified.

Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to [[Java_Monitor|synchronization and deadlocks]] to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work on everyone running on background. When you are supervising such modular system this is the first thing that you want to prevent.

:There are various extensions to [[NetBeans]] [[Virtual File System]] library.
:One of them is support for [[CVS]], [[Subversion]] or [[Mercurial]]. Their job
:is slightly harder then traditional task of regular file system. Some times
:they need to make decisions and they needed to ask user questions. Indeed this
:was very deadlock prone and needed to prevented and [[TryCatchRedo|fixed]].

Simplest fix, especially if you own both [[API]]s is to set some '''ThreadLocal''' variable whenever a method from storage [[API]] is on the stack and whenever one tries to show a wizard or dialog verify that this '''ThreadLocal''' is not set. If it is, rise an exception. This is simple, yet it feels like quite a brute force hack than a recommended pattern.

As such I was very pleased to see [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini Penchikala's presentation] describing use of [[AOP]] for the same task. Instead polluting the both [[API]] with ''ThreadLocal'' tricks and making them semi-aware of each other (wizard often do not need storage), one can define one or two ''aspects'' externally and achieve the same.

For preventing these kinds of unwanted compile or runtime dependencies the [[AOP]] seems to be perfect. Get more inspication by [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini].

<comments/>

[[Category:Tools]]