geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Move blocker GERONIMO-1960 to 1.1.1?
Date Wed, 24 May 2006 06:26:35 GMT

On May 23, 2006, at 11:04 PM, David Jencks wrote:

> +1 on excluding this from 1.1.  I agree it's not a blocker.
> I think client-corba needs a dependency on client-security, I  
> thought it was there.  I'll try to investigate on the plane tomorrow.
> I expected you to fix this by modifying the ServiceConfigBuilder to  
> check that the gbean reference was satisfied in the ancestor set  
> when it is reading the xml.  This is what the other builders do for  
> e.g. resource-refs, and I think it would be simple and non- 
> invasive.  However, in any case I don't think this is a blocker....  
> the worst that can happen is that you get an error later rather  
> than sooner, you get essentially the same effect either way.
Umm, re this comment, I should think before writing :-)

A moment's further thought reminded me that the reason we can check  
e.g. resource-refs when we process them is that we have a multistep  
process in the j2ee module builders and when we resolve the  
references we already know all the gbeans.  This is not the case for  
service modules so the verify method you added or some other way of  
introducing 2 steps would be necessary.

david jencks

> thanks
> david jencks
> On May 23, 2006, at 7:55 PM, Dain Sundstrom wrote:
>> I finished the patch for GERONIMO-1960 ( 
>> jira/browse/GERONIMO-1960), but I think it may be destabilizing  
>> and should be move to 1.1.1.
>> I added a verify method to Deployment context which is called from  
>> getConfigurationData().  This method verifies the references and  
>> dependencies on can be resolved.  I only try to resolve  
>> dependencies and single valued references. Further, only  
>> unresolved reference patterns are resolved, under the assumption  
>> that the deployer created a resolved pattern correctly.   We can  
>> not absolute references to beans in external modules.
>> A couple of the client plans threw exceptions so I had to patch  
>> them also, which is why I am concerned.  The client-security has  
>> unnecessary and possibly incorrect module declarations and the  
>> client-corba plan has a dependency on SecurityService which can't  
>> be resolved since there is no dependency on client-security.  I  
>> removed the former and commented out the latter.  I am not sure if  
>> we need the dependency on SecurityService in client-corba, and if  
>> so, I'm not sure if we can add a dependency from client-corba to  
>> client-security.  David Jencks any help here would be appreciated.
>> Anyway, I don't think this is issue actually a blocker issue, and  
>> think we can safely move it to 1.1.1 (or 1.2 if my 1.1.1 proposal  
>> flops).
>> -dain

View raw message