Re: [DISCUSS] ds for cdi 1.2+ only
the workarounds aren't that bad. it's just that we could drop more reflection calls (similar to what we discussed for jdk8 and java.util.Optional). ok - i'll document details about the warnings during the bootstrapping process (and if needed how to get rid of some of them). regards, gerhard 2018-04-04 6:13 GMT+02:00 Rudy De Busscher : > I have not a clear view of the workarounds which are made and how > 'bad'/hacky they are. But when we don't have major complaints about it (now > or in the past) I would not invest too much time in a temporary version for > CDI 1.2. > > so #3. > > Rudy > > On 3 April 2018 at 22:34, Romain Manni-Bucau > wrote: > > > All work for me and the apps i work on since a few years. > > > > Le 3 avr. 2018 22:17, "Thomas Andraschko" > a > > écrit : > > > > > +1 for 3) > > > the workarounds are really not that big... > > > > > > i would leave it as it is for now and start with DS 2.0 (= CDI2.0 only) > > the > > > next months. > > > > > > 2018-04-03 22:06 GMT+02:00 Gerhard Petracek : > > > > > > > hi @ all, > > > > > > > > since we will need to maintain v1.8.x for a while and it's too early > > for > > > > using cdi 2.0 (for a while), we should discuss if we should have one > > > branch > > > > using cdi 1.2+. > > > > it would allow to get rid of several workarounds (and the > corresponding > > > > warnings during the bootstrapping process). > > > > > > > > we had a short discussion in the irc-channel about the following > > options: > > > > #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+ > > > > > > > > vs > > > > > > > > #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with > cdi > > > > v1.2+; ds v2: jdk8 with cdi 2.0+ > > > > > > > > vs > > > > > > > > #3) we don't care about v1.2 as a min. requirement at all > > > > (the workarounds are minimal anyway and users can continue to ignore > > the > > > > warnings during the bootstrapping process) > > > > > > > > or for sure > > > > #4) [any other nice suggestion] > > > > > > > > -> please send your preferred approach > > > > > > > > regards, > > > > gerhard > > > > > > > > > >
Re: [DISCUSS] ds for cdi 1.2+ only
I have not a clear view of the workarounds which are made and how 'bad'/hacky they are. But when we don't have major complaints about it (now or in the past) I would not invest too much time in a temporary version for CDI 1.2. so #3. Rudy On 3 April 2018 at 22:34, Romain Manni-Bucau wrote: > All work for me and the apps i work on since a few years. > > Le 3 avr. 2018 22:17, "Thomas Andraschko" a > écrit : > > > +1 for 3) > > the workarounds are really not that big... > > > > i would leave it as it is for now and start with DS 2.0 (= CDI2.0 only) > the > > next months. > > > > 2018-04-03 22:06 GMT+02:00 Gerhard Petracek : > > > > > hi @ all, > > > > > > since we will need to maintain v1.8.x for a while and it's too early > for > > > using cdi 2.0 (for a while), we should discuss if we should have one > > branch > > > using cdi 1.2+. > > > it would allow to get rid of several workarounds (and the corresponding > > > warnings during the bootstrapping process). > > > > > > we had a short discussion in the irc-channel about the following > options: > > > #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+ > > > > > > vs > > > > > > #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with cdi > > > v1.2+; ds v2: jdk8 with cdi 2.0+ > > > > > > vs > > > > > > #3) we don't care about v1.2 as a min. requirement at all > > > (the workarounds are minimal anyway and users can continue to ignore > the > > > warnings during the bootstrapping process) > > > > > > or for sure > > > #4) [any other nice suggestion] > > > > > > -> please send your preferred approach > > > > > > regards, > > > gerhard > > > > > >
Re: [DISCUSS] ds for cdi 1.2+ only
All work for me and the apps i work on since a few years. Le 3 avr. 2018 22:17, "Thomas Andraschko" a écrit : > +1 for 3) > the workarounds are really not that big... > > i would leave it as it is for now and start with DS 2.0 (= CDI2.0 only) the > next months. > > 2018-04-03 22:06 GMT+02:00 Gerhard Petracek : > > > hi @ all, > > > > since we will need to maintain v1.8.x for a while and it's too early for > > using cdi 2.0 (for a while), we should discuss if we should have one > branch > > using cdi 1.2+. > > it would allow to get rid of several workarounds (and the corresponding > > warnings during the bootstrapping process). > > > > we had a short discussion in the irc-channel about the following options: > > #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+ > > > > vs > > > > #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with cdi > > v1.2+; ds v2: jdk8 with cdi 2.0+ > > > > vs > > > > #3) we don't care about v1.2 as a min. requirement at all > > (the workarounds are minimal anyway and users can continue to ignore the > > warnings during the bootstrapping process) > > > > or for sure > > #4) [any other nice suggestion] > > > > -> please send your preferred approach > > > > regards, > > gerhard > > >
Re: [DISCUSS] ds for cdi 1.2+ only
+1 for 3) the workarounds are really not that big... i would leave it as it is for now and start with DS 2.0 (= CDI2.0 only) the next months. 2018-04-03 22:06 GMT+02:00 Gerhard Petracek : > hi @ all, > > since we will need to maintain v1.8.x for a while and it's too early for > using cdi 2.0 (for a while), we should discuss if we should have one branch > using cdi 1.2+. > it would allow to get rid of several workarounds (and the corresponding > warnings during the bootstrapping process). > > we had a short discussion in the irc-channel about the following options: > #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+ > > vs > > #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with cdi > v1.2+; ds v2: jdk8 with cdi 2.0+ > > vs > > #3) we don't care about v1.2 as a min. requirement at all > (the workarounds are minimal anyway and users can continue to ignore the > warnings during the bootstrapping process) > > or for sure > #4) [any other nice suggestion] > > -> please send your preferred approach > > regards, > gerhard >
[DISCUSS] ds for cdi 1.2+ only
hi @ all, since we will need to maintain v1.8.x for a while and it's too early for using cdi 2.0 (for a while), we should discuss if we should have one branch using cdi 1.2+. it would allow to get rid of several workarounds (and the corresponding warnings during the bootstrapping process). we had a short discussion in the irc-channel about the following options: #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+ vs #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with cdi v1.2+; ds v2: jdk8 with cdi 2.0+ vs #3) we don't care about v1.2 as a min. requirement at all (the workarounds are minimal anyway and users can continue to ignore the warnings during the bootstrapping process) or for sure #4) [any other nice suggestion] -> please send your preferred approach regards, gerhard
[jira] [Commented] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more
[ https://issues.apache.org/jira/browse/DELTASPIKE-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423665#comment-16423665 ] ASF subversion and git services commented on DELTASPIKE-1324: - Commit a360578bd1239985835519c6162ed4f5e9745ee1 in deltaspike's branch refs/heads/deltaspike-1.8.x from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a360578 ] DELTASPIKE-1324 Ensure that class level is read before method level. > @Transactional annotation at method level doesn't override the one at class > level any more > -- > > Key: DELTASPIKE-1324 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324 > Project: DeltaSpike > Issue Type: Bug > Components: Data-Module >Affects Versions: 1.8.1 >Reporter: Jens Berke >Assignee: John D. Ament >Priority: Major > Fix For: 1.9.0 > > > Hi. The behaviour of @Transactional has changed with 1.8.1: > Until version 1.8.0 @Transactional annotations at method level overrode those > at the class level. Like this: > {code:java} > @Transactional(readOnly = true) > public class MyClass { > public void doSomethingReadOnly() > @Transactional > public void writeSomething(){code} > This stopped working with version 1.8.1 because the @Transactional annotation > at method level seems to be ignored and the transaction for the method > remains read-only. The cause is probably the change introduced with > DELTASPIKE-940, where the following method was added to > org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper: > {code:java} > EntityManagerMetadata createEntityManagerMetadata(InvocationContext context) > { > EntityManagerMetadata metadata = new EntityManagerMetadata(); > metadata.readFrom(context.getMethod(), beanManager); > metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager); > return metadata; > }{code} > If first reads the data at method level and then at class level, which seems > to be the wrong order. Swapping these lines would restore the correct > behaviour: > {code:java} > metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager); > metadata.readFrom(context.getMethod(), beanManager);{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)