geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: ENC (Environment Naming Context) Question
Date Tue, 06 Mar 2007 17:06:52 GMT

On Mar 6, 2007, at 11:42 AM, Christopher M. Cardona wrote:

> David Jencks wrote:
>>
>> On Mar 5, 2007, at 4:50 AM, Christopher M. Cardona wrote:
>>
>>> Some questions about our ENC implementation:
>>>
>>> 1. How do we add/create a subcontext for "java:comp/env"? Do we  
>>> have an API for doing this? I get  
>>> javax.naming.OperationNotSupportedException when calling  
>>> createSubcontext().
>>
>> Per the spec java:comp is read-only.  The content is set up in the  
>> NamingBuilders during deployment: we construct a map of stuff,  
>> which is turned into a Context using  
>> EnterpriseNamingContext.createEnterpriseNamingContext.
>
> David,
>
> That explains it. Yes, I saw this called while debugging through  
> the deployment of a webapp. Sorry I wasn't asking the right  
> questions. What I was trying to do is bind a resource (e.g.  
> JavaMail Session or JDBC DataSource) to the global jndi during  
> deployment. I think I figured out where to do this during  
> deployment but not exactly sure which context to use for binding.  
> IIUC, we already bind something locally to the ENC so a particular  
> module can have access to it at runtime. But if we wanted another  
> module or even a standalone app (possibly a different jvm) to have  
> access to those resources we need to use the global JNDI. Is my  
> understanding correct? Am I asking the right questions here? :-)  
> Any clarification would help.

I think you are on a better track now.  Dain implemented some stuff  
that binds all connection factories to global jndi in the

sandbox/plugins/global-jndi/src/main/java/org/apache/geronimo/gjndi/ 
binding/ResourceBindings.java

file and there is some related code there too.  There are 2  
approaches I can think of for this: one is to automatically bind  
everything at locations determined from their gbean name, and the  
other is to only bind specially marked gbeans.  Dain took the first  
approach and I think it would be reasonable to start by resurrecting  
it and making it work.  I think there's something wrong with the  
current code because IIRC someone tried to use it in a 1.2 snapshot  
server and it didn't work.  However it should be fairly easy to get  
it working again.

At that point we'll have something working, you'll know how the  
pieces fit together, and we can see if we like it and if we want more  
flexibility.

thanks
david jencks



>
> Thanks,
> chris


Mime
View raw message