You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Otávio Gonçalves de Santana <os...@tomitribe.com> on 2017/07/06 20:44:49 UTC

Adds an option to ignore mdb.activation fields

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

Re: Adds an option to ignore mdb.activation fields

Posted by jgallimore <jo...@gmail.com>.
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



--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/Adds-an-option-to-ignore-mdb-activation-fields-tp4682126p4682233.html
Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: Adds an option to ignore mdb.activation fields

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.
I added the description in the PR too:

Set activation properties on a per-container basis. This change makes
activation properties belongs to a specific container.

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

I'll belong just to a container whose the id is MDB2 otherwise will ignore.

On Wed, Jul 12, 2017 at 9:55 AM, Jonathan Gallimore <jg...@apache.org>
wrote:

> 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 <
> osantana@tomitribe.com> 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 <
> > jonathan.gallimore@gmail.com> 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 <
> > > osantana@tomitribe.com> 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
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jg...@apache.org>.
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 <os...@tomitribe.com> 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 <
> jonathan.gallimore@gmail.com> 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 <
> > osantana@tomitribe.com> 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
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <rm...@gmail.com>
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 <
> osantana@tomitribe.com>:
>
> > 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 <
> > jonathan.gallimore@gmail.com> 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 <
> > > osantana@tomitribe.com> 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
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.
There is other problem:
 ejbDeployment.getContainerId(); //it returns null


On Wed, Jul 12, 2017 at 10:04 AM, Otávio Gonçalves de Santana <
osantana@tomitribe.com> wrote:

> 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 <rmannibucau@gmail.com
> > 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 <
>> osantana@tomitribe.com>:
>>
>> > 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 ActivationConfigPropertyOverri
>> de.
>> > Please let us know if we've missed something there.
>> >
>> > On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com
>> > >
>> > 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 <
>> > > osantana@tomitribe.com>:
>> > >
>> > > > 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 <
>> > > > jonathan.gallimore@gmail.com> 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 <
>> > > > > osantana@tomitribe.com> 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.OpenEJBExce
>> ption:
>> > > > > 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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jo...@gmail.com>.
I took a look at this earlier. Thanks for incorporating the feedback. The
tests in your backport fail for me (see below), but otherwise, unless there
are objections, I think we should merge this in once those tests are fixed.

Thanks

Jon

On Wed, Jul 12, 2017 at 6:00 PM, Otávio Gonçalves de Santana <
osantana@tomitribe.com> wrote:

> Thanks Romain, Jonathan.
>
> I did this change and also put more tests:
>
> https://github.com/apache/tomee/pull/89
>
>
>
> On Wed, Jul 12, 2017 at 10:16 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> wrote:
>
> > SystemInstance.get().getComponent(ContainerSystem.
> class).getContainer(id)
> >
> > Since AutoConfig should pass before it should be set and if not we should
> > just move the override dynamicdeployer at the right place to have it set
> > and still be read by its consumers. In any case, not splitting the
> override
> > logic is key for maintenance and ensure it is done in the right order
> > (which is something to ensure we test - override priorities)
> >
> >
> > 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 15:04 GMT+02:00 Otávio Gonçalves de Santana <
> > osantana@tomitribe.com>:
> >
> > > 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 <
> > rmannibucau@gmail.com
> > > >
> > > 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 <
> > > > osantana@tomitribe.com>:
> > > >
> > > > > 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
> ActivationConfigPropertyOverri
> > > de.
> > > > > Please let us know if we've missed something there.
> > > > >
> > > > > On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <
> > > > rmannibucau@gmail.com
> > > > > >
> > > > > 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 <
> > > > > > osantana@tomitribe.com>:
> > > > > >
> > > > > > > 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 <
> > > > > > > jonathan.gallimore@gmail.com> 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 <
> > > > > > > > osantana@tomitribe.com> 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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.
Thanks Romain, Jonathan.

I did this change and also put more tests:

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



On Wed, Jul 12, 2017 at 10:16 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> SystemInstance.get().getComponent(ContainerSystem.class).getContainer(id)
>
> Since AutoConfig should pass before it should be set and if not we should
> just move the override dynamicdeployer at the right place to have it set
> and still be read by its consumers. In any case, not splitting the override
> logic is key for maintenance and ensure it is done in the right order
> (which is something to ensure we test - override priorities)
>
>
> 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 15:04 GMT+02:00 Otávio Gonçalves de Santana <
> osantana@tomitribe.com>:
>
> > 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 <
> rmannibucau@gmail.com
> > >
> > 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 <
> > > osantana@tomitribe.com>:
> > >
> > > > 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 ActivationConfigPropertyOverri
> > de.
> > > > Please let us know if we've missed something there.
> > > >
> > > > On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > 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 <
> > > > > osantana@tomitribe.com>:
> > > > >
> > > > > > 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 <
> > > > > > jonathan.gallimore@gmail.com> 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 <
> > > > > > > osantana@tomitribe.com> 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Romain Manni-Bucau <rm...@gmail.com>.
SystemInstance.get().getComponent(ContainerSystem.class).getContainer(id)

