Re: [DISCUSS] ds for cdi 1.2+ only

[Gerhard Petracek]

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

[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

[Romain Manni-Bucau]

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
> >
>

[DISCUSS] ds for cdi 1.2+ only

[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

[jira] [Commented] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)