I'd see it as an enhancement: if we have that we can still support the config in PU but we can also detect if we can't support it. So if you have 1 PU and that the PU is triggering the enhancement -> it works and we can support addDefaultCt ; if we have 2 PU and one of the two only has the option -> we can fail properly ; if enhancement was done before -> then the responsonbility was before and we can just check it looks like what we expect.
In other works we can guarantee a good level of compatibility and ensure we fail where we were random before wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-09-13 17:40 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>: > Romain had an interesting proposal on irc: > > > > Currently our PCEnhancer is a WILD mix between state and persistence unit > infos and options from 'outside' > The reason for this is that each PU might contain parameters meant for the > enhancer, e.g. : > https://github.com/struberg/lightweightEE/blob/master/ > backend-api/src/main/resources/META-INF/persistence.xml#L26 > > You can also add parameters which affect the generated bytecode on the > commandline, as opts, as args, etc. > > This stuff will definitely break things once you have the same Entity > class enlisted in multiple Persistence Units (e.g. in a XA PU and then in a > non-jta PU). If those 2 PUs have different config then the bytecode you > will get is basically random... > > > Back to Romains idea: to make the generated bytecode independent from any > configuration. Idempotent so to say. > > Adding to this we could e.g. get the current config from the StateManager > and try to switch features depending on this configuration on the fly. This > would e.g. work for our serialisation options. > > > It will _not_ work for the 'defaultCt' option of course. But does it hurt > to have a default ct? > Just brainstorming... > > LieGrue, > strub > > > > > On Tuesday, 13 September 2016, 17:31, Francesco Chicchiriccò < > ilgro...@apache.org> wrote: > > > >On 13/09/2016 17:28, Romain Manni-Bucau wrote: > >> then not yet ;) or in a branch IMHO > >> > >> we need to keep trunk green I think > > > >+1 > >Regards. > > > > > >> 2016-09-13 17:27 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>: > >> > >>> once I go ahead and kill the first serp parts then it will not be green > >>> anymore ;) > >>> > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> On Tuesday, 13 September 2016, 17:20, Romain Manni-Bucau < > >>> rmannibu...@gmail.com> wrote: > >>> > >>> > >>>> > >>>> move on on trunk if it is still green > >>>> > >>>> > >>>> BTW: i think an enhancer doesnt really need a persistence unit so > would > >>> it make sense to move the enhancer to be even more isolated (and as > easy as > >>> Enhancer.run(classesOrBytes, someconfigifreallyneeded))? > >>>> > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau | Blog | Old Wordpress Blog | Github | LinkedIn | > >>> Tomitriber | JavaEE Factory > >>>> 2016-09-13 17:12 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>: > >>>> > >>>> Hi folks! > >>>>> You might have seen the patch I added to > >>>>> > >>>>> https://issues.apache.org/ jira/browse/OPENJPA-2662 > >>>>> > >>>>> > >>>>> Do you think it makes sense to create a feature branch to work on > that part? > >>>>> I hesitate to trash our trunk with it right now ;) > >>>>> > >>>>> txs and LieGrue, > >>>>> strub > > > >-- > >Francesco Chicchiriccò > > > >Tirasa - Open Source Excellence > >http://www.tirasa.net/ > > > >Involved at The Apache Software Foundation: > >member, Syncope PMC chair, Cocoon PMC, Olingo PMC, > >CXF Committer, OpenJPA Committer, PonyMail PPMC > >http://home.apache.org/~ilgrosso/ > > > > > > > > > > >
