JmsInvokerProxyFactoryBean not working in SpringSource dm Server 1.0

[soks86]

Hi,

I'm quite new to OSGi and Spring DM but I've been working with it for a few weeks and this issue has really stumped me.

I'm using the JmsInvokerProxyFactoryBean to remote invoke a DAO service that's running on another server with Hibernate. Currently my client (calling dao) and server (dao) are both started as normal Java programs.

Now I'm working on getting the client to run in an OSGi environment and after working out all of my dependency issues I'm getting a really funky error. I did want to test this in Spring DM Server 2.0 but I can't get it to start my bundles/usr bundles for some reason...

Anyways I have a bean like this:

    <bean id="traderDataStore"  
          class="org.springframework.jms.remoting.JmsInvokerProxyFactoryBean">
        <property name="serviceInterface" value="com.icarus.pitboss.risk_manager.dao.TraderDataStore"/>
        <property name="connectionFactory" ref="connectionFactory"/>
        <property name="queue" ref="traderQueue"/>
    </bean>

and another like this:

	<bean id="limitsDialogFactory" 
		class="com.icarus.pitboss.risk_manager.display.limits.LimitsDialogFactory">
		<constructor-arg ref="limitDataStore" />
		<constructor-arg ref="addLimitDialogFactory" />
		<constructor-arg ref="limitTableModelFactory"/>
		<constructor-arg ref="traderDataStore"/>
	</bean>

A few different beans use the traderDataStore as well and all the other referenced beans are in the same file and shouldn't apply to this situation.

Now all of the above runs if I package up the program in a jar and run it with a normal Spring ApplicationContextLoader. However when I drop it into my OSGi server I get the following error:

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'addLimitDialogFactory' defined in URL [bundleentry://87/META-INF/spring/bundle-context.xml]: Unsatisfied dependency expressed through constructor argument with index 0 of type [com.icarus.pitboss.risk_manager.dao.TraderDataStore]: Could not convert constructor argument value of type [org.springframework.jms.remoting.JmsInvokerProxyFactoryBean] to required type [com.icarus.pitboss.risk_manager.dao.TraderDataStore]: Failed to convert value of type [org.springframework.jms.remoting.JmsInvokerProxyFactoryBean] to required type [com.icarus.pitboss.risk_manager.dao.TraderDataStore]; nested exception is java.lang.IllegalArgumentException: Cannot convert value of type [org.springframework.jms.remoting.JmsInvokerProxyFactoryBean] to required type [com.icarus.pitboss.risk_manager.dao.TraderDataStore]: no matching editors or conversion strategy found

Unfortunately I'm not that great with Spring so I don't quite get how to analyse this. From what I can tell, in this situation Spring would create a Proxy class that extends my TraderDataStore interface and fills in the calls with all of it's wonderful Springey goodness... but the mechanism for this transformation is beyond the scope of my Spring knowledge. Since I have no clue how this "works" I can't guess as to why it is breaking...

Ideas? Need more info?

Sorry, OSGi and Spring DM (Server) have been kicking my butt so I may have omitted some important information. Thanks in advance!

[soks86]

Alright... I have this down to something... I believe...

From looking at my logs I see that "afterPropertiesSet()" is not being called on my 'traderDataStore' bean.

Any idea why this wouldn't occur in a Spring DM environment? Does this sound likely?

I'm checking if this is why the class type is not correct but if anyone else knows I would appreciate not spending all night looking.

Thanks in advance!

[soks86]

Aha... the instanceof is failing on:

org.springframework.beans.factory.support.Abstract AutowireCapableBeanFactory line 1364

Even though JmsInvokerProxyFactory is definitely an InitializingBean.

I've read a few things about Spring DM using proxies that could interfere with type comparisons and implementing InfrastructureProxy is supposed to protect against bad type checks but I don't get how I'm supposed to do that... or better yet I'll just try.

[soks86]

Alright. I implemented InfrastructureProxy and now I'm getting something much more reasonable:

 Cannot resolve: com.icarus.pitboss.risk_manager
  Resolver report:
    Bundle: com.icarus.pitboss.risk_manager_0.0.1 - Uses Conflict: Import-Package: com.icarus.common.dao; version="0.0.0"
      Possible Supplier: com.icarus.common_0.1.1 - Export-Package: com.icarus.common.dao; version="0.1.1"
        Possible Conflicts: org.springframework.test.annotation,com.icarus.common.instruments,org.springframework.orm.hibernate3.support,org.hibernate
.

I'm guessing this will be a much easier issue to fix.

[Andy Wilkinson]

It's great to see your progress as you've attempted to diagnose the problem. Thanks for the updates.

The fact that the instanceof check fails suggests to me that there are two different versions of Spring involved, with two IntializingBean types. Your bean will implement one of these types, and AbstractAutowireCapableBeanFactory will be checking for the other, hence the instanceof check failing.

The fact that you get a uses constraint violation when you implement InfrastructureProxy also points towards their being two incompatible versions of something (most likely Spring) fighting with each other.

Can you please post a little more information about the version of dm Server you're using and what, if any, bundles you've added to the repository?

Thanks.

[soks86]

Andy,

Thanks for the help!

The instanceof was fixed by implementing InfrastructureProxy. However you were right about the two version, I ran a clean Spring DM server and double checked my POM's to match up all of my library versions and it started working, I know that's hardly a scientific method but I looked up uses after you pointed it out and decided to start clean since I had misunderstood some important concepts.

I did develop a new issue but I started a separate thread for it because it seemed a bit different than what was going on here (my mistakes). Now I'm not sure what's going on, but if you want to look at it here's the link

http://forum.springsource.org/newrep...ote=1&p=246078

oh, looks like someone responded...