Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=tOiETuHl+kJigXude7k0EZaCuoNCyowqXxMyhBPweYUH0aiR1SCu1zg/7eAxa/iIvmKmDPH3dkJ8lGacB7YyxHMDjnmxIbiMWG9MbIcXl/KIhWWwZMtp8VTJiJFhMR1HjvEhd2cDuEf0Wz7KP6olDFT7AuJL3gdg8SNMGCap0h0=
  ;
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <adf34c300606101445x1fcf53ffob2c46d58e146e852@mail.gmail.com>
References: <adf34c300606101237g7f1c3dfek1b20f1dd2c8f73a6@mail.gmail.com>
 <74e15baa0606101242x2cbbd95bu8b7911df11c8a87c@mail.gmail.com>
 <adf34c300606101316i2ab1ff9qa32b0b73f9c279fa@mail.gmail.com>
 <74e15baa0606101326l3a33674emfcf9141481313edb@mail.gmail.com>
 <adf34c300606101418v3ff08e1bge7475f28ffc1c3c0@mail.gmail.com>
 <74e15baa0606101425t5c69176dga0c8638519aa8aeb@mail.gmail.com>
 <3F45D6E8-275A-4654-B82A-5DCD1F01F9FF@yahoo.com>
 <adf34c300606101445x1fcf53ffob2c46d58e146e852@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BE8C7BCC-4D7C-43C2-93BB-4C3104C2B938@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Adding new deployable module types
Date: Sat, 10 Jun 2006 15:08:50 -0700
To: user@geronimo.apache.org


On Jun 10, 2006, at 2:45 PM, Stefan Arentz wrote:

> On 6/10/06, David Jencks <david_jencks@yahoo.com> wrote:
> ...
>> > You can also package the resource and application as plugins, so  
>> they
>> > could be separate but anyone who installed the application plugin
>> > would automatically get the realm and pool and so on.
>>
>> I think the missing piece is making the stuff deployed this way
>> accessible through spring.  I think the way to to is is with spring
>> beans that look up the gbeans: then you can use spring injection to
>> get the e.g. datasource into your spring bean.
>
> What would be the advantage of talking to GBeans instead of doing a
> simple JNDI lookup?

Well,
- right now jndi is only available in j2ee apps.  Global jndi is  
expected in 1.2, but I think it's a terrible idea :-).  If you really  
want jndi, I'd work on something like the j2ee description of how to  
put stuff in java:comp
- Why would you consider using jndi when you have a dependency  
injection system available from spring?

Maybe I'm misunderstanding your question, so I'll explain how looking  
up a datasource in jndi works now:
- we bind a reference into jndi.  It contains the kernel name and  
gbean name for a ManagedConnectionFactoryWrapper gbean
- when you look up the reference, to resolve what it points to, it  
finds the gbean in the kernel and calls a method, $getResource, which  
returns (a proxy to) the connection factory.  We return the  
connection factory as the lookup result.

IIUC Spring has a way of injecting the result of calling a method on  
a spring bean as a constructor or setter parameter.  I'm thinking  
that we should have in this case a spring bean that has a method that  
delegates to the $getResource method, so you can use spring to inject  
the datasource that is set up in geronimo.

thanks
david jencks

>
> S.