Add classpath configs path support to eclipse prefs for running @RunWith(SpringJUnit4ClassRunner.class) #57

Open
santeriv opened this Issue Aug 31, 2011 · 7 comments

Comments

Projects
None yet
7 participants
  1. Problem test fails because spring application context - configs - cannot be loaded
  • IllegalStateException (Failed to load ApplicationContext) in ManagerTest.testLists (for all testclasses and testmethods)

ManagerTest extends a BaseTest which has following
@contextconfiguration(locations={"classpath:application-config.xml", "classpath:env/unit-test-infra.xml", "classpath:extension-test.xml"})
@runwith(SpringJUnit4ClassRunner.class)

  1. Problem ?
    I guess... Running SpringJUnit4ClassRunner is not the problem the problem is that I should be able to configure somehow the classpath containing all needed configs, if not so, then there is also another problem not being able to run BlockJUnit4ClassRunner like SpringJUnit4ClassRunner.

FOR LATER FOLLOW-UP: 5.1.93 was eclipse plugin version

dgageot was assigned Jan 5, 2012

I'm seeing a very similar problem. I end up getting red X's in the Problem view of STS.

I'm running: JDK 1.6, SpringToolSuite 2.9.2 with Infinitest 5.1.103.

Here's my error and my test class:

Description Resource Path Location Type
IllegalStateException (Failed to load ApplicationContext) in OfficeDaoImplTest.testAnything OfficeDaoImplTest.java /office/src/test/java/com/paraware/office/dao line 0 Infinitest Test Failure

import static org.hamcrest.Matchers.*;
import static org.junit.Assert.*;

import java.util.List;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ActiveProfiles;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.TestExecutionListeners;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.support.DependencyInjectionTestExecutionListener;
import org.springframework.test.context.support.DirtiesContextTestExecutionListener;
import org.springframework.test.context.transaction.TransactionalTestExecutionListener;

import com.github.springtestdbunit.DbUnitTestExecutionListener;
import com.github.springtestdbunit.annotation.DatabaseSetup;
import com.paraware.office.domain.Office;
import com.paraware.office.spring.DaoLayerConfiguration;
import com.paraware.office.spring.TestDataSourceConfiguration;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = { DaoLayerConfiguration.class,
        TestDataSourceConfiguration.class })
@TestExecutionListeners({ DependencyInjectionTestExecutionListener.class,
        DirtiesContextTestExecutionListener.class,
        TransactionalTestExecutionListener.class,
        DbUnitTestExecutionListener.class })
@ActiveProfiles("test")
public class OfficeDaoImplTest {

    @Autowired
    private OfficeDao officeDao;

    @Test
    @DatabaseSetup("OfficeDaoImplTest.xml")
    public void testAnything()
    {
        // do anything
    }
}

mjjensen commented Jul 9, 2012

I had a similar problem with a Spring Roo generated application, which I fixed by editing the following line in the (generated by Roo) AspectJ file called IntegrationTest_Roo_IntegrationTest.aj ...

declare @type: IntegrationTest: @contextconfiguration(locations = "classpath:/META-INF/spring/applicationContext*.xml");

I added an asterix after "classpath" and before the ":" ... I would suggest doing something similar to the "locations" parameter of your "@contextconfiguration()" annotation.

Note that I did this without understanding what the asterix actually does in this case (I assume it does some sort of wildcard matching, perhaps on the name of the CLASSPATH environment variable??), I just saw a similar context configuration in another post while trying to track down a solution for this and I got lucky. Maybe I'll look it up one day :-) Cheers!

Murray...

Collaborator

dgageot commented Dec 13, 2012

Can somebody provide a sample project?

takacsot commented Apr 5, 2013

Probably my problem is not the same but I got similar error.

I extracted the essence of the problem: https://github.com/takacsot/InfinitestFail
(Example is using Oracle, I think it should not be a problem)

In Infinitest console I got

    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
    ... 36 more
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSource' defined in class path resource [spring-datasource.xml]: Invocation of init method failed; nested exception is javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
    at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
    at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322)
    ... 54 more
Caused by: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial
    at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)

Definitely because if some kind of classpath issue. The hart of the exampl is the separate config for unit test and for production release (in prod it is using JNDI for datasource in test it is using manually created datasource).

Of course the process is green both from eclipse and command line maven.

Sample project is provided as requested.

Here's a scenario: A web project that has a persistence layer that is in a separate project. (web talks straight to persistence in this example)

The persistence project will work fine. However, at the point I add tests to the web project which depend upon loading the application context in the persistence layer, Infinitest fails.

At this point, I'd like to point out that both Maven and JUnit are both happy. I can execute either successfully.

For now, what I have done is to change my "classpath:" imports in the web project to "classpath*:" to ensure that classpath searches descend into JARs. This works. However, I'm not clear why Infinitest forces me into this when JUnit and Maven do not. Honestly, it's a little frustrating, and it bothers me that I have to make Spring search all classpaths in order to load the persistence layer's context file.

Why is Infinitest working differently than everything else? ... and do you know when it will behave standardly? :-)

I confirm I've got the same context classpath problem and that changing from classpath:my-file.xml to classpath*:my-file.xml did solve the problem. On the other hand I wish to raise a warning: the change might lead to other problems in case the same application context is defined in multiple projects.

This is a major problem which currently has a workaround, but should be addressed ASAP!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment