Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Integration testing issue: object is not an instance of declaring class Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Integration testing issue: object is not an instance of declaring class

    Hello,

    I'm trying to run a basic integration test with Spring DM 1.1.1. I've red Spring DM docs and watched screencast but i'm still stuck.

    In the JUnit test, after injection of the referenced service by Spring DM, when querying the referenced service

    Code:
    m_fooService.echo("Hello World!")
    i get the following stacktrace

    Code:
    java.lang.IllegalArgumentException: object is not an instance of declaring class
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:585)
    	at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:64)
    	at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:78)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
    	at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
    	at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
    	at org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:36)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
    	at org.springframework.osgi.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:59)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
    	at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
    	at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
    	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
    	at $Proxy2.echo(Unknown Source)
    	at org.foo.service.FooServiceTest.testFooService(FooServiceTest.java:33)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:585)
    	at junit.framework.TestCase.runTest(TestCase.java:164)
    	at org.springframework.osgi.test.AbstractOsgiTests.osgiRunTest(AbstractOsgiTests.java:553)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:585)
    	at org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:193)
    	at org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:178)
    	at org.springframework.osgi.test.internal.support.OsgiJUnitTestAdapter.osgiRunTest(OsgiJUnitTestAdapter.java:76)
    	at org.springframework.osgi.test.internal.support.OsgiJUnitService$1.protect(OsgiJUnitService.java:101)
    	at junit.framework.TestResult.runProtected(TestResult.java:124)
    	at org.springframework.osgi.test.internal.support.OsgiJUnitService.runTest(OsgiJUnitService.java:98)
    	at org.springframework.osgi.test.internal.support.OsgiJUnitService.executeTest(OsgiJUnitService.java:71)
    	at org.springframework.osgi.test.internal.support.OsgiJUnitService.runTest(OsgiJUnitService.java:45)
    	at org.springframework.osgi.test.JUnitTestActivator.executeTest(JUnitTestActivator.java:73)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:585)
    	at org.springframework.osgi.test.AbstractOsgiTests.invokeOSGiTestExecution(AbstractOsgiTests.java:397)
    	at org.springframework.osgi.test.AbstractOsgiTests.runBare(AbstractOsgiTests.java:206)
    	at org.springframework.osgi.test.AbstractOsgiTests$1.protect(AbstractOsgiTests.java:184)
    	at junit.framework.TestResult.runProtected(TestResult.java:124)
    	at org.springframework.osgi.test.AbstractOsgiTests.run(AbstractOsgiTests.java:181)
    	at junit.framework.TestSuite.runTest(TestSuite.java:230)
    	at junit.framework.TestSuite.run(TestSuite.java:225)
    	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
    	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)


    Here is the JUnit test:


    Code:
    public class FooServiceTest extends AbstractConfigurableBundleCreatorTests
    {
    	private FooService m_fooService;
    	
    	public void testFooService() throws Exception {
    		assertEquals("Hello World!", m_fooService.echo("Hello World!"));
    	}
    
    	protected String[] getConfigLocations() {
    		return new String[] {"/org/foo/service/spring/foo-context-test.xml"};
    	}
    	
        protected String[] getTestBundlesNames() {
        	return new String[] {"org.foo,org.foo.service,1.0.0"};
        }
        
    	public void setFooService(FooService aFooService) {
    		m_fooService = aFooService;
    	}
    
    }
    the Spring DM file context

    Code:
    	<bean id="fooService" class="org.foo.service.internal.FooServiceImpl" />
    	<service ref="fooService" interface="org.foo.service.FooService" />
    the Spring DM Test file context

    Code:
    	<osgi:reference id="fooService" interface="org.foo.service.FooService" />



    I have attached the org.foo.service Eclipse project if you need more infos.


    I dont get why the "object is not an instance of declaring class", any idea ?


    Thanks

    Fred
    Last edited by frederic.conrotte; Sep 30th, 2008, 05:08 PM.

  • #2
    The error suggests that you are using two different class types. By the looks of it, the test archive might include a FooService internally different then the one used by the service.
    Take a look at the integration tests available in the samples to jumpstart your test...

    Comment


    • #3
      Indeed the simpleservice sample works, but the integration-test is another bundle, separated from the bundle under test.

      While I understand separation of concerns in this case, why isn't it generaly possible to run integration-tests from the bundle itself since it creates the TestBundle on the fly ?

      Comment


      • #4
        It's a cleaner and quicker way to run tests. In the majority of cases, a bundle will have multiple integration tests applied against it. Thus, it's easier to have the project code as a bundle which gets shared by the rest of the tests.
        In fact, the bundle/project is loaded from the repo while the integration tests is simply generated and then executed. With a project, you tend to have certain manifest entries and considerably more code then with the integration test which has a pretty much defined structure.
        At the end of the day, it was a design choice. We found it in practice to work nicely so we opted for it.

        Comment

        Working...
        X