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 22:44:29 GMT
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!


> 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