From dev-return-11312-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Wed Feb 02 15:58:07 2005 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 95968 invoked from network); 2 Feb 2005 15:58:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 2 Feb 2005 15:58:02 -0000 Received: (qmail 55138 invoked by uid 500); 2 Feb 2005 15:57:57 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 55029 invoked by uid 500); 2 Feb 2005 15:57:57 -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 55012 invoked by uid 99); 2 Feb 2005 15:57:56 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from jetty3.inetu.net (HELO jetty3.inetu.net) (209.235.255.182) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 02 Feb 2005 07:57:55 -0800 Received: (qmail 67732 invoked from network); 2 Feb 2005 15:57:52 -0000 Received: from host217-42-73-28.range217-42.btcentralplus.com (HELO ?192.168.0.4?) (jules@217.42.73.28) by jetty3.inetu.net with AES256-SHA encrypted SMTP; 2 Feb 2005 15:57:52 -0000 Message-ID: <4200F7A4.90103@coredevelopers.net> Date: Wed, 02 Feb 2005 15:54:12 +0000 From: Jules Gosnell User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read) References: <41F985BC.2060303@coredevelopers.net> <41FA0EE3.70402@cakesolutions.net> <41FA17C2.2080705@cakesolutions.net> <41FA27C6.2040005@coredevelopers.net> <41FA60AF.9010909@coredevelopers.net> <41FA6E6A.3050006@apache.org> <41FA708C.3050007@cakesolutions.net> <488CDCAD-716F-11D9-9297-000D93C5B79C@gluecode.com> <41FAB054.5070603@coredevelopers.net> <41FAB467.5070201@cakesolutions.net> <420039B0.3080009@coredevelopers.net> <4200AEB2.2090905@cakesolutions.net> <4200B4A1.1040208@coredevelopers.net> <4200BA4A.1050001@cakesolutions.net> <4200BFFE.3030807@coredevelopers.net> In-Reply-To: <4200BFFE.3030807@coredevelopers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Jules Gosnell wrote: > Rob Harrop wrote: > >> Jules, >> >> The Spring config file does not change when new modules are added, it >> is generic enough to support most configuration options. For JMX >> metadata we currently use interfaces or source level metadata >> (Commons Attributes or Annotations). I am working on an XML-based JMX >> descriptor, but this is separate from the core config file. You can >> hook into the JMX registration process by implementing the >> RegistrationStrategy interface and you can then transform the MBean >> into a GBean. The MBeans we use are ModelMBeans so you can get all >> the metadata from that. >> > Excellent :-) > > I am just putting in a placeholder POJOGBean that wraps each POJO, but > the API is simply that of GBean (i.e. has one accessor getPeer()) at > the moment - I have to look into how we can dynamically declare an > interface's metadata to the kernel... I'm looking at how I can interface a POJO with the Geronimo kernel. GBeanInstance has a concept of 'target' (see getTarget()) which GBeanAttributes and Operations seem to use to retrieve the object on which to act. So, this is good - I just need to make GBeanInstance wrap a ready made object (my POJO) instead of constructing another one... However, the GBeanInstance ctor insists on creating a new object from scratch - no good if I want to just proxy one already existing in Spring.... (unless I add yet another layer of wrapping, which is not ideal). So, I guess I am looking at altering or subclassing GBeanInstance to allow the passing in of an object to be wrapped and extending the Kernel with a method to loadGBean() around an already existing object. Are the people who know about how the kernel works happy with this solution, or have I missed another way of achieving this ? Are you happy for me to put this in, or would you like to do this yourselves ? Cheers, Jules > > Jules > >> Rob >> >> Jules Gosnell wrote: >> >>> Rob Harrop wrote: >>> >>>> Jules, >>>> >>>> I think it is best to keep the metadata in geronimo-spring.xml, >>>> purely because spring.xml has no support for modifying the XML >>>> format. You want that to be a standard Spring config with no >>>> special features. >>>> >>> I though you might say that :-) >>> >>> We will end up with an xdoclet template to generate a >>> geronimo-spring.xml with metadata about classes and methods that >>> need exposing and keep it in sync with the code.... - maybe this can >>> be done via source-level attributes... >>> >>> Does Spring not have any tag (or requirement for one - e.g. for JMX >>> exporting), which, in a Geronimo context, might be overloaded to >>> mean "export to Geronimo kernel" rather than just "export to JMX >>> Agent" ? i.e. just "export to relevant infrastructure". >>> >>>> From a Spring perspective, the two things we need are JMX-exposed >>>> POJOs, which we can already do, and a JNDI-bound ApplicationContext >>>> which will allow for transparent merging of shared services into an >>>> application. >>> >>> >>> >>> >>> The more I'm learning about this stuff, the less straightforward it >>> is becoming :-( >>> >>> It doesn't seem enough to just expose POJOs to JMX, since Geronimo >>> doesn't necessarily use it - we have to expose ourselves to the >>> kernel as GBeans, which means that the Spring JMX support needs to >>> kick out something which can be transformed into/look like a GBean >>> description, or we need to build it from the ground up. >>> >>> Re JNDI - from what David is saying, it looks like being a >>> well-named GBean may be enough to get us published via JNDI. I will >>> investigate this more today. >>> >>> Happy hacking ;-) >>> >>> Jules >>> >>>> >>>> Rob >>>> >>>> Jules Gosnell wrote: >>>> >>>>> >>>>> I've taken all of the points raised on board and just checked in >>>>> the second cut, which splits Spring support into runtime and >>>>> deploy time components. >>>>> >>>>> I'm still having trouble getting the Builder spotted by the >>>>> Deployer, but as long as I run the DebugConsole config aswell I am >>>>> OK - I'll look further into it when the dust dies down. >>>>> >>>>> If anyone wants to take another look at the code and comment (yeah >>>>> - I know it's ugly at the moment) that would be gratefully received. >>>>> >>>>> Rob, what are your thoughts on publishing POJOs to the Geronimo >>>>> kernel ? Do we just blindly export all of them, can you attach >>>>> metadata in the spring.xml or source, or do you think it should go >>>>> in the geronimo-spring.xml. >>>>> >>>>> Logically, I think it should go in the latter, however, >>>>> pragmatically, this will lead to a maintenance nightmare as >>>>> spring.xml moves on and geronimo-spring.xml fossilises, so I would >>>>> rather see a single descriptor... - I guess we could do both ? >>>>> >>>>> Anyone have any interesting thoughts ? >>>>> >>>>> Jules >>>>> >>>>> >>> >>> > > -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /********************************** * Jules Gosnell * Partner * Core Developers Network (Europe) * * www.coredevelopers.net * * Open Source Training & Support. **********************************/