You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2016/09/13 15:12:33 UTC
PCEnhancer refactoring wip
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
Re: PCEnhancer refactoring wip
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@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ò <
> ilgrosso@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 <st...@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 <
> >>> rmannibucau@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 <st...@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/
> >
> >
> >
> >
> >
>
Re: PCEnhancer refactoring wip
Posted by Mark Struberg <st...@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ò <il...@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 <st...@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 <
>>> rmannibucau@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 <st...@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/
>
>
>
>
>
Re: PCEnhancer refactoring wip
Posted by Francesco Chicchiriccò <il...@apache.org>.
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 <st...@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 <
>> rmannibucau@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 <st...@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/
Re: PCEnhancer refactoring wip
Posted by Romain Manni-Bucau <rm...@gmail.com>.
then not yet ;) or in a branch IMHO
we need to keep trunk green I think
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:27 GMT+02:00 Mark Struberg <st...@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 <
> rmannibucau@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 <st...@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
> >>
> >
> >
> >
>
Re: PCEnhancer refactoring wip
Posted by Mark Struberg <st...@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 <rm...@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 <st...@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
>>
>
>
>
Re: PCEnhancer refactoring wip
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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:12 GMT+02:00 Mark Struberg <st...@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
>