Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F8DFCDE.9080903@apache.org>
Date: Thu, 16 Oct 2003 04:05:18 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Cc: dev@avalon.apache.org
Subject: Re: Fortress Migration Strategy
References: <3F8C3358.3050707@apache.org> <3F8C587C.8000600@apache.org>
 <3F8C6B06.3030600@apache.org> <3F8D420E.4040605@apache.org>
In-Reply-To: <3F8D420E.4040605@apache.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit


Berin Loritsch wrote:

> Stephen McConnell wrote:
>
>>
>> Berin:
>>
>> A couple, of notes in-line...
>>
>> Berin Loritsch wrote:
>>
>>>
>>> Request Scoped Components: Create a new lifestyle handler for Fortress.
>>
>>
>>
>>
>> Is this equivalent to the creation of a new component instance for 
>> each invocation against the service manager?
>
>
> No, this is having one instance of a component for each HTTP Request. 
> When
> the HTTP Request is processed and the response is sent, the container 
> cleans
> up the components to release them.


OK - this is usage policy as opposed to an implementation policy. 
Currently we have four standard lifestyle - "singleton", "thread", 
"pooled" and "transient". Each lifestyle represents a different strategy 
concerning new instance creation and release based on implementation 
decisions (i.e. no client context). In what you are describing above - 
it sounds like a "session" scoped create/destroy cycle - which basically 
comes down to a policy of instance creation relative to a supplied 
identity. Under Avalon 4.X services are resolved relative to a string 
identifier. An "identity" lifestyle policy would require that a 
supplementary identity key be supplied to a service manager and 
propergated back to a lifestyle handler, which in turn invokes instance 
deployment requests against a factory etc. Under 4.X this is not a good 
idea because the ServiceManager/ComponentManager interfaces are simply 
not geared for this.

Based on what we have today (A4 + containment technologies in hand), and 
taking into account a reasonable strategy then will deliver migration to 
a single Avalon container, there are IMO only two short-term possibilities:

Either:

1. Cocoon defines this as a service (i.e. a SessionThingFactory 
dependency), or
2. Avalon defines a standard "custom" lifestyle policy tag in the 
avalon-meta
package (and the coresponding backend)

Any other solution will result in the specialization of Fortress for 
Cocoon which will result in the continuation of the division between 
preventive and dynamic containment semantics (i.e. the Phoenix versus 
ECM semantic fork). A quick solution is to craft some extra 
functionality into Fortress to deal with immediate requirements - but 
the better solution is to take a moment and think the implications - 
sort out strategy with clean semantics - and do it right. Fortress is 
positioning as a migration path to Merlin. Merlin is positioning as an 
step in the delivery of a next generation Avalon containment solution. 
The final solution has one set of generic semantics that are 
sufficiently defined to be implementable and supportable at the level of 
interface specification � i.e. a framework, meta and container spec.

What I really would like to see is that this discussion moves to 
dev@avalon - where we focus or attention on providing a good migration 
solution. The key to that is establishing a technical framework that 
makes sense with respect to an Avalon today, our roadmap, and community 
interests. That roadmap needs to take into account Cocoon, Turbine, 
James, and lots of other external users. I also want to say that now - 
here - this instant - we should not push for Cocoon specifics from 
Avalon containers because this will only damage the Avalon proposition. 
Instead - we should work with Avalon on establishing consistent abstract 
semantics requirements.

I.e. let's not push this too fast, take some time, do some thinking, and 
come up with something that is a viable long term mutual assured solution.

Stephen.


-- 

Stephen J. McConnell
mailto:mcconnell@apache.org