From dev-return-9054-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Sun Oct 03 16:21:55 2004 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 72701 invoked from network); 3 Oct 2004 16:21:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 3 Oct 2004 16:21:55 -0000 Received: (qmail 79835 invoked by uid 500); 3 Oct 2004 16:21:47 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 79799 invoked by uid 500); 3 Oct 2004 16:21:47 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@geronimo.apache.org Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 79785 invoked by uid 99); 3 Oct 2004 16:21:47 -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 [64.14.202.141] (HELO mgd.gluecode.com) (64.14.202.141) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 03 Oct 2004 09:21:44 -0700 Received: from [10.0.1.6] (ca-stmnca-cuda2-blade8b-82.stmnca.adelphia.net [68.65.226.82]) (authenticated bits=0) by mgd.gluecode.com (8.12.10/8.12.10) with ESMTP id i93GV01q016357 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 3 Oct 2004 09:31:01 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <99BB6DF2-154D-11D9-B7E9-000D93361CAA@gluecode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <507A406A-1558-11D9-B927-000D93C5B79C@gluecode.com> Content-Transfer-Encoding: 7bit From: Dain Sundstrom Subject: Re: Multiple Inheritance Date: Sun, 3 Oct 2004 09:21:43 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.619) X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I would simply put the 5 resource adapters in an EAR and then make each of the 3 applications a child of the resources EAR. Does this solution work for you? As for "during app deployment we could silently construct the RA CL for you and insert that "above" the rest of your application," I really dislike this idea. The last application server I worked on, had this type if implicit class loader manipulation which has made it usable for complex production deployments. -dain On Oct 3, 2004, at 8:29 AM, Aaron Mulder wrote: > On Sun, 3 Oct 2004, David Jencks wrote: >> I agree this is inconvenient. The solutions I know of are: >> ... > > I'm more worried about the general-purpose case where you have 5 > connectors in the server and each of 3 apps requires a different > subset of > them. I don't think there's a way to make that work with either of the > methods you suggested. You'd have to deploy each app with the > connectors > it uses and just sacrifice the potential to pool connections across > applications. > > If we were going to try to make this work, I wouldn't try to > construct an app classloader with multiple parent classloaders, I'd > instead create an "RA ClassLoader" for the app that included all the RA > JARs for all the RAs that the application depends on. So in essence, > you'd get: > > normal parent CL (o/a/g/System?) > | > App's RA CL (references JAR URLs from RAs) > | > App's normal CL > > That way the parent of the app could be whatever, and we could tell > from > the resource mappings what RA's the app requires (and perhaps let you > list > additional ones explicitly), and during app deployment we could > silently > construct the RA CL for you and insert that "above" the rest of your > application. We could do a similar thing for web apps that depend on > EJB > JARs (normal parent - RA CL - EJB CL - web app) too. That would be > nice > because it would pretty much eliminate the need to manually specify > this > ClassLoader hierarchy in your Geronimo deployment plan -- everything > could > default to the parent o/a/g/System and we'd auto-wire the obvious > dependencies and everything ought to "just work". > > Of course, I'm not sure this would really work in practice -- but > it seems like it has some potential. I'd really like to avoid needing > to > manually configure all the parentIds properly in order for your app to > work. > > Aaron > >> >> 1. make a chain Server --- Connector1 --- Connector2 --- MyApp >> >> 2. put everything (both connectors and MyApp) in an ear. >> >> I think there are 2 cases here. >> >> If you need the connector classes on the MyApp classpath, then I think >> the solutions (1,2) are sufficient. Otherwise we will have to write >> some bizarre classloader with several parent classloaders, that most >> likely won't work reliably. >> >> If you simply need the connectors started and available before MyApp >> starts, this could be taken care of by some kind of explicit >> dependency >> mechanism. So far I haven't thought of a reasonable way to do this, >> but I think it would be possible and convenient.