Git Product home page Git Product logo

cdi-unit's Introduction

cdi-unit

Unit testing for CDI applications. Supports Mockito for mocking dependencies.

See website for full details http://cdi-unit.github.io/cdi-unit

Discussion can be found here https://groups.google.com/forum/#!forum/cdi-unit

Maven Central

<dependency>
  <groupId>org.jglue.cdi-unit</groupId>
  <artifactId>cdi-unit</artifactId>
  <version>${cdi-unit-version}</version>
  <scope>test</scope>
</dependency>
class Starship {
 
  @Inject
  Engine engine; //We don't know the exact engine that this ship will have.
 
  void start() {
    engine.start();
  }
}

@RunWith(CdiRunner.class)
@AdditionalClasses(WarpDrive.class) // WarpDrive is available to use.
class TestStarship {
 
  @Inject
  Starship starship;
 
  @Test
  public void testStart() {
    starship.start(); // Going to warp!
  }
}

Acknowledgements

This project uses code shamelessly copied from:

Mockrunner under Apache license. Resteasy under Apache license.

License

Copyright 2013 Bryn Cooke

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

cdi-unit's People

Contributors

alien0matic avatar aschoerk avatar brunoessmann avatar bryncooke avatar cschroeder0303 avatar dastrobu avatar dependabot[bot] avatar gmahieux avatar ikysil avatar itsmeden avatar kalgon avatar kdubb avatar lastnico avatar mamohr avatar nicolassfpd avatar pa314159 avatar pcasaes avatar seanf avatar serprime avatar sparty02 avatar sventorben avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cdi-unit's Issues

Add feature to activate stereotypes

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.

Invalidate is not called when closing contexts

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.

Error when running CDI-Uni t3.0.1 in Weld 2.2.1.Final

         <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)

CDIUnit does'nt discover Test class as CDI class when using gradle

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.

Get rid of System.out.println

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).

StackOverflowError

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

Upgrade to JUnit 4.11

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).

Class not found

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:


T E S T S

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);
}

}

Http support is broken

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.

javax.enterprise.event.ObserverException, after upgrading to CDI-Unit 2.2.0

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)

Commit cause unsatisfied dependency exception

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

getNameParser in InitialContext returns null

We wanted to use cdi-unit with jersey 1.18.

unfortunately when booting up - jersey is calling:

initalContext.getNameParser("").parse("sth")

here : http://grepcode.com/file/repo1.maven.org/maven2/com.sun.jersey/jersey-servlet/1.17.1/com/sun/jersey/server/impl/cdi/CDIExtension.java?av=f#264

and cdi-unit implementation of InitialContext returns null in getNameParser(String):

https://github.com/BrynCooke/cdi-unit/blob/master/cdi-unit/src/main/java/org/jglue/cdiunit/internal/CdiUnitContext.java#L97

Remove dependency on Java 7 that was introduced in 3.0.0

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" />

Exception during deployment when providing parameterized class

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);
}
}
}
}

TestNG support

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);
            }
        }
    }

}

Problem with Extension inhereted from abstract class

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() {

}

}

StackOverflowException while using @Mock

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()

Order of dependencies in pom.xml make CDI-Unit crash

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-

Compatibility with Wildfly ?

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.

CdiRunner and @Named annotation

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:

  • Interface Node
  • Class RealNode
  • A factory creating RealNodes named "rnode"
  • Class JunitNode for testing
  • A factory creating JunitNodes named "junit".

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

Method signature change Weld 2.1.2.Final and cdi-unit 2.2.1

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

Add additional discovery annotations

@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

NPE in class ContextController.closeRequest()

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;
    }

Cannot use JUNIT TestRule while using cdi-unit

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());
        };
    };

}

Error when running CDI-Unit 2.2.0 in combination with Weld-SE:2.1.0.Final

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

Infinite loop in constructor WeldTestUrlDeployment

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;

}

I'm trying to use CDI-Unit for my project but I keep getting errors

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?

Put it on Maven-Central

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!

Inject @EJB

I need the @ejb annotation to inject dependencies equal to @Inject annotation does.
For when I unit test an EJB which injects another EJB through @ejb annotation, this other EJB is null.

Thank you.

Tiago.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.