Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@jakarta.apache.org Received: (qmail 65887 invoked by uid 500); 12 Oct 2001 10:35:18 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: "Avalon Development" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 65870 invoked from network); 12 Oct 2001 10:35:17 -0000 Message-ID: <3BC6C71E.6070100@yahoo.com> Date: Fri, 12 Oct 2001 11:34:06 +0100 From: Paul Hammant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: Avalon Development Subject: Re: phoenix use question with catalina/bay & cocoon References: <5.1.0.14.0.20011011145229.01b87e78@pop> 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 Peter Royal wrote: > I looked at the Bay wrapper for Catalina, but I don't see any easy way > to pass information into webapps. I'm thinking maybe the parent > ComponentManager support that was added to Cocoon might be what I'm > looking for? But it seems to just allow you to define a class to be > instantiated. I'm not quite sure how it can "reach out" into the > phoenix world that contains it. I've not really finished it yet. When it is it should expose an interface that would allow blocks to depend on it and add hosts and webapps/war files. It should be quite good. It still won't help in your communication with Coocoon using RMI. Cocoon is not a block in it's own right *yet*. I guess if it was it would also solve your problem. I've talked to Berin about this and he thinks that it could, in the future, be a block as well as a WAR file deployable app. Regards, - Paul H --------------------------------------------------------------------- To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: avalon-dev-help@jakarta.apache.org