From dev-return-73275-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Apr 13 16:23:46 2005 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 18200 invoked from network); 13 Apr 2005 16:23:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Apr 2005 16:23:46 -0000 Received: (qmail 16314 invoked by uid 500); 13 Apr 2005 15:29:36 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 16241 invoked by uid 500); 13 Apr 2005 15:29:36 -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 Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 16223 invoked by uid 99); 13 Apr 2005 15:29:36 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from blossom.betaversion.org (HELO blossom.betaversion.org) (62.140.213.100) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 13 Apr 2005 08:29:34 -0700 Received: by blossom.betaversion.org (Postfix, from userid 101) id 3842B1B8F7D; Wed, 13 Apr 2005 16:08:40 +0100 (BST) X-AntiVirus-Version: ClamAV 0.84rc1/825 X-AntiSpam-Version: SpamAssassin 3.0.2 X-AntiSpam-Status: No (score=-2.8/limit=7.5) X-AntiSpam-Rules: all_trusted Received: from [10.75.35.126] (unknown [62.140.213.2]) by blossom.betaversion.org (Postfix) with ESMTP id B75E51BD994 for ; Wed, 13 Apr 2005 16:08:39 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <425D0549.80401@apache.org> References: <20050409083134.46541.qmail@minotaur.apache.org> <425A36D5.4010809@nada.kth.se> <425A3A7B.5030203@apache.org> <425A6B42.1040009@nada.kth.se> <425A7094.8040906@apache.org> <425A8A7A.1030203@nada.kth.se> <425A8EAF.7090502@apache.org> <255a9c1e1ee0934507a1f5447f3ef066@betaversion.org> <425BDF4B.8040705@apache.org> <3e1766b0f6774aa2f9b7a26a729043ae@betaversion.org> <425D0549.80401@apache.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9c28f5a45d1ec41b74503c823fa64351@betaversion.org> Content-Transfer-Encoding: 7bit From: Pier Fumagalli Subject: Re: Java components in blocks Date: Wed, 13 Apr 2005 16:08:47 +0100 To: dev@cocoon.apache.org X-Mailer: Apple Mail (2.619.2) X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 13 Apr 2005, at 12:40, Reinhard Poetz wrote: > Pier Fumagalli wrote: > >> Ok, here is where I don't agree... >> By adding to blocks the capability of "bringing components" with >> them, we enter a quite big minefield, imposed by the restrictions of >> the Java VM. The complexity escalates at this point as now blocks >> must be aware of their class-loading mechanism, and the component >> manager must be aware of blocks and interfaces. >> For example, classes and libraries included in an interface block >> must be loaded by the parent ClassLoader of the blocks using >> (implementing, extending, requiring) them to avoid >> ClassCastException(s). >> So, alongside blocks and their deployment graph (block A extends B, >> implements C, ... blabla ...) we need to start keep tracking also the >> classes included in those blocks, and create a completely different >> tree based on the class loading structure that those represent. >> And then you get into the minefield of versioning... If it's easy to >> determine that two versions of the same block can co-exist (by using >> two separate class loaders children of the same parent) without >> creating too many problems, what happens in the case of two >> interfaces with different versions? The class loading tree should (at >> this point) become very fine-grained and start building multiple >> class-loaders for multiple versions of the same interface, and then >> build as children of those class loaders for the individual blocks >> "using" them, ... > > Hmmm, are we really the first project tackling this? How did Eclipse > solved this? I'm not saying that we are the first, nor that it can't be solved. I'm just saying that the concerns are separate: a block provides generators, transformers, serializers, ... to other blocks, but those are de-coupled from the real java components (if any) doing the job. For example, a "mailprovider" implementation used for the block "sendmail" will have to provide a generator that accepts URI like "imap://user:password@server/folder/id", and generates a MimeDocument XML stream. It doesn't matter to the block what components will be used to generate the XML, I can use a single component to do this job, or I can use a virtual component calling god knows what generator and a number of different transformers to achieve the same output, it doesn't matter to the block using the interface implementation. And it shouldn't matter to the block deployment frameworks whether those components are written in Java or JavaScript or whatever... And neither it should matter what kind of Java ClassLoading components do require to be available to blocks, right? Pier