geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Improved EJB integration... can we get some portlets?
Date Fri, 10 Oct 2008 16:17:13 GMT

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  
> <david_jencks@yahoo.com> 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


Mime
View raw message