I have narrowed down to two approaches for persisting MdbContainer changes 1) Add a properties attribute for the OpenEJBSystemGbean and use its contents to set/override properties of all containers. This properties attribute will be used during MdbContainer creation for checking for configuration changes that were persisted.
2) Create an MdbContainer Gbean for each of the MdbContainers created. The first time an RA is created the GBean will be created and started and during subsequent startups and shutdowns it will be the Gbeans that will be creating the containers whenever RA's are initialized. I am currently planning to go with approach 1 as 2 results in a gbean getting added per RA/MdbContainer and the subsequent pollution of config.xml. Once added the entries cannot be removed also from config.xml. Also some code needs to be duplicated in the new MdbContainerGbean from OpenEJBSystem (Creation of a ReferenceCollection listener for a collection of RA's) Something else that I would need to do is to extract the interface for the EjbContainer Gbean so that I can create a proxy and set values at runtime on the the container Gbeans that will get persisted. I will attach the openejb integration changes as a separate JIRA for easier tracking and merging. Let me know if anyone has any concerns with the approach I am taking or if approach 2 looks to be better. Regards Manu On Mon, Mar 10, 2008 at 5:38 PM, Manu George <[EMAIL PROTECTED]> wrote: > I came up with a few approaches for resolving this issue > > 1) The old approach of adding a system properties GBean. However I add > it to the plan of the openejb configuration and just keep updating the > properties there > > 2) There are GBeans created for all containers other than the > MdbContainer. The Gbeans are of type EjbContainer and they have a > persistent properties attribute. The configurable values can be passed > to the container by setting these properties. However MdbContainer > doesn't have a Gbean corresponding to it. The reason for this is that > the resource adapter instance is passed to the openejb container as a > property value. So this value cannot be persisted. Also the > OpenEJBSystem GBean actually creates and destroys MdbContainers > corresponding to creation and destruction of resource adapters. The > problem with the current approach of not having GBeans for the > MdbContainer is that changes that I make to the properties object > cannot be persisted AFAIK.. So the approach is to have a Gbean for > MdbContainers also which actually registers a lifecycle listener to > create the container when the corresponding RA is created(Move from > the OpenEJBSystem Gbean). This will require me to extend the current > EjbContainer Gbean as well as make its attributes protected instead of > private. > > 3) I can do whatever is done currently. However during creation of the > MdbContainer I also create a gbean of the same name that will persist > the property changes that need to be made to the container. The > properties can then be read and passed in to the container during > creation. The non persistable properties like RA instance etc can also > be obtained from geronimo and passed to the container during creation. > > 4) The current approach is to have a Gbean per container. Instead of > that we have a Gbean per type of container. The Gbean will actually > store the configuration parameters of each of the containers and > instantiate each of them at startup. This will enable multiple > containers to be created at runtime without requiring a new Gbean for > each container. Currently also there is no GBean for the MdbContainer. > The disadvantage here is that there won't be gbeans for each > container. Now this will enable the provision of the functionality to > add containers via the console. By default all the EJB's deployed will > go to the default containers. A provision can be made in > openejb-jar.xml to map the Ejbs to different containers. Before that > is done we can still use this feature using geronimo-openejb.xml. For > MdbContainers the Gbean will need to register lifecycle listeners. > > Which one do you feel is the better approach? Any other suggestions? > > Regards > Manu > > > > On Sat, Mar 8, 2008 at 3:54 AM, Manu George <[EMAIL PROTECTED]> wrote: > > Hi David, > > > > Currently Openejb standalone only allows you to set the configurations > > at the container level. > > Currently openejb standalone accepts these configuration values at the > > constructor of the container. In standalone I believe that you can > > have different Mdb Containers with different configurations. There is > > no limitation there as we can map different ejbs to different > > containers. You can also pass these values via a properties object or > > via system properties. Also standalone has configuration files for > > this too. > > > > Currently in Geronimo there is a wrapper Gbean created for all > > containers other than the Mdb Container and that wrapper Gbean has a > > properties attribute wherein we can pass these values. However there > > is no wrapper Gbean for the MdbContainers created as they are created > > dynamically one for each resource adapter. The properties are set > > during creation and openejb when creating the container will use these > > property values. To override these values we can always set system > > property values which have the highest priority. > > > > Yes so we need to setup different containers for different > > configurations. However for Mdbs with geronimo a container is created > > per RA. I am also not yet sure whether we can deploy ejbs to different > > other types containers in geronimo also using openejb-jar.xml. I think > > that it is possible only via geronimo-openejb.xml(May be wrong here. > > Someone correct me if we can specify which container an ejb must be > > depoyed in openejb-jar.xml :) ). If this is correct then maybe we need > > to add that flexibility in the openejb-jar.xml plan and maybe add the > > capability to add new containers in the portlet. This will provide > > full flexibility in a more user friendly way. > > > > Regards > > Manu > > > > > > > > > > On Fri, Mar 7, 2008 at 1:36 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > > > > > On Mar 7, 2008, at 12:42 PM, Manu George wrote: > > > > > > > Hi > > > > Yes that may be possible to do. I can set the properties > > > > directly in the Gbeans for each container. The problem here is that > > > > there is no Gbean corressponding to the MdbContainer as it is > > > > dynamically created for each resource adapter in the > > > > addResourceAdapter method of OpenEjbSystemGBean. I need the changes I > > > > make to be persistable as that they are applied on server restart. > > > > Maybe I can add one more attribute for MdbContainer properties to the > > > > OpenEjbSystemGBean and edit them from the portlet. But is adding a > new > > > > attribute to the OpenEjbSystemGBean acceptable? > > > > > > two question, no? > > > > > > - IIRC you can make the gbean attribute changes persistent by calling > > > kernel.setAttribute(...) I think this happens if you get a proxy to > > > the gbean. I think there are some classes like > > > KernelManagementHelper that show how to do this. > > > - I'd expect we'd want the ability to configure different mdbs > > > differently, just as IIUC you can set up lots of StatelessContainers > > > with different configs and use them. How does openejb standalone > > > solve this problem for mdbs? I'd hate to put ourselves in a box > > > without understanding the whole situation. > > > > > > thanks > > > david jencks > > > > > > > > > > > > > > > > > Regards > > > > Manu > > > > > > > > On Fri, Mar 7, 2008 at 9:03 PM, David Jencks > > > > <[EMAIL PROTECTED]> wrote: > > > >> IIUC (I didn't look too hard) this is using system properties to > > > >> configure openejb? Or at least storing override values in a system > > > >> properties gbean? I wonder if there is a way to hook more directly > > > >> into the openejb configuration mechanism. I'm not sure where the > > > >> openejb internal configuration files are now but maybe they could > be > > > >> located in var/openejb or var/config and modified directly? > > > >> > > > >> thanks > > > >> david jencks > > > >> > > > >> > > > >> > > > >> On Mar 7, 2008, at 12:21 AM, Vamsavardhana Reddy (JIRA) wrote: > > > >> > > > >>> > > > >>> [ https://issues.apache.org/jira/browse/GERONIMO-3811? > > > >>> page=com.atlassian.jira.plugin.system.issuetabpanels:comment- > > > >>> tabpanel&focusedCommentId=12576071#action_12576071 ] > > > >>> > > > >>> Vamsavardhana Reddy commented on GERONIMO-3811: > > > >>> ----------------------------------------------- > > > >>> > > > >>> The patch seems to be adding a SystemProperties GBean to j2ee- > > > >>> server config. Can this GBean be added to openejb config instead? > > > >>> > > > >>>> EjbServer portlet > > > >>>> ----------------- > > > >>>> > > > >>>> Key: GERONIMO-3811 > > > >>>> URL: https://issues.apache.org/jira/browse/ > > > >>>> GERONIMO-3811 > > > >>>> Project: Geronimo > > > >>>> Issue Type: New Feature > > > >>>> Security Level: public(Regular issues) > > > >>>> Components: OpenEJB > > > >>>> Environment: All > > > >>>> Reporter: Manu T George > > > >>>> Attachments: g3811_r632068.patch, g3811_r634213.patch, > > > >>>> openejb.zip, screenshot-1.jpg, screenshot-2.jpg > > > >>>> > > > >>>> > > > >>>> A portlet to show information about the OpenEJB container > > > >>>> integrated in Geronimo. It should also allow configuration of some > > > >>>> parameters like pool size etc > > > >>> > > > >>> -- > > > >>> This message is automatically generated by JIRA. > > > >>> - > > > >>> You can reply to this email to add a comment to the issue online. > > > >>> > > > >> > > > >> > > > > > > > > >
