RE: [ANNOUNCE] Release of Apache DeltaSpike 1.7.0

[Marvin Toll]

It is (perhaps) fortuitous that this issue comes up at this time.

I have struggled to imagine a thoughtful value proposition for DeltaSpike 
targeting our 700+ developers on six continents (that don't necessarily use 
English as a first language). The subtle distinction between a CDI-container 
and a CDI extension seems to me like a lower-level concern that fails to 
grapple with the value proposition for DeltaSpike.

That is, why should one consider DeltaSpike as a wrapper for technologies that 
are implementable with a native API?

For example, in the persistence space, what is the compelling value proposition 
for obfuscating the specification-backed Java Persistence API with a 
proprietary DeltaSpike API that dictates a CDI dependency? (Presume that some 
folks perceive an additional dependency as a negative... not a positive.)

Said a third way, if we expect DeltaSpike acceptance to grow beyond the current 
faithful, how do we articulate the advantages in a manner that causes the 
thoughtful to think?

_Marvin


-Original Message-
From: John D. Ament [mailto:john.d.am...@gmail.com] 
Sent: Monday, June 20, 2016 10:41 AM
Subject: Re: [ANNOUNCE] Release of Apache DeltaSpike 1.7.0

Sebb,

Great points.  I'll make sure the email for the next release provides more 
details.
John

On Mon, Jun 20, 2016 at 10:33 AM sebb  wrote:

> What is the project about? Why should I be interested in it?
> (rhetorical questions)

> So the e-mails should contain at least brief details of what the 
> product does. However the sentence:

> "Apache DeltaSpike is not a CDI-container, but a portable CDI extension."

> will mean nothing to most people. What does CDI mean?

Justify: CDI/DeltaSpike Testing with Rules

[Marvin Toll]

The soon to be released Justify Open Source project supporting rule-based
CDI JUnit testing is now briefly documented for System Engineers at
http://pedcentral.com/justify/ .  It now depends on DeltaSpike v1.6.1.

 

We appreciate any feedback that can be rendered before the GA release by
those that give it a try.

 

_Marvin

[jira] [Commented] (DELTASPIKE-1157) Repository.findBy methods do not allow an override to add query hints.

[Marvin Toll (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15311489#comment-15311489
 ] 

Marvin Toll commented on DELTASPIKE-1157:
-

Thanks John!

--
--
 
Pattern Enabled Development ® (PED) - http://pedCentral.com
PED seeks to advance Java/JavaScript application construction
by inspiring software engineers with  Pattern First Thinking, 
enabling project teams with a Pattern Palette, and harmonizing
enterprise communication with a Unified Pattern Language. 






> Repository.findBy methods do not allow an override to add query hints.
> --
>
> Key: DELTASPIKE-1157
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1157
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module
>Affects Versions: 1.5.3
>Reporter: Amita Mehta
>Assignee: John D. Ament
> Fix For: 1.6.2
>
>
> We need a way to to add hints or a property override to the findBy methods 
> for the primary key to prevent reading stale data .
> We tried overriding the findBy with query hints but these are ignored by the 
> DelatSpike Data Module EntityRepositoryHandler .
> {code}
> @Override
> @Query(hints = {@QueryHint(name = "javax.persistence.cache.retrieveMode",
> value = "BYPASS"), @QueryHint(name = "eclipselink.refresh",
> value = "TRUE")})
> public ENTITY findBy(PK primaryKey);
> {code}
> The only thing that works is creating a custom query in the repository that 
> uses override properties –
> {code}
>public AgentDE findByPK(final String primaryKey) {
> final Map<String, Object> properties = new HashMap<String, Object>();
> properties.put("QueryHints.CACHE_USAGE", CacheUsage.DoNotCheckCache);
> properties.put("eclipselink.refresh", "true");
> 
> entityManager().getEntityManagerFactory().getCache().evict(entityClass(), 
> primaryKey);
> entityManager().clear();
> return entityManager().find(entityClass(), primaryKey, properties);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1157) Repository.findBy methods do not allow an override to add query hints.

[Marvin Toll (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15310319#comment-15310319
 ] 

Marvin Toll commented on DELTASPIKE-1157:
-

Good clarification/elaboration!

> Repository.findBy methods do not allow an override to add query hints.
> --
>
> Key: DELTASPIKE-1157
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1157
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module
>Affects Versions: 1.5.3
>Reporter: Amita Mehta
>Assignee: John D. Ament
>
> We need a way to to add hints or a property override to the findBy methods 
> for the primary key to prevent reading stale data .
> We tried overriding the findBy with query hints but these are ignored by the 
> DelatSpike Data Module EntityRepositoryHandler .
> {code}
> @Override
> @Query(hints = {@QueryHint(name = "javax.persistence.cache.retrieveMode",
> value = "BYPASS"), @QueryHint(name = "eclipselink.refresh",
> value = "TRUE")})
> public ENTITY findBy(PK primaryKey);
> {code}
> The only thing that works is creating a custom query in the repository that 
> uses override properties –
> {code}
>public AgentDE findByPK(final String primaryKey) {
> final Map<String, Object> properties = new HashMap<String, Object>();
> properties.put("QueryHints.CACHE_USAGE", CacheUsage.DoNotCheckCache);
> properties.put("eclipselink.refresh", "true");
> 
> entityManager().getEntityManagerFactory().getCache().evict(entityClass(), 
> primaryKey);
> entityManager().clear();
> return entityManager().find(entityClass(), primaryKey, properties);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1157) Repository.findBy methods do not allow an override to add query hints.

[Marvin Toll (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15310159#comment-15310159
 ] 

Marvin Toll commented on DELTASPIKE-1157:
-

If this is not going to work:

 @Override
@Query(hints = {@QueryHint(name = "javax.persistence.cache.retrieveMode",
value = "BYPASS"), @QueryHint(name = "eclipselink.refresh",
value = "TRUE")})
public ENTITY findBy(PK primaryKey);

It would be helpful if a runtime exception were thrown indicating query hints 
are ignored; thus avoiding (in this case) stale data being delivered to the 
customer.

> Repository.findBy methods do not allow an override to add query hints.
> --
>
> Key: DELTASPIKE-1157
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1157
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module
>Affects Versions: 1.5.3
>Reporter: Amita Mehta
>Assignee: John D. Ament
>
> We need a way to to add hints or a property override to the findBy methods 
> for the primary key to prevent reading stale data .
> We tried overriding the findBy with query hints but these are ignored by the 
> DelatSpike Data Module EntityRepositoryHandler .
> {code}
> @Override
> @Query(hints = {@QueryHint(name = "javax.persistence.cache.retrieveMode",
> value = "BYPASS"), @QueryHint(name = "eclipselink.refresh",
> value = "TRUE")})
> public ENTITY findBy(PK primaryKey);
> {code}
> The only thing that works is creating a custom query in the repository that 
> uses override properties –
> {code}
>public AgentDE findByPK(final String primaryKey) {
> final Map<String, Object> properties = new HashMap<String, Object>();
> properties.put("QueryHints.CACHE_USAGE", CacheUsage.DoNotCheckCache);
> properties.put("eclipselink.refresh", "true");
> 
> entityManager().getEntityManagerFactory().getCache().evict(entityClass(), 
> primaryKey);
> entityManager().clear();
> return entityManager().find(entityClass(), primaryKey, properties);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: [jira] [Commented] (DELTASPIKE-1157) Repository.findBy methods do not allow an override to add query hints.

[Marvin Toll]

John,

 

I’m having a hard time arriving at the suggested syntax from the documentation 
page indicated. However, we return to work tomorrow (USA) and let me check with 
 colleagues and see what they think.

 

_Marvin

 

From: John D. Ament [mailto:john.d.am...@gmail.com] 
Sent: Monday, May 30, 2016 8:36 AM
override to add query hints.

 

Marvin,

 

I guess you're looking for this page?

 

http://deltaspike.apache.org/documentation/data.html#QueryMethodExpressions

 

John

On Mon, May 30, 2016 at 7:57 AM Marvin Toll <marvint...@gtcgroup.com 
<mailto:marvint...@gtcgroup.com> > wrote:

John,

 Let me express my root concern… and see if it valid or I’m seeing a concern 
that does not exist.

 If we have 700 plus or minus 200 developers on six continents… how do we 
express to them the use of this particular syntax? That is, can we point to an 
Internet page describing/documenting the use of this syntax?

 @Query(hints = {@QueryHint(name = "javax.persistence.cache.retrieveMode", 
value = "BYPASS"), @QueryHint(name = "eclipselink.refresh", value = "TRUE")}

_Marvin

 

RE: [jira] [Commented] (DELTASPIKE-1157) Repository.findBy methods do not allow an override to add query hints.

[Marvin Toll]

John,

 

Let me express my root concern… and see if it valid or I’m seeing a concern 
that does not exist.

 

If we have 700 plus or minus 200 developers on six continents… how do we 
express to them the use of this particular syntax? That is, can we point to an 
Internet page describing/documenting the use of this syntax?

 

@Query(hints = {@QueryHint(name = "javax.persistence.cache.retrieveMode", value 
= "BYPASS"), @QueryHint(name = "eclipselink.refresh", value = "TRUE")}



_Marvin

 

 

From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Sunday, May 29, 2016 8:09 PM
override to add query hints.

 

Martin,

 

Not sure what you mean.  "findById" is a method expression query, assuming that 
"id" is your primary key attribute.

 

John

 

RE: [jira] [Commented] (DELTASPIKE-1157) Repository.findBy methods do not allow an override to add query hints.

[Marvin Toll]

John,

I've Googled briefly (and unsuccessfully) for this syntax; is it backed by a 
specification?

_Marvin

-Original Message-
From: John D. Ament (JIRA) [mailto:j...@apache.org] 
---

[~am]

I just ran a quick test.  I was able to get it working using the following 
syntax.  Can you let me know if this fits your need within eclipselink?

{code}
@Query(hints = {@QueryHint(name = "javax.persistence.cache.retrieveMode", 
value = "BYPASS"), @QueryHint(name = "eclipselink.refresh", value = "TRUE")}
public abstract Simple findById(Long id); {code}

> Repository.findBy methods do not allow an override to add query hints.
> --

RE: Cutting over to Java 7

[Marvin Toll]

Thanks John,

Believe me... I've been watching the thread closely.  :-)

I did not feel compelled to enter in until such time as it was being determined 
the approach for accommodation of Java 6 users.

You may have seen some POC code that is being used for preparation of our 
eventual move to Java 7 that we thought was going to begin this year???  
However, our standard data center offering remains WAS 8 (classic) with Java 6 
(at this time).

_Marvin

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Thursday, April 7, 2016 7:13 AM
Subject: Re: Cutting over to Java 7

Hi Marvin,

Thanks for the input.  You can find our discussion/vote thread from last month 
here:
http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201603.mbox/%3CCAOqetn_vo69sx-yQjLt%3DQpfdRXgXVqu7NiobanLgXKOOr6Co0Q%40mail.gmail.com%3E

The curious thing about your note - the WebSphere version I've seen the Ford 
team mention a few times requires Java 7.  In general, EE 7 systems were built 
for Java 7 support (JMS made use of autocloseable is one I can think of off the 
top of my head).

As mentioned, there's still a plan to support the 1.6.x line.  If you guys find 
any issues that you need to stay on 1.6.x, please feel free to raise them and 
we can address as additional 1.6.x patches.

John

On Thu, Apr 7, 2016 at 6:42 AM Marvin Toll <marvint...@gtcgroup.com> wrote:

> A data point: Ford Motor Company is on Java 6.  Given our portfolio of
> 4,000 applications (a subset of which are Java) - it is difficult to 
> know how long a migration to Java 7 will take.  It was scheduled to 
> begin in calendar year 2016 - the current "begin" target is 2017.
>
> _Marvin
>
> -Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: Wednesday, April 6, 2016 10:14 PM
> To: deltaspike <dev@deltaspike.apache.org>
> Subject: Cutting over to Java 7
>
> All,
>
> I wanted to get opinions for how to cut over to Java 7.
>
> There's two ways I've done similar cut overs in the past, wanted to 
> share them and build out some ideas.
>
> 1. Continue maintenance on 1.6 for x months.  When we decide that 
> we're going to cut a 1.7 we do the switch then.
>
> 2. Decide now that the next release is going to be planned as 1.7.  If 
> we need to do maintenance on 1.6 we branch from the tag and merge back 
> in when done.
>
> The former is safer, but will take longer.  The last minor release had 
> the most patch releases on it, 4.  The latter is more practical and 
> shows implementation much quicker.  It creates a bit more overhead as 
> we'd need to merge branches.  In the 4.5 years of deltaspike, we 
> haven't had to do it thus yet.  I suspect that given our user base, #2 
> would be acceptable since most everyone's using Java 7+, so it seems a 
> small chance that we'd run into a JVM difference.  I'm not sure if 
> others have different ideas to throw out.
>
> John
>
>

RE: Cutting over to Java 7

[Marvin Toll]

A data point: Ford Motor Company is on Java 6.  Given our portfolio of 4,000 
applications (a subset of which are Java) - it is difficult to know how long a 
migration to Java 7 will take.  It was scheduled to begin in calendar year 2016 
- the current "begin" target is 2017.

_Marvin

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Wednesday, April 6, 2016 10:14 PM
To: deltaspike 
Subject: Cutting over to Java 7

All,

I wanted to get opinions for how to cut over to Java 7.

There's two ways I've done similar cut overs in the past, wanted to share them 
and build out some ideas.

1. Continue maintenance on 1.6 for x months.  When we decide that we're going 
to cut a 1.7 we do the switch then.

2. Decide now that the next release is going to be planned as 1.7.  If we need 
to do maintenance on 1.6 we branch from the tag and merge back in when done.

The former is safer, but will take longer.  The last minor release had the most 
patch releases on it, 4.  The latter is more practical and shows implementation 
much quicker.  It creates a bit more overhead as we'd need to merge branches.  
In the 4.5 years of deltaspike, we haven't had to do it thus yet.  I suspect 
that given our user base, #2 would be acceptable since most everyone's using 
Java 7+, so it seems a small chance that we'd run into a JVM difference.  I'm 
not sure if others have different ideas to throw out.

John

RE: CdiRunner --> Rule

[Marvin Toll]

Gerhard,

 

The value proposition for Justify goes beyond what any one technology can 
deliver.  For example - 
https://deltaspike.apache.org/documentation/test-control.html#Usingjersey-testwithtest-control
 

 

We found additional clashes between various technologies.

 

In addition, there is the underlying philosophical position, “real” vs. 
“mocks”, represented by JUST [ http://pedcentral.com/principles/junit-testing/ 
].  That is, we are not simply peddling a technology but seeking to influence 
approach.

 

_Marvin

 

 

From: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] 
Sent: Wednesday, February 24, 2016 2:58 AM
To: dev@deltaspike.apache.org
Cc: Marvin Toll <marvint...@gtcgroup.com>
Subject: Re: CdiRunner --> Rule

 

hi @ all,

 

yes - we discussed it several times, however, so far there was not enough time 
(+ concrete demand) to add a rule (which supports all the existing features).

maybe we can create one for one of the upcoming versions.

 

regards,

gerhard

 

 

 

RE: CdiRunner --> Rule

[Marvin Toll]

John – thanks for your pre-release comments:

 

1)The GA release is pending, probably early next week.  We are in the final 
stages of testing at Ford.  At that time we will publish to Maven Central.

 

2)There is a QuickStart page 
http://pedcentral.com/hands-on/justify/justify-quickstart/ that includes access 
to ~200 tests 

 

3)We will be expanding on the “Sample” project you see if using the 
“QuickStart” – for now, check out the “justify-test” project

 

_Marvin

 

From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Tuesday, February 23, 2016 7:06 PM
To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
Subject: Re: CdiRunner --> Rule

 

Marvin,

 

Definitely interesting.  I've considered such an approach before, but never saw 
it implemented, so kudos.  There's a few things I see missing.

 

- Examples.  How do I use these things?  What does a test based on Justify look 
like with CDI support?

 

- Publishing.  This library isn't built/deployed out to maven central or 
bintray as far as I can tell.  This means users need to build it themselves.  
Convenience binaries are so useful, especially when there's no build script.

 

John

On Mon, Feb 22, 2016 at 11:39 PM Marvin Toll <marvint...@gtcgroup.com 
<mailto:marvint...@gtcgroup.com> > wrote:

DeltaSpike Colleagues,

We haven't shared this until now. since there was not a lot to talk about
until it was working.

Ford has partnered with an Open Source team to utilize a 100% rule-based
testing approach that wraps JUnit 4. As part of this effort, the CdiRuner
was mostly eliminated in favor of a JstConfigureCdiForMethodRule Rule:

http://ped.gtcgroup.com/_jst_configure_cdi_for_method_rule_8java_source.html

A light weight JstSatisfyAnnotationOnTestMethodRunner runner does remain if
required:

http://ped.gtcgroup.com/_jst_satisfy_annotation_on_test_method_runner_8java_ 
<http://ped.gtcgroup.com/_jst_satisfy_annotation_on_test_method_runner_8java_source.html>
 
source.html

The Open Source project is called Justify at:

  http://pedcentral.com/hands-on/justify/

Any thoughts or feedback are welcomed.

_Marvin

CdiRunner --> Rule

[Marvin Toll]

DeltaSpike Colleagues,

 

We haven't shared this until now. since there was not a lot to talk about
until it was working.

 

Ford has partnered with an Open Source team to utilize a 100% rule-based
testing approach that wraps JUnit 4. As part of this effort, the CdiRuner
was mostly eliminated in favor of a JstConfigureCdiForMethodRule Rule:

 

 
http://ped.gtcgroup.com/_jst_configure_cdi_for_method_rule_8java_source.html


 

A light weight JstSatisfyAnnotationOnTestMethodRunner runner does remain if
required:

 

 
http://ped.gtcgroup.com/_jst_satisfy_annotation_on_test_method_runner_8java_
source.html 

 

The Open Source project is called Justify at: 

 

  http://pedcentral.com/hands-on/justify/ 

 

Any thoughts or feedback are welcomed.

 

_Marvin

RE: [jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[Marvin Toll]

At the risk of demonstrating a lack of adequate context to contribute to the 
discussion...

One preference expressed at our shop is to eliminate the notion of "defaulting" 
to an EntityManager.  That is, pursue an API that provides explicit readability 
as to which EntityManager/persistenceUnitName is being invoked.

In addition, the API should enable multiple alternative EntityManagers during 
JUnit testing.

Here is the type of testing use case typical in a large shop:

1. A standard JUnit tests uses H2 as an embedded database.
2. A 'special case' Stored Procedure test uses the application SQL Server 
database (DEV instance).
3. A 'special case' View test accesses a legacy DB2 database. 

In this scenario items #1 and #2 require at least one alternatve and #3 
requires a unique persitenceUnitName.  And of course there are additional 
scenarios where more than one alternative is required.

So perhaps for some, the idea of an API providing "magic" defaulting is less 
attractive than explicit in-line readability.

_Marvin

-Original Message-
From: Thomas Hug (JIRA) [mailto:j...@apache.org] 
Sent: Friday, January 22, 2016 6:50 AM
To: deltaspike-...@incubator.apache.org
Subject: [jira] [Commented] (DELTASPIKE-940) @Transactional and 
@EntityManagerConfig each use a different method to resolve EntityManagers

> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used

RE: EntityRepository + EntityManagerDelegate

[Marvin Toll]

Without having the benefit of "test driving" the change, it seems to make a lot 
of sense to me.  Any approach enabling direct access to the (native) JPA API 
can only be beneficial when it is impossible to imagine all of the different 
use cases that might emerge for hundreds of developers over the next decade.

_Marvin

-Original Message-
From: Harald Wellmann [mailto:hwellmann...@gmail.com] 
Sent: Wednesday, December 9, 2015 4:26 PM
To: dev@deltaspike.apache.org
Subject: EntityRepository + EntityManagerDelegate

For the benefit of all DS Data users who prefer persist() and merge() over 
save(), I propose to extend the Data API by something like this:


public interface FullEntityRepository
 extends EntityRepository, EntityManagerDelegate {
}


public abstract class AbstractFullEntityRepository
 extends AbstractEntityRepository
 implements EntityManagerDelegate {

}

I don't really care about the exact class names (Full, Extended, you 
name it), the point is that end users can simply write

public interface CustomerRepository extends 
FullEntityRepository {}

to get access to all EntityManager methods.

What do you think?

Regards,
Harald

RE: EntityRepository + EntityManagerDelegate

[Marvin Toll]

Romain - I’m not clear on the term “data design”?  In what ways does exposing 
the specification backed JPA API break “data design”?

 

Or, perhaps you are referencing Eric Evens “Repository Pattern” and asserting 
that by mixing the JPA API and the DeltaSpike Repository API in the same class 
causes “breakage”?

 

Would you mind elaborating?

 

_Marvin 

 

From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Sent: Wednesday, December 9, 2015 6:03 PM
Subject: RE: EntityRepository + EntityManagerDelegate

 

Doesnt it break data design? Why not using the em if it is what you need? One 
doesnt prevent the other.

Le 9 déc. 2015 23:12, "Marvin Toll" <marvint...@gtcgroup.com 
<mailto:marvint...@gtcgroup.com> > a écrit :

Without having the benefit of "test driving" the change, it seems to make a lot 
of sense to me.  Any approach enabling direct access to the (native) JPA API 
can only be beneficial when it is impossible to imagine all of the different 
use cases that might emerge for hundreds of developers over the next decade.

_Marvin

-Original Message-
From: Harald Wellmann [mailto:hwellmann...@gmail.com 
<mailto:hwellmann...@gmail.com> ]
Sent: Wednesday, December 9, 2015 4:26 PM
To: dev@deltaspike.apache.org <mailto:dev@deltaspike.apache.org> 
Subject: EntityRepository + EntityManagerDelegate

For the benefit of all DS Data users who prefer persist() and merge() over 
save(), I propose to extend the Data API by something like this:


public interface FullEntityRepository<E, PK extends Serializable>
 extends EntityRepository<E, PK>, EntityManagerDelegate {
}


public abstract class AbstractFullEntityRepository<E, PK extends
Serializable>
 extends AbstractEntityRepository<E, PK>
 implements EntityManagerDelegate {

}

I don't really care about the exact class names (Full, Extended, you
name it), the point is that end users can simply write

public interface CustomerRepository extends
FullEntityRepository<Customer, Long> {}

to get access to all EntityManager methods.

What do you think?

Regards,
Harald

RE: [VOTE] Release of Apache DeltaSpike 1.5.2

[Marvin Toll]

At Ford, we have continued to be impacted (as well) by "issues" with the DM.  
In recent weeks, we came to the independent conclusion that the DM test suite 
is probably inadequate.

We are also interested in performance --- not that we have any basis for a 
concern.  Rather, just wondering if the additional DM layer has an impact on 
"native" (for us EclipseLink) performance/scalability - and whether the DM test 
suite includes a performance check for releases? 

_Marvin

-Original Message-
From: Harald Wellmann [mailto:hwellmann...@gmail.com] 
Sent: Monday, December 7, 2015 5:35 PM
To: dev@deltaspike.apache.org
Subject: Re: [VOTE] Release of Apache DeltaSpike 1.5.2

-1.

This release breaks one of my applications (again) with an exception in 
DeltaSpike Data.

I'll get back with a JIRA ticket once I've identified the cause, which will 
probably be too late for this vote.

The release will go ahead anyway, and I don't really object to that, if people 
are waiting for improvements in other areas, but this feels like a déjà vu.

In fact, each of the previous releases broke my applications in one way or 
another, so I think the bottom line is this: There have been too many subtle 
incompatible changes going on in DeltaSpike Data that in theory should never 
happen with a patch release, and apparently there's too little test coverage or 
too much happy path testing, or else these incompatibilities would have been 
noticed sooner.

Looks like we should spend some more time on Data tests before working on bugs 
or new features.

Regards,
Harald


Am 06.12.2015 um 20:54 schrieb Gerhard Petracek:
> Hi,
>
> I was running the needed tasks to get the 21th release of Apache 
> DeltaSpike out.
> The artifacts are deployed to Nexus [1] (and [2]).
>
> The tag is available at [3] and the release-branch at [4].
> They will get pushed to the ASF repository once the vote passed.
>
> Please take a look at the 1.5.2 artifacts and vote!
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes (see [5]).
>
> 
> [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 
> for fatal flaws that should cause these bits not to be released, and 
> why..
> 
>
> Thanks,
> Gerhard
>
> [1]
> https://repository.apache.org/content/repositories/orgapachedeltaspike
> -1031/
> [2]
> https://repository.apache.org/content/repositories/orgapachedeltaspike
> -1031/org/apache/deltaspike/deltaspike/1.5.2/deltaspike-1.5.2-source-r
> elease.zip [3] 
> https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.2
> [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.2
> [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
>

RE: first steps for the next release

[Marvin Toll]

Ford was able to complete verification (today) that all occurrences of 
cascading abnormalities (that is, a differences between native EclipseLink and 
DM) previously discovered have been resolved with v. 1.5.1.

 

Although we will continue our testing… we don’t expect any additional issues 
unique to v. 1.5.1… and therefore do not see any reason to refrain from 
releasing this version.

 

_Marvin 

 

From: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] 
Sent: Wednesday, October 14, 2015 9:44 AM
To: dev@deltaspike.apache.org; Marvin Toll <marvint...@gtcgroup.com>
Cc: Amita Mehta <ameh...@ford.com>
Subject: Re: first steps for the next release

 

hi marvin,

 

great to hear that!

if this topic takes a bit longer, we might postpone the release a bit or 
release v1.5.2 next month.

 

regards,

gerhard

 

 

 

2015-10-14 15:02 GMT+02:00 Marvin Toll <marvint...@gtcgroup.com 
<mailto:marvint...@gtcgroup.com> >:

Gerhard... at Ford we have only begun testing... we have our first test that 
failed under previous releases and is working with DM 1.5.1.

We anticipate having our complete test suite working (or not) by the end of the 
week.

[Our revised testing approach is to use the exact same test with native 
EclipseLink JPA and DeltaSpike DM... seeking a consistent result.]

_Marvin


-Original Message-
From: Gerhard Petracek [mailto:gpetra...@apache.org 
<mailto:gpetra...@apache.org> ]
Sent: Wednesday, October 14, 2015 3:38 AM
To: dev@deltaspike.apache.org <mailto:dev@deltaspike.apache.org> 
Subject: first steps for the next release

hi @ all,

if there are no objections, i will start with the first steps for the next 
release (v1.5.1) by the end of next week.

regards,
gerhard

 

RE: first steps for the next release

[Marvin Toll]

Gerhard... at Ford we have only begun testing... we have our first test that 
failed under previous releases and is working with DM 1.5.1.

We anticipate having our complete test suite working (or not) by the end of the 
week.

[Our revised testing approach is to use the exact same test with native 
EclipseLink JPA and DeltaSpike DM... seeking a consistent result.]

_Marvin

--
|  USA Cell: 248.866.4897
|  Email: mar...@gtcgroup.com
|  Web: http://MarvinToll.com
|  Skype: marvin.toll
--

-Original Message-
From: Gerhard Petracek [mailto:gpetra...@apache.org] 
Sent: Wednesday, October 14, 2015 3:38 AM
To: dev@deltaspike.apache.org
Subject: first steps for the next release

hi @ all,

if there are no objections, i will start with the first steps for the next 
release (v1.5.1) by the end of next week.

regards,
gerhard

RE: [Proposal] CdiManagedRunnable

[Marvin Toll]

The Executor Service was added by Doug Lea in Java 5.


http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ExecutorService.html
 

However, in Java 7 he put in the much improved Fork Join Pool... which extends 


http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html 

He then back-ported capability to Java 7 and Java 6 from the enhanced Java 8 
implementation:

http://g.oswego.edu/dl/concurrency-interest/ 

However, the backport uses different packaging which makes things a bit awkward 
from a Framework perspective.

_Marvin

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Saturday, September 19, 2015 12:13 PM
To: dev@deltaspike.apache.org
Cc: Arne Limburg 
Subject: Re: [Proposal] CdiManagedRunnable

Are you thinking that this includes an executor service impl?
Wouldn't we need to jump to java 7?

John

On Sat, Sep 19, 2015 at 12:05 PM Romain Manni-Bucau 
wrote:

> I always thought a CDI frienly executor service would be nice so +1 
> for ds Le 19 sept. 2015 01:32, "Thomas Andraschko" 
>  a écrit :
>
> > 1+ romain
> > But wdyt about adding something to DS for JEE6/7 users?
> >
> > 2015-09-19 9:23 GMT+02:00 Arne Limburg :
> >
> > > +1
> > > I really thought the same, when I read that proposal.
> > >
> > > Cheers,
> > > Arne
> > >
> > > Von meinem Samsung Gerät gesendet.
> > >
> > >
> > >  Ursprüngliche Nachricht 
> > > Von: Romain Manni-Bucau 
> > > Datum: 18.09.2015 16:28 (GMT+01:00)
> > > An: dev@deltaspike.apache.org
> > > Cc: Thomas Andraschko 
> > > Betreff: Re: [Proposal] CdiManagedRunnable
> > >
> > > Hi
> > >
> > > I like the idea but isnt it close enough of concurrency utilities 
> > > to
> kind
> > > of put it in this spec? There is this proxy factory which 
> > > could/should support scopes IMO.
> > >
> > > CDI has few thread requirements which is good IMO so I would put 
> > > it in
> > the
> > > "thread" spec.
> > >
> > > Romain
> > > Le 18 sept. 2015 07:23, "Martin Kouba"  a écrit :
> > >
> > > > Hi Thomas,
> > > >
> > > > I think it's a good idea. Weld has a similar API [1], except 
> > > > it's
> > focused
> > > > solely on the "thread-local-based context". We are also 
> > > > considering
> the
> > > use
> > > > of an interceptor to active/deactivate the ThreadContext per 
> > > > business method invocation [2].
> > > >
> > > > I wonder, whether this should be standardized in CDI 2.0. It 
> > > > seems to
> > me
> > > > that CDI SE lacks some built-in contexts. Unlike Java EE where 
> > > > the
> > > built-in
> > > > scopes align with the lifecycle of EE components 
> > > > (@RequestScoped, @SessionScoped, etc.).
> > > >
> > > > Martin
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://docs.jboss.org/weld/reference/latest/en-US/html/environments.ht
> ml#_thread_context
> > > >
> > > > [2]
> > > > https://issues.jboss.org/browse/WELD-1905
> > > >
> > > >
> > > > Dne 10.9.2015 v 18:02 Thomas Andraschko napsal(a):
> > > >
> > > >> Hi,
> > > >>
> > > >> it's often required to manual activate scopes in a async
> > > threads/runnables
> > > >> if you don't use JavaEE 7.
> > > >> I already used this in 3-4 projects in the last 3 years.
> > > >>
> > > >> My current API looks like:
> > > >>
> > > >> CdiManagedRunnable - A abstract class with implements Runnable 
> > > >> and
> > > starts
> > > >> the RequestScoped via ContextControl and a new scope called
> > ThreadScope
> > > >> RequestScoped is optional,
> CdiManagedRunnable#isRequestScopedSupported
> > > >> return false per default and can be overwritten by the user.
> > > >>
> > > >> ThreadContext - A AbstractContext implementation which a static
> static
> > > >> ThreadLocal
> > > >>
> > > >> ThreadContextExtension
> > > >> ThreadScoped
> > > >>
> > > >> WDYT? Is this useful for other people too?
> > > >>
> > > >> Regards,
> > > >> Thomas
> > > >>
> > > >>
> > > > --
> > > > Martin Kouba
> > > > Software Engineer
> > > > Red Hat, Czech Republic
> > > >
> > >
> >
>

RE: [DISCUSS] Add persist and merge methods to EntityRepository

[Marvin Toll]

Agreed... mixing the JPA API (persist / merge) with an abstraction API 
(save) is confusing.

Said another way... the goals of an abstraction to provide convenience and 
reduce the learning curve is being thwarted by too many choices and an extended 
learning curve.

-Original Message-
From: Thomas Hug [mailto:thomas@gmail.com] 
Sent: Monday, August 24, 2015 5:00 PM
To: dev@deltaspike.apache.org
Subject: Re: [DISCUSS] Add persist and merge methods to EntityRepository

Also I had the impression that having save, persist and merge would be 
confusing - seems like that assumption was not correct :)

RE: [DISCUSS] Add persist and merge methods to EntityRepository

[Marvin Toll]

Good suggestion!

Trying to figure out what save does in all contexts has been a challenge... 
and those that know native JPA are familiar with these seven often used methods:

clear()
contains()
detach()
flush()
merge()
persist()
remove()

If these methods exercise the underlying provider implementation directly, that 
is as forwarding methods, then perhaps the save methods could be deprecated 
so they no longer 'add' to the JPA API learning curve and potentially are a 
source of confusion?

--

There has been a second area of confusion.

Our current theory is that when using Request Scoped transactions the Flush is 
required when subsequent processing occurs after a transaction (but before the 
end of the Request).

However, when using Transaction Scoped transactions the flush is not required.

Therefore, when changing declarative scope a corresponding programmatic change 
is required.  We plan to verify this accuracy of this theory in multiple 
functional contexts next week.

--

Realize that our team learning context is as users of persistence (Toplink) for 
ten+ years and native JPA (EclipseLink) for a couple of years.

Thus, some confusion is to be expected when determining how the DS abstraction 
interacts with EclipseLink.

_Marvin

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Friday, August 21, 2015 9:23 PM
To: deltaspike dev@deltaspike.apache.org
Subject: [DISCUSS] Add persist and merge methods to EntityRepository

All,

Based on the findings from Harald, and the general issues being seen with 
EntityRepository I'd like to propose that we add merge and persist methods to 
the EntityRepository interface.

Both methods would delegate down direct to the underlying EntityManager's 
methods of the same signature and have the exact same behavior.  This will give 
app developers direct access in cases where they want to explicitly call one or 
the other.

John

RE: Issues with EntityRepository.save()

[Marvin Toll]

First an FYI... the Ford Motor Company Intellectual Property attorney group 
approved our (ten specifically named Software Engineers) participation with the 
Apache DeltaSpike community yesterday.  So, we can now use the word Ford in 
our informal communications.  :-)

This does not represent a formal endorsement of DS nor does it give license for 
the use/misuse of the Ford brand in any formal communications. 

In any case, we are continuing to develop use cases using the save method in 
combination with EclipseLink (only).  We may have found a 'broken scenario 
today but plan to verify this on Monday with fresh eyes to see whether this is 
truly a bug... and worth pursing as a representative case of unexpected 
behavior using the save abstraction.

Our strategy includes, running a scenario with native JPA (EclipseLink) and 
then the same scenario with DS Data... and looking for different outcomes.

Bottom line?  I agree with John that this discussion needs attention.

More to come,
Marvin

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Friday, August 21, 2015 5:22 PM
To: dev@deltaspike.apache.org; Marvin Toll marvint...@gtcgroup.com
Subject: Re: Issues with EntityRepository.save()

So the discussions on this died down, but I think we should still plan to do 
something regarding the issue.

I'd like to propose that we do #1 and the back half of #4.

We may want to add some additional comments.  For example, recommend that the 
@Id column is always nullable, which should clarify some of the behavior.  We 
may even want to try to add a log message around it.

I'm going to try to add nullable IDs to the project I'm working on right now to 
see if it works the way I expect.  If so would be the right way to go IMHO for 
users in general.

Another issue I noticed with EntityRepository is that I can extend it with 
EntityRepositoryPojo,String where String is not the @Id column.  There are 
absolutely no warning about this, and you wouldn't notice the issue until you 
try calling findBy(PK).  May want to add a note about this as well, even if its 
only in dev mode.

John

   Harald At the moment, I don't see a way to specify and 
   implement
   save() in a way that is logically consistent *and* portable 
   across JPA
  providers.
(I'll be happy to be proved false.) /Harald
  

RE: Wildfly 9 Tests?

[Marvin Toll]

Now that IBM finally got an EE7 server certified 
(http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html
 )... does it make sense to add them to the suite (particularly if we are going 
to add Wildfly 9)?

_Marvin

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Sunday, August 16, 2015 10:07 PM
To: deltaspike dev@deltaspike.apache.org
Subject: Wildfly 9 Tests?

All,

Looking at http://deltaspike.apache.org/documentation/build.html it seems we 
don't build and test against Wildfly 9, only 8.  One key difference is that now 
the Arquillian container is separately managed.

Is this simply an over sight?

John

RE: Issues with EntityRepository.save()

[Marvin Toll]

Harald At the moment, I don't see a way to specify and implement save() in a 
way that is logically consistent *and* portable across JPA providers.
 (I'll be happy to be proved false.)
/Harald?

Had another idea just before drifting off to sleep last night... perhaps this 
dreamy though is useful for consideration in the light of day?

What if---

DeltaSpike DataH[impl only] (the current DeltaSpike Data) was optimized for 
Hibernate?

And a new DeltaSpike DataE[impl only] was optimized for EclipseLink?


Said another way, an objective of trying to abstract both of these provides, 
given the large volume of custom extensions required for a still too immature 
JPA specification, and perhaps more importantly maintain an adequate Test 
Suite(s), may be more challenging/limiting than first imagined?


_Marvin


-Original Message-
From: Thomas Hug [mailto:thomas@gmail.com] 
Sent: Friday, August 14, 2015 5:00 AM
To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
Subject: Re: Issues with EntityRepository.save()

Thanks guys for all the effort in digging into the issue here. From a pragmatic 
point of view I guess #2 would be my preferred option and then think about what 
we should do with that save thing :) Maybe a strategy pattern similar to what 
we have for TX would be the way to go.

The documentation does not put a focus on it, but Data is in no way exclusively 
dependent on EntityRepository resp. AbstractEntityRepository - those are just 
convenience constructs which I have seen in almost any team I've worked popping 
up when it comes to JPA usage. With delegates [1] you can actually build your 
own convenience base repositories the way they should be ;) Also other features 
like criteria support have been moved to their own interfaces and can be pulled 
in on demand.

Hope that helps,
Thomas

[1] http://deltaspike.apache.org/documentation/data.html#QueryDelegates

On Thu, Aug 13, 2015 at 6:21 PM, Marvin Toll marvint...@gtcgroup.com
wrote:

 Am in strong agreement with Harald's statement:

 I never really liked the fact that save() blurs the distinction 
 between
 persist() and merge(), and by its very name it encourages users to 
 always call save() after changing an entity state which is usually 
 unnecessary and sometimes even wrong - so far, I've seen each and 
 every new user of DeltaSpike Data doing that.

 Having used near-native JPA2 for about 3.5 years I'm having an awkward 
 time mentally mapping the Data module abstraction to native JPA.  
 Said another way, I become a bit confused trying to remember how 
 native JPA2 works and how the DeltaSpike abstraction works.  However, 
 this potential criticism is made without me having adequate 
 time/experience with DeltaSpike Data... and may simply be my own transition 
 discomfort.


 A wild idea... would you consider a less intrusive abstraction for a 
 Data2 module?  One that does not try to mirror Spring (or the 
 Repository Pattern) but rather seeks to extend the JPA2 API?


 _Marvin

 -Original Message-
 From: Harald Wellmann [mailto:hwellmann...@gmail.com]
 Sent: Wednesday, August 12, 2015 5:46 PM
 To: dev@deltaspike.apache.org
 Subject: Issues with EntityRepository.save()

 This is a quick summary of the issues around EntityRepository.save() 
 that seem to exist since 1.4.2.

 I'll create test cases and JIRA issues as time permits, but I think 
 these notes may be helpful at this stage to find out whether or not 
 incompatibilities experienced by other users have the same root cause.

 According to Javadoc [1], this is what save() does:

 Persist (new entity) or merge the given entity. The distinction on 
 calling either method is done based on the primary key field being 
 null or not. If this results in wrong behavior for a specific case, 
 consider using the EntityManagerDelegate which offers both persist and merge.

 As far as I can see, the description accurately describes the 
 behaviour in 1.4.1.

 The behaviour was changed in 1.4.2 in an incompatible way without 
 adapting the documentation. Since 1.4.2, if the primary key is not 
 null, DeltaSpike also runs a database query to check whether an entity 
 with the given key exists. If so, it calls merge(), otherwise persist().

 So there are now quite a few cases when save() calls persist() where 
 it would have called merge() in 1.4.1.

 Some use cases:

 Use case 1:

 // assume separate transactions.
 foo = save(foo);
 remove(foo);
 foo = save(foo);

 Result in 1.4.1:
 foo is persistent. The second save() is a merge().

 Result in 1.4.2:
 Exception. The second save() is a persist(), since the key no longer 
 exists. But then Hibernate complains it cannot persist a detached entity.

 Use case 2:

 Assume a one-to-many association Blog - Comment, both with 
 auto-generated identities of type long.

 public Blog createBlog(ListComment comments) {
  Blog = new Blog();
  blog.setComments(comments);
  blog = blogRepository.save(blog);
  blog.getComments

RE: Issues with EntityRepository.save()

[Marvin Toll]

Sounds good... perhaps obviously I'm a DeltaSpike newbie and negotiating my way 
through the learning curve.

-Original Message-
From: Karl Kildén [mailto:karl.kil...@gmail.com] 
Sent: Friday, August 14, 2015 8:00 AM
To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
Subject: Re: Issues with EntityRepository.save()

Marvin,

What you are suggesting is not required imo. Some strategy configuration like 
suggested from Thomas would give the same benefits.

On 14 August 2015 at 13:39, Marvin Toll marvint...@gtcgroup.com wrote:

 Harald At the moment, I don't see a way to specify and implement 
 save() in a way that is logically consistent *and* portable across JPA 
 providers.
  (I'll be happy to be proved false.)
 /Harald?

 Had another idea just before drifting off to sleep last night... 
 perhaps this dreamy though is useful for consideration in the light of day?

 What if---

 DeltaSpike DataH[impl only] (the current DeltaSpike Data) was 
 optimized for Hibernate?

 And a new DeltaSpike DataE[impl only] was optimized for EclipseLink?


 Said another way, an objective of trying to abstract both of these 
 provides, given the large volume of custom extensions required for a 
 still too immature JPA specification, and perhaps more importantly 
 maintain an adequate Test Suite(s), may be more challenging/limiting 
 than first imagined?


 _Marvin

RE: Issues with EntityRepository.save()

[Marvin Toll]

Am in strong agreement with Harald's statement:

I never really liked the fact that save() blurs the distinction between 
persist() and merge(), and by its very name it encourages users to always call 
save() after changing an entity state which is usually unnecessary and 
sometimes even wrong - so far, I've seen each and every new user of DeltaSpike 
Data doing that.

Having used near-native JPA2 for about 3.5 years I'm having an awkward time 
mentally mapping the Data module absraction to native JPA.  Said another way, 
I become a bit confused trying to remember how native JPA2 works and how the 
DeltaSpike abstraction works.  However, this potential criticism is made 
without me having adequate time/experience with DeltaSpike Data... and may 
simply be my own transition discomfort. 


A wild idea... would you consider a less intrusive abstraction for a Data2 
module?  One that does not try to mirror Spring (or the Repository Pattern) but 
rather seeks to extend the JPA2 API?


_Marvin

-Original Message-
From: Harald Wellmann [mailto:hwellmann...@gmail.com] 
Sent: Wednesday, August 12, 2015 5:46 PM
To: dev@deltaspike.apache.org
Subject: Issues with EntityRepository.save()

This is a quick summary of the issues around EntityRepository.save() that seem 
to exist since 1.4.2.

I'll create test cases and JIRA issues as time permits, but I think these notes 
may be helpful at this stage to find out whether or not incompatibilities 
experienced by other users have the same root cause.

According to Javadoc [1], this is what save() does:

Persist (new entity) or merge the given entity. The distinction on calling 
either method is done based on the primary key field being null or not. If this 
results in wrong behavior for a specific case, consider using the 
EntityManagerDelegate which offers both persist and merge.

As far as I can see, the description accurately describes the behaviour in 
1.4.1.

The behaviour was changed in 1.4.2 in an incompatible way without adapting the 
documentation. Since 1.4.2, if the primary key is not null, DeltaSpike also 
runs a database query to check whether an entity with the given key exists. If 
so, it calls merge(), otherwise persist().

So there are now quite a few cases when save() calls persist() where it would 
have called merge() in 1.4.1.

Some use cases:

Use case 1:

// assume separate transactions.
foo = save(foo);
remove(foo);
foo = save(foo);

Result in 1.4.1:
foo is persistent. The second save() is a merge().

Result in 1.4.2:
Exception. The second save() is a persist(), since the key no longer exists. 
But then Hibernate complains it cannot persist a detached entity.

Use case 2:

Assume a one-to-many association Blog - Comment, both with auto-generated 
identities of type long.

public Blog createBlog(ListComment comments) {
 Blog = new Blog();
 blog.setComments(comments);
 blog = blogRepository.save(blog);
 blog.getComments().add(new Comment()); }

Now someone calls createBlog(Arrays.asList(c1, c2)).

In 1.4.1 this call succeeds. In 1.4.2, there is an 
UnsupportedOperationException since blog.getComments() is immutable.

In 1.4.1, the identity member is 0. 0 is not null, so save() performs a 
merge(). merge() creates a new blog instance with a new mutable comments list 
(at least with Hibernate (PersistentBag)).

In 1.4.2, there is no existing blog entity with identity 0, so save() calls 
persist() and returns the original blog instance. Its comments member is the 
result of Arrays.asList() which is immutable.

Sometimes it is useful to question the things you think you know, like an 
entity with an identity value of 0 or null cannot be persistent. I searched 
the JPA 2.1 spec and did not find a word about zero identities. 
In fact, Eclipselink has an option to *enable* zero identities 
(eclipselink.allow-zero-id).

The exception from Hibernate is also misleading. Just because an entity passed 
to persist() has a non-null and non-zero key, it does not have to be detached, 
it may well be a new transient entity.

I never really liked the fact that save() blurs the distinction between
persist() and merge(), and by its very name it encourages users to always call 
save() after changing an entity state which is usually unnecessary and 
sometimes even wrong - so far, I've seen each and every new user of DeltaSpike 
Data doing that.

At the moment, I don't see a way to specify and implement save() in a way that 
is logically consistent *and* portable across JPA providers. 
(I'll be happy to be proved false.)

So for the next release we should do one of the following:

1) Adapt Javadoc to the current behaviour and document the incompatibilities.

2) Leave Javadoc unchanged and restore compatibility.

3) Specify a new expected behaviour and adapt both Javadoc and implementation.

4) Add a big fat warning to save() Javadoc and move persist() and
merge() from EntityManagerDelegate to EntityRepository.

[1]

RE: [VOTE] Release of Apache DeltaSpike 1.5.0

[Marvin Toll]

Gerhard,

Interesting suggestion... we will consider it.

_Marvin

-Original Message-
From: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] 
Sent: Wednesday, August 12, 2015 10:43 AM
Subject: Re: [VOTE] Release of Apache DeltaSpike 1.5.0

hi marvin,

...

(since we release quite often some projects even have a 2nd ci-job which 
executes the test-suite (of the application) against the latest (daily) 
snapshot (see [1]) to ensure that they can upgrade to the next version easily 
and without a significant overhead.)

regards,
gerhard

[1] http://deltaspike.apache.org/documentation/snapshots.html

RE: [VOTE] Release of Apache DeltaSpike 1.5.0

[Marvin Toll]

An update from an unspecified Motor Company:

We made the decision to roll-back from 1.4.2 to 1.4.0 this morning... as we had 
skipped 1.4.1.

I'd suggest that you pull 1.4.2... as it now appears this release broke about 
50 of our Reference Application JUnit tests.

_Marvin


-Original Message-
From: Harald Wellmann [mailto:hwellmann...@gmail.com] 
Sent: Tuesday, August 11, 2015 2:30 PM
To: dev@deltaspike.apache.org
Subject: Re: [VOTE] Release of Apache DeltaSpike 1.5.0

Hi Gerhard,

I compared to 1.4.1 because that's the last known good version, 1.4.2 broke my 
application already (DELTASPIKE-965),

After some analysis, I believe the new regressions I reported yesterday were 
introduced in 1.4.2 and not in 1.5.0 - I wasn't able to see them with 1.4.2 due 
to that first blocker (or maybe I should have looked more closely).

The point is, the behavior of EntityRepository.save() has changed in an 
incompatible way which is likely to break some other applications (not just 
mine).

I now change my vote to +1, seeing that this 1.5.0 candidate is an improvement 
over 1.4.2, but that does not mean that all is well - we need to sort out a 
couple of issues related to save().

I'll start a separate thread on that, to keep the discussion focused.

Regards,
Harald

RE: [DOCUMENTATION] Incorrect Link?

[Marvin Toll]

Gerhard,

As you mentioned, if you are no longer an incubator project it would be great 
to remove that from all documentation.

We had a little negative feedback/concern on that issue within our company... 

_Marvin

--
|  USA Cell: 248.866.4897
|  Email: mar...@gtcgroup.com
|  Web: http://MarvinToll.com
|  Skype: marvin.toll
--
 
Pattern Enabled Development ® (PED) - http://pedCentral.com
PED seeks to advance Java/JavaScript application construction
by inspiring software engineers with  Pattern First Thinking,
enabling project teams with a Pattern Palette, and harmonizing
enterprise communication with a Unified Pattern Language.

-Original Message-
From: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] 
Sent: Wednesday, July 15, 2015 4:41 AM
To: dev@deltaspike.apache.org
Cc: Dan Allen
Subject: Re: [DOCUMENTATION] Incorrect Link?

hi marvin,

thx! we saw that as well some time ago.
dan created the mirror back then.
- we still need someone else with a nabble-account who gets added as
co-owner.
(as you can see it's labeled as incubator - at that time there was no 
dedicated users-list.)

regards,
gerhard