Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 21311 invoked from network); 23 Oct 2002 15:24:30 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Oct 2002 15:24:30 -0000 Received: (qmail 9071 invoked by uid 97); 23 Oct 2002 15:24:24 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 8979 invoked by uid 97); 23 Oct 2002 15:24:23 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 8936 invoked by uid 98); 23 Oct 2002 15:24:22 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DB6BED9.8030008@thinkdynamics.com> Date: Wed, 23 Oct 2002 11:23:05 -0400 X-Sybari-Trust: bc716ffb 941f1c9f a4468164 0000093d From: Igor Fedorenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon-Phoenix Developers List Subject: Block context as shared source of block related information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2002 15:23:13.0139 (UTC) FILETIME=[1A22FC30:01C27AA8] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi, Interceptors and other stuff I am working on right now need extensible way to associate block with context information. For example, security infrastructure needs block's "security info", management needs block's "mx info" and so on. This has been already discussed (see "[Interceptors] Definition and basic use cases" thread) but I did not have time to implement it. As I finally have to do it I want to reiterate the idea to get some feedback from phoenix developers. Scope of context data. Application: same key/value pairs for all blocks. Example would be application home directory and name. Block: key/value pairs are specific to a particular block instance. Examples: block metadata, mxinfo, security info and so on. Invocation: different key/value pairs for each invocation. Examples are thread's transaction and security contexts. Context data layout. Application will have single application context instance (not sure if it is the same as ApplicationContext). For each block there is going to be one block context object with application context as a parent. To avoid confusion all application and block specific keys must be unique. Invocation context will be created by BlockInvocationHandler for each invocation and will keep a reference to block's context. Invocation context will be passed as parameter to Interceptor.invoke call (see bug 12405) and will be available as thread local to the blocks. Population block context with data. Application and block contexts will be populated by ContextContributors defined as public interface ContextContributor { void contribute(ContextImpl context); } ContextImpl is a subclass of DefaultContext that enforces key uniqueness. In assembly.xml context contributor will be specified with the following tags Invocation context will be populated by interceptors. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com -- To unsubscribe, e-mail: For additional commands, e-mail: