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: Resolving a GBean reference
Date Fri, 08 Sep 2006 22:30:06 GMT
I don't follow this at all.  What gbean is creating the orb?  Do I  
understand correctly that the ssl info can be in either a CorbaBean  
or a CSSBean?  Can these gbeans create the socket factory and  
whatever needs it get it from them using a reference from that "X"  
bean to the CorbaBean/CSSBean?  It sounds like there's a circular  
dependency but I don't see what the dependency of the CorbaBean/ 
CSSBean is on.

thanks
david jencks

On Sep 8, 2006, at 2:25 PM, Dain Sundstrom wrote:

> I'm not sure I totally follow this, but is sounds like a classic  
> circular dependency problem.
>
> To start with using KernelRegistry.getSingleKernel() or looking up  
> references via getGBean are both highly discouraged.  It is better  
> use either a GBean reference or to pass a reference to 'this' to  
> the corba socket factory in the doStart method (you should never  
> publish a public 'this' reference from a constructor).
>
> In this case can we change the socket factory so it has a create  
> method taking the orb or a create method that takes the information  
> it extracts from the orb?
>
> -dain
>
> On Sep 8, 2006, at 6:42 AM, Rick McGuire wrote:
>
>> I think I've run into a classic chicken-and-egg problem trying to  
>> get yoko hooked into Geronimo.
>>
>> Let me recap the situation first, and the consensus solution we  
>> came up with earlier.  To fully enable the SSL transport for Yoko,  
>> it's necessary to cause Yoko to load a socket factory object that  
>> will be used to sort out what sort of sockets need to get created  
>> for a given connection situation.  This socket factory needs  
>> access to information held by the creating CORBABean or CSSBean  
>> object.  The socket factory is enabled by setting an argument on  
>> the call to ORB.init() to identify the name of the socket factory  
>> class, and there's an additional optional argument that can  
>> contain a single string value that's passed to the socket  
>> factory's init() method.
>>
>> So, to hook the socket factory back to the launching CORBABean or  
>> CSSBean object, the socket factory argument value is set to the  
>> abstract name for the associated bean instance, and the socket  
>> factor init() method retrieves the reference using:
>>             Kernel kernel = KernelRegistry.getSingleKernel();
>>             config = (ORBConfiguration)kernel.getGBean(new  
>> AbstractName(new URI(configName)));
>>
>> I'm getting the ORB launched, the socket factory class is getting  
>> loaded and the init() is failing with the following exception:
>>
>>    java.lang.IllegalStateException: GBean is not running:      
>> org.apache.geronimo.configs/j2ee-corba/1.2-SNAPSHOT/car? 
>> ServiceModule=org.apache.geronimo.configs/j2ee-corba/1.2-SNAPSHOT/ 
>> car,j2eeType=CORBABean,name=Server
>>
>>
>> In the calling sequence, the ORB is initialized in the CORBABean  
>> or CSSBean doStart() method, so these beans are not yet in a  
>> started state when the socket factory gets initialized.  I'm  
>> unable to delay resolution of the bean because the first actions  
>> required of the socket factory occur before the doStart() methods  
>> return.
>> The best solution I've come up thus far would be to keep a private  
>> registry of the beans in the ORBConfigAdapter class as static  
>> methods, and have the SocketFactory use that to retrieve the  
>> reference.  I'd rather not resort to that if there is a better  
>> solution.
>>
>> Rick
>>
>


Mime
View raw message