cdi-unit / cdi-unit Goto Github PK
View Code? Open in Web Editor NEWUnit testing for CDI applications
Home Page: http://cdi-unit.github.io/cdi-unit/
License: Apache License 2.0
Unit testing for CDI applications
Home Page: http://cdi-unit.github.io/cdi-unit/
License: Apache License 2.0
I think this is to do with https://issues.jboss.org/browse/CDI-132.
I can get around this by using Seam Solder AnnotationTypeBuuilder which processes the type from scratch....
I have simple suite of unit tests that pass with cdi-unit 2.2.1 on Java 6, and pass with cdi-unit 3.0.0 on Java 7, but fail with cdi-unit 3.0.0 on Java 6.
The call in question is the URLClassLoader.close() method. Here is the specific stack trace I get. Below that I listed relevant Ivy dependencies I was using at the time.
Thanks!
java.lang.NoSuchMethodError: java/net/URLClassLoader.close()V
at org.jglue.cdiunit.internal.WeldTestUrlDeployment.populateCdiClasspathSet(WeldTestUrlDeployment.java:355)
at org.jglue.cdiunit.internal.WeldTestUrlDeployment.(WeldTestUrlDeployment.java:90)
at org.jglue.cdiunit.CdiRunner$1.createDeployment(CdiRunner.java:83)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:137)
at org.jglue.cdiunit.CdiRunner.createTest(CdiRunner.java:94)
at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:244)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:241)
at org.jglue.cdiunit.CdiRunner.methodBlock(CdiRunner.java:122)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
<!-- JUnit CDI TESTING -->
<dependency org="junit" name="junit" rev="4.11" />
<dependency org="com.h2database" name="h2" rev="1.3.175" />
<dependency org="org.jglue.cdi-unit" name="cdi-unit" rev="3.0.0">
<exclude org="org.testng" />
<exclude org="org.easymock" />
</dependency>
<dependency org="javax.enterprise" name="cdi-api" rev="1.2" />
<dependency org="org.jboss.spec.javax.annotation" name="jboss-annotations-api_1.2_spec" rev="1.0.0.Final" />
<dependency org="org.jboss.spec.javax.interceptor" name="jboss-interceptors-api_1.2_spec" rev="1.0.0.Final" />
<dependency org="org.jboss.weld" name="weld-api" rev="2.2.Final" />
<dependency org="org.jboss.weld" name="weld-spi" rev="2.2.Final" />
Hi,
is it possible to drop the dependency to weld and use the detalspike cdictrl api? When you are using openwebbeans (for example from openejb), the weld dependency does cause some problems.
We wanted to use cdi-unit with jersey 1.18.
unfortunately when booting up - jersey is calling:
initalContext.getNameParser("").parse("sth")
and cdi-unit implementation of InitialContext returns null in getNameParser(String):
I have tried to use CDI-Unit for testing my Wicket enabled application. It seems work during Eclipse development, but fails during the Maven test phase. I suspect Wicket needs to inject classes. How to broaden search for CDI enabled classes?
More info here: http://stackoverflow.com/questions/16770518/unit-test-with-wickettester-and-cdi-unit-works-in-eclipse-but-fails-during-maven
I'm using Weld-SE 2.1.0.Final together with CDI-Unit 2.2.0:
compile 'org.jboss.weld.se:weld-se:2.1.0.Final'
compile ('org.jglue.cdi-unit:cdi-unit:2.2.0') {
exclude group: 'org.jboss.weld.se'
}
When running a test I get a WELD-000049 exception, probably due to a method signature incompatibility:
Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.jglue.cdiunit.ContextController.setup() on org.jglue.cdiunit.ContextController@65277345
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:91)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:72)
at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:95)
at org.jboss.weld.injection.producer.BeanInjectionTarget.postConstruct(BeanInjectionTarget.java:63)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:162)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:94)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78)
at org.jglue.cdiunit.ContextController$Proxy$_$$_WeldClientProxy.closeRequest(Unknown Source)
at org.jglue.cdiunit.internal.InRequestInterceptor.around(InRequestInterceptor.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30)
at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90)
at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53)
at com.wibu.backoffice.ws.test.WSCmActTest$Proxy$_$$_WeldSubclass.getPrepareDBRule(Unknown Source)
at com.wibu.backoffice.ws.test.WSCmActTest$Proxy$_$$_WeldClientProxy.getPrepareDBRule(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.runners.model.TestClass.getAnnotatedMethodValues(TestClass.java:173)
... 20 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:89)
... 49 more
Caused by: java.lang.NoSuchMethodError: org.jboss.weld.servlet.HttpContextLifecycle.<init>(Lorg/jboss/weld/manager/BeanManagerImpl;Lorg/jboss/weld/servlet/spi/HttpContextActivationFilter;)V
at org.jglue.cdiunit.ContextController.setup(ContextController.java:80)
... 54 more
@AdditionalPackage(A.class) //Pulls in every class that is in the same package as A that is in the same archive as A
@AdditionalClasspath(A.class) //Pulls in every class that is in the same archive as A
Without calling invalidate the context's beans are not destroyed and thus doesn't allow testing of @Disposes. Also, as in my application, not destroying the beans can cause the unit tests to fail because @Produces/@Disposes are used to doll out JDBC connections which are required to be commited/closed in order for further unit tests to proceed properly.
It appears cdi-unit will inject classes from non cdi enabled jars. This causes conflicts when working with third party jars and writing producer methods. Is it possible to exclude classes from non cdi enabled jars or at least have a mechanism to exclude specific classes?
This is because Request Session and Servlet all need to know about each other.
It is not feasible to allow user to pass in their own versions.
It is the main reason why the tree is broken at the moment.
Can you add a feature to activate stereotypes in addition to alternative classes? Using @ActivatedAlternatives produces a error message about bean class not alternative since the alternative annotation exists in the stereotype and not in the class directly, or produces an error message about bean not a class when used on the stereotype annotation directly.
Hello
For a simple try-out project I had CDI-Unit working fine. Then I changed the order of my dependencies in pom.xml, precisely, i moved "javaee-web-api" to be the first depedency and suddenly "mvn test" crashed with the following stack trace:
$ cat /home/chammers/workspace/lathspellsphp-code/java_test_ee6_jsf_cdiunit/target/surefire-reports/*txt
-------------------------------------------------------------------------------
Test set: de.lathspell.java_test_ee6_jsf_cdiunit.MyExampleBeanTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.127 sec <<< FAILURE!
testGetName(de.lathspell.java_test_ee6_jsf_cdiunit.MyExampleBeanTest) Time elapsed: 0.012 sec <<< ERROR!
java.lang.NullPointerException
at org.jglue.cdiunit.CdiRunner$2.evaluate(CdiRunner.java:120)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
The problems are probably not directly your fault but I had almost given up on cdi-unit as it apparently didn't work so it might be worth to add some kind of warnings/explanations to the tutorial?
The example project is available at http://sourceforge.net/p/lathspellsphp/code/234/tree/java_test_ee6_jsf_cdiunit/
bye,
-christian-
Currently if a test throws an exception then the weld container will not be shut down. Needs to be in a finally block.
I'm doing CDI integration testing without persistence and everything worked fine with 2.1.1 when running tests from Eclipse. I had to upgrade to 2.2.0 since test classes that have classes from external jars injected fail when running the tests with Maven. With Maven these external jar dependency injections cannot be resolved.
I checked release notes for CDI-Unit release 2.2.0 and saw "Fixed Maven build to run unit tests for cdi-unit module.". After upgrading to version 2.2.0 both Eclipse and Maven cannot successfully run any of my CDI-Unit tests. I get following exception:
org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
javax.enterprise.event.ObserverException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:37)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:75)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:101)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:170)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:129)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:103)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:515)
at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.deployBeans(ForwardingBootstrap.java:63)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:143)
at org.jglue.cdiunit.CdiRunner.createTest(CdiRunner.java:82)
at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:227)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:224)
at org.jglue.cdiunit.CdiRunner.methodBlock(CdiRunner.java:113)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.lang.NoSuchMethodError: org.jboss.weld.context.AbstractUnboundContext.<init>(Ljava/lang/String;Z)V
at org.jboss.weld.environment.se.contexts.ThreadContext.<init>(ThreadContext.java:40)
at org.jboss.weld.environment.se.WeldSEBeanRegistrant.registerWeldSEContexts(WeldSEBeanRegistrant.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
... 32 more
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:37)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:515)
at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.deployBeans(ForwardingBootstrap.java:63)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:143)
at org.jglue.cdiunit.CdiRunner.createTest(CdiRunner.java:82)
at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:227)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:224)
at org.jglue.cdiunit.CdiRunner.methodBlock(CdiRunner.java:113)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Is it possible to use Wildfly embedded container together with JGlue?
My point is to execute unit tests with jglue and the same CDI container as in Wildfly.
So that unmanaged classes can access the BeanManager during a test
When using gradle as a build tool, no beans.xml will be placed in the test classes binary folder (there is a separate build/resources dir). WeldTestUrlDeployment.isCdiClass(Class<?>) therefore returns false and further processing for CDIUnit enabled test classes is omitted.
WeldTestUrlDeployment.populateCdiClasspathSet() should maybe be amended to also accept gradle test output directories as cdiClasspathEntries.
As a workaround I create empty META-INF/beans.xml files in the binary output folders.
Accesing http://jglue.org/cdi-unit/ returns 404.
I don't know if this is the right place to post but I couldn't find anywhere else.
I'm trying to use CDI-Unit for my project but I'm getting the following error:
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [interface javax.servlet.http.HttpServletRequest]; Bindings: [@javax.enterprise.inject.Default()]
I'm using glassfish-embedded as my Java EE implementation. If I add the HttpServletRequest glassfish implementation in @AdditionalClasses I get even more strange errors.
Any idea?
WeldTestUrlDeployment dont work with Extension InheretedExtension from an abstract Extension.
Code:
public abstract class AbstractExtension implements Extension {
}
public class InheretedExtension extends AbstractExtension {
}
@RunWith(CdiRunner.class)
@AdditionalClasses({InheretedExtension.class})
public class ExtensionInheritanceTest {
@Test
public void test() {
}
}
I get an occasional NPE in ContextController.closeRequest() as the currentRequest is null. This is probably due to an error when using the API, but still it would be great if it would be more fault tolerant. A simple if query should do the trick:
public void closeRequest() {
if (currentRequest != null) {
lifecycle.requestDestroyed(currentRequest);
currentSession = currentRequest.getSession(false);
}
currentRequest = null;
}
The latest patch from commit "f2a5562" causes:
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type WeldListener with qualifiers @default
at injection point [BackedAnnotatedField] @Inject private org.jglue.cdiunit.ContextController.listener
at org.jglue.cdiunit.ContextController.listener(ContextController.java:0)
if you use tests without cdi-unit
@instance is not being followed when calculating the deployment.
Classes with bidirectional dependency causes infinite loop in WeldTestUrlDeployment because the classes are never added to the classesProcessed.
Example that cause the problem:
public class ClassA {
@Inject
private ClassB classB;
}
public class ClassB {
@Inject
private ClassA classA;
}
Hi,
it would be really helpful, if cdi-unit was available from maven central. It's against our company policy to use additional repositories, which is a common policy in larger companies. And putting adding it to our company maven repo involves a lot of ceremony about agreeing with a lot of people that it's necessary. This simply prevents a lot of people from using cdi-unit :-(
Cool tool, btw!
Rü
I saw a previous issue with a method signature change. I verified that my Test runs successfully with Weld 2.1.0.Final. So there must have been a signature change in 2.1.1 or 2.1.2.
here.... java.lang.NoSuchMethodException: org.jboss.weld.servlet.HttpContextLifecycle.(javax.enterprise.inject.spi.BeanManager, org.jboss.weld.servlet.spi.helpers.AcceptingHttpContextActivationFilter)
.
.
.
org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.jglue.cdiunit.ContextController.setup() on org.jglue.cdiunit.ContextController@65faa5a9
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:91)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:72)
at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:95)
at org.jboss.weld.injection.producer.BeanInjectionTarget.postConstruct(BeanInjectionTarget.java:63)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:162)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78)
at org.jglue.cdiunit.ContextController$Proxy$_$$WeldClientProxy.openRequest(Unknown Source)
at web.controllers.ValidateControllerTest.validateTest(ValidateControllerTest.java:41)
at web.controllers.ValidateControllerTest$Proxy$$$_WeldClientProxy.validateTest(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.jglue.cdiunit.CdiRunner$2.evaluate(CdiRunner.java:130)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:89)
... 34 more
Caused by: java.lang.RuntimeException: java.lang.NoSuchMethodException: org.jboss.weld.servlet.HttpContextLifecycle.(javax.enterprise.inject.spi.BeanManager, org.jboss.weld.servlet.spi.helpers.AcceptingHttpContextActivationFilter)
at org.jglue.cdiunit.ContextController.setup(ContextController.java:87)
... 39 more
Caused by: java.lang.NoSuchMethodException: org.jboss.weld.servlet.HttpContextLifecycle.(javax.enterprise.inject.spi.BeanManager, org.jboss.weld.servlet.spi.helpers.AcceptingHttpContextActivationFilter)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.getConstructor(Unknown Source)
at org.jglue.cdiunit.ContextController.setup(ContextController.java:85)
... 39 more
Hi
We use CDI-Unit 2.2.0
The class is org.jglue.cdiunit.internal.WeldTestUrlDeployment, the exception is thrown in the constructor at the following place:
.....
Class<?> superClass = c.getSuperclass();
if (superClass != null && superClass != Object.class) {
classesToProcess.add(superClass);
}
for (Field field : c.getDeclaredFields()) {
if (field.isAnnotationPresent(Inject.class)
|| field.isAnnotationPresent(Produces.class)) {
Class<?> type = field.getType();
classesToProcess.add(type);
}
if (field.getType().equals(Provider.class)) {
ParameterizedType type = (ParameterizedType) field
.getGenericType();
=== Exception thrown ====> classesToProcess.add((Class) type
.getActualTypeArguments()[0]);
}
}
for (Method method : c.getDeclaredMethods()) {
if (method.isAnnotationPresent(Inject.class)
|| method.isAnnotationPresent(Produces.class)) {
for (Class param : method.getParameterTypes()) {
classesToProcess.add(param);
}
}
}
}
CDI-Unit won't work with weld 1.0.1. Currently it blows up, but it would be better if it gave a nice error message.
Cdi unit needs to be aware of generated-classes
I've implemented a runner for TestNG framework.
I would suggest to add oficial support with code below.
PS: Congrats for the awesome tool!
@SuppressWarnings("unchecked")
public class CdiUnitRunner {
private final Class<?> _clazz = this.getClass();
private Weld _weld;
private WeldContainer _container;
private InitialContext _initialContext;
/**
* Setup CDI environment for the class.<br>
* INTERNAL: Do not use.
*/
@BeforeClass(alwaysRun = true)
protected void setupCdi() {
try {
Weld.class.getDeclaredMethod("createDeployment", ResourceLoader.class, Bootstrap.class);
} catch (NoSuchMethodException e) {
throw new RuntimeException(
"Weld 1.0.1 is not supported, please use weld 1.1.0 or newer. If you are using maven add\n<dependency>\n <groupId>org.jboss.weld.se</groupId>\n <artifactId>weld-se-core</artifactId>\n <version>1.1.0.Final</version>\n</dependency>\n to your pom.");
}
_weld = new Weld() {
@Override
protected Deployment createDeployment(ResourceLoader resourceLoader, Bootstrap bootstrap) {
try {
return new WeldTestUrlDeployment(resourceLoader, bootstrap, _clazz);
} catch (IOException e) {
throw new RuntimeException(e);
}
}
};
}
/**
* Initialize the CDI container.<br>
* PUBLIC: Should be used only in DataProvider methods which require injection.
*/
@BeforeMethod(alwaysRun = true)
public void initializeCdi() {
_container = _weld.initialize();
BeanManager beanManager = _container.getBeanManager();
CreationalContext creationalContext = beanManager.createCreationalContext(null);
AnnotatedType annotatedType = beanManager.createAnnotatedType(_clazz);
InjectionTarget injectionTarget = beanManager.createInjectionTarget(annotatedType);
injectionTarget.inject(this, creationalContext);
System.setProperty("java.naming.factory.initial",
"org.jglue.cdiunit.internal.CdiUnitContextFactory");
try {
_initialContext = new InitialContext();
_initialContext.bind("java:comp/BeanManager", beanManager);
} catch (NamingException e) {
throw new RuntimeException(e);
}
}
/**
* Shutdown the CDI container.<br>
* PUBLIC: Should be used only in DataProvider methods which require injection.
*/
@AfterMethod(alwaysRun = true)
public void shutdownCdi() {
if (_weld != null) {
_weld.shutdown();
}
if (_initialContext != null) {
try {
_initialContext.close();
} catch (NamingException e) {
throw new RuntimeException(e);
}
}
}
}
Hi, only a small thing.
On your page (http://jglue.org/cdi-unit/)
The tags of the artifact are wrong, so copy/paste is not so comfortable.
&
Thanks
org.jglue cdi-unit 0.9.7 test
This is causing #21 due to caching of type data in wicket.
In CDI-UNIT 3.0.1, each single jar in the classpath is output using System.out.println(url);
, which may result in a rather lengthy output to console on each single test.
While this information may be useful for debugging purposes, it should be output through the logger which is present anyway (preferably wih level DEBUG).
As CDI-Unit has a specialised deployment it is not a valid when running weld standalone in tests
Description:
https://issues.jboss.org/browse/WELD-1431
Symptom:
java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=javax/el/ELResolver, offset=6
Resolution:
Problem has been resolved in weld-se-2.0.1.final.
Would it be possible to upgrade the JUnit dependency from 4.8.2 to 4.11?
I would like to use JUnit Rules, and they are available only since 4.10 (or greater).
Actually Extensions like hibernate-validator-cdi are not getting enabled in unit tests.
Hi, I found your cdi-unit until I googled "cdi junit java se" and want to try it.
I added the repository + artifact (0.9.7) into my pom.xml (using Maven 3.0.2)
Any idea?
Uwe / Germany
Here are output and test case:
Running ula.sandbox.model.HausFactoryTest
59 [main] INFO org.jboss.weld.Version - WELD-000900 1.0.1 (Final)
124 [main] ERROR org.jboss.weld.environment.se.discovery.Scanner - Error loading org/jglue/cdiunit/DummyHttpRequest.class
java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletRequest
at java.lang.ClassLoader.defineClass1(Native Method)
My test class is use simple POJO object:
package ula.sandbox.model;
import static org.junit.Assert.*;
import javax.inject.Inject;
import org.jglue.cdiunit.CdiRunner;
import org.junit.Test;
import org.junit.runner.RunWith;
@RunWith(CdiRunner.class)
public class HausFactoryTest {
// @Inject
// private HausFactory factory;
@Inject
private Haus haus;
@Test
public void test() {
System.out.println(haus);
}
}
Weld 2.0.1 changed AbstractWeldSEDeployment to implement CDI11Deployment and SessionHolder handle HttpSession therefor cdi-unit needs to be updated.
Hello,
when using CDI-Unit with mockito 1.9.5 and weld 1.1.10.final on the simle Starship+Engine sample i always get a StackOverflowError.
Seems like there is a endless recursion when injecting mock+bean:
java.lang.StackOverflowError
at java.nio.HeapByteBuffer.(HeapByteBuffer.java:52)
at java.nio.ByteBuffer.wrap(ByteBuffer.java:350)
at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:66)
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52)
at java.lang.reflect.Field.declaredAnnotations(Field.java:1014)
at java.lang.reflect.Field.getDeclaredAnnotations(Field.java:1007)
at java.lang.reflect.AccessibleObject.getAnnotations(AccessibleObject.java:175)
at org.mockito.internal.configuration.DefaultAnnotationEngine.process(DefaultAnnotationEngine.java:65)
at org.mockito.internal.configuration.InjectingAnnotationEngine.processIndependentAnnotations(InjectingAnnotationEngine.java:71)
at org.mockito.internal.configuration.InjectingAnnotationEngine.process(InjectingAnnotationEngine.java:55)
at org.mockito.MockitoAnnotations.initMocks(MockitoAnnotations.java:108)
at org.jglue.cdiunit.internal.MockExtension$1.produce(MockExtension.java:36)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:292)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:608)
at org.jboss.weld.bean.AbstractReceiverBean.getReceiver(AbstractReceiverBean.java:77)
at org.jboss.weld.bean.AbstractProducerBean$AbstractProducer.produce(AbstractProducerBean.java:317)
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:307)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:608)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:674)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:763)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:772)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157)
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153)
at org.jglue.cdiunit.internal.MockExtension$1.inject(MockExtension.java:49)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:608)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:674)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:763)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:772)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157)
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153)
at org.jglue.cdiunit.internal.MockExtension$1.inject(MockExtension.java:49)
at ...
Solution might be:
public class MockExtension implements Extension {
public <T> void process(@Observes ProcessInjectionTarget<T> event) {
final InjectionTarget<T> injectionTarget = event.getInjectionTarget();
if ( event.getInjectionTarget() instanceof InjectionTargetImpl)
return; // avoid endless recursions, StackOverflowError
event.setInjectionTarget(new InjectionTargetImpl<T>(injectionTarget));
}
private final class InjectionTargetImpl<T> implements
InjectionTarget<T> {
HTH,
Markus
There seem to be several issues with Weld 2.2 itself and Jandex for annotation scanning.
The minimal setup to reproduce (seriously: minimal) is the one below.
Let me know if you need any more insight into this issue!
@RunWith(CdiRunner.class)
@AdditionalClasses({ CdiTest.ABeanToBeInjected.class,
CdiTest.AProducer.class
})
public class CdiTest {
@Produces
@Mock
private CdiTest.ABeanToBeMocked aMockedBean;
@Inject
private CdiTest.ABeanToBeInjected aBeanToBeInjected;
@Before
public void setUp() throws Exception {
}
@Test
public void test() {
}
public static class AProducer {
private CdiTest.ABeanToBeMocked aMockedBean;
protected AProducer() {
// CDI
}
@Inject
public AProducer(CdiTest.ABeanToBeMocked aMockedBean) {
this.aMockedBean = aMockedBean;
}
@Produces
public ABean namedBean() {
return new ABean();
}
}
public static class ABeanToBeMocked {
}
public static class ABeanToBeInjected {
protected ABeanToBeInjected() {
// CDI
}
@Inject
public ABeanToBeInjected(CdiTest.ABean namedBean) {
}
}
public static class ABean {
}
}
a stack trace shows repeating execution of MockExtension$1.produce() and MockExtension$1.inject()
CDI does not allow managed beans to declare fields. Junit requires that TestRules be public fields.
I'm fairly certain a workaround would be to declare the Test class as @Dependent
, but cdi-unit makes all tests @ApplicationScoped and it's impossible to override that.
This test won't work:
@RunWith(CdiRunner.class)
@AdditionalClasses({ CdiSlf4jLoggerFactory.class })
public class LeadTierClassifierTest {
@Inject
private Logger log;
@Rule
public TestRule watchman = new TestWatcher() {
protected void starting(Description description) {
log.info("{}", description.getMethodName());
};
};
}
https://groups.google.com/forum/#!topic/cdi-unit/cPS9LEMw31U
When using ContextController:
@RequestScoped beans survive invocations of closeRequest() . Ditto for @SessionScoped beans and closeSession().
Hi,
I have another question. I'm beginning to use CDI with Java SE.
I have made a small test project (eclipse+maven+cdirunner).
I never read the CDI spec and I don't want to start a discussion
about Qualifier here.
I only tried to use the @nAmed annotation which I have seen
in other examples in the internet.
I have a:
A Main call:
@Inject
@nAmed("jnode")
//@nAmed("rnode")
private Node node;
If I use the @nAmed in Main, I can toggle which factory is used.
In the JUnit test, I used the injection:
@Inject
@nAmed("jnode")
private Node node;
And it doesn't work, because I think the @nAmed "tag" is not considered.
Or must I used the CdiRunner in another way?
If I can attach a zip file, I will upload it, or send it be email to my last contact with you.
Uwe / Germany
<dependency>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-core</artifactId>
<version>2.2.1.Final</version>
</dependency>
<dependency>
<groupId>org.jglue.cdi-unit</groupId>
<artifactId>cdi-unit</artifactId>
<version>3.0.1</version>
</dependency>
when running:
09:50:08.338 [weld-worker-3] WARN org.jboss.weld.Validator - WELD-001440: Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [BackedAnnotatedField] @Inject @ApplicationScoped private org.jglue.cdiunit.ContextController.listener
Exception in thread "main" org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type WeldListener with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject @ApplicationScoped private org.jglue.cdiunit.ContextController.listener
at org.jglue.cdiunit.ContextController.listener(ContextController.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:370)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:291)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:165)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:529)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
In V3?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.