You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2006/09/08 15:42:00 UTC
Resolving a GBean reference
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
Re: Resolving a GBean reference
Posted by David Jencks <da...@yahoo.com>.
On Sep 8, 2006, at 7:02 PM, Rick McGuire wrote:
> 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).
I at least think I finally got it :-)
thanks for your patience :-)
david jencks
> Rick
>
>
>>
>> -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
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
Re: Resolving a GBean reference
Posted by Rick McGuire <ri...@gmail.com>.
Dain Sundstrom wrote:
> This is starting to make more sense to me. Can you point me at the
> implementation we currently have for the sun orb? Also, what is the
> information the socket factory needs from the orb?
The current implementation is
org.openejb.corba.sunorb.OrbSocketFactory. The property/argument setup
is done in org.openejb.corba.sunorb.SunOrbConfigAdapter.
For the current version, the required information is passed along by
parsing the CSSConfig/TSSConfig information and cramming the settings
into some system properties that are picked up by the socket factory
once it's instantiated. Not exactly the most thread-safe of methods.
However, in addition to the Yoko work, I'm also reworking things for
GERONIMO-2002. To implement this, the socket factories (for either ORB)
is going to need a reference to a configured KeystoreManager. This is
not easily encoded in string form, and also involves many more pieces of
information. So, rather than expand the existing processing, it seemed
better to just allow the socket factory to obtain a reference to its
instantiating GBean (either a CorbaBean or a CSSBean) and have it pull
the configuration information from the bean. This seriously simplified
things, but I still had the problem of how the socket factory manages to
obtain the object reference when the GBean does not directly instantiate
the object. I'd discussed this with David Jencks back at JavaOne, and
he recommended using the AbstractName and getBean() method. Things
finally reached the point this week where I could put this to the
test....that's when I bumped into the problem with getGBean() not
working because it was called before the doStart() method completed.
I've managed to bypass the problem by storing the GBean reference in a
static HashMap in the configurator class so that the socket factory can
request it when it's started.
Rick
>
> -dain
>
> On Sep 8, 2006, at 4:02 PM, Rick McGuire wrote:
>
>> 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).
>> Rick
>>
>>
>>>
>>> -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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Resolving a GBean reference
Posted by Dain Sundstrom <da...@iq80.com>.
This is starting to make more sense to me. Can you point me at the
implementation we currently have for the sun orb? Also, what is the
information the socket factory needs from the orb?
-dain
On Sep 8, 2006, at 4:02 PM, Rick McGuire wrote:
> 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).
> Rick
>
>
>>
>> -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
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: Resolving a GBean reference
Posted by Rick McGuire <ri...@gmail.com>.
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).
Rick
>
> -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
>>>>>
>>>>
>>>
>>>
>
>
Re: Resolving a GBean reference
Posted by Dain Sundstrom <da...@iq80.com>.
I'm more confused now... is the ORB aware of the geronimo kernel? If
not, what code is talking to the registry?
-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
>>>>
>>>
>>
>>
Re: Resolving a GBean reference
Posted by Rick McGuire <ri...@gmail.com>.
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
>>>
>>
>
>
Re: Resolving a GBean reference
Posted by David Jencks <da...@yahoo.com>.
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
>>
>
Re: Resolving a GBean reference
Posted by Dain Sundstrom <da...@iq80.com>.
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
>