geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
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  
> <> 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 file? If not
> the changes will be lost on server shutdown.

The method is  
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  

> 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 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
> if required.

see comment above.

hope this helps
david jencks

> Regards
> Manu

View raw message