int:gateway creates EventDrivenConsumer instead of proxy for my interface

[mirciob]

Hi,
I'm using SI 2.1. I need to create a standard gateway but every time I want to access/inject it the type is EventDrivenConsumer instead of proxy for my interface (as I know SI should use GatewayProxyFactoryBean).

    <int:channel id="requestChannel"/>
    
        					
    <oxm:jaxb2-marshaller id="marshaller" contextPath="my_package"/>
    
    <int:gateway id="gateway" 
				 service-interface="_my_interface_"
				 default-request-channel="requestChannel">
    </int:gateway>				     
    
    <ws:outbound-gateway id="wsGateway" 
    					 marshaller="marshaller"
    					 unmarshaller="marshaller"
    					 uri="#{wsUrl}" 
    					 request-channel="requestChannel" />

I've also tried adding a Gateway annotation for my interface but it doesn't work as well.
PS: I'm pretty sure that all necessary SI jars are in the classpath.

[mirciob]

I investigated the problem and above configuration works fine with http:outbound-gateway (instead of ws:outbound-gateway). Of course it doesn't solve my problem :| ... just indicates to problematic part

[mirciob]

Ok. I know what was the problem. Removed 'id' element of ws:outbound-gateway and it works now. Quite strange :| ... Does anybody know if I should create some bug for this ?

[Mark Fisher]

The config excerpt you posted has "wsGateway" as a value for the id of the ws:outbound-gateway. Is the actual value of that "gateway"? (thus overwriting the GatewayProxyFactoryBean's id) - If not, can you describe how you are accessing/injecting the bean?

Thanks,
Mark

[mirciob]

Hi,
definitely I used different ID but your suggestion is 100% right. As I double checked other XML files. The ID I used for WS outbound-gateway was defined before :| ... so that was the reason. But the main problem is that SI just creates that consumer object instead of throwing an error
Generally we can close this topic. Thanks a lot for your help

[Mark Fisher]

That's the underlying Spring behavior. Ultimately these are just "bean names" and by default in Spring bean names can be overridden (a useful feature when replacing beans for a particular environment, e.g. testing). If you really want an error instead, you can disable bean-overriding at the Spring configuration level.

Hope that makes sense.
-Mark

[mirciob]

Definitely it makes sense. But on the other hand some extra warning when override not compatible beans would be nice. Generally for overriding I used to use 'alias' but I understand that in many cases the behavior you described is a must-be

Thanks a lot.