Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 76663 invoked from network); 17 Feb 2006 18:51:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Feb 2006 18:51:26 -0000 Received: (qmail 31964 invoked by uid 500); 17 Feb 2006 18:51:10 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 31861 invoked by uid 500); 17 Feb 2006 18:51:10 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 31756 invoked by uid 99); 17 Feb 2006 18:51:09 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2006 10:51:09 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of timster.lists@gmail.com designates 64.233.162.203 as permitted sender) Received: from [64.233.162.203] (HELO zproxy.gmail.com) (64.233.162.203) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2006 10:51:07 -0800 Received: by zproxy.gmail.com with SMTP id r28so486188nza for ; Fri, 17 Feb 2006 10:50:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=sXRbQpccuiVw5lnuArnFSBSnmYR3EI0hk/fe4yz0ck6Dy5K05TddhXkv+NnLNIbnL0aNMRcmOtizTCsgYCBlQhMtQpjzml3x1iROi0pFsMRS9miyvk7z2JvXU8V4rTSswIt1Lav7UW8Oc+QNTsGTCsoa+yuuI0QerRo30bE/MUA= Received: by 10.36.129.13 with SMTP id b13mr2443750nzd; Fri, 17 Feb 2006 10:50:46 -0800 (PST) Received: by 10.36.56.5 with HTTP; Fri, 17 Feb 2006 10:50:46 -0800 (PST) Message-ID: <329a68be0602171050s192f7b49ub9b7622ec0cf2cc0@mail.gmail.com> Date: Fri, 17 Feb 2006 13:50:46 -0500 From: Tim Kettering To: user@geronimo.apache.org Subject: tying together various components w/ gbeans and spring? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N hi everyone.. this is more of a "lets fling this into the list and see if anyone bites" question on architectural ideas/suggestions regarding tying together an componentized application using geronimo. hopefully i dont make this too long-winded. we've been deploying our product as a single webapp on tomcat, but as things have gotten bigger and more complex, its become more bothersome for the developers to constantly have to build and redeploy the whole damn application when all they did was add a log statement to xyz class. so i've been looking into options to make the dev process easier, and also to break down the application into more modular components (ooh, a buzzword!), which is something we should be doing anyway. after looking at servicemix, i ended up at geronimo.. although they're wholly different beasts, i've started looking at geronimo more closely to see if it could become the app server of our choice. i like how it brings together ldap, jms, jta, yadda yadda under a common umbrealla... i've come up with some stuff to deploy plans, .wars and all that jazz, and i'm quite excited by the parent-child options that makes shaping the classloader hiearchy somewhat more elegantly and spiffy than the tomcat structure alone. but enough background information, now to the burning questions. lets say we have a package of core biz functionality. call it=20 foo-core.jar. it doesn't relate to the web-ui at all. i can deploy this to geronimo as a deployment plan, stick it in the classloader and give it a configuration name, then deploy a .war file as a child of that configuration and it'll pick up the classes from the parent.=20 that's rather nice. however i tried redeploying the core .jar again (while the webapp continues to run) - and it seems to shut down the child web-app when i do that. is this standard functionality? i would have expected it to reload at least. i was not able to find any documentation that covers how gbean lifecycle are affected by parent gbeans. next thing i looked at was deploying foo-core.jar wrapped around a gbean as a server module. i hooked things up so that when foo-core gets deployed, the internal spring application context in foo-core.jar is started up and initalized. my intention then was to somehow introduce that context into the webapp (and hopefully not having to use any geronimo specific stuff in the webapp code). i had been thinking something along the lines of deploying various application components as gbeans, then the webapp itself could pick up the references to those gbeans when it starts up. by components, i mean foo-core, ldap reference, a jms reference, and datasource references, to name a few. i read up on how to do dependency injection w/ gbeans - and have been able to accomplish that, but what im wondering is if anyone here has figured out a good way to get those gbeans included in a spring context that the webapp starts up as well? lets say foo-webapp has a spring context that is started up when the webapp starts up. ideally i'd like this spring context to be able to obtain the various gbeans that are set in the server and make them available as beans in the context. has anyone done this, or could anyone offer some ideas/suggestions on how that might be done? i will continue to work this angle - and share any answers i might by miracle discover, considering my very amateur understanding of this geronimo thing here. :) -tim