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.gallim...@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 <rmannibu...@gmail.com > > wrote: > >> 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <jgallim...@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 < >> > 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.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 >> > >> > >
