MdbActiveOnStartup / MdbJMXControl config

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

MdbActiveOnStartup / MdbJMXControl config

jgallimore
Hi

We recently added support for controlling MDB endpoint activation using the
MdbActiveOnStartup and MdbJMXControl deployment properties - so you'd add
something like this to openejb-jar.xml:

  <ejb-deployment ejb-name="MyEjb">
    <properties>
      MdbActiveOnStartup = true
      MdbJMXControl = true
    </properties>
  </ejb-deployment>

This works great, but the trouble is, you need to provide these properties
for every single MDB, which if you have a lot of them, is a pain. For
activation properties, we have the means to specify a setting using the
mdb.activation.[property]=[value] system property, which will apply to all
MDBs, unless those MDBs specify that activation property themselves. It
would be great if this worked the same way.

I'm wondering what the community thinks - I have a couple of ideas:

1. Allow EJB deployment properties to have overrides in the same way that
activation properties do. This might mean adding similar logic
to org.apache.openejb.config.BeanProperties
from org.apache.openejb.config.ActivationConfigPropertyOverride (or add a
new DynamicDeployer)
2. Change the MdbActiveOnStartup / MdbJMXControl feature to activation
properties. These can still be specified in openejb-jar.xml:

  <ejb-deployment ejb-name="MyEjb">
    <properties>
      activation.MdbActiveOnStartup = true
      activation.MdbJMXControl = true
    </properties>
  </ejb-deployment>

but would also allow the setting to be configured for all beans through the
existing method:

mdb.activation.MdbActiveOnStartup=true
mdb.activation. MdbJMXControl =true

Given that this config hasn't appeared in a released version yet, now might
be a good time to change it.

What do you think? I think I'm leaning towards option 2 at the moment. I'd
appreciate any thoughts, or alternative ideas. I'm happy to propose the
code change for review whichever way we go.

Cheers

Jon
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MdbActiveOnStartup / MdbJMXControl config

jgallimore
I'm still open to any comments or idea on this one. I did create PRs for
option 2 below for both master and the tomee-1.7.x branches.

Any feedback on those would also be most welcome.

Thanks

Jon

On Tue, Jul 25, 2017 at 10:56 AM, Jonathan Gallimore <
[hidden email]> wrote:

> Hi
>
> We recently added support for controlling MDB endpoint activation using
> the MdbActiveOnStartup and MdbJMXControl deployment properties - so you'd
> add something like this to openejb-jar.xml:
>
>   <ejb-deployment ejb-name="MyEjb">
>     <properties>
>       MdbActiveOnStartup = true
>       MdbJMXControl = true
>     </properties>
>   </ejb-deployment>
>
> This works great, but the trouble is, you need to provide these properties
> for every single MDB, which if you have a lot of them, is a pain. For
> activation properties, we have the means to specify a setting using the
> mdb.activation.[property]=[value] system property, which will apply to
> all MDBs, unless those MDBs specify that activation property themselves. It
> would be great if this worked the same way.
>
> I'm wondering what the community thinks - I have a couple of ideas:
>
> 1. Allow EJB deployment properties to have overrides in the same way that
> activation properties do. This might mean adding similar logic
> to org.apache.openejb.config.BeanProperties from org.apache.openejb.
> config.ActivationConfigPropertyOverride (or add a new DynamicDeployer)
> 2. Change the MdbActiveOnStartup / MdbJMXControl feature to activation
> properties. These can still be specified in openejb-jar.xml:
>
>   <ejb-deployment ejb-name="MyEjb">
>     <properties>
>       activation.MdbActiveOnStartup = true
>       activation.MdbJMXControl = true
>     </properties>
>   </ejb-deployment>
>
> but would also allow the setting to be configured for all beans through
> the existing method:
>
> mdb.activation.MdbActiveOnStartup=true
> mdb.activation. MdbJMXControl =true
>
> Given that this config hasn't appeared in a released version yet, now
> might be a good time to change it.
>
> What do you think? I think I'm leaning towards option 2 at the moment. I'd
> appreciate any thoughts, or alternative ideas. I'm happy to propose the
> code change for review whichever way we go.
>
> Cheers
>
> Jon
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MdbActiveOnStartup / MdbJMXControl config

jgallimore
I missed the links for those PRs:

https://github.com/apache/tomee/pull/97
https://github.com/apache/tomee/pull/98

Please do let me know if there's any feedback or concern. This thread has
been open a while, so if there's no feedback in a couple of days, I'll
merge these in.

Thanks

Jon

On Thu, Jul 27, 2017 at 5:28 PM, Jonathan Gallimore <
[hidden email]> wrote:

