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.
> 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.
> 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 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.
Regards
Manu
