There is other problem:
 ejbDeployment.getContainerId(); //it returns null

On Wed, Jul 12, 2017 at 10:04 AM, Otávio Gonçalves de Santana <
osant...@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 <rmannibu...@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 <
>> osant...@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 <
>> rmannibu...@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 <
>> > > osant...@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.gallim...@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 <
>> > > > > osant...@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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Reply via email to