[jira] [Created] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
Falko Modler created DELTASPIKE-1116:
Summary: CdiTestRunner injects test class fields twice
Key: DELTASPIKE-1116
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
Project: DeltaSpike
Issue Type: Bug
Components: TestControl
Affects Versions: 1.6.0, 1.5.4, 1.0.2
Environment: Apache Maven 3.2.5
(12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
Maven home: C:\Program Files\apache-maven-3.2.5
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: C:\Develop\jdk1.7.0_80\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Falko Modler
{{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
{{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes it
possible to use injected beans in a {{@Before}} method or even in a JUnit
{{TestRule}}.
But shortly before executing the actual test method,
{{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
overwriting any changes that have been made to the fields in a JUnit
{{TestRule}} or a {{@Before}} method in the test.
The second injection was introduced by DELTASPIKE-342:
https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
I don't know why there needs to be a second injection at all.
All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-1116:
-
Attachment: DELTASPIKE-1116.zip
Please see attached maven project which contains a showcase test for this
problem:
A bean is injected and is wrapped into a mockito spy via {{@Spy}} and
{{MockitoJUnitRule}}.
The {{@Before}} method "sees" the spy as expected, but in the actual test
method it's gone (overwritten with the Weld proxy by the second injection).
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-1116:
-
Attachment: DELTASPIKE-1116.zip
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-1116:
-
Attachment: (was: DELTASPIKE-1116.zip)
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[ANNOUNCE] Release of Apache DeltaSpike 1.6.0
The Apache DeltaSpike team is pleased to announce the 24th release of DeltaSpike. Apache DeltaSpike is not a CDI-container, but a portable CDI extension. Documentation: http://deltaspike.apache.org/documentation/ Download: http://deltaspike.apache.org/download.html Release Notes: http://s.apache.org/DS_1.6.0 Enjoy! Gerhard Petracek
[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-1116:
-
Assignee: Gerhard Petracek
Priority: Minor (was: Major)
changed to minor, because only fields annotated with @Inject are touched -
those fields shouldn't get changed manually
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228027#comment-15228027
]
Gerhard Petracek commented on DELTASPIKE-1116:
--
[~famod]:
if BeanProvider#injectFields changes fields which aren't annotated with
@Inject, please file an issue at the issue-tracker for the cdi-implementation
you are using
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228046#comment-15228046
]
Falko Modler commented on DELTASPIKE-1116:
--
Only @Inject fields are changed.
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-1114) update site and javadoc to 1.6.0
[ https://issues.apache.org/jira/browse/DELTASPIKE-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-1114. -- Resolution: Fixed > update site and javadoc to 1.6.0 > > > Key: DELTASPIKE-1114 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1114 > Project: DeltaSpike > Issue Type: Task > Components: Documentation >Affects Versions: 1.6.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 1.6.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228055#comment-15228055
]
Falko Modler commented on DELTASPIKE-1116:
--
{quote}
those fields shouldn't get changed manually
{quote}
Why not? While I understand that this isn't the default use case, shouldn't the
test to be able to decide what to do with it's fields after the frameworks did
their job?
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-707) AbstractMockManager does not support interfaces mocked by mockito
[
https://issues.apache.org/jira/browse/DELTASPIKE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228063#comment-15228063
]
Falko Modler commented on DELTASPIKE-707:
-
I have a suggestion for an alternative/extended {{AbstractMockManager}}
implementation that fixes this problem.
Do I have to start a discussion in the mailing list and push a discussion
branch first or can I just put it here?
> AbstractMockManager does not support interfaces mocked by mockito
> -
>
> Key: DELTASPIKE-707
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-707
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2
> Environment: Mockito 1.9.5
> JDK 1.7u51
>Reporter: Falko Modler
>
> Following the
> [manual|https://deltaspike.apache.org/test-control.html#mock-frameworks], I
> tried to mock {{EntitityManager}} in my test class:
> {noformat}
> @RunWith(CdiTestRunner.class)
> public class SomeTest {
> @Inject
> private DynamicMockManager mockManager;
> @Test
> public void mockitoMockAsCdiBean() {
> mockManager.addMock(Mockito.mock(EntityManager.class));
> [...]
> }
> }
> {noformat}
> Unfortunately this doesn't work as {{AbstractMockManager}} fails with:
> {noformat}
> java.lang.IllegalArgumentException:
> $javax.persistence.EntityManager$$EnhancerByMockitoWithCGLIB$$b065dd9c isn't
> a supported approach for mocking -> please extend from the original class.
> at
> org.apache.deltaspike.testcontrol.impl.mock.AbstractMockManager.addMock(AbstractMockManager.java:45)
> {noformat}
> Following (rather ugly) workaound fixes the problem:
> {noformat}
> @Typed(EntityManager.class)
> public static abstract class EntityManagerMockBase implements
> EntityManager {
> }
> {noformat}
> {noformat}
> mockManager.addMock(Mockito.mock(EntityManagerMockBase.class));
> {noformat}
> If this problem cannot be solved then the documentation should at least
> mention that mocking does not work for interfaces and how to work around that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-707) AbstractMockManager does not support interfaces mocked by mockito
[
https://issues.apache.org/jira/browse/DELTASPIKE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228147#comment-15228147
]
John D. Ament commented on DELTASPIKE-707:
--
[~famod] this ticket's been closed for a really long time. I'd suggest
bringing it up on the discussion channels (dev@ or user@) to brain storm ideas.
I'm curious to see what you have, as I have needs to do something similar.
> AbstractMockManager does not support interfaces mocked by mockito
> -
>
> Key: DELTASPIKE-707
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-707
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2
> Environment: Mockito 1.9.5
> JDK 1.7u51
>Reporter: Falko Modler
>
> Following the
> [manual|https://deltaspike.apache.org/test-control.html#mock-frameworks], I
> tried to mock {{EntitityManager}} in my test class:
> {noformat}
> @RunWith(CdiTestRunner.class)
> public class SomeTest {
> @Inject
> private DynamicMockManager mockManager;
> @Test
> public void mockitoMockAsCdiBean() {
> mockManager.addMock(Mockito.mock(EntityManager.class));
> [...]
> }
> }
> {noformat}
> Unfortunately this doesn't work as {{AbstractMockManager}} fails with:
> {noformat}
> java.lang.IllegalArgumentException:
> $javax.persistence.EntityManager$$EnhancerByMockitoWithCGLIB$$b065dd9c isn't
> a supported approach for mocking -> please extend from the original class.
> at
> org.apache.deltaspike.testcontrol.impl.mock.AbstractMockManager.addMock(AbstractMockManager.java:45)
> {noformat}
> Following (rather ugly) workaound fixes the problem:
> {noformat}
> @Typed(EntityManager.class)
> public static abstract class EntityManagerMockBase implements
> EntityManager {
> }
> {noformat}
> {noformat}
> mockManager.addMock(Mockito.mock(EntityManagerMockBase.class));
> {noformat}
> If this problem cannot be solved then the documentation should at least
> mention that mocking does not work for interfaces and how to work around that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Result (was: Re: [VOTE] Release of Apache DeltaSpike 1.6.0)
Technically speaking, Harald is not on the PMC. John On Wed, Apr 6, 2016 at 1:22 AM Gerhard Petracek wrote: > thank you for voting! > > 8 binding +1 votes (pmc): > - Christian Kaltepoth > - Cody Lerum > - Gerhard Petracek > - Harald Wellmann > - John D. Ament > - Mark Struberg > - Romain Manni-Bucau > - Thomas Andraschko > > no -1 votes > > regards, > gerhard > > > > 2016-04-02 23:46 GMT+02:00 Gerhard Petracek : > > > Hi, > > > > I was running the needed tasks to get the 24th 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.6.0 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-1034/ > > [2] > > > https://repository.apache.org/content/repositories/orgapachedeltaspike-1034/org/apache/deltaspike/deltaspike/1.6.0/deltaspike-1.6.0-source-release.zip > > [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.6.0 > > [4] https://github.com/os890/deltaspike-vote/tree/ds-1.6.0 > > [5] http://www.apache.org/foundation/voting.html#ReleaseVotes > > >
Re: Result (was: Re: [VOTE] Release of Apache DeltaSpike 1.6.0)
thank you for voting! 7 binding +1 votes (pmc): - Christian Kaltepoth - Cody Lerum - Gerhard Petracek - John D. Ament - Mark Struberg - Romain Manni-Bucau - Thomas Andraschko 1 non-binding +1 vote: - Harald Wellmann no -1 votes regards, gerhard 2016-04-06 14:02 GMT+02:00 John D. Ament : > Technically speaking, Harald is not on the PMC. > > John > > On Wed, Apr 6, 2016 at 1:22 AM Gerhard Petracek > wrote: > > > thank you for voting! > > > > 8 binding +1 votes (pmc): > > - Christian Kaltepoth > > - Cody Lerum > > - Gerhard Petracek > > - Harald Wellmann > > - John D. Ament > > - Mark Struberg > > - Romain Manni-Bucau > > - Thomas Andraschko > > > > no -1 votes > > > > regards, > > gerhard > > > > > > > > 2016-04-02 23:46 GMT+02:00 Gerhard Petracek : > > > > > Hi, > > > > > > I was running the needed tasks to get the 24th 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.6.0 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-1034/ > > > [2] > > > > > > https://repository.apache.org/content/repositories/orgapachedeltaspike-1034/org/apache/deltaspike/deltaspike/1.6.0/deltaspike-1.6.0-source-release.zip > > > [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.6.0 > > > [4] https://github.com/os890/deltaspike-vote/tree/ds-1.6.0 > > > [5] http://www.apache.org/foundation/voting.html#ReleaseVotes > > > > > >
[jira] [Created] (DELTASPIKE-1117) add cache(long ms) to ConfigResolver.TypedResolver
Mark Struberg created DELTASPIKE-1117: - Summary: add cache(long ms) to ConfigResolver.TypedResolver Key: DELTASPIKE-1117 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1117 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.6.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.6.1 add a method to automatically cache resolved values until for a specific time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228292#comment-15228292
]
Gerhard Petracek commented on DELTASPIKE-1116:
--
[~famod]:
if you use @Inject, you leave the control to the container.
if you change the value anyway, you can just drop the annotation...
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1117) add cache(long ms) to ConfigResolver.TypedResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228329#comment-15228329 ] Romain Manni-Bucau commented on DELTASPIKE-1117: [~struberg] would it makes sense to not do it in DS but wire it to a Storage then user can use any caching impl he wants instead of redoing it in DS? The SPI would be pretty thin. > add cache(long ms) to ConfigResolver.TypedResolver > -- > > Key: DELTASPIKE-1117 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1117 > Project: DeltaSpike > Issue Type: Bug > Components: Configuration >Affects Versions: 1.6.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.6.1 > > > add a method to automatically cache resolved values until for a specific time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1117) add cache(long ms) to ConfigResolver.TypedResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228350#comment-15228350 ] Mark Struberg commented on DELTASPIKE-1117: --- Users can already do that. But adding this simple method to the builder is a big gain and does not cost much (2 longs internally). > add cache(long ms) to ConfigResolver.TypedResolver > -- > > Key: DELTASPIKE-1117 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1117 > Project: DeltaSpike > Issue Type: Bug > Components: Configuration >Affects Versions: 1.6.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.6.1 > > > add a method to automatically cache resolved values until for a specific time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1118) ThrottledInterceptor needs to use an InterceptorStrategy
Gerhard Petracek created DELTASPIKE-1118: Summary: ThrottledInterceptor needs to use an InterceptorStrategy Key: DELTASPIKE-1118 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1118 Project: DeltaSpike Issue Type: Improvement Affects Versions: 1.6.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.6.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1119) FutureableInterceptor needs to use an InterceptorStrategy
Gerhard Petracek created DELTASPIKE-1119: Summary: FutureableInterceptor needs to use an InterceptorStrategy Key: DELTASPIKE-1119 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1119 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 1.6.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.6.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1120) LockedInterceptor needs to use an InterceptorStrategy
Gerhard Petracek created DELTASPIKE-1120: Summary: LockedInterceptor needs to use an InterceptorStrategy Key: DELTASPIKE-1120 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1120 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 1.6.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.6.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1117) add cache(long ms) to ConfigResolver.TypedResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228363#comment-15228363 ] Romain Manni-Bucau commented on DELTASPIKE-1117: [~struberg] it does since then you need evict(key) and you will likely want this caching at source level too or by key pattern next time. Having a cache SPI will allow to rely on widely used cache implementation and get it for free letting the user design its configuration/keys as he wants (= add Cache SPI in DS and not cache in a map internally if provided but use that cache, this is not doable today or if it is this feature is useless, no?). > add cache(long ms) to ConfigResolver.TypedResolver > -- > > Key: DELTASPIKE-1117 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1117 > Project: DeltaSpike > Issue Type: Bug > Components: Configuration >Affects Versions: 1.6.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.6.1 > > > add a method to automatically cache resolved values until for a specific time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1121) documentation for @Throttled
Gerhard Petracek created DELTASPIKE-1121: Summary: documentation for @Throttled Key: DELTASPIKE-1121 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1121 Project: DeltaSpike Issue Type: Task Components: Documentation Affects Versions: 1.6.0 Reporter: Gerhard Petracek Assignee: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1118) ThrottledInterceptor needs to use an InterceptorStrategy
[ https://issues.apache.org/jira/browse/DELTASPIKE-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-1118: - Issue Type: Improvement (was: Task) > ThrottledInterceptor needs to use an InterceptorStrategy > > > Key: DELTASPIKE-1118 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1118 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.6.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 1.6.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1122) documentation for @Futureable
Gerhard Petracek created DELTASPIKE-1122: Summary: documentation for @Futureable Key: DELTASPIKE-1122 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1122 Project: DeltaSpike Issue Type: Task Components: Documentation Affects Versions: 1.6.0 Reporter: Gerhard Petracek Assignee: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1118) ThrottledInterceptor needs to use an InterceptorStrategy
[ https://issues.apache.org/jira/browse/DELTASPIKE-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-1118: - Issue Type: Task (was: Improvement) > ThrottledInterceptor needs to use an InterceptorStrategy > > > Key: DELTASPIKE-1118 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1118 > Project: DeltaSpike > Issue Type: Task > Components: Core >Affects Versions: 1.6.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 1.6.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1123) documentation for @Locked
Gerhard Petracek created DELTASPIKE-1123: Summary: documentation for @Locked Key: DELTASPIKE-1123 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1123 Project: DeltaSpike Issue Type: Task Components: Documentation Affects Versions: 1.6.0 Reporter: Gerhard Petracek Assignee: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1118) ThrottledInterceptor needs to use an InterceptorStrategy
[ https://issues.apache.org/jira/browse/DELTASPIKE-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-1118: - Component/s: Core > ThrottledInterceptor needs to use an InterceptorStrategy > > > Key: DELTASPIKE-1118 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1118 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.6.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 1.6.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-1117) add cache(long ms) to ConfigResolver.TypedResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-1117. --- Resolution: Fixed > add cache(long ms) to ConfigResolver.TypedResolver > -- > > Key: DELTASPIKE-1117 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1117 > Project: DeltaSpike > Issue Type: Bug > Components: Configuration >Affects Versions: 1.6.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.6.1 > > > add a method to automatically cache resolved values until for a specific time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1117) add cache(long ms) to ConfigResolver.TypedResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228426#comment-15228426 ] Mark Struberg commented on DELTASPIKE-1117: --- there is no Map in DS. It's really a simple long reloadAfter logic + the last value. That's it. Of couse, every value has it's own timeout. If you need a full cache, then it's a different story. > add cache(long ms) to ConfigResolver.TypedResolver > -- > > Key: DELTASPIKE-1117 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1117 > Project: DeltaSpike > Issue Type: Bug > Components: Configuration >Affects Versions: 1.6.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.6.1 > > > add a method to automatically cache resolved values until for a specific time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
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
