geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Resolving a GBean reference
Date Fri, 08 Sep 2006 23:02:30 GMT
Dain Sundstrom wrote:
> I'm more confused now... is the ORB aware of the geronimo kernel?  If 
> not, what code is talking to the registry?
Only the socket factory is aware of the geronimo kernel.  This is a 
pluggable bit of code that is configured by specifying a special 
argument on ORB.init().  Both Yoko and the Sun ORB have a similar 
facility in that regard.  The ORB instantiates an instance of the 
specified class and plugs it in as the provider that creates the sockets 
used for the connections.  The socket factory, once created, needs some 
configuration info that's held in the GBean that created the ORB 
instance.  Unfortunately, there's no way to pass object references 
through the interface used to create an ORB instance...we're limited to 
string arguments and properties (and again, I have the same problem with 
the Sun ORB as well). 


> -dain
> On Sep 8, 2006, at 3:44 PM, Rick McGuire wrote:
>> David Jencks wrote:
>>> 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.
>> The ORB instantiates the socket factory, based on arguments passed in 
>> to ORB.init(), so there's no way to get a reference to the factory 
>> after the ORB is created.  The ORB instances are created by the 
>> doStart() methods of either a CorbaBean or CSSBean, which tells the 
>> ORB to create a socket factory instance.  The only information I'm 
>> able to pass into the socket factory instance is a single string 
>> value.  I was passing the abstract name of the instantiating GBean, 
>> which I was then attempting to retrieve using kernel.getGBean().  
>> Unfortunately, since the ORB is getting initialized by the bean's 
>> doStart() method, the bean is not yet active, and not retrievable.
>> I managed to get around this problem by creating a registry in the 
>> class that configures and creates the ORBs.  The socket factory calls 
>> back to that registry to retrieve the reference, and everything works 
>> fine from there.  This afternoon, I managed to successfully start the 
>> j2ee-corba module using the Yoko ORB.  That means we're successfully 
>> launching the transient name service plus 2 ORBs (one using plain 
>> sockets, one using SSL).  I immediately found a problem with stopping 
>> the module, but it's nice to actually report progress!
>> Rick
>>> 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

View raw message