There is always the Weld User Forum: http://seamframework.org/Community/WeldUsers Weld Test does exist: http://anonsvn.jboss.org/repos/weld/test/trunk/ but will be 'converted' to a Arquillian container: Arquillian is a allover 'in container' test framework. Have a look at: http://community.jboss.org/docs/DOC-14376?uniqueTitle=false http://community.jboss.org/wiki/Arquillian-Demo Junit demo code: http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo/ TestNG demo code: http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo-testng/ Arquillian does not have any direct/standalone Weld support yet, but this is in the works and will be out soon. As for now, Weld can be used via the Jboss 6.0 Remote Container. Example of Weld + JUnit + Arquillian: http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo/src/test/java... This is the basis of upcoming Seam 3 Test. -- -- Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; http://www.conduct.no; mailto:aslak@conduct.no Conduct AS - Professional Open Source Services - Red Hat/JBoss Premier System Integrator - Pentaho Preferred Integration Partner - Atlassian Technology Partner 2009/12/26 Johan Eltes <johan.eltes(a)callistaenterprise.se&gt; It would be great me and other users to get a weld-user list! My major pain is to wrap my head around how to implement junit tests for cdi beans. Having a place where users could get together to sort out essential issues for projects trying to use Weld, would be great. If anyone has a sample of a unit test that does not depend on anything else than weld 1.0.0 would be really great: - How to have the test target object injected into the test case ? ... or... - How to obtain an injected test target object from within the test case? /Johan _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

The error message says it can't find a Container. If your testing the demo project, it is setup to run against multiple containers controlled via maven profile. see the arquillian demo wiki. ie: mvn test -P jboss-remote-60 -aslak- 2009/12/26 Johan Eltes <johan.eltes(a)callistaenterprise.se&gt; Excellent, Arquillian seems perfect for my needs. The snapshot build fails, though (the demo project). All tests fails with the same problem report: <testcase time="0.004" classname="com.acme.ejb.InjectionTestCase" name="initializationError"> <error message="No containers found" type="java.lang.RuntimeException">java.lang.RuntimeException: No containers found at org.jboss.arquillian.spi.util.DeployableContainers.load(DeployableContainers.java:37) at org.jboss.arquillian.impl.DeployableTestBuilder.build(DeployableTestBuilder.java:56) at org.jboss.arquillian.junit.Arquillian.&lt;init&gt;(Arquillian.java:52) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) at org.apache.maven.surefire.junit4.JUnit4TestSet.&lt;init&gt;(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993) </error> </testcase> Any hints that helps me forwards would be much appreciated. /Johan On 26 dec 2009 v52, at 11.19, Aslak Knutsen wrote: > There is always the Weld User Forum: http://seamframework.org/Community/WeldUsers > > Weld Test does exist: > http://anonsvn.jboss.org/repos/weld/test/trunk/ > but will be 'converted' to a Arquillian container: > > Arquillian is a allover 'in container' test framework. Have a look at: > http://community.jboss.org/docs/DOC-14376?uniqueTitle=false > http://community.jboss.org/wiki/Arquillian-Demo > > Junit demo code: > http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo/ > > TestNG demo code: > http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo-testng/ > > Arquillian does not have any direct/standalone Weld support yet, but this is in the works and will be out soon. As for now, Weld can be used via the Jboss 6.0 Remote Container. > > Example of Weld + JUnit + Arquillian: > http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo/src/test/java... > > > This is the basis of upcoming Seam 3 Test. > > -- > -- > Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 > Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; > http://www.conduct.no; mailto:aslak@conduct.no > > Conduct AS - Professional Open Source Services > - Red Hat/JBoss Premier System Integrator > - Pentaho Preferred Integration Partner > - Atlassian Technology Partner > > 2009/12/26 Johan Eltes <johan.eltes(a)callistaenterprise.se&gt; > It would be great me and other users to get a weld-user list! > My major pain is to wrap my head around how to implement junit tests for cdi beans. > Having a place where users could get together to sort out essential issues for projects trying to use Weld, would be great. If anyone has a sample of a unit test that does not depend on anything else than weld 1.0.0 would be really great: > > - How to have the test target object injected into the test case ? > ... or... > - How to obtain an injected test target object from within the test case? > > /Johan > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > -- -- Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; http://www.conduct.no; mailto:aslak@conduct.no Conduct AS - Professional Open Source Services - Red Hat/JBoss Premier System Integrator - Pentaho Preferred Integration Partner - Atlassian Technology Partner

Is there any working sample of how to set up a unit test for a weld bean? I'm only looking for java-se weld support here, not ejb/jsf. /Johan _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Johan, You also need to have JBoss AS running when using the jboss-remote-60 profile. I can confirm that JBoss AS 6.0.0.M1 works, but you have to first apply this metadata fix: http://community.jboss.org/thread/69486 So here are your steps to getting the arquillian demos working. 1) Download and extra JBoss AS 6.0.0.M1: http://jboss.org/jbossas/downloads 2) Apply the bean validation metadata fix described here: http://community.jboss.org/thread/69486?tstart=0 3) Start JBoss AS 6.0.0.M1 (using the typical ./bin/run.sh or via an IDE) 4) Run the Arquillian build (either from root of the project or either the demo or demo-testng folder) $MAVEN22_HOME/bin/mvn clean install -Pjboss-remote-60 As Aslak mentioned, the embedded jboss container is not working at the moment. The Arquillian project also has plans for supporting non-JBoss containers such as GlassFish V3, it just isn't done yet (so don't be mislead that this will always be JBoss AS-specific). -Dan p.s. Aslak, where are we with GlassFish V3 support? Is there somewhere you can point developers who are interested in helping getting that working? p.p.s. Aslak, do you mind if I add the steps above to the Arquillian page for now? On Sat, Dec 26, 2009 at 3:50 PM, Aslak Knutsen <aslak(a)conduct.no&gt; wrote: > The embedded container does not work atm due to classloader isolation > problems. > > The error your getting tho, is due to missing environment variable > JBOSS_HOME, so it assumes current directory as JBOSS_HOME and can't find the > lib folder. > > -aslak- > > 2009/12/26 Johan Eltes <johan.eltes(a)callistaenterprise.se&gt; > >> Missed the profiles. Thanks. Also, the emedded-container-project was >> commented in the multi-modue pom. Removed the comments, mvn install and then >> tried the demo project with the embedded profile. The test failed to execute >> (there is no demo/lib project): >> >> <testcase time="0.002" classname="com.acme.weld.InjectionTestCase" >> name="initializationError"> >> <error message="Could not start container" >> type="org.jboss.arquillian.spi.LifecycleException">org.jboss.arquillian.spi.LifecycleException: >> Could not start container >> at >> org.jboss.arquillian.jboss.JbossEmbeddedContainer.start(JbossEmbeddedContainer.java:55) >> at >> org.jboss.arquillian.impl.container.ContainerController.start(ContainerController.java:40) >> at >> org.jboss.arquillian.junit.Arquillian.&lt;init&gt;(Arquillian.java:55) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >> at >> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) >> at >> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) >> at >> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >> at >> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) >> at >> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >> at >> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) >> at >> org.apache.maven.surefire.junit4.JUnit4TestSet.&lt;init&gt;(JUnit4TestSet.java:45) >> at >> org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) >> at >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) >> at >> org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) >> at org.apache.maven.surefire.Surefire.run(Surefire.java:90) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289) >> at >> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993) >> Caused by: org.jboss.bootstrap.api.config.InvalidConfigurationException: >> Could not get a connection to the jboss.lib.url: >> file:/Users/johan/Documents/Development/Projects/arquillian/trunk/demo/lib >> at >> org.jboss.bootstrap.impl.as.config.JBossASBasedConfigurationValidator.require(JBossASBasedConfigurationValidator.java:193) >> at >> org.jboss.bootstrap.impl.as.config.JBossASBasedConfigurationValidator.require(JBossASBasedConfigurationValidator.java:163) >> at >> org.jboss.bootstrap.impl.as.config.JBossASBasedConfigurationValidator.validate(JBossASBasedConfigurationValidator.java:84) >> at >> org.jboss.bootstrap.impl.as.config.JBossASBasedConfigurationValidator.validate(JBossASBasedConfigurationValidator.java:43) >> at >> org.jboss.bootstrap.impl.base.server.AbstractServer.validate(AbstractServer.java:1045) >> at >> org.jboss.bootstrap.impl.base.server.AbstractServer.doInitialize(AbstractServer.java:599) >> at >> org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doInitialize(AbstractMCServerBase.java:224) >> at >> org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doInitialize(AbstractJBossASServerBase.java:274) >> at >> org.jboss.embedded.core.server.JBossASEmbeddedServerImpl.doInitialize(JBossASEmbeddedServerImpl.java:420) >> at >> org.jboss.bootstrap.impl.base.server.AbstractServer.initialize(AbstractServer.java:548) >> at >> org.jboss.bootstrap.impl.base.server.AbstractServer.start(AbstractServer.java:353) >> at >> org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.start(AbstractMCServerBase.java:250) >> at >> org.jboss.arquillian.jboss.JbossEmbeddedContainer.start(JbossEmbeddedContainer.java:51) >> ... 23 more >> Caused by: java.io.FileNotFoundException: >> /Users/johan/Documents/Development/Projects/arquillian/trunk/demo/lib (No >> such file or directory) >> at java.io.FileInputStream.open(Native Method) >> at java.io.FileInputStream.&lt;init&gt;(FileInputStream.java:106) >> at java.io.FileInputStream.&lt;init&gt;(FileInputStream.java:66) >> at >> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70) >> at >> org.jboss.bootstrap.impl.as.config.JBossASBasedConfigurationValidator.require(JBossASBasedConfigurationValidator.java:189) >> ... 35 more >> >> >> >> On 26 dec 2009 v52, at 21.15, Aslak Knutsen wrote: >> >> The error message says it can't find a Container. >> >> If your testing the demo project, it is setup to run against multiple >> containers controlled via maven profile. see the arquillian demo wiki. >> >> ie: >> mvn test -P jboss-remote-60 >> >> -aslak- >> >> 2009/12/26 Johan Eltes <johan.eltes(a)callistaenterprise.se&gt; >> >>> Excellent, Arquillian seems perfect for my needs. >>> The snapshot build fails, though (the demo project). All tests fails >>> with the same problem report: >>> >>> <testcase time="0.004" classname="com.acme.ejb.InjectionTestCase" >>> name="initializationError"> >>> <error message="No containers found" >>> type="java.lang.RuntimeException">java.lang.RuntimeException: No containers >>> found >>> at >>> org.jboss.arquillian.spi.util.DeployableContainers.load(DeployableContainers.java:37) >>> at >>> org.jboss.arquillian.impl.DeployableTestBuilder.build(DeployableTestBuilder.java:56) >>> at >>> org.jboss.arquillian.junit.Arquillian.&lt;init&gt;(Arquillian.java:52) >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>> at >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>> at >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>> at >>> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) >>> at >>> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) >>> at >>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>> at >>> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) >>> at >>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>> at >>> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) >>> at >>> org.apache.maven.surefire.junit4.JUnit4TestSet.&lt;init&gt;(JUnit4TestSet.java:45) >>> at >>> org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) >>> at >>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) >>> at >>> org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) >>> at org.apache.maven.surefire.Surefire.run(Surefire.java:90) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>> at java.lang.reflect.Method.invoke(Method.java:597) >>> at >>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289) >>> at >>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993) >>> </error> >>> </testcase> >>> >>> Any hints that helps me forwards would be much appreciated. >>> >>> /Johan >>> >>> On 26 dec 2009 v52, at 11.19, Aslak Knutsen wrote: >>> >>> There is always the Weld User Forum: >>> http://seamframework.org/Community/WeldUsers >>> >>> Weld Test does exist: >>> http://anonsvn.jboss.org/repos/weld/test/trunk/ >>> but will be 'converted' to a Arquillian container: >>> >>> Arquillian is a allover 'in container' test framework. Have a look at: >>> http://community.jboss.org/docs/DOC-14376?uniqueTitle=false >>> http://community.jboss.org/wiki/Arquillian-Demo >>> >>> Junit demo code: >>> http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo/ >>> >>> TestNG demo code: >>> http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo-testng/ >>> >>> Arquillian does not have any direct/standalone Weld support yet, but >>> this is in the works and will be out soon. As for now, Weld can be used via >>> the Jboss 6.0 Remote Container. >>> >>> Example of Weld + JUnit + Arquillian: >>> >>> http://anonsvn.jboss.org/repos/common/arquillian/trunk/demo/src/test/java... >>> >>> >>> This is the basis of upcoming Seam 3 Test. >>> >>> -- >>> -- >>> Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 >>> Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; >>> http://www.conduct.no; mailto:aslak@conduct.no >>> >>> Conduct AS - Professional Open Source Services >>> - Red Hat/JBoss Premier System Integrator >>> - Pentaho Preferred Integration Partner >>> - Atlassian Technology Partner >>> >>> 2009/12/26 Johan Eltes <johan.eltes(a)callistaenterprise.se&gt; >>> >>>> It would be great me and other users to get a weld-user list! >>>> My major pain is to wrap my head around how to implement junit tests >>>> for cdi beans. >>>> Having a place where users could get together to sort out essential >>>> issues for projects trying to use Weld, would be great. If anyone has a >>>> sample of a unit test that does not depend on anything else than weld 1.0.0 >>>> would be really great: >>>> >>>> - How to have the test target object injected into the test case ? >>>> ... or... >>>> - How to obtain an injected test target object from within the test >>>> case? >>>> >>>> /Johan >>>> _______________________________________________ >>>> weld-dev mailing list >>>> weld-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>>> >>> >>> >>> >>> >> >> >> -- >> -- >> Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 >> Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; >> http://www.conduct.no; mailto:aslak@conduct.no >> >> Conduct AS - Professional Open Source Services >> - Red Hat/JBoss Premier System Integrator >> - Pentaho Preferred Integration Partner >> - Atlassian Technology Partner >> >> >> > > > -- > -- > Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 > Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; > http://www.conduct.no; mailto:aslak@conduct.no > > Conduct AS - Professional Open Source Services > - Red Hat/JBoss Premier System Integrator > - Pentaho Preferred Integration Partner > - Atlassian Technology Partner > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

On Sat, Dec 26, 2009 at 4:16 PM, Aslak Knutsen <aslak(a)conduct.no&gt; wrote: > I've started some simple tests on a glassfish 3 embedded container, but > stopped due to some thing that seemed to be glassfish issues. I will try to > get some none jboss containers up pretty soon to 'prove the point'.. :) Yep, that's exactly what we are looking for. Just one alternative container (likely GlassFish V3 or GlassFish V3 embedded) and then we can let the community take it from there. > > Dan, please add it.. i have some demo description here: > http://community.jboss.org/wiki/Arquillian-Demo > Yep, that is exactly where I was planning to add the notes, once I find a browser that can actually edit the JBoss wiki ;) Thanks! -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

It had a link already under Project Information, but obviously not visible enough.. :)

Thanks for the write up! :o)

Checkout the Weld Java SE project.. JUnit 'example': http://anonsvn.jboss.org/repos/weld/java-se/trunk/src/test/java/org/jboss... src: http://anonsvn.jboss.org/repos/weld/java-se/trunk -aslak- 2009/12/26 Johan Eltes <johan.eltes(a)callistaenterprise.se&gt; Is there any working sample of how to set up a unit test for a weld bean? I'm only looking for java-se weld support here, not ejb/jsf. /Johan _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev -- -- Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; http://www.conduct.no; mailto:aslak@conduct.no Conduct AS - Professional Open Source Services - Red Hat/JBoss Premier System Integrator - Pentaho Preferred Integration Partner - Atlassian Technology Partner

org.jboss.weld.test.core.TestCore is used by the org.jboss.weld.test.junit.CDIRunner to inject the dependencies of the test case. However, it only supports injection of qualified fields. As a side effect, dependencies declared as concrete classes can not be injected, since qualifiers only make sense to interface/abstract dependency declarations: package org.jboss.weld.test.core; ... public class TestCore { ... private void injectField(Field field, Object target) throws Exception { * if (!hasBindTypeAnnotation(field.getAnnotations())) { return; }* if (!field.isAccessible()) { field.setAccessible(true); } Object injectable = getInstanceByType(field.getType(), field .getAnnotations()); if (injectable != null) { field.set(target, injectable); } } Just wondering the value of this restriction? /Johan _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Do remember that Weld-Test will be 'replaced' by Arquillian, so don't put to much work into it.. :)

I'm happy to try out the Arquillian embedded container testing as soon as it is available.

On Sun, Dec 27, 2009 at 12:31 PM, Johan Eltes < johan.eltes(a)callistaenterprise.se&gt; wrote: > I'm happy to try out the Arquillian embedded container testing as soon as > it is available. > Ah, so that is probably the #1 showstopper on the migration. I believe Aslak said there was a classloading issue. Aslak, is that something you have to wait on the AS guys to get around. Perhaps we can get ALR on it? -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

+1 on the standalone CDI bootstap. I think that was the real productivity boost for the CDI TCK effort. The remote containers really aren't bad because it just stays running in the background and the only delay is the app deployment. Aslak, does Arquillian start the remote server if it isn't already started like JBoss Test Harness did? That might be a really nice feature to get back in. I guess we can start w/ a JIRA for it. I'm thinking an option to start and another option to keep running or shutdown after suite (I'm on the road today so I can't add a JIRA.) - Dan Allen Sent from my Android-powered phone: An open platform for carriers, consumers and developers. On Dec 27, 2009 12:54 PM, "Aslak Knutsen" <aslak(a)conduct.no&gt; wrote: It's not 100% a Embedded issue, but Andrew is looking into something that could help. But the biggest problem is Jboss ASs startup time. 45 sec overhead pr test suite run is a bit to much. The Reloaded project is trying to help here as far as I know.. First priority for Arquillian is a Weld SE/EE Mock container to speed it up, else for now i recommend using the remote containers. -aslak- 2009/12/27 Dan Allen <dan.j.allen(a)gmail.com&gt; > > On Sun, Dec 27, 2009 at 12:31 PM, Johan Eltes < johan.eltes(a)callistaenterprise.se&gt; wrote: >> >> ... -- -- Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 Kongens gate 14; Boks 805 Sentrum, 0104 O...

Awesome, that will be a good feature to get in. - Dan Allen Sent from my Android-powered phone: An open platform for carriers, consumers and developers. > On Dec 27, 2009 1:35 PM, "Aslak Knutsen" <aslak(a)conduct.no > <mailto:aslak@conduct.no>> wrote: > > Arquillian 'starts' it, but the container impl does not actually > start a not started jboss instance. > > https://jira.jboss.org/jira/browse/ARQ-48 > > -aslak- 2009/12/27 Dan Allen <dan.j.allen(a)gmail.com > <mailto:dan.j.allen@gmail.com>> > > +1 on the standalone CDI > bootstap. I think... > > -- > -- > > Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 > > Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; http://www.conduct.no; > mailto:aslak@conduct.no <mailto:aslak@conduct.no> Conduc... >

Hmm.... Sorry to come to the conversation late on this, but this e-mail is raising a potential red flag for me. I apologize if this has been already addressed and I missed it, but... Controlling the lifecycle of a non-embedded container from a build is something you want to be very careful about from a security perspective. Now, if you have a plugin that requires an explicit command as well as a link in a settings.xml, that seems perfectly reasonable. I am worried that a someone running "mvn test" for application foo.war could startup non-foo wars because they were deployed to a local container. Also, I am concerned that it may startup the wrong container and cause similar problems. I usually work on multiple applications at a time and have a container for foo.war and a separate container for bar.war. I may think it is starting up foo's container, but it may startup bar's container and cause trouble. For me, that can get really dangerous because my applications contact external resources on startup as well as access things like files and bdb databases that are not suitable for usage by multiple applications. They could corrupt the file with simultaneous writes or more likely write duplicate or erroneous data. I know I sound like a member of the "tin-foil-hat-club" here, but I deal with patient data, so my apps are required by law to be paranoid about security. On 12/27/2009 03:54 PM, Dan Allen wrote: Awesome, that will be a good feature to get in. - Dan Allen Sent from my Android-powered phone: An open platform for carriers, consumers and developers. On Dec 27, 2009 1:35 PM, "Aslak Knutsen" <aslak(a)conduct.no&gt; wrote: Arquillian 'starts' it, but the container impl does not actually start a not started jboss instance. https://jira.jboss.org/jira/browse/ARQ-48 -aslak- 2009/12/27 Dan Allen <dan.j.allen(a)gmail.com&gt; > > +1 on the standalone CDI bootstap. I think... -- -- Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; http://www.conduct.no; mailto:aslak@conduct.no Conduc...

Steven, Naturally, starting and stopping the container from a test is going to be a preference that some developers will want and others not. That's why I suggested that it would be a system property (or some other configuration mechanism) that you could use to enable this behavior. I can tell you that from experience working with the CDI TCK that this was a very nice feature to have. I'm sure the other guys that worked on the TCK could offer their opinion. The subject line of your e-mail made me thinking of another possibility. It would be possible to include a Maven plugin configuration that would start and stop the container around the test (or integration) phase of the Maven life cycle. The only downside there is that it wouldn't carry over to the IDE JUnit or TestNG plugin. So, in general, I think it's a good thing to offer. I also agree that it shouldn't be the only way, perhaps not even the default behavior. -Dan On Mon, Dec 28, 2009 at 11:13 AM, Steven Boscarine <steven.boscarine(a)childrens.harvard.edu <mailto:steven.boscarine@childrens.harvard.edu>> wrote: Hmm.... Sorry to come to the conversation late on this, but this e-mail is raising a potential red flag for me. I apologize if this has been already addressed and I missed it, but... Controlling the lifecycle of a non-embedded container from a build is something you want to be very careful about from a security perspective. Now, if you have a plugin that requires an explicit command as well as a link in a settings.xml, that seems perfectly reasonable. I am worried that a someone running "mvn test" for application foo.war could startup non-foo wars because they were deployed to a local container. Also, I am concerned that it may startup the wrong container and cause similar problems. I usually work on multiple applications at a time and have a container for foo.war and a separate container for bar.war. I may think it is starting up foo's container, but it may startup bar's container and cause trouble. For me, that can get really dangerous because my applications contact external resources on startup as well as access things like files and bdb databases that are not suitable for usage by multiple applications. They could corrupt the file with simultaneous writes or more likely write duplicate or erroneous data. I know I sound like a member of the "tin-foil-hat-club" here, but I deal with patient data, so my apps are required by law to be paranoid about security. On 12/27/2009 03:54 PM, Dan Allen wrote: > Awesome, that will be a good feature to get in. > > - Dan Allen > > Sent from my Android-powered phone: > An open platform for carriers, consumers > and developers. > >> On Dec 27, 2009 1:35 PM, "Aslak Knutsen" <aslak(a)conduct.no >> <mailto:aslak@conduct.no>> wrote: >> >> Arquillian 'starts' it, but the container impl does not actually >> start a not started jboss instance. >> >> https://jira.jboss.org/jira/browse/ARQ-48 >> >> -aslak- 2009/12/27 Dan Allen <dan.j.allen(a)gmail.com >> <mailto:dan.j.allen@gmail.com>> > > +1 on the standalone CDI >> bootstap. I think... >> >> -- >> -- >> >> Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 >> >> Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; >> http://www.conduct.no; mailto:aslak@conduct.no >> <mailto:aslak@conduct.no> Conduc... >> -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

On 28 Dec 2009, at 20:35, Steven Boscarine wrote: > I like your suggestion of making it a POM option. I'd advocate that it only be started via a specific non-default profile. > > For our projects, we usually define projects with non-Maven dependencies, like a partner web service or SMTP server, in a specific TestNG group which is excluded in the default profile. > > Sorry if this is repetitive, but... > The big and central concern that I want to express to people is that you can unintentionally trigger code that doesn't belong to your project using commands that are typically assumed to be innocuous, like "mvn install." > > This is a classic scenario where you're giving the developer a really, really, really sharp tool. Individuals obviously need to take responsibility for their projects and decide what's appropriate. > > For my team (at CHB...my day job), I'd obviously have to make sure that they don't put anything where mvn test can run any code that's not part of its project. I'd have no issues with a team member starting an embedded container because they would only be running their own code, defined in their project, but if someone started up an installed container from mvn test, I'd have no choice but to put a stop to it. This is an interesting point, and one I guess that isn't really an issue in places I've worked. I can see that it would make sense to ensure that this runs in the "correct" (often a clean) container. The exact way you would specify that you want to use a particular "installed" container is to enable the container in your POM, by adding a dependency to the connector, and then specifying the path to the container in the connectors properties. This seems pretty explicit to me - but is it enough?

For me, the upcoming weld standalone and embedded JBoss AS test implementations are much more compelling and I can't wait to try them out.

Well today is your lucky day! :) Just commited a Weld SE Arquillian Container 'preview'.. Preview because it's only tested with very basic CDI features. (and has a couple of know 'improvements' code wise) The container starts a SessionScope pr TestCase and a RequestScope pr TestMethod. https://jira.jboss.org/jira/browse/ARQ-54 http://anonsvn.jboss.org/repos/common/arquillian/trunk/container-weld-emb... I've added a new profile to demo and demo-testng: weld-se Under the weld-se profile only the CDI example works(@Inject Local Stateless Session Bean) mvn test -P weld-se -Dtest=com.acme.cdi.InjectionTestCase If anyone is interested in contributing a bit more complex CDI example/testsuite, it's very welcome! Enjoy and Good luck..... ;) -aslak- 2010/1/5 Dan Allen <dan.j.allen(a)gmail.com&gt; > > For me, the upcoming weld standalone and embedded JBoss AS test >> implementations are much more compelling and I can't wait to try them out. > > > Without a doubt, I agree that this is the ideal solution. > > -Dan > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://www.google.com/profiles/dan.j.allen > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- -- Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24 Kongens gate 14; Boks 805 Sentrum, 0104 Oslo; http://www.conduct.no; mailto:aslak@conduct.no Conduct AS - Professional Open Source Services - Red Hat/JBoss Premier System Integrator - Pentaho Preferred Integration Partner - Atlassian Technology Partner