> I'm still open to any comments or idea on this one. I did create PRs for
> option 2 below for both master and the tomee-1.7.x branches.
>
> Any feedback on those would also be most welcome.
>
> Thanks
>
> Jon
>
> On Tue, Jul 25, 2017 at 10:56 AM, Jonathan Gallimore <
> [hidden email]> wrote:
>
>> Hi
>>
>> We recently added support for controlling MDB endpoint activation using
>> the MdbActiveOnStartup and MdbJMXControl deployment properties - so you'd
>> add something like this to openejb-jar.xml:
>>
>>   <ejb-deployment ejb-name="MyEjb">
>>     <properties>
>>       MdbActiveOnStartup = true
>>       MdbJMXControl = true
>>     </properties>
>>   </ejb-deployment>
>>
>> This works great, but the trouble is, you need to provide these
>> properties for every single MDB, which if you have a lot of them, is a
>> pain. For activation properties, we have the means to specify a setting
>> using the mdb.activation.[property]=[value] system property, which will
>> apply to all MDBs, unless those MDBs specify that activation property
>> themselves. It would be great if this worked the same way.
>>
>> I'm wondering what the community thinks - I have a couple of ideas:
>>
>> 1. Allow EJB deployment properties to have overrides in the same way that
>> activation properties do. This might mean adding similar logic
>> to org.apache.openejb.config.BeanProperties
>> from org.apache.openejb.config.ActivationConfigPropertyOverride (or add
>> a new DynamicDeployer)
>> 2. Change the MdbActiveOnStartup / MdbJMXControl feature to activation
>> properties. These can still be specified in openejb-jar.xml:
>>
>>   <ejb-deployment ejb-name="MyEjb">
>>     <properties>
>>       activation.MdbActiveOnStartup = true
>>       activation.MdbJMXControl = true
>>     </properties>
>>   </ejb-deployment>
>>
>> but would also allow the setting to be configured for all beans through
>> the existing method:
>>
>> mdb.activation.MdbActiveOnStartup=true
>> mdb.activation. MdbJMXControl =true
>>
>> Given that this config hasn't appeared in a released version yet, now
>> might be a good time to change it.
>>
>> What do you think? I think I'm leaning towards option 2 at the moment.
>> I'd appreciate any thoughts, or alternative ideas. I'm happy to propose the
>> code change for review whichever way we go.
>>
>> Cheers
>>
>> Jon
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MdbActiveOnStartup / MdbJMXControl config

jgallimore
This has been open for a while - this is the last call, if there's no
objections, I'll merge these in.

Thanks

Jon

On Mon, Jul 31, 2017 at 11:03 AM, Jonathan Gallimore <
[hidden email]> wrote:

> I missed the links for those PRs:
>
> https://github.com/apache/tomee/pull/97
> https://github.com/apache/tomee/pull/98
>
> Please do let me know if there's any feedback or concern. This thread has
> been open a while, so if there's no feedback in a couple of days, I'll
> merge these in.
>
> Thanks
>
> Jon
>
> On Thu, Jul 27, 2017 at 5:28 PM, Jonathan Gallimore <
> [hidden email]> wrote:
>
>> I'm still open to any comments or idea on this one. I did create PRs for
>> option 2 below for both master and the tomee-1.7.x branches.
>>
>> Any feedback on those would also be most welcome.
>>
>> Thanks
>>
>> Jon
>>
>> On Tue, Jul 25, 2017 at 10:56 AM, Jonathan Gallimore <
>> [hidden email]> wrote:
>>
>>> Hi
>>>
>>> We recently added support for controlling MDB endpoint activation using
>>> the MdbActiveOnStartup and MdbJMXControl deployment properties - so you'd
>>> add something like this to openejb-jar.xml:
>>>
>>>   <ejb-deployment ejb-name="MyEjb">
>>>     <properties>
>>>       MdbActiveOnStartup = true
>>>       MdbJMXControl = true
>>>     </properties>
>>>   </ejb-deployment>
>>>
>>> This works great, but the trouble is, you need to provide these
>>> properties for every single MDB, which if you have a lot of them, is a
>>> pain. For activation properties, we have the means to specify a setting
>>> using the mdb.activation.[property]=[value] system property, which will
>>> apply to all MDBs, unless those MDBs specify that activation property
>>> themselves. It would be great if this worked the same way.
>>>
>>> I'm wondering what the community thinks - I have a couple of ideas:
>>>
>>> 1. Allow EJB deployment properties to have overrides in the same way
>>> that activation properties do. This might mean adding similar logic
>>> to org.apache.openejb.config.BeanProperties
>>> from org.apache.openejb.config.ActivationConfigPropertyOverride (or add
>>> a new DynamicDeployer)
>>> 2. Change the MdbActiveOnStartup / MdbJMXControl feature to activation
>>> properties. These can still be specified in openejb-jar.xml:
>>>
>>>   <ejb-deployment ejb-name="MyEjb">
>>>     <properties>
>>>       activation.MdbActiveOnStartup = true
>>>       activation.MdbJMXControl = true
>>>     </properties>
>>>   </ejb-deployment>
>>>
>>> but would also allow the setting to be configured for all beans through
>>> the existing method:
>>>
>>> mdb.activation.MdbActiveOnStartup=true
>>> mdb.activation. MdbJMXControl =true
>>>
>>> Given that this config hasn't appeared in a released version yet, now
>>> might be a good time to change it.
>>>
>>> What do you think? I think I'm leaning towards option 2 at the moment.
>>> I'd appreciate any thoughts, or alternative ideas. I'm happy to propose the
>>> code change for review whichever way we go.
>>>
>>> Cheers
>>>
>>> Jon
>>>
>>
>>
>
Loading...