{"id":2024,"date":"2016-02-16T17:41:33","date_gmt":"2016-02-16T16:41:33","guid":{"rendered":"http:\/\/www.xenonique.co.uk\/blog\/?p=2024"},"modified":"2016-02-17T19:44:21","modified_gmt":"2016-02-17T18:44:21","slug":"upgrade-deltaspike-gradle-and-cdi-container-with-test-module","status":"publish","type":"post","link":"https:\/\/www.xenonique.co.uk\/blog\/2016\/02\/16\/upgrade-deltaspike-gradle-and-cdi-container-with-test-module\/","title":{"rendered":"Upgrade DeltaSpike, Gradle and CDI Container with Test Module"},"content":{"rendered":"

I am puzzled by the Java EE 7 Developer Handbook that I wrote about two years ago. Well I researched it in 2013 and published it. I was looking at the code for Chapter 2, which has an old example of Apache DeltaSpike, JBoss Weld and Gradle. I want to upgrade it to work with the latest stable releases circa 2016. <\/p>\n

So where am I? I am stuck for once, because I received this exception whilst executing gradle build --stacktracer<\/code>. <\/p>\n

 <\/p>\n

\r\nFeb 16, 2016 2:50:34 PM org.apache.deltaspike.testcontrol.api.junit.CdiTestSuiteRunner$LogRunListener testFailure\r\nINFO: [failed] je7hb.standalone.CreditProcessorTest#null message: WELD-ENV-002000: Weld SE container STATIC_INSTANCE is already running!\r\n\r\njava.lang.IllegalStateException: WELD-ENV-002000: Weld SE container STATIC_INSTANCE is already running!\r\n\r\n\tat org.jboss.weld.environment.se.WeldContainer.initialize(WeldContainer.java:138)\r\n\tat org.jboss.weld.environment.se.Weld.initialize(Weld.java:562)\r\n\tat org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:68)\r\n\tat org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:76)\r\n\tat org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:463)\r\n\tat org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:366)\r\n\tat org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:393)\r\n\tat org.junit.runners.ParentRunner.run(ParentRunner.java:363)\r\n\tat org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:142)\r\n\tat org.junit.runners.Suite.runChild(Suite.java:128)\r\n\tat org.junit.runners.Suite.runChild(Suite.java:27)\r\n\tat org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)\r\n\tat org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)\r\n\tat org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)\r\n\tat org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)\r\n\tat org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)\r\n\tat org.junit.runners.ParentRunner.run(ParentRunner.java:363)\r\n\tat org.junit.runner.JUnitCore.run(JUnitCore.java:137)\r\n\tat com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)\r\n\tat com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)\r\n\tat com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)\r\n\tat sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\r\n\tat sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\r\n\tat sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\r\n\tat java.lang.reflect.Method.invoke(Method.java:497)\r\n\tat com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)\r\n<\/pre>\n
 <\/p>\n
They say always run on the command line, and so I did. I also verified this also issue inside IDEA 15.0.3.<\/p>\n
The unit test code is actually the simplest in the book:<\/p>\n
 <\/p>\n
\r\npackage je7hb.standalone;\r\n\r\nimport org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner;\r\nimport org.junit.Test;\r\nimport org.junit.runner.RunWith;\r\n\r\nimport javax.inject.Inject;\r\n\r\nimport static org.junit.Assert.*;\r\n\r\n@RunWith(CdiTestRunner.class)\r\npublic class CreditProcessorTest {\r\n    private @Inject @Economy CreditProcessor agent;\r\n\r\n    @Test\r\n    public void shouldInjectStreetCredit() {\r\n        assertNotNull(agent);\r\n        agent.check("12354678");\r\n        System.out.printf("agent=%s\\n", agent );\r\n    }\r\n}\r\n<\/pre>\n
 <\/p>\n
I threw out my older AbstractCdiContainerTest<\/code> implementation, because Delta Spike has replaced it with a new JUnit 4 Runner implementation. I upgraded to JBoss Weld 2.3.2<\/a> against Delta Spike 1.5.2<\/a>.<\/p>\n
At the moment, I am refactoring the Gradle build into a proper MULTI-MODULE build for all the students. There is something strange going on? The codebase is help on GitHub<\/a>.<\/p>\n
Extract of the build file is:<\/p>\n
\r\narchivesBaseName = 'ch02-cdi-standalone'\r\n\r\ndependencies {    \r\n    compile     "javax:javaee-api:${javaeeVersion}"\r\n\r\n    compile     "org.slf4j:slf4j-simple:${slf4jVersion}"\r\n    compile     "org.apache.deltaspike.cdictrl:deltaspike-cdictrl-api:${deltaspikeVersion}"\r\n    compile     "org.apache.deltaspike.cdictrl:deltaspike-cdictrl-weld:${deltaspikeVersion}"\r\n\r\n    compile     "org.jboss.weld.se:weld-se-core:${weldSEVersion}"\r\n    compile     "org.apache.deltaspike.modules:deltaspike-test-control-module-api:${deltaspikeVersion}"\r\n\r\n    testCompile     "org.apache.deltaspike.modules:deltaspike-test-control-module-impl:${deltaspikeVersion}"\r\n}\r\n\r\ntest {\r\n    testLogging.showStandardStreams = true\r\n\r\n    \/\/ set heap size for the test JVM(s)\r\n    minHeapSize = "128m"\r\n    maxHeapSize = "768m"\r\n\r\n    \/\/ Ensure that the working directory for the test is the same as the project directory in order to run the Spike Delta container tests\r\n    \/\/ *PP* 11\/02\/2016\r\n    workingDir = project.projectDir\r\n}\r\n\r\n<\/pre>\n
The dependencies are now set in the root Gradle project. Here is the extract:<\/p>\n
\r\nallprojects {\r\n    apply plugin: 'java'\r\n    apply plugin: 'maven'\r\n    apply plugin: 'eclipse'\r\n    apply plugin: 'idea'\r\n\r\n    \/\/ Define equivalent Maven GAV coordinates.\r\n    group = 'uk.co.xenonique.javaee7handbook'\r\n    version = '1.0-SNAPSHOT'\r\n\r\n    ext {\r\n        arquillianVersion                   = "1.1.11.Final"\r\n        arquillianJunitVersion              = "1.1.11.Final"\r\n        arquillianPersistenceVersion        = "1.0.0.Alpha6"\r\n        arquillianGlassfishEmbeddedVersion  = "1.0.0.Final-SNAPSHOT"\r\n        arquillianGlassfishManagedVersion   = "1.0.0.CR4"\r\n        arquillianGlassfishRemoteVersion    = "1.0.0.CR4"\r\n        deltaspikeVersion                   = "1.5.2"\r\n        glassfishVersion                    = "4.1"\r\n        hamcrestVersion                     = "1.3"\r\n        javaeeVersion                       = "7.0"\r\n        jodaTimeVersion                     = "2.2"\r\n        junitVersion                        = "4.12"\r\n        ozarkVersion                        = "1.0.0-m01"\r\n        mockitoVersion                      = "1.10.19"\r\n        shrinkWrapVersion                   = "1.0.1"\r\n\r\n        \/\/'org.slf4j:slf4j-api:1.7.14'\r\n        slf4jVersion                        = "1.7.14"\r\n        weldEEEmbeddedVersion               = "1.0.0.CR3" \r\n        weldSEVersion                       = "2.3.2.Final"\r\n    }\r\n\r\n    repositories {\r\n        mavenLocal()\r\n        mavenCentral()\r\n        maven {\r\n            url 'https:\/\/maven.java.net\/content\/groups\/promoted'\r\n        }\r\n        maven {\r\n            url 'https:\/\/repository.jboss.org\/nexus\/content\/groups\/public'\r\n        }        \r\n    }\r\n\r\n    \/\/ Java version compatibility to use when compiling Java source \r\n    sourceCompatibility = '1.8'\r\n    \/\/ Java version to generate classes\r\n    targetCompatibility = '1.8'\r\n...\r\n}\r\n<\/pre>\n
This failure is a complete mystery, why code that worked in 2013 and no longer executes in 2016. However, I am sure that it will be revealed.<\/p>\n
UPDATE<\/h2>\n
I was chatting on the DeltaSpike IRC and @os890<\/strong> informed me about a trick that works around the issue. <\/p>\n
You can also find a description in the Java EE 7 Tutorial about the @Priority annotation and Alternatives<\/a>.<\/p>\n

\n“The alternatives that you specify in the beans.xml file apply only to classes in the same archive. Use the @Priority annotation to specify alternatives globally for an application that consists of multiple modules …”
\n<\/cite><\/p>\n
And also <\/p>\n

\n“The alternative with higher priority value is selected if several alternative beans that implement the same interface are annotated with @Priority. You do not need to specify the alternative in the beans.xml file when you use the @Priority annotation.”
\n<\/cite><\/p>\n
To work around the issue, I use the @Priority<\/code> and Gradle builds everything fine. <\/p>\n
\r\n@Alternative\r\n@Priority(Interceptor.Priority.APPLICATION+100)\r\npublic class XenoniqueFoodProcessor implements FoodProcessor {\r\n    @Override\r\n    public String sayBrand() {\r\n        return "Xenonique";\r\n    }\r\n}\r\n<\/pre>\n
I added the above annotation to the Weld specific project, then I executed the test successfully. <\/p>\n
I do not believe DeltaSpike is broken and so the question remains,  is the Java EE 7 reference implementation of CDI 1.1 specification correct or incorrect with respect with Alternative configured in a beans.xml<\/code>?<\/p>\n
I also created source code to exercise Open Web Beans container as a parallel sub-project, see standalone-owb<\/code> in Github<\/a>. Indeed removed the @Priority<\/code> annotation from the XenoniqueFoodProcessor<\/code> bean and Gradle builds successfully! Ah ha this is an issue with JBoss Weld 1.5.3! It is not respecting @Alternatives as CDI 1.0 specification according to my examples.<\/p>\n
 <\/p>\n
+PP+<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
I am puzzled by the Java EE 7 Developer Handbook that I wrote about two years ago. Well I researched it in 2013 and published it. I was looking at the code for Chapter 2, which has an old example of Apache DeltaSpike, JBoss Weld and Gradle. I want to upgrade it to work with […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[174,148,143],"tags":[],"_links":{"self":[{"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/posts\/2024"}],"collection":[{"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=2024"}],"version-history":[{"count":9,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/posts\/2024\/revisions"}],"predecessor-version":[{"id":2035,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/posts\/2024\/revisions\/2035"}],"wp:attachment":[{"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=2024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=2024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.xenonique.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=2024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}