Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 3528 invoked from network); 3 Sep 2002 09:36:01 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Sep 2002 09:36:01 -0000 Received: (qmail 12517 invoked by uid 97); 3 Sep 2002 09:36:45 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 12497 invoked by uid 97); 3 Sep 2002 09:36:44 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 12452 invoked by uid 98); 3 Sep 2002 09:36:43 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3D74822A.5050800@apache.org> Date: Tue, 03 Sep 2002 11:34:34 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation 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 Developers List Subject: [FOP Avalonization] IoC the holy grail? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I'm doing some work on Avalonizing FOP, as it has been decided it's the right way. We are using already LogEnabled, and now it's time for Configuration, but most important of all, usage of the SourceResolver. Now, I'm dealing with a problem I already had with POI (we want to avalonize it too probably). When we have big object pacakge structures and classes, it becomes somewhat impractical to use IoC. For example, in POI there are tons of classes that represent portions of the OLE2 file format. Shall I have all of these become container-components? Or in FOP: there needs to be an ImageFactoryService, but the problem is that it needs to be used by projects deep in the call stack. How can I make these components serviceable? Should I? It seems that when the model becomes too finegrained, the Avalon patterns become difficult to use. Comments, ideas? -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: