Adds an option to ignore mdb.activation fields

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

Adds an option to ignore mdb.activation fields

Otávio Gonçalves de Santana
The problem

The configuration for MDB activation properties allow any key/value to be
specified. At present on the 1.7.x branch, the server will fail to deploy
the application if the activation property is not present on the activation
spec class.

This becomes painful in a scenario where more than one JMS resource
adapter/MDB container is used, and you wish to configure the activation
properties of multiple MDBs in one go using the `mdb.activation.` system
property.. Right now,if an activation property is used that one provider
uses but other one does, the server will throw an exception.

For example, given these parameters,

   -

      mdb.activation.ignore=foo
   -

      mdb.activation.ignore2=bar


if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
class, the following exception will be thrown.

Caused by: org.apache.openejb.OpenEJBException: Error deploying
'Listener'.  Exception: class org.apache.openejb.OpenEJBException: Unable
to create activation spec: No setter found for the activation spec
properties: [ignore, ignore2]: Unable to create activation spec: No setter
found for the activation spec properties: [ignore, ignore2]

   at
org.apache.openejb.assembler.classic.Assembler.startEjbs(Assembler.java:1430)

   at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:796)

   ... 19 more

Caused by: org.apache.openejb.OpenEJBException: Unable to create activation
spec: No setter found for the activation spec properties: [ignore, ignore2]

   at
org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(MdbContainer.java:292)

   at org.apache.openejb.core.mdb.MdbContainer.deploy(MdbContainer.java:159)

   at
org.apache.openejb.assembler.classic.Assembler.startEjbs(Assembler.java:1417)

   ... 20 more

Caused by: java.lang.IllegalArgumentException: No setter found for the
activation spec properties: [ignore, ignore2]

   at
org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(MdbContainer.java:262)

   ... 22 more


The solution

The best solution to solve the communication among server is to put a new
configuration property in TomEE. When this setting is enabled, overriding
the FailOnUnknownActivationSpec attribute at
org.apache.openejb.core.mdb.MdbContainer class., that will be disabled by
default to don't break the compatibility, when the setter does not exist it
put a log and then keep working.

Basically, my proposal does a backport to 1.7 branch:
https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55eded08aec0

Path:

https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Jonathan Gallimore-4
I'm +1 for back porting that patch, thanks Otavio.

One thing I'd be interested in as an extra, is seeing if we can set
activation properties on a per-container basis too.

What do you think?

Jon

On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
[hidden email]> wrote:

> The problem
>
> The configuration for MDB activation properties allow any key/value to be
> specified. At present on the 1.7.x branch, the server will fail to deploy
> the application if the activation property is not present on the activation
> spec class.
>
> This becomes painful in a scenario where more than one JMS resource
> adapter/MDB container is used, and you wish to configure the activation
> properties of multiple MDBs in one go using the `mdb.activation.` system
> property.. Right now,if an activation property is used that one provider
> uses but other one does, the server will throw an exception.
>
> For example, given these parameters,
>
>    -
>
>       mdb.activation.ignore=foo
>    -
>
>       mdb.activation.ignore2=bar
>
>
> if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> class, the following exception will be thrown.
>
> Caused by: org.apache.openejb.OpenEJBException: Error deploying
> 'Listener'.  Exception: class org.apache.openejb.OpenEJBException: Unable
> to create activation spec: No setter found for the activation spec
> properties: [ignore, ignore2]: Unable to create activation spec: No setter
> found for the activation spec properties: [ignore, ignore2]
>
>    at
> org.apache.openejb.assembler.classic.Assembler.startEjbs(
> Assembler.java:1430)
>
>    at
> org.apache.openejb.assembler.classic.Assembler.
> createApplication(Assembler.java:796)
>
>    ... 19 more
>
> Caused by: org.apache.openejb.OpenEJBException: Unable to create
> activation
> spec: No setter found for the activation spec properties: [ignore, ignore2]
>
>    at
> org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> MdbContainer.java:292)
>
>    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> MdbContainer.java:159)
>
>    at
> org.apache.openejb.assembler.classic.Assembler.startEjbs(
> Assembler.java:1417)
>
>    ... 20 more
>
> Caused by: java.lang.IllegalArgumentException: No setter found for the
> activation spec properties: [ignore, ignore2]
>
>    at
> org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> MdbContainer.java:262)
>
>    ... 22 more
>
>
> The solution
>
> The best solution to solve the communication among server is to put a new
> configuration property in TomEE. When this setting is enabled, overriding
> the FailOnUnknownActivationSpec attribute at
> org.apache.openejb.core.mdb.MdbContainer class., that will be disabled by
> default to don't break the compatibility, when the setter does not exist it
> put a log and then keep working.
>
> Basically, my proposal does a backport to 1.7 branch:
> https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> eded08aec0
>
> Path:
>
> https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
>



--
Jonathan Gallimore
http://twitter.com/jongallimore
http://www.tomitribe.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Romain Manni-Bucau
2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <[hidden email]>:

> I'm +1 for back porting that patch, thanks Otavio.
>
> One thing I'd be interested in as an extra, is seeing if we can set
> activation properties on a per-container basis too.
>

Mean like adding one new key in
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/config/ActivationConfigPropertyOverride.java#L94
using .container.<id>?

+1 if ~so (just wanted to avoid a misunderstanding and get a completely new
feature/code)



Side note on the fail flag: this was a flag added to pass tck and was in
"ignore" mode of the MDB (which is fine for this need) but not intended to
be used or reliable for real applications where it would be saner to fix
the broken configuration instead of bet on it working ignoring the work
some people did configuring it. I'm not against backporting it but think it
is important to remind that I think we don't want to promote that flag
(shouldn't hit the doc for instance since it is an internal workaround
IMHO).


>
> What do you think?
>
> Jon
>
> On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> [hidden email]> wrote:
>
> > The problem
> >
> > The configuration for MDB activation properties allow any key/value to be
> > specified. At present on the 1.7.x branch, the server will fail to deploy
> > the application if the activation property is not present on the
> activation
> > spec class.
> >
> > This becomes painful in a scenario where more than one JMS resource
> > adapter/MDB container is used, and you wish to configure the activation
> > properties of multiple MDBs in one go using the `mdb.activation.` system
> > property.. Right now,if an activation property is used that one provider
> > uses but other one does, the server will throw an exception.
> >
> > For example, given these parameters,
> >
> >    -
> >
> >       mdb.activation.ignore=foo
> >    -
> >
> >       mdb.activation.ignore2=bar
> >
> >
> > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > class, the following exception will be thrown.
> >
> > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> Unable
> > to create activation spec: No setter found for the activation spec
> > properties: [ignore, ignore2]: Unable to create activation spec: No
> setter
> > found for the activation spec properties: [ignore, ignore2]
> >
> >    at
> > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > Assembler.java:1430)
> >
> >    at
> > org.apache.openejb.assembler.classic.Assembler.
> > createApplication(Assembler.java:796)
> >
> >    ... 19 more
> >
> > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > activation
> > spec: No setter found for the activation spec properties: [ignore,
> ignore2]
> >
> >    at
> > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > MdbContainer.java:292)
> >
> >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > MdbContainer.java:159)
> >
> >    at
> > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > Assembler.java:1417)
> >
> >    ... 20 more
> >
> > Caused by: java.lang.IllegalArgumentException: No setter found for the
> > activation spec properties: [ignore, ignore2]
> >
> >    at
> > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > MdbContainer.java:262)
> >
> >    ... 22 more
> >
> >
> > The solution
> >
> > The best solution to solve the communication among server is to put a new
> > configuration property in TomEE. When this setting is enabled, overriding
> > the FailOnUnknownActivationSpec attribute at
> > org.apache.openejb.core.mdb.MdbContainer class., that will be disabled
> by
> > default to don't break the compatibility, when the setter does not exist
> it
> > put a log and then keep working.
> >
> > Basically, my proposal does a backport to 1.7 branch:
> > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> > eded08aec0
> >
> > Path:
> >
> > https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
> >
>
>
>
> --
> Jonathan Gallimore
> http://twitter.com/jongallimore
> http://www.tomitribe.com
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

jgallimore
I'm thinking something along the lines of:

  <Container id="MDB1" ctype="MESSAGE">
    ResourceAdapter MyResourceAdapter
    ActivationSpecClass My.ActivationSpecImpl

   activation.property1 = value1
   activation.property2 = value2
  </Container>

  <Container id="MDB2" ctype="MESSAGE">
    ResourceAdapter MyOTHERResourceAdapter
    ActivationSpecClass My.Other.ActivationSpecImpl
   activation.property1 = othervalue1
   activation.property2 = othervalue2
  </Container>

So all the MDBs in container MDB1 would get the following on their
activation spec
   property1 = value1
   property2 = value2

And all the MDBs in container MDB2 would get the following on their
activation spec
   property1 = othervalue1
   property2 = othervalue2


And then have the potential to override them with system.properties like so:
   MDB1.activation.property1 = othervalue1
   MDB1.activation.property2 = othervalue2
   MDB2.activation.property1 = othervalue1
   MDB2.activation.property2 = othervalue2

Maybe something is needed to call 'MDB1' out as a container as opposed to a
bean name. In terms of precedence, I'd expect properties on the container
to override any `mdb.activation` properties, and any properties specific to
a bean to override any container properties - so its Global
(mdb.activation) -> Container ([containerid].activation) -> Bean
([BeanName].activation).

I imagine it would essentially boil down to a new key at the point you
suggest, and expand on the test cases.

I'm in favour of the backport irrespective of whether we choose to explore
my suggestion (or any other suggestion) though.

Cheers

Jon

On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <[hidden email]>
wrote:

> 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <[hidden email]>:
>
> > I'm +1 for back porting that patch, thanks Otavio.
> >
> > One thing I'd be interested in as an extra, is seeing if we can set
> > activation properties on a per-container basis too.
> >
>
> Mean like adding one new key in
> https://github.com/apache/tomee/blob/master/container/
> openejb-core/src/main/java/org/apache/openejb/config/
> ActivationConfigPropertyOverride.java#L94
> using .container.<id>?
>
> +1 if ~so (just wanted to avoid a misunderstanding and get a completely new
> feature/code)
>
>
>
> Side note on the fail flag: this was a flag added to pass tck and was in
> "ignore" mode of the MDB (which is fine for this need) but not intended to
> be used or reliable for real applications where it would be saner to fix
> the broken configuration instead of bet on it working ignoring the work
> some people did configuring it. I'm not against backporting it but think it
> is important to remind that I think we don't want to promote that flag
> (shouldn't hit the doc for instance since it is an internal workaround
> IMHO).
>
>
> >
> > What do you think?
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > [hidden email]> wrote:
> >
> > > The problem
> > >
> > > The configuration for MDB activation properties allow any key/value to
> be
> > > specified. At present on the 1.7.x branch, the server will fail to
> deploy
> > > the application if the activation property is not present on the
> > activation
> > > spec class.
> > >
> > > This becomes painful in a scenario where more than one JMS resource
> > > adapter/MDB container is used, and you wish to configure the activation
> > > properties of multiple MDBs in one go using the `mdb.activation.`
> system
> > > property.. Right now,if an activation property is used that one
> provider
> > > uses but other one does, the server will throw an exception.
> > >
> > > For example, given these parameters,
> > >
> > >    -
> > >
> > >       mdb.activation.ignore=foo
> > >    -
> > >
> > >       mdb.activation.ignore2=bar
> > >
> > >
> > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > > class, the following exception will be thrown.
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > Unable
> > > to create activation spec: No setter found for the activation spec
> > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > setter
> > > found for the activation spec properties: [ignore, ignore2]
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1430)
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:796)
> > >
> > >    ... 19 more
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > activation
> > > spec: No setter found for the activation spec properties: [ignore,
> > ignore2]
> > >
> > >    at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:292)
> > >
> > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > MdbContainer.java:159)
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1417)
> > >
> > >    ... 20 more
> > >
> > > Caused by: java.lang.IllegalArgumentException: No setter found for the
> > > activation spec properties: [ignore, ignore2]
> > >
> > >    at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:262)
> > >
> > >    ... 22 more
> > >
> > >
> > > The solution
> > >
> > > The best solution to solve the communication among server is to put a
> new
> > > configuration property in TomEE. When this setting is enabled,
> overriding
> > > the FailOnUnknownActivationSpec attribute at
> > > org.apache.openejb.core.mdb.MdbContainer class., that will be disabled
> > by
> > > default to don't break the compatibility, when the setter does not
> exist
> > it
> > > put a log and then keep working.
> > >
> > > Basically, my proposal does a backport to 1.7 branch:
> > > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> > > eded08aec0
> > >
> > > Path:
> > >
> > > https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
> > >
> >
> >
> >
> > --
> > Jonathan Gallimore
> > http://twitter.com/jongallimore
> > http://www.tomitribe.com
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Romain Manni-Bucau
sounds good this way for container activation props


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-07 12:40 GMT+02:00 Jonathan Gallimore <[hidden email]>
:

> I'm thinking something along the lines of:
>
>   <Container id="MDB1" ctype="MESSAGE">
>     ResourceAdapter MyResourceAdapter
>     ActivationSpecClass My.ActivationSpecImpl
>
>    activation.property1 = value1
>    activation.property2 = value2
>   </Container>
>
>   <Container id="MDB2" ctype="MESSAGE">
>     ResourceAdapter MyOTHERResourceAdapter
>     ActivationSpecClass My.Other.ActivationSpecImpl
>    activation.property1 = othervalue1
>    activation.property2 = othervalue2
>   </Container>
>
> So all the MDBs in container MDB1 would get the following on their
> activation spec
>    property1 = value1
>    property2 = value2
>
> And all the MDBs in container MDB2 would get the following on their
> activation spec
>    property1 = othervalue1
>    property2 = othervalue2
>
>
> And then have the potential to override them with system.properties like
> so:
>    MDB1.activation.property1 = othervalue1
>    MDB1.activation.property2 = othervalue2
>    MDB2.activation.property1 = othervalue1
>    MDB2.activation.property2 = othervalue2
>
> Maybe something is needed to call 'MDB1' out as a container as opposed to a
> bean name. In terms of precedence, I'd expect properties on the container
> to override any `mdb.activation` properties, and any properties specific to
> a bean to override any container properties - so its Global
> (mdb.activation) -> Container ([containerid].activation) -> Bean
> ([BeanName].activation).
>
> I imagine it would essentially boil down to a new key at the point you
> suggest, and expand on the test cases.
>
> I'm in favour of the backport irrespective of whether we choose to explore
> my suggestion (or any other suggestion) though.
>
> Cheers
>
> Jon
>
> On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <[hidden email]
> >
> wrote:
>
> > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <[hidden email]
> >:
> >
> > > I'm +1 for back porting that patch, thanks Otavio.
> > >
> > > One thing I'd be interested in as an extra, is seeing if we can set
> > > activation properties on a per-container basis too.
> > >
> >
> > Mean like adding one new key in
> > https://github.com/apache/tomee/blob/master/container/
> > openejb-core/src/main/java/org/apache/openejb/config/
> > ActivationConfigPropertyOverride.java#L94
> > using .container.<id>?
> >
> > +1 if ~so (just wanted to avoid a misunderstanding and get a completely
> new
> > feature/code)
> >
> >
> >
> > Side note on the fail flag: this was a flag added to pass tck and was in
> > "ignore" mode of the MDB (which is fine for this need) but not intended
> to
> > be used or reliable for real applications where it would be saner to fix
> > the broken configuration instead of bet on it working ignoring the work
> > some people did configuring it. I'm not against backporting it but think
> it
> > is important to remind that I think we don't want to promote that flag
> > (shouldn't hit the doc for instance since it is an internal workaround
> > IMHO).
> >
> >
> > >
> > > What do you think?
> > >
> > > Jon
> > >
> > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > [hidden email]> wrote:
> > >
> > > > The problem
> > > >
> > > > The configuration for MDB activation properties allow any key/value
> to
> > be
> > > > specified. At present on the 1.7.x branch, the server will fail to
> > deploy
> > > > the application if the activation property is not present on the
> > > activation
> > > > spec class.
> > > >
> > > > This becomes painful in a scenario where more than one JMS resource
> > > > adapter/MDB container is used, and you wish to configure the
> activation
> > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > system
> > > > property.. Right now,if an activation property is used that one
> > provider
> > > > uses but other one does, the server will throw an exception.
> > > >
> > > > For example, given these parameters,
> > > >
> > > >    -
> > > >
> > > >       mdb.activation.ignore=foo
> > > >    -
> > > >
> > > >       mdb.activation.ignore2=bar
> > > >
> > > >
> > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > > > class, the following exception will be thrown.
> > > >
> > > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > > Unable
> > > > to create activation spec: No setter found for the activation spec
> > > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > > setter
> > > > found for the activation spec properties: [ignore, ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > Assembler.java:1430)
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.
> > > > createApplication(Assembler.java:796)
> > > >
> > > >    ... 19 more
> > > >
> > > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > > activation
> > > > spec: No setter found for the activation spec properties: [ignore,
> > > ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > MdbContainer.java:292)
> > > >
> > > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > > MdbContainer.java:159)
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > Assembler.java:1417)
> > > >
> > > >    ... 20 more
> > > >
> > > > Caused by: java.lang.IllegalArgumentException: No setter found for
> the
> > > > activation spec properties: [ignore, ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > MdbContainer.java:262)
> > > >
> > > >    ... 22 more
> > > >
> > > >
> > > > The solution
> > > >
> > > > The best solution to solve the communication among server is to put a
> > new
> > > > configuration property in TomEE. When this setting is enabled,
> > overriding
> > > > the FailOnUnknownActivationSpec attribute at
> > > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> disabled
> > > by
> > > > default to don't break the compatibility, when the setter does not
> > exist
> > > it
> > > > put a log and then keep working.
> > > >
> > > > Basically, my proposal does a backport to 1.7 branch:
> > > > https://github.com/apache/tomee/commit/
> 6522f349d0c31d6ec82e66378e0e55
> > > > eded08aec0
> > > >
> > > > Path:
> > > >
> > > > https://patch-diff.githubusercontent.com/raw/
> apache/tomee/pull/86.diff
> > > >
> > >
> > >
> > >
> > > --
> > > Jonathan Gallimore
> > > http://twitter.com/jongallimore
> > > http://www.tomitribe.com
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

jgallimore
In reply to this post by jgallimore
I think we also have a typo in "FailOnUnknownActivationSpec" where an 'n'
is missing. I think we should correct that.

https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/resources/META-INF/org.apache.openejb/service-jar.xml#L494

Jon

On Fri, Jul 7, 2017 at 11:40 AM, Jonathan Gallimore <
[hidden email]> wrote:

> I'm thinking something along the lines of:
>
>   <Container id="MDB1" ctype="MESSAGE">
>     ResourceAdapter MyResourceAdapter
>     ActivationSpecClass My.ActivationSpecImpl
>
>    activation.property1 = value1
>    activation.property2 = value2
>   </Container>
>
>   <Container id="MDB2" ctype="MESSAGE">
>     ResourceAdapter MyOTHERResourceAdapter
>     ActivationSpecClass My.Other.ActivationSpecImpl
>    activation.property1 = othervalue1
>    activation.property2 = othervalue2
>   </Container>
>
> So all the MDBs in container MDB1 would get the following on their
> activation spec
>    property1 = value1
>    property2 = value2
>
> And all the MDBs in container MDB2 would get the following on their
> activation spec
>    property1 = othervalue1
>    property2 = othervalue2
>
>
> And then have the potential to override them with system.properties like
> so:
>    MDB1.activation.property1 = othervalue1
>    MDB1.activation.property2 = othervalue2
>    MDB2.activation.property1 = othervalue1
>    MDB2.activation.property2 = othervalue2
>
> Maybe something is needed to call 'MDB1' out as a container as opposed to
> a bean name. In terms of precedence, I'd expect properties on the container
> to override any `mdb.activation` properties, and any properties specific to
> a bean to override any container properties - so its Global
> (mdb.activation) -> Container ([containerid].activation) -> Bean
> ([BeanName].activation).
>
> I imagine it would essentially boil down to a new key at the point you
> suggest, and expand on the test cases.
>
> I'm in favour of the backport irrespective of whether we choose to explore
> my suggestion (or any other suggestion) though.
>
> Cheers
>
> Jon
>
> On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <[hidden email]
> > wrote:
>
>> 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <[hidden email]>:
>>
>> > I'm +1 for back porting that patch, thanks Otavio.
>> >
>> > One thing I'd be interested in as an extra, is seeing if we can set
>> > activation properties on a per-container basis too.
>> >
>>
>> Mean like adding one new key in
>> https://github.com/apache/tomee/blob/master/container/openej
>> b-core/src/main/java/org/apache/openejb/config/Activati
>> onConfigPropertyOverride.java#L94
>> using .container.<id>?
>>
>> +1 if ~so (just wanted to avoid a misunderstanding and get a completely
>> new
>> feature/code)
>>
>>
>>
>> Side note on the fail flag: this was a flag added to pass tck and was in
>> "ignore" mode of the MDB (which is fine for this need) but not intended to
>> be used or reliable for real applications where it would be saner to fix
>> the broken configuration instead of bet on it working ignoring the work
>> some people did configuring it. I'm not against backporting it but think
>> it
>> is important to remind that I think we don't want to promote that flag
>> (shouldn't hit the doc for instance since it is an internal workaround
>> IMHO).
>>
>>
>> >
>> > What do you think?
>> >
>> > Jon
>> >
>> > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
>> > [hidden email]> wrote:
>> >
>> > > The problem
>> > >
>> > > The configuration for MDB activation properties allow any key/value
>> to be
>> > > specified. At present on the 1.7.x branch, the server will fail to
>> deploy
>> > > the application if the activation property is not present on the
>> > activation
>> > > spec class.
>> > >
>> > > This becomes painful in a scenario where more than one JMS resource
>> > > adapter/MDB container is used, and you wish to configure the
>> activation
>> > > properties of multiple MDBs in one go using the `mdb.activation.`
>> system
>> > > property.. Right now,if an activation property is used that one
>> provider
>> > > uses but other one does, the server will throw an exception.
>> > >
>> > > For example, given these parameters,
>> > >
>> > >    -
>> > >
>> > >       mdb.activation.ignore=foo
>> > >    -
>> > >
>> > >       mdb.activation.ignore2=bar
>> > >
>> > >
>> > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
>> > > class, the following exception will be thrown.
>> > >
>> > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
>> > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
>> > Unable
>> > > to create activation spec: No setter found for the activation spec
>> > > properties: [ignore, ignore2]: Unable to create activation spec: No
>> > setter
>> > > found for the activation spec properties: [ignore, ignore2]
>> > >
>> > >    at
>> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
>> > > Assembler.java:1430)
>> > >
>> > >    at
>> > > org.apache.openejb.assembler.classic.Assembler.
>> > > createApplication(Assembler.java:796)
>> > >
>> > >    ... 19 more
>> > >
>> > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
>> > > activation
>> > > spec: No setter found for the activation spec properties: [ignore,
>> > ignore2]
>> > >
>> > >    at
>> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
>> > > MdbContainer.java:292)
>> > >
>> > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
>> > > MdbContainer.java:159)
>> > >
>> > >    at
>> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
>> > > Assembler.java:1417)
>> > >
>> > >    ... 20 more
>> > >
>> > > Caused by: java.lang.IllegalArgumentException: No setter found for
>> the
>> > > activation spec properties: [ignore, ignore2]
>> > >
>> > >    at
>> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
>> > > MdbContainer.java:262)
>> > >
>> > >    ... 22 more
>> > >
>> > >
>> > > The solution
>> > >
>> > > The best solution to solve the communication among server is to put a
>> new
>> > > configuration property in TomEE. When this setting is enabled,
>> overriding
>> > > the FailOnUnknownActivationSpec attribute at
>> > > org.apache.openejb.core.mdb.MdbContainer class., that will be
>> disabled
>> > by
>> > > default to don't break the compatibility, when the setter does not
>> exist
>> > it
>> > > put a log and then keep working.
>> > >
>> > > Basically, my proposal does a backport to 1.7 branch:
>> > > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
>> > > eded08aec0
>> > >
>> > > Path:
>> > >
>> > > https://patch-diff.githubusercontent.com/raw/apache/tomee/
>> pull/86.diff
>> > >
>> >
>> >
>> >
>> > --
>> > Jonathan Gallimore
>> > http://twitter.com/jongallimore
>> > http://www.tomitribe.com
>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

jgallimore
In reply to this post by Romain Manni-Bucau
Thanks for the feedback Romain! @Otavio - what do you think? You want to
have a go at that?

Jon

On Fri, Jul 7, 2017 at 11:41 AM, Romain Manni-Bucau <[hidden email]>
wrote:

> sounds good this way for container activation props
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-07 12:40 GMT+02:00 Jonathan Gallimore <
> [hidden email]>
> :
>
> > I'm thinking something along the lines of:
> >
> >   <Container id="MDB1" ctype="MESSAGE">
> >     ResourceAdapter MyResourceAdapter
> >     ActivationSpecClass My.ActivationSpecImpl
> >
> >    activation.property1 = value1
> >    activation.property2 = value2
> >   </Container>
> >
> >   <Container id="MDB2" ctype="MESSAGE">
> >     ResourceAdapter MyOTHERResourceAdapter
> >     ActivationSpecClass My.Other.ActivationSpecImpl
> >    activation.property1 = othervalue1
> >    activation.property2 = othervalue2
> >   </Container>
> >
> > So all the MDBs in container MDB1 would get the following on their
> > activation spec
> >    property1 = value1
> >    property2 = value2
> >
> > And all the MDBs in container MDB2 would get the following on their
> > activation spec
> >    property1 = othervalue1
> >    property2 = othervalue2
> >
> >
> > And then have the potential to override them with system.properties like
> > so:
> >    MDB1.activation.property1 = othervalue1
> >    MDB1.activation.property2 = othervalue2
> >    MDB2.activation.property1 = othervalue1
> >    MDB2.activation.property2 = othervalue2
> >
> > Maybe something is needed to call 'MDB1' out as a container as opposed
> to a
> > bean name. In terms of precedence, I'd expect properties on the container
> > to override any `mdb.activation` properties, and any properties specific
> to
> > a bean to override any container properties - so its Global
> > (mdb.activation) -> Container ([containerid].activation) -> Bean
> > ([BeanName].activation).
> >
> > I imagine it would essentially boil down to a new key at the point you
> > suggest, and expand on the test cases.
> >
> > I'm in favour of the backport irrespective of whether we choose to
> explore
> > my suggestion (or any other suggestion) though.
> >
> > Cheers
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <
> [hidden email]
> > >
> > wrote:
> >
> > > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <
> [hidden email]
> > >:
> > >
> > > > I'm +1 for back porting that patch, thanks Otavio.
> > > >
> > > > One thing I'd be interested in as an extra, is seeing if we can set
> > > > activation properties on a per-container basis too.
> > > >
> > >
> > > Mean like adding one new key in
> > > https://github.com/apache/tomee/blob/master/container/
> > > openejb-core/src/main/java/org/apache/openejb/config/
> > > ActivationConfigPropertyOverride.java#L94
> > > using .container.<id>?
> > >
> > > +1 if ~so (just wanted to avoid a misunderstanding and get a completely
> > new
> > > feature/code)
> > >
> > >
> > >
> > > Side note on the fail flag: this was a flag added to pass tck and was
> in
> > > "ignore" mode of the MDB (which is fine for this need) but not intended
> > to
> > > be used or reliable for real applications where it would be saner to
> fix
> > > the broken configuration instead of bet on it working ignoring the work
> > > some people did configuring it. I'm not against backporting it but
> think
> > it
> > > is important to remind that I think we don't want to promote that flag
> > > (shouldn't hit the doc for instance since it is an internal workaround
> > > IMHO).
> > >
> > >
> > > >
> > > > What do you think?
> > > >
> > > > Jon
> > > >
> > > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > > [hidden email]> wrote:
> > > >
> > > > > The problem
> > > > >
> > > > > The configuration for MDB activation properties allow any key/value
> > to
> > > be
> > > > > specified. At present on the 1.7.x branch, the server will fail to
> > > deploy
> > > > > the application if the activation property is not present on the
> > > > activation
> > > > > spec class.
> > > > >
> > > > > This becomes painful in a scenario where more than one JMS resource
> > > > > adapter/MDB container is used, and you wish to configure the
> > activation
> > > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > > system
> > > > > property.. Right now,if an activation property is used that one
> > > provider
> > > > > uses but other one does, the server will throw an exception.
> > > > >
> > > > > For example, given these parameters,
> > > > >
> > > > >    -
> > > > >
> > > > >       mdb.activation.ignore=foo
> > > > >    -
> > > > >
> > > > >       mdb.activation.ignore2=bar
> > > > >
> > > > >
> > > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation
> spec
> > > > > class, the following exception will be thrown.
> > > > >
> > > > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > > > Unable
> > > > > to create activation spec: No setter found for the activation spec
> > > > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > > > setter
> > > > > found for the activation spec properties: [ignore, ignore2]
> > > > >
> > > > >    at
> > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > Assembler.java:1430)
> > > > >
> > > > >    at
> > > > > org.apache.openejb.assembler.classic.Assembler.
> > > > > createApplication(Assembler.java:796)
> > > > >
> > > > >    ... 19 more
> > > > >
> > > > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > > > activation
> > > > > spec: No setter found for the activation spec properties: [ignore,
> > > > ignore2]
> > > > >
> > > > >    at
> > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > MdbContainer.java:292)
> > > > >
> > > > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > > > MdbContainer.java:159)
> > > > >
> > > > >    at
> > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > Assembler.java:1417)
> > > > >
> > > > >    ... 20 more
> > > > >
> > > > > Caused by: java.lang.IllegalArgumentException: No setter found for
> > the
> > > > > activation spec properties: [ignore, ignore2]
> > > > >
> > > > >    at
> > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > MdbContainer.java:262)
> > > > >
> > > > >    ... 22 more
> > > > >
> > > > >
> > > > > The solution
> > > > >
> > > > > The best solution to solve the communication among server is to
> put a
> > > new
> > > > > configuration property in TomEE. When this setting is enabled,
> > > overriding
> > > > > the FailOnUnknownActivationSpec attribute at
> > > > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> > disabled
> > > > by
> > > > > default to don't break the compatibility, when the setter does not
> > > exist
> > > > it
> > > > > put a log and then keep working.
> > > > >
> > > > > Basically, my proposal does a backport to 1.7 branch:
> > > > > https://github.com/apache/tomee/commit/
> > 6522f349d0c31d6ec82e66378e0e55
> > > > > eded08aec0
> > > > >
> > > > > Path:
> > > > >
> > > > > https://patch-diff.githubusercontent.com/raw/
> > apache/tomee/pull/86.diff
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Jonathan Gallimore
> > > > http://twitter.com/jongallimore
> > > > http://www.tomitribe.com
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Romain Manni-Bucau
In reply to this post by jgallimore
good catch for the typo,

-0 to backport it (really read it as "this flag shouldnt have existed
anyway" more than "don't backport it")


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-07 12:43 GMT+02:00 Jonathan Gallimore <[hidden email]>
:

> I think we also have a typo in "FailOnUnknownActivationSpec" where an 'n'
> is missing. I think we should correct that.
>
> https://github.com/apache/tomee/blob/master/container/
> openejb-core/src/main/resources/META-INF/org.apache.
> openejb/service-jar.xml#L494
>
> Jon
>
> On Fri, Jul 7, 2017 at 11:40 AM, Jonathan Gallimore <
> [hidden email]> wrote:
>
> > I'm thinking something along the lines of:
> >
> >   <Container id="MDB1" ctype="MESSAGE">
> >     ResourceAdapter MyResourceAdapter
> >     ActivationSpecClass My.ActivationSpecImpl
> >
> >    activation.property1 = value1
> >    activation.property2 = value2
> >   </Container>
> >
> >   <Container id="MDB2" ctype="MESSAGE">
> >     ResourceAdapter MyOTHERResourceAdapter
> >     ActivationSpecClass My.Other.ActivationSpecImpl
> >    activation.property1 = othervalue1
> >    activation.property2 = othervalue2
> >   </Container>
> >
> > So all the MDBs in container MDB1 would get the following on their
> > activation spec
> >    property1 = value1
> >    property2 = value2
> >
> > And all the MDBs in container MDB2 would get the following on their
> > activation spec
> >    property1 = othervalue1
> >    property2 = othervalue2
> >
> >
> > And then have the potential to override them with system.properties like
> > so:
> >    MDB1.activation.property1 = othervalue1
> >    MDB1.activation.property2 = othervalue2
> >    MDB2.activation.property1 = othervalue1
> >    MDB2.activation.property2 = othervalue2
> >
> > Maybe something is needed to call 'MDB1' out as a container as opposed to
> > a bean name. In terms of precedence, I'd expect properties on the
> container
> > to override any `mdb.activation` properties, and any properties specific
> to
> > a bean to override any container properties - so its Global
> > (mdb.activation) -> Container ([containerid].activation) -> Bean
> > ([BeanName].activation).
> >
> > I imagine it would essentially boil down to a new key at the point you
> > suggest, and expand on the test cases.
> >
> > I'm in favour of the backport irrespective of whether we choose to
> explore
> > my suggestion (or any other suggestion) though.
> >
> > Cheers
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <
> [hidden email]
> > > wrote:
> >
> >> 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <[hidden email]
> >:
> >>
> >> > I'm +1 for back porting that patch, thanks Otavio.
> >> >
> >> > One thing I'd be interested in as an extra, is seeing if we can set
> >> > activation properties on a per-container basis too.
> >> >
> >>
> >> Mean like adding one new key in
> >> https://github.com/apache/tomee/blob/master/container/openej
> >> b-core/src/main/java/org/apache/openejb/config/Activati
> >> onConfigPropertyOverride.java#L94
> >> using .container.<id>?
> >>
> >> +1 if ~so (just wanted to avoid a misunderstanding and get a completely
> >> new
> >> feature/code)
> >>
> >>
> >>
> >> Side note on the fail flag: this was a flag added to pass tck and was in
> >> "ignore" mode of the MDB (which is fine for this need) but not intended
> to
> >> be used or reliable for real applications where it would be saner to fix
> >> the broken configuration instead of bet on it working ignoring the work
> >> some people did configuring it. I'm not against backporting it but think
> >> it
> >> is important to remind that I think we don't want to promote that flag
> >> (shouldn't hit the doc for instance since it is an internal workaround
> >> IMHO).
> >>
> >>
> >> >
> >> > What do you think?
> >> >
> >> > Jon
> >> >
> >> > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> >> > [hidden email]> wrote:
> >> >
> >> > > The problem
> >> > >
> >> > > The configuration for MDB activation properties allow any key/value
> >> to be
> >> > > specified. At present on the 1.7.x branch, the server will fail to
> >> deploy
> >> > > the application if the activation property is not present on the
> >> > activation
> >> > > spec class.
> >> > >
> >> > > This becomes painful in a scenario where more than one JMS resource
> >> > > adapter/MDB container is used, and you wish to configure the
> >> activation
> >> > > properties of multiple MDBs in one go using the `mdb.activation.`
> >> system
> >> > > property.. Right now,if an activation property is used that one
> >> provider
> >> > > uses but other one does, the server will throw an exception.
> >> > >
> >> > > For example, given these parameters,
> >> > >
> >> > >    -
> >> > >
> >> > >       mdb.activation.ignore=foo
> >> > >    -
> >> > >
> >> > >       mdb.activation.ignore2=bar
> >> > >
> >> > >
> >> > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation
> spec
> >> > > class, the following exception will be thrown.
> >> > >
> >> > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> >> > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> >> > Unable
> >> > > to create activation spec: No setter found for the activation spec
> >> > > properties: [ignore, ignore2]: Unable to create activation spec: No
> >> > setter
> >> > > found for the activation spec properties: [ignore, ignore2]
> >> > >
> >> > >    at
> >> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> >> > > Assembler.java:1430)
> >> > >
> >> > >    at
> >> > > org.apache.openejb.assembler.classic.Assembler.
> >> > > createApplication(Assembler.java:796)
> >> > >
> >> > >    ... 19 more
> >> > >
> >> > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> >> > > activation
> >> > > spec: No setter found for the activation spec properties: [ignore,
> >> > ignore2]
> >> > >
> >> > >    at
> >> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> >> > > MdbContainer.java:292)
> >> > >
> >> > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> >> > > MdbContainer.java:159)
> >> > >
> >> > >    at
> >> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> >> > > Assembler.java:1417)
> >> > >
> >> > >    ... 20 more
> >> > >
> >> > > Caused by: java.lang.IllegalArgumentException: No setter found for
> >> the
> >> > > activation spec properties: [ignore, ignore2]
> >> > >
> >> > >    at
> >> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> >> > > MdbContainer.java:262)
> >> > >
> >> > >    ... 22 more
> >> > >
> >> > >
> >> > > The solution
> >> > >
> >> > > The best solution to solve the communication among server is to put
> a
> >> new
> >> > > configuration property in TomEE. When this setting is enabled,
> >> overriding
> >> > > the FailOnUnknownActivationSpec attribute at
> >> > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> >> disabled
> >> > by
> >> > > default to don't break the compatibility, when the setter does not
> >> exist
> >> > it
> >> > > put a log and then keep working.
> >> > >
> >> > > Basically, my proposal does a backport to 1.7 branch:
> >> > > https://github.com/apache/tomee/commit/
> 6522f349d0c31d6ec82e66378e0e55
> >> > > eded08aec0
> >> > >
> >> > > Path:
> >> > >
> >> > > https://patch-diff.githubusercontent.com/raw/apache/tomee/
> >> pull/86.diff
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Jonathan Gallimore
> >> > http://twitter.com/jongallimore
> >> > http://www.tomitribe.com
> >> >
> >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Otávio Gonçalves de Santana
In reply to this post by jgallimore
Sure, I can fix it on the master.
About the activation properties on a per-container basis, I agree, however
as a different diff path.

On Fri, Jul 7, 2017 at 7:44 AM, Jonathan Gallimore <
[hidden email]> wrote:

> Thanks for the feedback Romain! @Otavio - what do you think? You want to
> have a go at that?
>
> Jon
>
> On Fri, Jul 7, 2017 at 11:41 AM, Romain Manni-Bucau <[hidden email]
> >
> wrote:
>
> > sounds good this way for container activation props
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-07 12:40 GMT+02:00 Jonathan Gallimore <
> > [hidden email]>
> > :
> >
> > > I'm thinking something along the lines of:
> > >
> > >   <Container id="MDB1" ctype="MESSAGE">
> > >     ResourceAdapter MyResourceAdapter
> > >     ActivationSpecClass My.ActivationSpecImpl
> > >
> > >    activation.property1 = value1
> > >    activation.property2 = value2
> > >   </Container>
> > >
> > >   <Container id="MDB2" ctype="MESSAGE">
> > >     ResourceAdapter MyOTHERResourceAdapter
> > >     ActivationSpecClass My.Other.ActivationSpecImpl
> > >    activation.property1 = othervalue1
> > >    activation.property2 = othervalue2
> > >   </Container>
> > >
> > > So all the MDBs in container MDB1 would get the following on their
> > > activation spec
> > >    property1 = value1
> > >    property2 = value2
> > >
> > > And all the MDBs in container MDB2 would get the following on their
> > > activation spec
> > >    property1 = othervalue1
> > >    property2 = othervalue2
> > >
> > >
> > > And then have the potential to override them with system.properties
> like
> > > so:
> > >    MDB1.activation.property1 = othervalue1
> > >    MDB1.activation.property2 = othervalue2
> > >    MDB2.activation.property1 = othervalue1
> > >    MDB2.activation.property2 = othervalue2
> > >
> > > Maybe something is needed to call 'MDB1' out as a container as opposed
> > to a
> > > bean name. In terms of precedence, I'd expect properties on the
> container
> > > to override any `mdb.activation` properties, and any properties
> specific
> > to
> > > a bean to override any container properties - so its Global
> > > (mdb.activation) -> Container ([containerid].activation) -> Bean
> > > ([BeanName].activation).
> > >
> > > I imagine it would essentially boil down to a new key at the point you
> > > suggest, and expand on the test cases.
> > >
> > > I'm in favour of the backport irrespective of whether we choose to
> > explore
> > > my suggestion (or any other suggestion) though.
> > >
> > > Cheers
> > >
> > > Jon
> > >
> > > On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <
> > [hidden email]
> > > >
> > > wrote:
> > >
> > > > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <
> > [hidden email]
> > > >:
> > > >
> > > > > I'm +1 for back porting that patch, thanks Otavio.
> > > > >
> > > > > One thing I'd be interested in as an extra, is seeing if we can set
> > > > > activation properties on a per-container basis too.
> > > > >
> > > >
> > > > Mean like adding one new key in
> > > > https://github.com/apache/tomee/blob/master/container/
> > > > openejb-core/src/main/java/org/apache/openejb/config/
> > > > ActivationConfigPropertyOverride.java#L94
> > > > using .container.<id>?
> > > >
> > > > +1 if ~so (just wanted to avoid a misunderstanding and get a
> completely
> > > new
> > > > feature/code)
> > > >
> > > >
> > > >
> > > > Side note on the fail flag: this was a flag added to pass tck and was
> > in
> > > > "ignore" mode of the MDB (which is fine for this need) but not
> intended
> > > to
> > > > be used or reliable for real applications where it would be saner to
> > fix
> > > > the broken configuration instead of bet on it working ignoring the
> work
> > > > some people did configuring it. I'm not against backporting it but
> > think
> > > it
> > > > is important to remind that I think we don't want to promote that
> flag
> > > > (shouldn't hit the doc for instance since it is an internal
> workaround
> > > > IMHO).
> > > >
> > > >
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Jon
> > > > >
> > > > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > The problem
> > > > > >
> > > > > > The configuration for MDB activation properties allow any
> key/value
> > > to
> > > > be
> > > > > > specified. At present on the 1.7.x branch, the server will fail
> to
> > > > deploy
> > > > > > the application if the activation property is not present on the
> > > > > activation
> > > > > > spec class.
> > > > > >
> > > > > > This becomes painful in a scenario where more than one JMS
> resource
> > > > > > adapter/MDB container is used, and you wish to configure the
> > > activation
> > > > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > > > system
> > > > > > property.. Right now,if an activation property is used that one
> > > > provider
> > > > > > uses but other one does, the server will throw an exception.
> > > > > >
> > > > > > For example, given these parameters,
> > > > > >
> > > > > >    -
> > > > > >
> > > > > >       mdb.activation.ignore=foo
> > > > > >    -
> > > > > >
> > > > > >       mdb.activation.ignore2=bar
> > > > > >
> > > > > >
> > > > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation
> > spec
> > > > > > class, the following exception will be thrown.
> > > > > >
> > > > > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > > > > 'Listener'.  Exception: class org.apache.openejb.
> OpenEJBException:
> > > > > Unable
> > > > > > to create activation spec: No setter found for the activation
> spec
> > > > > > properties: [ignore, ignore2]: Unable to create activation spec:
> No
> > > > > setter
> > > > > > found for the activation spec properties: [ignore, ignore2]
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > > Assembler.java:1430)
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.assembler.classic.Assembler.
> > > > > > createApplication(Assembler.java:796)
> > > > > >
> > > > > >    ... 19 more
> > > > > >
> > > > > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > > > > activation
> > > > > > spec: No setter found for the activation spec properties:
> [ignore,
> > > > > ignore2]
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > > MdbContainer.java:292)
> > > > > >
> > > > > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > > > > MdbContainer.java:159)
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > > Assembler.java:1417)
> > > > > >
> > > > > >    ... 20 more
> > > > > >
> > > > > > Caused by: java.lang.IllegalArgumentException: No setter found
> for
> > > the
> > > > > > activation spec properties: [ignore, ignore2]
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > > MdbContainer.java:262)
> > > > > >
> > > > > >    ... 22 more
> > > > > >
> > > > > >
> > > > > > The solution
> > > > > >
> > > > > > The best solution to solve the communication among server is to
> > put a
> > > > new
> > > > > > configuration property in TomEE. When this setting is enabled,
> > > > overriding
> > > > > > the FailOnUnknownActivationSpec attribute at
> > > > > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> > > disabled
> > > > > by
> > > > > > default to don't break the compatibility, when the setter does
> not
> > > > exist
> > > > > it
> > > > > > put a log and then keep working.
> > > > > >
> > > > > > Basically, my proposal does a backport to 1.7 branch:
> > > > > > https://github.com/apache/tomee/commit/
> > > 6522f349d0c31d6ec82e66378e0e55
> > > > > > eded08aec0
> > > > > >
> > > > > > Path:
> > > > > >
> > > > > > https://patch-diff.githubusercontent.com/raw/
> > > apache/tomee/pull/86.diff
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jonathan Gallimore
> > > > > http://twitter.com/jongallimore
> > > > > http://www.tomitribe.com
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

jgallimore
Yep - I'd definitely do that in another PR.

Jon

On Fri, Jul 7, 2017 at 12:30 PM, Otávio Gonçalves de Santana <
[hidden email]> wrote:

> Sure, I can fix it on the master.
> About the activation properties on a per-container basis, I agree, however
> as a different diff path.
>
> On Fri, Jul 7, 2017 at 7:44 AM, Jonathan Gallimore <
> [hidden email]> wrote:
>
> > Thanks for the feedback Romain! @Otavio - what do you think? You want to
> > have a go at that?
> >
> > Jon
> >
> > On Fri, Jul 7, 2017 at 11:41 AM, Romain Manni-Bucau <
> [hidden email]
> > >
> > wrote:
> >
> > > sounds good this way for container activation props
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2017-07-07 12:40 GMT+02:00 Jonathan Gallimore <
> > > [hidden email]>
> > > :
> > >
> > > > I'm thinking something along the lines of:
> > > >
> > > >   <Container id="MDB1" ctype="MESSAGE">
> > > >     ResourceAdapter MyResourceAdapter
> > > >     ActivationSpecClass My.ActivationSpecImpl
> > > >
> > > >    activation.property1 = value1
> > > >    activation.property2 = value2
> > > >   </Container>
> > > >
> > > >   <Container id="MDB2" ctype="MESSAGE">
> > > >     ResourceAdapter MyOTHERResourceAdapter
> > > >     ActivationSpecClass My.Other.ActivationSpecImpl
> > > >    activation.property1 = othervalue1
> > > >    activation.property2 = othervalue2
> > > >   </Container>
> > > >
> > > > So all the MDBs in container MDB1 would get the following on their
> > > > activation spec
> > > >    property1 = value1
> > > >    property2 = value2
> > > >
> > > > And all the MDBs in container MDB2 would get the following on their
> > > > activation spec
> > > >    property1 = othervalue1
> > > >    property2 = othervalue2
> > > >
> > > >
> > > > And then have the potential to override them with system.properties
> > like
> > > > so:
> > > >    MDB1.activation.property1 = othervalue1
> > > >    MDB1.activation.property2 = othervalue2
> > > >    MDB2.activation.property1 = othervalue1
> > > >    MDB2.activation.property2 = othervalue2
> > > >
> > > > Maybe something is needed to call 'MDB1' out as a container as
> opposed
> > > to a
> > > > bean name. In terms of precedence, I'd expect properties on the
> > container
> > > > to override any `mdb.activation` properties, and any properties
> > specific
> > > to
> > > > a bean to override any container properties - so its Global
> > > > (mdb.activation) -> Container ([containerid].activation) -> Bean
> > > > ([BeanName].activation).
> > > >
> > > > I imagine it would essentially boil down to a new key at the point
> you
> > > > suggest, and expand on the test cases.
> > > >
> > > > I'm in favour of the backport irrespective of whether we choose to
> > > explore
> > > > my suggestion (or any other suggestion) though.
> > > >
> > > > Cheers
> > > >
> > > > Jon
> > > >
> > > > On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <
> > > [hidden email]
> > > > >
> > > > wrote:
> > > >
> > > > > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <
> > > [hidden email]
> > > > >:
> > > > >
> > > > > > I'm +1 for back porting that patch, thanks Otavio.
> > > > > >
> > > > > > One thing I'd be interested in as an extra, is seeing if we can
> set
> > > > > > activation properties on a per-container basis too.
> > > > > >
> > > > >
> > > > > Mean like adding one new key in
> > > > > https://github.com/apache/tomee/blob/master/container/
> > > > > openejb-core/src/main/java/org/apache/openejb/config/
> > > > > ActivationConfigPropertyOverride.java#L94
> > > > > using .container.<id>?
> > > > >
> > > > > +1 if ~so (just wanted to avoid a misunderstanding and get a
> > completely
> > > > new
> > > > > feature/code)
> > > > >
> > > > >
> > > > >
> > > > > Side note on the fail flag: this was a flag added to pass tck and
> was
> > > in
> > > > > "ignore" mode of the MDB (which is fine for this need) but not
> > intended
> > > > to
> > > > > be used or reliable for real applications where it would be saner
> to
> > > fix
> > > > > the broken configuration instead of bet on it working ignoring the
> > work
> > > > > some people did configuring it. I'm not against backporting it but
> > > think
> > > > it
> > > > > is important to remind that I think we don't want to promote that
> > flag
> > > > > (shouldn't hit the doc for instance since it is an internal
> > workaround
> > > > > IMHO).
> > > > >
> > > > >
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Jon
> > > > > >
> > > > > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > > > > [hidden email]> wrote:
> > > > > >
> > > > > > > The problem
> > > > > > >
> > > > > > > The configuration for MDB activation properties allow any
> > key/value
> > > > to
> > > > > be
> > > > > > > specified. At present on the 1.7.x branch, the server will fail
> > to
> > > > > deploy
> > > > > > > the application if the activation property is not present on
> the
> > > > > > activation
> > > > > > > spec class.
> > > > > > >
> > > > > > > This becomes painful in a scenario where more than one JMS
> > resource
> > > > > > > adapter/MDB container is used, and you wish to configure the
> > > > activation
> > > > > > > properties of multiple MDBs in one go using the
> `mdb.activation.`
> > > > > system
> > > > > > > property.. Right now,if an activation property is used that one
> > > > > provider
> > > > > > > uses but other one does, the server will throw an exception.
> > > > > > >
> > > > > > > For example, given these parameters,
> > > > > > >
> > > > > > >    -
> > > > > > >
> > > > > > >       mdb.activation.ignore=foo
> > > > > > >    -
> > > > > > >
> > > > > > >       mdb.activation.ignore2=bar
> > > > > > >
> > > > > > >
> > > > > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s
> activation
> > > spec
> > > > > > > class, the following exception will be thrown.
> > > > > > >
> > > > > > > Caused by: org.apache.openejb.OpenEJBException: Error
> deploying
> > > > > > > 'Listener'.  Exception: class org.apache.openejb.
> > OpenEJBException:
> > > > > > Unable
> > > > > > > to create activation spec: No setter found for the activation
> > spec
> > > > > > > properties: [ignore, ignore2]: Unable to create activation
> spec:
> > No
> > > > > > setter
> > > > > > > found for the activation spec properties: [ignore, ignore2]
> > > > > > >
> > > > > > >    at
> > > > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > > > Assembler.java:1430)
> > > > > > >
> > > > > > >    at
> > > > > > > org.apache.openejb.assembler.classic.Assembler.
> > > > > > > createApplication(Assembler.java:796)
> > > > > > >
> > > > > > >    ... 19 more
> > > > > > >
> > > > > > > Caused by: org.apache.openejb.OpenEJBException: Unable to
> create
> > > > > > > activation
> > > > > > > spec: No setter found for the activation spec properties:
> > [ignore,
> > > > > > ignore2]
> > > > > > >
> > > > > > >    at
> > > > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > > > MdbContainer.java:292)
> > > > > > >
> > > > > > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > > > > > MdbContainer.java:159)
> > > > > > >
> > > > > > >    at
> > > > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > > > Assembler.java:1417)
> > > > > > >
> > > > > > >    ... 20 more
> > > > > > >
> > > > > > > Caused by: java.lang.IllegalArgumentException: No setter found
> > for
> > > > the
> > > > > > > activation spec properties: [ignore, ignore2]
> > > > > > >
> > > > > > >    at
> > > > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > > > MdbContainer.java:262)
> > > > > > >
> > > > > > >    ... 22 more
> > > > > > >
> > > > > > >
> > > > > > > The solution
> > > > > > >
> > > > > > > The best solution to solve the communication among server is to
> > > put a
> > > > > new
> > > > > > > configuration property in TomEE. When this setting is enabled,
> > > > > overriding
> > > > > > > the FailOnUnknownActivationSpec attribute at
> > > > > > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> > > > disabled
> > > > > > by
> > > > > > > default to don't break the compatibility, when the setter does
> > not
> > > > > exist
> > > > > > it
> > > > > > > put a log and then keep working.
> > > > > > >
> > > > > > > Basically, my proposal does a backport to 1.7 branch:
> > > > > > > https://github.com/apache/tomee/commit/
> > > > 6522f349d0c31d6ec82e66378e0e55
> > > > > > > eded08aec0
> > > > > > >
> > > > > > > Path:
> > > > > > >
> > > > > > > https://patch-diff.githubusercontent.com/raw/
> > > > apache/tomee/pull/86.diff
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jonathan Gallimore
> > > > > > http://twitter.com/jongallimore
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

jgallimore
In reply to this post by Otávio Gonçalves de Santana
We have a +1 and a +0 for the backport. I'm pulling the latest code and
running the tests. If it looks ok, I'll merge it, while Otavio works on the
container-based config in another patch. Please shout if you have any
objections.

Otavio, let us know if you need any help or guidance on the container based
settings!

Jon

On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
[hidden email]> wrote:

> The problem
>
> The configuration for MDB activation properties allow any key/value to be
> specified. At present on the 1.7.x branch, the server will fail to deploy
> the application if the activation property is not present on the activation
> spec class.
>
> This becomes painful in a scenario where more than one JMS resource
> adapter/MDB container is used, and you wish to configure the activation
> properties of multiple MDBs in one go using the `mdb.activation.` system
> property.. Right now,if an activation property is used that one provider
> uses but other one does, the server will throw an exception.
>
> For example, given these parameters,
>
>    -
>
>       mdb.activation.ignore=foo
>    -
>
>       mdb.activation.ignore2=bar
>
>
> if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> class, the following exception will be thrown.
>
> Caused by: org.apache.openejb.OpenEJBException: Error deploying
> 'Listener'.  Exception: class org.apache.openejb.OpenEJBException: Unable
> to create activation spec: No setter found for the activation spec
> properties: [ignore, ignore2]: Unable to create activation spec: No setter
> found for the activation spec properties: [ignore, ignore2]
>
>    at
> org.apache.openejb.assembler.classic.Assembler.startEjbs(
> Assembler.java:1430)
>
>    at
> org.apache.openejb.assembler.classic.Assembler.
> createApplication(Assembler.java:796)
>
>    ... 19 more
>
> Caused by: org.apache.openejb.OpenEJBException: Unable to create
> activation
> spec: No setter found for the activation spec properties: [ignore, ignore2]
>
>    at
> org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> MdbContainer.java:292)
>
>    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> MdbContainer.java:159)
>
>    at
> org.apache.openejb.assembler.classic.Assembler.startEjbs(
> Assembler.java:1417)
>
>    ... 20 more
>
> Caused by: java.lang.IllegalArgumentException: No setter found for the
> activation spec properties: [ignore, ignore2]
>
>    at
> org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> MdbContainer.java:262)
>
>    ... 22 more
>
>
> The solution
>
> The best solution to solve the communication among server is to put a new
> configuration property in TomEE. When this setting is enabled, overriding
> the FailOnUnknownActivationSpec attribute at
> org.apache.openejb.core.mdb.MdbContainer class., that will be disabled by
> default to don't break the compatibility, when the setter does not exist it
> put a log and then keep working.
>
> Basically, my proposal does a backport to 1.7 branch:
> https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> eded08aec0
>
> Path:
>
> https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Otávio Gonçalves de Santana
I have created this resource to both master and backported.


   - https://github.com/apache/tomee/pull/90
   - https://github.com/apache/tomee/pull/89


On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
[hidden email]> wrote:

> We have a +1 and a +0 for the backport. I'm pulling the latest code and
> running the tests. If it looks ok, I'll merge it, while Otavio works on the
> container-based config in another patch. Please shout if you have any
> objections.
>
> Otavio, let us know if you need any help or guidance on the container based
> settings!
>
> Jon
>
> On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> [hidden email]> wrote:
>
> > The problem
> >
> > The configuration for MDB activation properties allow any key/value to be
> > specified. At present on the 1.7.x branch, the server will fail to deploy
> > the application if the activation property is not present on the
> activation
> > spec class.
> >
> > This becomes painful in a scenario where more than one JMS resource
> > adapter/MDB container is used, and you wish to configure the activation
> > properties of multiple MDBs in one go using the `mdb.activation.` system
> > property.. Right now,if an activation property is used that one provider
> > uses but other one does, the server will throw an exception.
> >
> > For example, given these parameters,
> >
> >    -
> >
> >       mdb.activation.ignore=foo
> >    -
> >
> >       mdb.activation.ignore2=bar
> >
> >
> > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > class, the following exception will be thrown.
> >
> > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> Unable
> > to create activation spec: No setter found for the activation spec
> > properties: [ignore, ignore2]: Unable to create activation spec: No
> setter
> > found for the activation spec properties: [ignore, ignore2]
> >
> >    at
> > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > Assembler.java:1430)
> >
> >    at
> > org.apache.openejb.assembler.classic.Assembler.
> > createApplication(Assembler.java:796)
> >
> >    ... 19 more
> >
> > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > activation
> > spec: No setter found for the activation spec properties: [ignore,
> ignore2]
> >
> >    at
> > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > MdbContainer.java:292)
> >
> >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > MdbContainer.java:159)
> >
> >    at
> > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > Assembler.java:1417)
> >
> >    ... 20 more
> >
> > Caused by: java.lang.IllegalArgumentException: No setter found for the
> > activation spec properties: [ignore, ignore2]
> >
> >    at
> > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > MdbContainer.java:262)
> >
> >    ... 22 more
> >
> >
> > The solution
> >
> > The best solution to solve the communication among server is to put a new
> > configuration property in TomEE. When this setting is enabled, overriding
> > the FailOnUnknownActivationSpec attribute at
> > org.apache.openejb.core.mdb.MdbContainer class., that will be disabled
> by
> > default to don't break the compatibility, when the setter does not exist
> it
> > put a log and then keep working.
> >
> > Basically, my proposal does a backport to 1.7 branch:
> > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> > eded08aec0
> >
> > Path:
> >
> > https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Romain Manni-Bucau
Hi Otavio,

I have 2 notes on this:

1. the getProperties() is useless I think (IDE generated?)
2. it would probably better fit ActivationConfigPropertyOverride to have a
right ordering of overrides, no?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-12 13:42 GMT+02:00 Otávio Gonçalves de Santana <
[hidden email]>:

> I have created this resource to both master and backported.
>
>
>    - https://github.com/apache/tomee/pull/90
>    - https://github.com/apache/tomee/pull/89
>
>
> On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> [hidden email]> wrote:
>
> > We have a +1 and a +0 for the backport. I'm pulling the latest code and
> > running the tests. If it looks ok, I'll merge it, while Otavio works on
> the
> > container-based config in another patch. Please shout if you have any
> > objections.
> >
> > Otavio, let us know if you need any help or guidance on the container
> based
> > settings!
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > [hidden email]> wrote:
> >
> > > The problem
> > >
> > > The configuration for MDB activation properties allow any key/value to
> be
> > > specified. At present on the 1.7.x branch, the server will fail to
> deploy
> > > the application if the activation property is not present on the
> > activation
> > > spec class.
> > >
> > > This becomes painful in a scenario where more than one JMS resource
> > > adapter/MDB container is used, and you wish to configure the activation
> > > properties of multiple MDBs in one go using the `mdb.activation.`
> system
> > > property.. Right now,if an activation property is used that one
> provider
> > > uses but other one does, the server will throw an exception.
> > >
> > > For example, given these parameters,
> > >
> > >    -
> > >
> > >       mdb.activation.ignore=foo
> > >    -
> > >
> > >       mdb.activation.ignore2=bar
> > >
> > >
> > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > > class, the following exception will be thrown.
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > Unable
> > > to create activation spec: No setter found for the activation spec
> > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > setter
> > > found for the activation spec properties: [ignore, ignore2]
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1430)
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:796)
> > >
> > >    ... 19 more
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > activation
> > > spec: No setter found for the activation spec properties: [ignore,
> > ignore2]
> > >
> > >    at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:292)
> > >
> > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > MdbContainer.java:159)
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1417)
> > >
> > >    ... 20 more
> > >
> > > Caused by: java.lang.IllegalArgumentException: No setter found for the
> > > activation spec properties: [ignore, ignore2]
> > >
> > >    at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:262)
> > >
> > >    ... 22 more
> > >
> > >
> > > The solution
> > >
> > > The best solution to solve the communication among server is to put a
> new
> > > configuration property in TomEE. When this setting is enabled,
> overriding
> > > the FailOnUnknownActivationSpec attribute at
> > > org.apache.openejb.core.mdb.MdbContainer class., that will be disabled
> > by
> > > default to don't break the compatibility, when the setter does not
> exist
> > it
> > > put a log and then keep working.
> > >
> > > Basically, my proposal does a backport to 1.7 branch:
> > > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> > > eded08aec0
> > >
> > > Path:
> > >
> > > https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

jgallimore
In reply to this post by Otávio Gonçalves de Santana
Hi Otavio

Can you give us a bit of a description about the change, and maybe a sample
config? Just so everyone has some context on the change?

At first glance, I'd say your testing is missing at least a scenario where
the container activation properties
(mdb.container.[containerID].activation.[property] = [value]) can be
overridden using system properties. Tests around bean properties overriding
container properties would be good too, as would testing both bean and
container properties being overridden by system properties.

Cheers

Jon

On Wed, Jul 12, 2017 at 12:42 PM, Otávio Gonçalves de Santana <
[hidden email]> wrote:

> I have created this resource to both master and backported.
>
>
>    - https://github.com/apache/tomee/pull/90
>    - https://github.com/apache/tomee/pull/89
>
>
> On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> [hidden email]> wrote:
>
> > We have a +1 and a +0 for the backport. I'm pulling the latest code and
> > running the tests. If it looks ok, I'll merge it, while Otavio works on
> the
> > container-based config in another patch. Please shout if you have any
> > objections.
> >
> > Otavio, let us know if you need any help or guidance on the container
> based
> > settings!
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > [hidden email]> wrote:
> >
> > > The problem
> > >
> > > The configuration for MDB activation properties allow any key/value to
> be
> > > specified. At present on the 1.7.x branch, the server will fail to
> deploy
> > > the application if the activation property is not present on the
> > activation
> > > spec class.
> > >
> > > This becomes painful in a scenario where more than one JMS resource
> > > adapter/MDB container is used, and you wish to configure the activation
> > > properties of multiple MDBs in one go using the `mdb.activation.`
> system
> > > property.. Right now,if an activation property is used that one
> provider
> > > uses but other one does, the server will throw an exception.
> > >
> > > For example, given these parameters,
> > >
> > >    -
> > >
> > >       mdb.activation.ignore=foo
> > >    -
> > >
> > >       mdb.activation.ignore2=bar
> > >
> > >
> > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > > class, the following exception will be thrown.
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > Unable
> > > to create activation spec: No setter found for the activation spec
> > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > setter
> > > found for the activation spec properties: [ignore, ignore2]
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1430)
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:796)
> > >
> > >    ... 19 more
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > activation
> > > spec: No setter found for the activation spec properties: [ignore,
> > ignore2]
> > >
> > >    at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:292)
> > >
> > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > MdbContainer.java:159)
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1417)
> > >
> > >    ... 20 more
> > >
> > > Caused by: java.lang.IllegalArgumentException: No setter found for the
> > > activation spec properties: [ignore, ignore2]
> > >
> > >    at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:262)
> > >
> > >    ... 22 more
> > >
> > >
> > > The solution
> > >
> > > The best solution to solve the communication among server is to put a
> new
> > > configuration property in TomEE. When this setting is enabled,
> overriding
> > > the FailOnUnknownActivationSpec attribute at
> > > org.apache.openejb.core.mdb.MdbContainer class., that will be disabled
> > by
> > > default to don't break the compatibility, when the setter does not
> exist
> > it
> > > put a log and then keep working.
> > >
> > > Basically, my proposal does a backport to 1.7 branch:
> > > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> > > eded08aec0
> > >
> > > Path:
> > >
> > > https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Otávio Gonçalves de Santana
In reply to this post by Romain Manni-Bucau
1) Getter removed, thanks
2) I took a look at that. As far as I can see, we don't have the container
(or its ID) available at the time when ActivationConfigPropertyOverride.
Please let us know if we've missed something there.

On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <[hidden email]>
wrote:

> Hi Otavio,
>
> I have 2 notes on this:
>
> 1. the getProperties() is useless I think (IDE generated?)
> 2. it would probably better fit ActivationConfigPropertyOverride to have a
> right ordering of overrides, no?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-12 13:42 GMT+02:00 Otávio Gonçalves de Santana <
> [hidden email]>:
>
> > I have created this resource to both master and backported.
> >
> >
> >    - https://github.com/apache/tomee/pull/90
> >    - https://github.com/apache/tomee/pull/89
> >
> >
> > On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> > [hidden email]> wrote:
> >
> > > We have a +1 and a +0 for the backport. I'm pulling the latest code and
> > > running the tests. If it looks ok, I'll merge it, while Otavio works on
> > the
> > > container-based config in another patch. Please shout if you have any
> > > objections.
> > >
> > > Otavio, let us know if you need any help or guidance on the container
> > based
> > > settings!
> > >
> > > Jon
> > >
> > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > [hidden email]> wrote:
> > >
> > > > The problem
> > > >
> > > > The configuration for MDB activation properties allow any key/value
> to
> > be
> > > > specified. At present on the 1.7.x branch, the server will fail to
> > deploy
> > > > the application if the activation property is not present on the
> > > activation
> > > > spec class.
> > > >
> > > > This becomes painful in a scenario where more than one JMS resource
> > > > adapter/MDB container is used, and you wish to configure the
> activation
> > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > system
> > > > property.. Right now,if an activation property is used that one
> > provider
> > > > uses but other one does, the server will throw an exception.
> > > >
> > > > For example, given these parameters,
> > > >
> > > >    -
> > > >
> > > >       mdb.activation.ignore=foo
> > > >    -
> > > >
> > > >       mdb.activation.ignore2=bar
> > > >
> > > >
> > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > > > class, the following exception will be thrown.
> > > >
> > > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > > Unable
> > > > to create activation spec: No setter found for the activation spec
> > > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > > setter
> > > > found for the activation spec properties: [ignore, ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > Assembler.java:1430)
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.
> > > > createApplication(Assembler.java:796)
> > > >
> > > >    ... 19 more
> > > >
> > > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > > activation
> > > > spec: No setter found for the activation spec properties: [ignore,
> > > ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > MdbContainer.java:292)
> > > >
> > > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > > MdbContainer.java:159)
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > Assembler.java:1417)
> > > >
> > > >    ... 20 more
> > > >
> > > > Caused by: java.lang.IllegalArgumentException: No setter found for
> the
> > > > activation spec properties: [ignore, ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > MdbContainer.java:262)
> > > >
> > > >    ... 22 more
> > > >
> > > >
> > > > The solution
> > > >
> > > > The best solution to solve the communication among server is to put a
> > new
> > > > configuration property in TomEE. When this setting is enabled,
> > overriding
> > > > the FailOnUnknownActivationSpec attribute at
> > > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> disabled
> > > by
> > > > default to don't break the compatibility, when the setter does not
> > exist
> > > it
> > > > put a log and then keep working.
> > > >
> > > > Basically, my proposal does a backport to 1.7 branch:
> > > > https://github.com/apache/tomee/commit/
> 6522f349d0c31d6ec82e66378e0e55
> > > > eded08aec0
> > > >
> > > > Path:
> > > >
> > > > https://patch-diff.githubusercontent.com/raw/
> apache/tomee/pull/86.diff
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

jgallimore
In reply to this post by Romain Manni-Bucau
I took a look at that. As far as I can see, we don't have the container (or
its ID) available at the time when ActivationConfigPropertyOverride. Please
let us know if we've missed something there.

Jon

On Wed, Jul 12, 2017 at 1:17 PM, Romain Manni-Bucau <[hidden email]>
wrote:

> Hi Otavio,
>
> I have 2 notes on this:
>
> 1. the getProperties() is useless I think (IDE generated?)
> 2. it would probably better fit ActivationConfigPropertyOverride to have a
> right ordering of overrides, no?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-12 13:42 GMT+02:00 Otávio Gonçalves de Santana <
> [hidden email]>:
>
> > I have created this resource to both master and backported.
> >
> >
> >    - https://github.com/apache/tomee/pull/90
> >    - https://github.com/apache/tomee/pull/89
> >
> >
> > On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> > [hidden email]> wrote:
> >
> > > We have a +1 and a +0 for the backport. I'm pulling the latest code and
> > > running the tests. If it looks ok, I'll merge it, while Otavio works on
> > the
> > > container-based config in another patch. Please shout if you have any
> > > objections.
> > >
> > > Otavio, let us know if you need any help or guidance on the container
> > based
> > > settings!
> > >
> > > Jon
> > >
> > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > [hidden email]> wrote:
> > >
> > > > The problem
> > > >
> > > > The configuration for MDB activation properties allow any key/value
> to
> > be
> > > > specified. At present on the 1.7.x branch, the server will fail to
> > deploy
> > > > the application if the activation property is not present on the
> > > activation
> > > > spec class.
> > > >
> > > > This becomes painful in a scenario where more than one JMS resource
> > > > adapter/MDB container is used, and you wish to configure the
> activation
> > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > system
> > > > property.. Right now,if an activation property is used that one
> > provider
> > > > uses but other one does, the server will throw an exception.
> > > >
> > > > For example, given these parameters,
> > > >
> > > >    -
> > > >
> > > >       mdb.activation.ignore=foo
> > > >    -
> > > >
> > > >       mdb.activation.ignore2=bar
> > > >
> > > >
> > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > > > class, the following exception will be thrown.
> > > >
> > > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > > Unable
> > > > to create activation spec: No setter found for the activation spec
> > > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > > setter
> > > > found for the activation spec properties: [ignore, ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > Assembler.java:1430)
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.
> > > > createApplication(Assembler.java:796)
> > > >
> > > >    ... 19 more
> > > >
> > > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > > activation
> > > > spec: No setter found for the activation spec properties: [ignore,
> > > ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > MdbContainer.java:292)
> > > >
> > > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > > MdbContainer.java:159)
> > > >
> > > >    at
> > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > Assembler.java:1417)
> > > >
> > > >    ... 20 more
> > > >
> > > > Caused by: java.lang.IllegalArgumentException: No setter found for
> the
> > > > activation spec properties: [ignore, ignore2]
> > > >
> > > >    at
> > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > MdbContainer.java:262)
> > > >
> > > >    ... 22 more
> > > >
> > > >
> > > > The solution
> > > >
> > > > The best solution to solve the communication among server is to put a
> > new
> > > > configuration property in TomEE. When this setting is enabled,
> > overriding
> > > > the FailOnUnknownActivationSpec attribute at
> > > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> disabled
> > > by
> > > > default to don't break the compatibility, when the setter does not
> > exist
> > > it
> > > > put a log and then keep working.
> > > >
> > > > Basically, my proposal does a backport to 1.7 branch:
> > > > https://github.com/apache/tomee/commit/
> 6522f349d0c31d6ec82e66378e0e55
> > > > eded08aec0
> > > >
> > > > Path:
> > > >
> > > > https://patch-diff.githubusercontent.com/raw/
> apache/tomee/pull/86.diff
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

jgallimore
In reply to this post by Otávio Gonçalves de Santana
Hi Otavio,

Can you give us a bit of a description about the change, and maybe a sample config? Just so everyone has some context on the change?

At first glance, I'd say your testing is missing at least a scenario where the container activation properties (mdb.container.[containerID].activation.[property] = [value]) can be overridden using system properties. Tests around bean properties overriding container properties would be good too, as would testing both bean and container properties being overridden by system properties.

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

Re: Adds an option to ignore mdb.activation fields

Romain Manni-Bucau
In reply to this post by Otávio Gonçalves de Santana
org.apache.openejb.jee.oejb3.EjbDeployment#getContainerId should give you
the container


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-12 14:29 GMT+02:00 Otávio Gonçalves de Santana <
[hidden email]>:

