Hi David,
Thank you for the response. It was very helpful.
Comments inline
On Fri, Oct 10, 2008 at 9:47 PM, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Oct 10, 2008, at 5:17 AM, Manu George wrote:
>
>> Hi David,
>> Thanks for replying. I have put a few questions/comments
>> inline below
>>
>> On Wed, Oct 8, 2008 at 10:09 PM, David Jencks <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Oct 8, 2008, at 7:42 AM, Manu George wrote:
>>>
>>
>>>
>>> To me it looks like you are basically proposing a plan editor or
>>> config.xml
>>> editor for openejb. You can't safely change the actual attribute values
>>> at
>>> runtime so lets look for a solution that doesn't pretend to be able to.
>>>
>>> I think you have three possible strategies here:
>>>
>>> 1. create a plan editor for plans similar to the openejb plugin and use
>>> it
>>> to generate replacements for the openejb plugin
>>
>> Generating an entire new plugin, and installing it seems to be a lot
>> of work for the user for just changing configuration parameters. A
>> restart of the openejb configuration looks to be simpler. Another
>> factor here is that there is no mention of the MdbContainer in the
>> plan as it is generated dynamically for the RA. So such an editor
>> won't show the Mdb Container properties.
>
> I'm not sure whether to regard creating a new plugin as a significant step
> or not. I think most of us are thinking of it as a larger bit of work than
> it is.
>
> The mdb configuration seems to be a sticky point everywhere. I don't really
> know what is available to configure on it. If the "knobs" you can turn are
> the same for all inbound resource adapters then perhaps we need a
> mdbtemplate gbean with named attributes for them, that provides the defaults
> for and MDBContainers we create for specific mdbs.
>
>>
.There is only 1 knob i.e instanceLimit and it is common. The Mdb
Containers are created in the openejb system gbean. So I added a
properties attribute there to store the customized values with mdb
container name as key.
>>
>>> 2. create an editor for specified customizations of config.xml. This
>>> might
>>> or might not be practical. It's more likely to work if the openejb
>>> plugin
>>> is stopped when you edit gbean attribute values.
>>
>> If I do stop the openejb configuration then would I be able to edit
>> the gbean attributes? After all they are final and would have already
>> been intialized. I am assuming that even before a gbean is started
>> its constructor is called. (GBean Loading Stage).
>> Another issue here is since the portlet should depend on the openejb
>> configuration it will also get stopped and removed from the admin
>> console if I stop the openejb configuration.
>>
>> I am unable to change the attributes of the gbean at runtime as all
>> the fields are final and there are no setter methods. However if I
>> have setter methods then i would be able to set the attributes at
>> runtime to the gbean. However the ejb containers will need to be
>> reinitialized which needs a restart of the openejb container system.
>> We can prompt the user to restart the openejb configuration.
>
> Stopping a gbean discards the gbean object instance. You're left with the
> GBeanData which is basically a map holding attribute values. This you can
> definitely edit.
>
> Any kind of configuration facility like this would not require the openjeb
> plugin to be started, just loaded. You can specify a
> <import>classes</import> dependency on openejb to get this, just like the
> openejb-deployer plugin does. This would let you cycle the openejb plugin
> while the console is running. (Obviously this won't work for a jetty/tomcat
> console plugin :-)
>
I am writing a jetty/tomcat plugin. I will externalize the
configurable properties to config-substitutions.properties.
However on editing I plan to edit the config.xml. The reason for this
is that later I plan to add the ability to create containers
dynamically and to configure them using the console. This will be
useful if u want some stateless beans to have say a different pool
size than others and so forth. In that case i would need to generate
keys for config-substitution.properties for each new container. So I
am planning on directly editing the config.xml in which case its not
required to have any configuration info in the plugin as u mentioned
>>
>>
>>> 3. put all the things you want to be able to change into
>>> config-substitutions as variables and edit those (in the in-memory map
>>> accessible through (????) ArtifactResolver).
>>
>> This sounds interesting. How can I access this inMemoryMap (not yet
>> figured out) and will the changes to the Map be persisted to the
>> config.xml file or the config-substitutions.properties file? If not
>> the changes will be lost on server shutdown.
>
> The method is
> org.apache.geronimo.system.configuration.PluginAttributeStore.addConfigSubstitutions(Properties
> properties) which is implemented in LocalAttributeManager. You can't read
> the values here but you might be able to get them from the gbean. This is a
> little odd because the openejb console plugin will need to know the names of
> the config-subst. variables used in the config.xml bit: I normally think of
> this as a configuration detail rather than something that is hardcoded.
> Maybe this is not a big problem.
>
Thanks for the pointer and explanation. I found the method I need i.e
ManageableAttributeStore.setValue on going through the interface u
mentioned. and it also helped me gain a new understanding of Attribute
management in G.
>>
>>
>> The other issue here is that the Mdb Containers are created
>> dynamically for each RA. So its not possible to make entries for these
>> in config-substitution.properties. However I can add a properties
>> attribute to the OpenEJBSystemGBean and during container creation
>> check it for custom values. I can then externalize this to
>> config-substitution.properties if required.
>>
>
> see comment above.
>
> hope this helps
> david jencks
>
>> Regards
>> Manu
>
>
Thanks
Manu
