You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Sachin Patel <sp...@gmail.com> on 2005/10/23 04:05:13 UTC

loading gbeans

Is there a way to load a "loaded configuration's" gbeans' without 
starting the configuration?  I'm basically wanting query a gbean's 
persistent attribute value on a loaded but not started configuration.  
Looking through the code the configuration's gbeans are loaded only 
after its containing configuration is started

kernel.startGBean(configName);
kernel.invoke(configName, "loadGBeans", new Object[] {attributeStore}, 
new String[] {ManageableAttributeStore.class.getName()});

This makes sense, but I'm wondering if there is an alternate way to get 
the gbeans attribute values on an already deployed and serialized 
configuration.

???

Sachin

Re: loading gbeans

Posted by Sachin Patel <sp...@gmail.com>.
Sending again.. (sorry if dup reply)

David Jencks wrote:
starts the configuration gbean, but
> not the gbeans in the configuration
> configurationManager.loadGBeans(myURI);  //loads but does not start the 
> gbeans in the configuration

Doh! must have overlooked that API.

> 
> will load the configuration whose ID is myURI, and then load but not 
> start the gbeans in the configuration, so you won't get any port 
> conflicts.  Starting the configuration 
> (configurationManager.start(myURI) will load and start the gbeans in the 
> configuration: you don't want to do this.
> 
> Second, does jmx remoting use the jndi naming port?  I keep getting 
> confused about which port jmx remoting connects to.

I thought so... but now I'm 100% sure myself.  :)   In the wiki  it does....

deployer:geronimo:jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector 
(which by the way the path is incorrect)

but in my eclipse tooling code... the uri I have is

deployer:geronimo:jmx:rmi://localhost/jndi/rmi:/JMXConnector

So I'm wondering now myself how its connecting to the correct port, or 
if not specified it just happens to be defaulting to 1099.

Sachin

Re: loading gbeans

Posted by Sachin Patel <sp...@gmail.com>.

David Jencks wrote:
> First of all...
> 
> configurationManager.load(myURI);  //starts the configuration gbean, but 
> not the gbeans in the configuration
> configurationManager.loadGBeans(myURI);  //loads but does not start the 
> gbeans in the configuration

Doh! must have overlooked that API.

> 
> will load the configuration whose ID is myURI, and then load but not 
> start the gbeans in the configuration, so you won't get any port 
> conflicts.  Starting the configuration 
> (configurationManager.start(myURI) will load and start the gbeans in the 
> configuration: you don't want to do this.
> 
> Second, does jmx remoting use the jndi naming port?  I keep getting 
> confused about which port jmx remoting connects to.

I thought so... but now I'm 100% sure myself. :)  In the wiki  it does....

deployer:geronimo:jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector 
(which by the way the path is incorrect)

but in my eclipse tooling code... the uri I have is

deployer:geronimo:jmx:rmi://localhost/jndi/rmi:/JMXConnector

So I'm wondering now myself how its connecting to the correct port, or 
if not specified it just happens to be defaulting to 1099.

> 
> thanks
> david jencks
> 
> 

Re: loading gbeans

Posted by David Jencks <da...@yahoo.com>.
this time I'll respond before hitting send :-(
On Oct 23, 2005, at 8:10 PM, Sachin Patel wrote:

>
>
> David Jencks wrote:
>> On Oct 22, 2005, at 7:05 PM, Sachin Patel wrote:
>>> Is there a way to load a "loaded configuration's" gbeans' without 
>>> starting the configuration?  I'm basically wanting query a gbean's 
>>> persistent attribute value on a loaded but not started 
>>> configuration.  Looking through the code the configuration's gbeans 
>>> are loaded only after its containing configuration is started
>>>
>>> kernel.startGBean(configName);
>>> kernel.invoke(configName, "loadGBeans", new Object[] 
>>> {attributeStore}, new String[] 
>>> {ManageableAttributeStore.class.getName()});
>>>
>>> This makes sense, but I'm wondering if there is an alternate way to 
>>> get the gbeans attribute values on an already deployed and 
>>> serialized configuration.
>> I don't think we can do better at this point.  There is no limit on 
>> the complexity of attribute values, and the only restriction other 
>> than serializablitly is that classes used must be loadable by the 
>> configuration's classloader.  This classloader is only available when 
>> the configuration gbean is started.
>> If you're willing to use the kernel methods directly rather than the 
>> methods on ConfigurationManager (I recommend sticking to using the 
>> ConfigurationManager) you could pass your own 
>> ManageableAttributeStore in that gets all the gbean datas and return 
>> an empty list.  This would result in you getting the gbean datas and 
>> no gbeans getting loaded.
>> Why do you want to avoid loading the gbeans?
>
> Well I was looking into the shutdown script a little this weekend and 
> we need to be able to shutdown the correct kernel if multiple server 
> instances are running.  In order to do so we need to get the correct 
> port number from the RMIRegistry gbean in order to be able to connect 
> to and shutdown the correct kernel.  So I launched a temp kernel and 
> loaded the RMINamingConfiguration.  From there, starting that 
> configuration fails since the RMIRegistry gbean's port number is 
> already in use.  So I was looking a way to bypass starting the 
> configuration and to just be able to load that particular gbean and 
> get its "port" attribute.  From there I can put togather the correct 
> uri, create a kernel delegate and shut it down.

First of all...

configurationManager.load(myURI);  //starts the configuration gbean, 
but not the gbeans in the configuration
configurationManager.loadGBeans(myURI);  //loads but does not start the 
gbeans in the configuration

will load the configuration whose ID is myURI, and then load but not 
start the gbeans in the configuration, so you won't get any port 
conflicts.  Starting the configuration 
(configurationManager.start(myURI) will load and start the gbeans in 
the configuration: you don't want to do this.

Second, does jmx remoting use the jndi naming port?  I keep getting 
confused about which port jmx remoting connects to.

thanks
david jencks


Re: loading gbeans

Posted by David Jencks <da...@yahoo.com>.
On Oct 23, 2005, at 8:10 PM, Sachin Patel wrote:

>
>
> David Jencks wrote:
>> On Oct 22, 2005, at 7:05 PM, Sachin Patel wrote:
>>> Is there a way to load a "loaded configuration's" gbeans' without 
>>> starting the configuration?  I'm basically wanting query a gbean's 
>>> persistent attribute value on a loaded but not started 
>>> configuration.  Looking through the code the configuration's gbeans 
>>> are loaded only after its containing configuration is started
>>>
>>> kernel.startGBean(configName);
>>> kernel.invoke(configName, "loadGBeans", new Object[] 
>>> {attributeStore}, new String[] 
>>> {ManageableAttributeStore.class.getName()});
>>>
>>> This makes sense, but I'm wondering if there is an alternate way to 
>>> get the gbeans attribute values on an already deployed and 
>>> serialized configuration.
>> I don't think we can do better at this point.  There is no limit on 
>> the complexity of attribute values, and the only restriction other 
>> than serializablitly is that classes used must be loadable by the 
>> configuration's classloader.  This classloader is only available when 
>> the configuration gbean is started.
>> If you're willing to use the kernel methods directly rather than the 
>> methods on ConfigurationManager (I recommend sticking to using the 
>> ConfigurationManager) you could pass your own 
>> ManageableAttributeStore in that gets all the gbean datas and return 
>> an empty list.  This would result in you getting the gbean datas and 
>> no gbeans getting loaded.
>> Why do you want to avoid loading the gbeans?
>
> Well I was looking into the shutdown script a little this weekend and 
> we need to be able to shutdown the correct kernel if multiple server 
> instances are running.  In order to do so we need to get the correct 
> port number from the RMIRegistry gbean in order to be able to connect 
> to and shutdown the correct kernel.  So I launched a temp kernel and 
> loaded the RMINamingConfiguration.  From there, starting that 
> configuration fails since the RMIRegistry gbean's port number is 
> already in use.  So I was looking a way to bypass starting the 
> configuration and to just be able to load that particular gbean and 
> get its "port" attribute.  From there I can put togather the correct 
> uri, create a kernel delegate and shut it down.
>
>
>
>> thanks
>> david jencks
>>>
>>> ???
>>>
>>> Sachin
>>>
>


Re: loading gbeans

Posted by Sachin Patel <sp...@gmail.com>.

David Jencks wrote:
> 
> On Oct 22, 2005, at 7:05 PM, Sachin Patel wrote:
> 
>> Is there a way to load a "loaded configuration's" gbeans' without 
>> starting the configuration?  I'm basically wanting query a gbean's 
>> persistent attribute value on a loaded but not started configuration.  
>> Looking through the code the configuration's gbeans are loaded only 
>> after its containing configuration is started
>>
>> kernel.startGBean(configName);
>> kernel.invoke(configName, "loadGBeans", new Object[] {attributeStore}, 
>> new String[] {ManageableAttributeStore.class.getName()});
>>
>> This makes sense, but I'm wondering if there is an alternate way to 
>> get the gbeans attribute values on an already deployed and serialized 
>> configuration.
> 
> I don't think we can do better at this point.  There is no limit on the 
> complexity of attribute values, and the only restriction other than 
> serializablitly is that classes used must be loadable by the 
> configuration's classloader.  This classloader is only available when 
> the configuration gbean is started.
> 
> If you're willing to use the kernel methods directly rather than the 
> methods on ConfigurationManager (I recommend sticking to using the 
> ConfigurationManager) you could pass your own ManageableAttributeStore 
> in that gets all the gbean datas and return an empty list.  This would 
> result in you getting the gbean datas and no gbeans getting loaded.
> 
> Why do you want to avoid loading the gbeans?

Well I was looking into the shutdown script a little this weekend and we 
need to be able to shutdown the correct kernel if multiple server 
instances are running.  In order to do so we need to get the correct 
port number from the RMIRegistry gbean in order to be able to connect to 
and shutdown the correct kernel.  So I launched a temp kernel and loaded 
the RMINamingConfiguration.  From there, starting that configuration 
fails since the RMIRegistry gbean's port number is already in use.  So I 
was looking a way to bypass starting the configuration and to just be 
able to load that particular gbean and get its "port" attribute.  From 
there I can put togather the correct uri, create a kernel delegate and 
shut it down.



> 
> thanks
> david jencks
> 
>>
>> ???
>>
>> Sachin
>>
> 
> 

Re: loading gbeans

Posted by David Jencks <da...@yahoo.com>.
On Oct 22, 2005, at 7:05 PM, Sachin Patel wrote:

> Is there a way to load a "loaded configuration's" gbeans' without 
> starting the configuration?  I'm basically wanting query a gbean's 
> persistent attribute value on a loaded but not started configuration.  
> Looking through the code the configuration's gbeans are loaded only 
> after its containing configuration is started
>
> kernel.startGBean(configName);
> kernel.invoke(configName, "loadGBeans", new Object[] {attributeStore}, 
> new String[] {ManageableAttributeStore.class.getName()});
>
> This makes sense, but I'm wondering if there is an alternate way to 
> get the gbeans attribute values on an already deployed and serialized 
> configuration.

I don't think we can do better at this point.  There is no limit on the 
complexity of attribute values, and the only restriction other than 
serializablitly is that classes used must be loadable by the 
configuration's classloader.  This classloader is only available when 
the configuration gbean is started.

If you're willing to use the kernel methods directly rather than the 
methods on ConfigurationManager (I recommend sticking to using the 
ConfigurationManager) you could pass your own ManageableAttributeStore 
in that gets all the gbean datas and return an empty list.  This would 
result in you getting the gbean datas and no gbeans getting loaded.

Why do you want to avoid loading the gbeans?

thanks
david jencks

>
> ???
>
> Sachin
>