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.
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 :-)
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.
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
