From dev-return-83186-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Mon Jan 02 19:00:32 2006
Return-Path:
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 3105 invoked from network); 2 Jan 2006 19:00:31 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 2 Jan 2006 19:00:31 -0000
Received: (qmail 78868 invoked by uid 500); 2 Jan 2006 19:00:28 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 78698 invoked by uid 500); 2 Jan 2006 19:00:27 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
List-Post:
Reply-To: dev@cocoon.apache.org
List-Id:
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 78687 invoked by uid 99); 2 Jan 2006 19:00:27 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jan 2006 11:00:27 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [24.93.47.42] (HELO ms-smtp-03-eri0.texas.rr.com) (24.93.47.42)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jan 2006 11:00:26 -0800
Received: from [192.168.1.101] (cpe-70-116-10-167.austin.res.rr.com [70.116.10.167])
by ms-smtp-03-eri0.texas.rr.com (8.12.10/8.12.7) with ESMTP id k02J02RZ019526
for ; Mon, 2 Jan 2006 13:00:03 -0600 (CST)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <43B577E9.6000306@apache.org>
References: <43B577E9.6000306@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6D542D7E-C0F3-4415-BE05-7E9AC24A971B@hard-bop.com>
Content-Transfer-Encoding: 7bit
From: Glen Ezkovich
Subject: Re: [RT] Simplifying component handling
Date: Mon, 2 Jan 2006 13:00:01 -0600
To: dev@cocoon.apache.org
X-Mailer: Apple Mail (2.746.2)
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
This thread got me thinking about alternatives to dependency
injection. The only credible alternative I can think of for Cocoon is
a Service Locator. One of the things I liked about Avalon was its
combination of dependency injection and service locator. This
combination made sense for a general purpose framework. The drawback
is that there is a great deal of complexity due to its use of
interface injection. (probably the real reason Carsten started this
thread) To simplify this all one need do is remove the interface
injection. Once the injection is removed each component is
responsible for constructing its self. The drawback of using a
service locator is the dependency on the locator itself. Cocoon is a
coherent framework that provides its own locator so this is a minimal
stumbling block.
There are two ways we could proceed using a service locator. One
would be to add a static method to a SeviceManager implementation
public static ServiceManager getServiceManager()
The other would be to use constructor injection
public MyComponent(ServiceManager m)
No reflection, no tricks, no jumping through hoops and a simple
contract.
This also provides a way to move away from Avalon while providing the
benefits of life-cycle management by allowing a component to request
its parameters, disposer, etc. by creating other locators. I don't
believe it would be to difficult to keep backwards compatibility
using this technique and all future components will be greatly
simplified.
WDYT?
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow