You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Manu George <ma...@gmail.com> on 2008/10/03 12:16:02 UTC
Re: Improved EJB integration... can we get some portlets?
Hi David,
What is the accessTimeout attribute of the BmpContainerGBean
for? It seems to map to poolSize. You are doing a
set("AccessTimeout", Integer.toString(accessTimeout)); but there
doesn't seem to be such a property in EntityContainer.
Shouldn't this property be poolSize?
Regards
Manu
On Fri, Sep 26, 2008 at 6:14 PM, Manu George <ma...@gmail.com> wrote:
> I will modify that patch to use the changes David has made. Let me
> know if you have any suggestions on the UI
>
> Regards
> Manu
>
> On 9/26/08, Donald Woods <dw...@apache.org> wrote:
>> I can try to check in the patch that's there, but I've never really
>> looked at or used EJBs and really don't have a burning desire to learn
>> it before we get 2.2 released.... :-)
>>
>> I went ahead a assigned it back to Manu, since he's a committer now and
>> understands the OpenEJB side of things....
>>
>>
>>
>> -Donald
>>
>>
>> David Blevins wrote:
>>> Wow, the screenshots on that issue look about perfect. Is this
>>> something you'd want to hack on?
>>>
>>> -David
>>>
>>> On Sep 25, 2008, at 12:00 PM, Donald Woods wrote:
>>>
>>>> Maybe the code provided in
>>>> https://issues.apache.org/jira/browse/GERONIMO-3811 can be used as a
>>>> starting point?
>>>>
>>>>
>>>> -Donald
>>>>
>>>>
>>>> David Blevins wrote:
>>>>> So I improved the EJB integration so that there's a gbean for each
>>>>> container type and the exact attributes for each container are
>>>>> strongly typed gbean attributes.
>>>>> Is it possible we can get someone to create a portlet that shows each
>>>>> ejb container in the system and allows people to edit the gbean
>>>>> attributes?
>>>>> Any volunteers?
>>>>> -David
>>>>
>>>
>>>
>>
>
Re: Improved EJB integration... can we get some portlets?
Posted by Lin Sun <li...@gmail.com>.
How about a modified version of No. 1 -
Include as a console plugin that has the geronimo-dojo plugin (which
includes the dojo mini v1.1.1) as the dependency. I think having the
geronimo-dojo as the dependency will automatically include dojo 1.1.1
mini into the assembly. We are looking at just providing one dojo
support (that is dojo 1.1.1) and get rid of dojo legacy 0.4.3 support
(or move it to the optional components).
Thanks
Lin
On Fri, Oct 24, 2008 at 7:00 AM, Manu George <ma...@gmail.com> wrote:
> I have two versions of the EJB Portlet with me. One with dojo 0.4.3
> and another with Dojo 1.x. There are 2 possibilities on how to
> integrate it.
>
> 1) Check in the portlet with dojo 0.4.3 support now as we do not ship
> Dojo 1.1 with the default server assembly. Later migrate to Dojo 1.1
> if we remove Dojo 0.4.3 and ship Dojo 1.1. This involves just changing
> the jsp to another one that I have.
>
> 2) Include this as an optional console plugin that will also install dojo 1.1.
>
> I am not sure how I would go ahead and create an optional console
> plugin if #2 is the better. option. Mostly how do I package it and
> where will it be distributed from. Are there any existing optional
> console plugins that I can refer?
>
> The other portlets seem to be installed by default with the
> corressponding server. So I am leaning towards #1.
>
> Regards
> Manu
>
Re: Improved EJB integration... can we get some portlets?
Posted by Donald Woods <dw...@apache.org>.
We ship both Dojo 0.4.3 and 1.1.1 in Geronimo 2.2 and we've been trying
to drop the old Dojo 0.4.3 usage for awhile, so please check-in the Dojo
1.1 version.
-Donald
Manu George wrote:
> I have two versions of the EJB Portlet with me. One with dojo 0.4.3
> and another with Dojo 1.x. There are 2 possibilities on how to
> integrate it.
>
> 1) Check in the portlet with dojo 0.4.3 support now as we do not ship
> Dojo 1.1 with the default server assembly. Later migrate to Dojo 1.1
> if we remove Dojo 0.4.3 and ship Dojo 1.1. This involves just changing
> the jsp to another one that I have.
>
> 2) Include this as an optional console plugin that will also install dojo 1.1.
>
> I am not sure how I would go ahead and create an optional console
> plugin if #2 is the better. option. Mostly how do I package it and
> where will it be distributed from. Are there any existing optional
> console plugins that I can refer?
>
> The other portlets seem to be installed by default with the
> corressponding server. So I am leaning towards #1.
>
> Regards
> Manu
>
Re: Improved EJB integration... can we get some portlets?
Posted by Manu George <ma...@gmail.com>.
I have two versions of the EJB Portlet with me. One with dojo 0.4.3
and another with Dojo 1.x. There are 2 possibilities on how to
integrate it.
1) Check in the portlet with dojo 0.4.3 support now as we do not ship
Dojo 1.1 with the default server assembly. Later migrate to Dojo 1.1
if we remove Dojo 0.4.3 and ship Dojo 1.1. This involves just changing
the jsp to another one that I have.
2) Include this as an optional console plugin that will also install dojo 1.1.
I am not sure how I would go ahead and create an optional console
plugin if #2 is the better. option. Mostly how do I package it and
where will it be distributed from. Are there any existing optional
console plugins that I can refer?
The other portlets seem to be installed by default with the
corressponding server. So I am leaning towards #1.
Regards
Manu
Re: Improved EJB integration... can we get some portlets?
Posted by Manu George <ma...@gmail.com>.
Hi David,
Thank you for the response. It was very helpful.
Comments inline
On Fri, Oct 10, 2008 at 9:47 PM, David Jencks <da...@yahoo.com> wrote:
>
> 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 <da...@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.
>
>>
.There is only 1 knob i.e instanceLimit and it is common. The Mdb
Containers are created in the openejb system gbean. So I added a
properties attribute there to store the customized values with mdb
container name as key.
>>
>>> 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 :-)
>
I am writing a jetty/tomcat plugin. I will externalize the
configurable properties to config-substitutions.properties.
However on editing I plan to edit the config.xml. The reason for this
is that later I plan to add the ability to create containers
dynamically and to configure them using the console. This will be
useful if u want some stateless beans to have say a different pool
size than others and so forth. In that case i would need to generate
keys for config-substitution.properties for each new container. So I
am planning on directly editing the config.xml in which case its not
required to have any configuration info in the plugin as u mentioned
>>
>>
>>> 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.
>
Thanks for the pointer and explanation. I found the method I need i.e
ManageableAttributeStore.setValue on going through the interface u
mentioned. and it also helped me gain a new understanding of Attribute
management in G.
>>
>>
>> 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
>
>
Thanks
Manu
Re: Improved EJB integration... can we get some portlets?
Posted by David Jencks <da...@yahoo.com>.
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
> <da...@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
Re: Improved EJB integration... can we get some portlets?
Posted by Manu George <ma...@gmail.com>.
I was wrong in my assumption that gbeans are not recreated at startup.
They are and their constructors are called.However the portlet should
still depend on the openejb configuration and so it will be stopped in
case openejb configuration is stopped.
Regards
Manu
On Fri, Oct 10, 2008 at 5:47 PM, Manu George <ma...@gmail.com> 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 <da...@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.
>
>> 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
>
Re: Improved EJB integration... can we get some portlets?
Posted by Manu George <ma...@gmail.com>.
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 <da...@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.
> 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
Re: Improved EJB integration... can we get some portlets?
Posted by David Jencks <da...@yahoo.com>.
On Oct 8, 2008, at 7:42 AM, Manu George wrote:
> Hi David B,
> All the attributes that you added in the container
> wrapper gbeans are final. I understand the reason for them being
> final i.e. the attributes are used only during the creation of the
> container. Previously all the gbeans had a properties attribute and I
> used to add the configuration properties to that. I also think that it
> was not final. Currently without setters and with attributes being
> final I can no longer edit the gbean attributes. The way i see it we
> need to add setter methods and also make the attributes non final. Let
> me know what you think.
>
> Previously the portlet would just edit the properties attributes
> of the gbean and inform the user that a server restart is necessary
> for the changes to be applied. What do you think is the approach i
> should take here?
>
> I observe that the admin console has a restart functionality which
> also starts all the dependencies so currently we will need only a
> restart of the openejb configuration
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
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.
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).
thanks
david jencks
>
>
> Regards
> Manu
>
>
> On Fri, Oct 3, 2008 at 3:46 PM, Manu George
> <ma...@gmail.com> wrote:
>> Hi David,
>> What is the accessTimeout attribute of the BmpContainerGBean
>> for? It seems to map to poolSize. You are doing a
>> set("AccessTimeout", Integer.toString(accessTimeout)); but there
>> doesn't seem to be such a property in EntityContainer.
>> Shouldn't this property be poolSize?
>>
>> Regards
>> Manu
>>
>> On Fri, Sep 26, 2008 at 6:14 PM, Manu George
>> <ma...@gmail.com> wrote:
>>> I will modify that patch to use the changes David has made. Let me
>>> know if you have any suggestions on the UI
>>>
>>> Regards
>>> Manu
>>>
>>> On 9/26/08, Donald Woods <dw...@apache.org> wrote:
>>>> I can try to check in the patch that's there, but I've never really
>>>> looked at or used EJBs and really don't have a burning desire to
>>>> learn
>>>> it before we get 2.2 released.... :-)
>>>>
>>>> I went ahead a assigned it back to Manu, since he's a committer
>>>> now and
>>>> understands the OpenEJB side of things....
>>>>
>>>>
>>>>
>>>> -Donald
>>>>
>>>>
>>>> David Blevins wrote:
>>>>> Wow, the screenshots on that issue look about perfect. Is this
>>>>> something you'd want to hack on?
>>>>>
>>>>> -David
>>>>>
>>>>> On Sep 25, 2008, at 12:00 PM, Donald Woods wrote:
>>>>>
>>>>>> Maybe the code provided in
>>>>>> https://issues.apache.org/jira/browse/GERONIMO-3811 can be used
>>>>>> as a
>>>>>> starting point?
>>>>>>
>>>>>>
>>>>>> -Donald
>>>>>>
>>>>>>
>>>>>> David Blevins wrote:
>>>>>>> So I improved the EJB integration so that there's a gbean for
>>>>>>> each
>>>>>>> container type and the exact attributes for each container are
>>>>>>> strongly typed gbean attributes.
>>>>>>> Is it possible we can get someone to create a portlet that
>>>>>>> shows each
>>>>>>> ejb container in the system and allows people to edit the gbean
>>>>>>> attributes?
>>>>>>> Any volunteers?
>>>>>>> -David
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: Improved EJB integration... can we get some portlets?
Posted by Manu George <ma...@gmail.com>.
Hi David B,
All the attributes that you added in the container
wrapper gbeans are final. I understand the reason for them being
final i.e. the attributes are used only during the creation of the
container. Previously all the gbeans had a properties attribute and I
used to add the configuration properties to that. I also think that it
was not final. Currently without setters and with attributes being
final I can no longer edit the gbean attributes. The way i see it we
need to add setter methods and also make the attributes non final. Let
me know what you think.
Previously the portlet would just edit the properties attributes
of the gbean and inform the user that a server restart is necessary
for the changes to be applied. What do you think is the approach i
should take here?
I observe that the admin console has a restart functionality which
also starts all the dependencies so currently we will need only a
restart of the openejb configuration
Regards
Manu
On Fri, Oct 3, 2008 at 3:46 PM, Manu George <ma...@gmail.com> wrote:
> Hi David,
> What is the accessTimeout attribute of the BmpContainerGBean
> for? It seems to map to poolSize. You are doing a
> set("AccessTimeout", Integer.toString(accessTimeout)); but there
> doesn't seem to be such a property in EntityContainer.
> Shouldn't this property be poolSize?
>
> Regards
> Manu
>
> On Fri, Sep 26, 2008 at 6:14 PM, Manu George <ma...@gmail.com> wrote:
>> I will modify that patch to use the changes David has made. Let me
>> know if you have any suggestions on the UI
>>
>> Regards
>> Manu
>>
>> On 9/26/08, Donald Woods <dw...@apache.org> wrote:
>>> I can try to check in the patch that's there, but I've never really
>>> looked at or used EJBs and really don't have a burning desire to learn
>>> it before we get 2.2 released.... :-)
>>>
>>> I went ahead a assigned it back to Manu, since he's a committer now and
>>> understands the OpenEJB side of things....
>>>
>>>
>>>
>>> -Donald
>>>
>>>
>>> David Blevins wrote:
>>>> Wow, the screenshots on that issue look about perfect. Is this
>>>> something you'd want to hack on?
>>>>
>>>> -David
>>>>
>>>> On Sep 25, 2008, at 12:00 PM, Donald Woods wrote:
>>>>
>>>>> Maybe the code provided in
>>>>> https://issues.apache.org/jira/browse/GERONIMO-3811 can be used as a
>>>>> starting point?
>>>>>
>>>>>
>>>>> -Donald
>>>>>
>>>>>
>>>>> David Blevins wrote:
>>>>>> So I improved the EJB integration so that there's a gbean for each
>>>>>> container type and the exact attributes for each container are
>>>>>> strongly typed gbean attributes.
>>>>>> Is it possible we can get someone to create a portlet that shows each
>>>>>> ejb container in the system and allows people to edit the gbean
>>>>>> attributes?
>>>>>> Any volunteers?
>>>>>> -David
>>>>>
>>>>
>>>>
>>>
>>
>