Since AutoConfig should pass before it should be set and if not we should
just move the override dynamicdeployer at the right place to have it set
and still be read by its consumers. In any case, not splitting the override
logic is key for maintenance and ensure it is done in the right order
(which is something to ensure we test - override priorities)


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 15:04 GMT+02:00 Otávio Gonçalves de Santana <
osantana@tomitribe.com>:

> 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 <rmannibucau@gmail.com
> >
> 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 <
> > osantana@tomitribe.com>:
> >
> > > 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 ActivationConfigPropertyOverri
> de.
> > > Please let us know if we've missed something there.
> > >
> > > On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > 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 <
> > > > osantana@tomitribe.com>:
> > > >
> > > > > 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 <
> > > > > jonathan.gallimore@gmail.com> 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 <
> > > > > > osantana@tomitribe.com> 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.
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 <rm...@gmail.com>
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 <
> osantana@tomitribe.com>:
>
> > 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 <
> rmannibucau@gmail.com
> > >
> > 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 <
> > > osantana@tomitribe.com>:
> > >
> > > > 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 <
> > > > jonathan.gallimore@gmail.com> 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 <
> > > > > osantana@tomitribe.com> 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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <
osantana@tomitribe.com>:

> 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 <rmannibucau@gmail.com
> >
> 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 <
> > osantana@tomitribe.com>:
> >
> > > 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 <
> > > jonathan.gallimore@gmail.com> 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 <
> > > > osantana@tomitribe.com> 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
> > > > >
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.
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 <rm...@gmail.com>
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 <
> osantana@tomitribe.com>:
>
> > 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 <
> > jonathan.gallimore@gmail.com> 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 <
> > > osantana@tomitribe.com> 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
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <
osantana@tomitribe.com>:

> 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 <
> jonathan.gallimore@gmail.com> 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 <
> > osantana@tomitribe.com> 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
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <
osantana@tomitribe.com> 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 <
> jonathan.gallimore@gmail.com> 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 <
> > osantana@tomitribe.com> 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
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.
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 <
jonathan.gallimore@gmail.com> 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 <
> osantana@tomitribe.com> 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
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <
osantana@tomitribe.com> 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
>

Re: Adds an option to ignore mdb.activation fields

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@gmail.com>
:

> 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 <
> jonathan.gallimore@gmail.com> 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 <
> rmannibucau@gmail.com
> > > wrote:
> >
> >> 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <jgallimore@tomitribe.com
> >:
> >>
> >> > 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 <
> >> > osantana@tomitribe.com> 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
> >> >
> >>
> >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <
jonathan.gallimore@gmail.com> 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 <rmannibucau@gmail.com
> > wrote:
>
>> 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <jg...@tomitribe.com>:
>>
>> > 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 <
>> > osantana@tomitribe.com> 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
>> >
>>
>
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <
osantana@tomitribe.com> 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 <
> jonathan.gallimore@gmail.com> 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 <
> rmannibucau@gmail.com
> > >
> > 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 <
> > > jonathan.gallimore@gmail.com>
> > > :
> > >
> > > > 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 <
> > > rmannibucau@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <
> > > jgallimore@tomitribe.com
> > > > >:
> > > > >
> > > > > > 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 <
> > > > > > osantana@tomitribe.com> 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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.
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 <
jonathan.gallimore@gmail.com> 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 <rmannibucau@gmail.com
> >
> 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 <
> > jonathan.gallimore@gmail.com>
> > :
> >
> > > 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 <
> > rmannibucau@gmail.com
> > > >
> > > wrote:
> > >
> > > > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <
> > jgallimore@tomitribe.com
> > > >:
> > > >
> > > > > 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 <
> > > > > osantana@tomitribe.com> 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
> > > > >
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <rm...@gmail.com>
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 <
> jonathan.gallimore@gmail.com>
> :
>
> > 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 <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <
> jgallimore@tomitribe.com
> > >:
> > >
> > > > 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 <
> > > > osantana@tomitribe.com> 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
> > > >
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@gmail.com>
:

> 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 <rmannibucau@gmail.com
> >
> wrote:
>
> > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <jgallimore@tomitribe.com
> >:
> >
> > > 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 <
> > > osantana@tomitribe.com> 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
> > >
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <rm...@gmail.com>
wrote:

> 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <jg...@tomitribe.com>:
>
> > 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 <
> > osantana@tomitribe.com> 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
> >
>

Re: Adds an option to ignore mdb.activation fields

Posted by Romain Manni-Bucau <rm...@gmail.com>.
2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <jg...@tomitribe.com>:

> 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 <
> osantana@tomitribe.com> 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
>

Re: Adds an option to ignore mdb.activation fields

Posted by Jonathan Gallimore <jg...@tomitribe.com>.
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 <
osantana@tomitribe.com> 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