> 1) Getter removed, thanks
> 2) I took a look at that. As far as I can see, we don't have the container
> (or its ID) available at the time when ActivationConfigPropertyOverride.
> Please let us know if we've missed something there.
>
> On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <[hidden email]
> >
> wrote:
>
> > Hi Otavio,
> >
> > I have 2 notes on this:
> >
> > 1. the getProperties() is useless I think (IDE generated?)
> > 2. it would probably better fit ActivationConfigPropertyOverride to
> have a
> > right ordering of overrides, no?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-12 13:42 GMT+02:00 Otávio Gonçalves de Santana <
> > [hidden email]>:
> >
> > > I have created this resource to both master and backported.
> > >
> > >
> > >    - https://github.com/apache/tomee/pull/90
> > >    - https://github.com/apache/tomee/pull/89
> > >
> > >
> > > On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> > > [hidden email]> wrote:
> > >
> > > > We have a +1 and a +0 for the backport. I'm pulling the latest code
> and
> > > > running the tests. If it looks ok, I'll merge it, while Otavio works
> on
> > > the
> > > > container-based config in another patch. Please shout if you have any
> > > > objections.
> > > >
> > > > Otavio, let us know if you need any help or guidance on the container
> > > based
> > > > settings!
> > > >
> > > > Jon
> > > >
> > > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > > [hidden email]> wrote:
> > > >
> > > > > The problem
> > > > >
> > > > > The configuration for MDB activation properties allow any key/value
> > to
> > > be
> > > > > specified. At present on the 1.7.x branch, the server will fail to
> > > deploy
> > > > > the application if the activation property is not present on the
> > > > activation
> > > > > spec class.
> > > > >
> > > > > This becomes painful in a scenario where more than one JMS resource
> > > > > adapter/MDB container is used, and you wish to configure the
> > activation
> > > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > > system
> > > > > property.. Right now,if an activation property is used that one
> > > provider
> > > > > uses but other one does, the server will throw an exception.
> > > > >
> > > > > For example, given these parameters,
> > > > >
> > > > >    -
> > > > >
> > > > >       mdb.activation.ignore=foo
> > > > >    -
> > > > >
> > > > >       mdb.activation.ignore2=bar
> > > > >
> > > > >
> > > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation
> spec
> > > > > class, the following exception will be thrown.
> > > > >
> > > > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > > > Unable
> > > > > to create activation spec: No setter found for the activation spec
> > > > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > > > setter
> > > > > found for the activation spec properties: [ignore, ignore2]
> > > > >
> > > > >    at
> > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > Assembler.java:1430)
> > > > >
> > > > >    at
> > > > > org.apache.openejb.assembler.classic.Assembler.
> > > > > createApplication(Assembler.java:796)
> > > > >
> > > > >    ... 19 more
> > > > >
> > > > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > > > activation
> > > > > spec: No setter found for the activation spec properties: [ignore,
> > > > ignore2]
> > > > >
> > > > >    at
> > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > MdbContainer.java:292)
> > > > >
> > > > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > > > MdbContainer.java:159)
> > > > >
> > > > >    at
> > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > Assembler.java:1417)
> > > > >
> > > > >    ... 20 more
> > > > >
> > > > > Caused by: java.lang.IllegalArgumentException: No setter found for
> > the
> > > > > activation spec properties: [ignore, ignore2]
> > > > >
> > > > >    at
> > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > MdbContainer.java:262)
> > > > >
> > > > >    ... 22 more
> > > > >
> > > > >
> > > > > The solution
> > > > >
> > > > > The best solution to solve the communication among server is to
> put a
> > > new
> > > > > configuration property in TomEE. When this setting is enabled,
> > > overriding
> > > > > the FailOnUnknownActivationSpec attribute at
> > > > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> > disabled
> > > > by
> > > > > default to don't break the compatibility, when the setter does not
> > > exist
> > > > it
> > > > > put a log and then keep working.
> > > > >
> > > > > Basically, my proposal does a backport to 1.7 branch:
> > > > > https://github.com/apache/tomee/commit/
> > 6522f349d0c31d6ec82e66378e0e55
> > > > > eded08aec0
> > > > >
> > > > > Path:
> > > > >
> > > > > https://patch-diff.githubusercontent.com/raw/
> > apache/tomee/pull/86.diff
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Jonathan Gallimore-2
In reply to this post by Otávio Gonçalves de Santana
Hi Otavio
Can you give us a bit of a description about the change, and maybe a sample config? Just so everyone has some context on the change?

At first glance, I'd say your testing is missing at least a scenario where the container activation properties (mdb.container.[containerID].activation.[property] = [value]) can be overridden using system properties. Tests around bean properties overriding container properties would be good too, as would testing both bean and container properties being overridden by system properties.

Cheers
Jon

On 2017-07-12 12:42 (+0100), Otávio Gonçalves de Santana <[hidden email]> wrote:

> I have created this resource to both master and backported.
>
>
>    - https://github.com/apache/tomee/pull/90
>    - https://github.com/apache/tomee/pull/89
>
>
> On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> [hidden email]> wrote:
>
> > We have a +1 and a +0 for the backport. I'm pulling the latest code and
> > running the tests. If it looks ok, I'll merge it, while Otavio works on the
> > container-based config in another patch. Please shout if you have any
> > objections.
> >
> > Otavio, let us know if you need any help or guidance on the container based
> > settings!
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > [hidden email]> wrote:
> >
> > > The problem
> > >
> > > The configuration for MDB activation properties allow any key/value to be
> > > specified. At present on the 1.7.x branch, the server will fail to deploy
> > > the application if the activation property is not present on the
> > activation
> > > spec class.
> > >
> > > This becomes painful in a scenario where more than one JMS resource
> > > adapter/MDB container is used, and you wish to configure the activation
> > > properties of multiple MDBs in one go using the `mdb.activation.` system
> > > property.. Right now,if an activation property is used that one provider
> > > uses but other one does, the server will throw an exception.
> > >
> > > For example, given these parameters,
> > >
> > >    -
> > >
> > >       mdb.activation.ignore=foo
> > >    -
> > >
> > >       mdb.activation.ignore2=bar
> > >
> > >
> > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > > class, the following exception will be thrown.
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > Unable
> > > to create activation spec: No setter found for the activation spec
> > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > setter
> > > found for the activation spec properties: [ignore, ignore2]
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1430)
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:796)
> > >
> > >    ... 19 more
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > activation
> > > spec: No setter found for the activation spec properties: [ignore,
> > ignore2]
> > >
> > >    at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:292)
> > >
> > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > MdbContainer.java:159)
> > >
> > >    at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1417)
> > >
> > >    ... 20 more
> > >
> > > Caused by: java.lang.IllegalArgumentException: No setter found for the
> > > activation spec properties: [ignore, ignore2]
> > >
> > >    at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:262)
> > >
> > >    ... 22 more
> > >
> > >
> > > The solution
> > >
> > > The best solution to solve the communication among server is to put a new
> > > configuration property in TomEE. When this setting is enabled, overriding
> > > the FailOnUnknownActivationSpec attribute at
> > > org.apache.openejb.core.mdb.MdbContainer class., that will be disabled
> > by
> > > default to don't break the compatibility, when the setter does not exist
> > it
> > > put a log and then keep working.
> > >
> > > Basically, my proposal does a backport to 1.7 branch:
> > > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> > > eded08aec0
> > >
> > > Path:
> > >
> > > https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adds an option to ignore mdb.activation fields

Otávio Gonçalves de Santana
In reply to this post by Romain Manni-Bucau
String containerId = ejbDeployment.getContainerId();

It returns a container id,
How can I return the container from that?

On Wed, Jul 12, 2017 at 9:40 AM, Romain Manni-Bucau <[hidden email]>
wrote:

> org.apache.openejb.jee.oejb3.EjbDeployment#getContainerId should give you
> the container
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-12 14:29 GMT+02:00 Otávio Gonçalves de Santana <
> [hidden email]>:
>
> > 1) Getter removed, thanks
> > 2) I took a look at that. As far as I can see, we don't have the
> container
> > (or its ID) available at the time when ActivationConfigPropertyOverride.
> > Please let us know if we've missed something there.
> >
> > On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <
> [hidden email]
> > >
> > wrote:
> >
> > > Hi Otavio,
> > >
> > > I have 2 notes on this:
> > >
> > > 1. the getProperties() is useless I think (IDE generated?)
> > > 2. it would probably better fit ActivationConfigPropertyOverride to
> > have a
> > > right ordering of overrides, no?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2017-07-12 13:42 GMT+02:00 Otávio Gonçalves de Santana <
> > > [hidden email]>:
> > >
> > > > I have created this resource to both master and backported.
> > > >
> > > >
> > > >    - https://github.com/apache/tomee/pull/90
> > > >    - https://github.com/apache/tomee/pull/89
> > > >
> > > >
> > > > On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> > > > [hidden email]> wrote:
> > > >
> > > > > We have a +1 and a +0 for the backport. I'm pulling the latest code
> > and
> > > > > running the tests. If it looks ok, I'll merge it, while Otavio
> works
> > on
> > > > the
> > > > > container-based config in another patch. Please shout if you have
> any
> > > > > objections.
> > > > >
> > > > > Otavio, let us know if you need any help or guidance on the
> container
> > > > based
> > > > > settings!
> > > > >
> > > > > Jon
> > > > >
> > > > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > The problem
> > > > > >
> > > > > > The configuration for MDB activation properties allow any
> key/value
> > > to
> > > > be
> > > > > > specified. At present on the 1.7.x branch, the server will fail
> to
> > > > deploy
> > > > > > the application if the activation property is not present on the
> > > > > activation
> > > > > > spec class.
> > > > > >
> > > > > > This becomes painful in a scenario where more than one JMS
> resource
> > > > > > adapter/MDB container is used, and you wish to configure the
> > > activation
> > > > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > > > system
> > > > > > property.. Right now,if an activation property is used that one
> > > > provider
> > > > > > uses but other one does, the server will throw an exception.
> > > > > >
> > > > > > For example, given these parameters,
> > > > > >
> > > > > >    -
> > > > > >
> > > > > >       mdb.activation.ignore=foo
> > > > > >    -
> > > > > >
> > > > > >       mdb.activation.ignore2=bar
> > > > > >
> > > > > >
> > > > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation
> > spec
> > > > > > class, the following exception will be thrown.
> > > > > >
> > > > > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > > > > 'Listener'.  Exception: class org.apache.openejb.
> OpenEJBException:
> > > > > Unable
> > > > > > to create activation spec: No setter found for the activation
> spec
> > > > > > properties: [ignore, ignore2]: Unable to create activation spec:
> No
> > > > > setter
> > > > > > found for the activation spec properties: [ignore, ignore2]
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > > Assembler.java:1430)
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.assembler.classic.Assembler.
> > > > > > createApplication(Assembler.java:796)
> > > > > >
> > > > > >    ... 19 more
> > > > > >
> > > > > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > > > > activation
> > > > > > spec: No setter found for the activation spec properties:
> [ignore,
> > > > > ignore2]
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > > MdbContainer.java:292)
> > > > > >
> > > > > >    at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > > > > MdbContainer.java:159)
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > > > > Assembler.java:1417)
> > > > > >
> > > > > >    ... 20 more
> > > > > >
> > > > > > Caused by: java.lang.IllegalArgumentException: No setter found
> for
> > > the
> > > > > > activation spec properties: [ignore, ignore2]
> > > > > >
> > > > > >    at
> > > > > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > > > > MdbContainer.java:262)
> > > > > >
> > > > > >    ... 22 more
> > > > > >
> > > > > >
> > > > > > The solution
> > > > > >
> > > > > > The best solution to solve the communication among server is to
> > put a
> > > > new
> > > > > > configuration property in TomEE. When this setting is enabled,
> > > > overriding
> > > > > > the FailOnUnknownActivationSpec attribute at
> > > > > > org.apache.openejb.core.mdb.MdbContainer class., that will be
> > > disabled
> > > > > by
> > > > > > default to don't break the compatibility, when the setter does
> not
> > > > exist
> > > > > it
> > > > > > put a log and then keep working.
> > > > > >
> > > > > > Basically, my proposal does a backport to 1.7 branch:
> > > > > > https://github.com/apache/tomee/commit/
> > > 6522f349d0c31d6ec82e66378e0e55
> > > > > > eded08aec0
> > > > > >
> > > > > > Path:
> > > > > >
> > > > > > https://patch-diff.githubusercontent.com/raw/
> > > apache/tomee/pull/86.diff
> > > > > >
> > > > >
> > > >
> > >
> >
>
12
Loading...