camel:proxy (CamelProxyFactoryBean) and CamelBeanMethodName

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

camel:proxy (CamelProxyFactoryBean) and CamelBeanMethodName

steve.ardis
When using Camel's Spring Remoting capability, it seems that the "CamelBeanMethodName" should/could be automatically set, including with support for overloaded methods by adding the parameter types.

I have an interface with several methods on it and am using the "direct-VM" transport.  The interface contains the following methods:

    - findById(int id)
    - findByName(String name)
    - create(Person person)

When I call "findById(1)" through the camel:proxy and consume it with the camel:export, it invokes "findByName(String)".  The same behavior happens when using the @Produce(uri="direct-vm:...") annotation on the caller.  Additionally, when I call "create(...)", I receive an AmbiguousMethodCallException.

I am assuming this fails because the "CamelBeanMethodName" is not automatically set - is this correct?  Is there already a way to have this property automatically set that I am missing.  I've ready through the documentation and the code, but I didn't see anything.

If this isn't currently possible, I'd be happy to try and work on a patch if my request seems reasonable.  It seems that the ProxyHelper or the CamelInvocationHandler is the right place for this logic, but my guess is that the CamelInvocationHandler is used in quite a few places.  Maybe creating a subclass of CamelInvocationHandler that will attempt to set the "CamelBeanMethodName" and use that instance in ProxyHelper??  If that would work, would I need to by concerned about the property already having been set manually?


Thanks -
Steve Ardis
Reply | Threaded
Open this post in threaded view
|

Re: camel:proxy (CamelProxyFactoryBean) and CamelBeanMethodName

steve.ardis
A little more discovery here...

With my unit tests, it appears to be invoking the correct method(s).  However, when deployed into tc Server across separate web applications (WARs), it is still invoking the wrong method.  

Just as an FYI, I am using the "direct-vm" transport because it is across different web applications - which I believe leaves me with either the "vm" or "direct-vm" transport.  However, I am specifically using the "direct-vm" transport because I need the invocation to be within the same transaction (JTA) - I don't think the "vm" transport supports this.

Any help is greatly appreciated.


Steve Ardis
Reply | Threaded
Open this post in threaded view
|

Re: camel:proxy (CamelProxyFactoryBean) and CamelBeanMethodName

steve.ardis
This post was updated on .
I decided to try the "vm" transport, and as expected I received a "HibernateException: Unable to locate current JTA transaction", but in the stacktrace I can see that it invoked the wrong method as well (same method as "direct-vm" transport).  I also started a new transaction, and as expected, it was in the wrong method.


Steve Ardis

Reply | Threaded
Open this post in threaded view
|

Re: camel:proxy (CamelProxyFactoryBean) and CamelBeanMethodName

steve.ardis
And, in case the question pops up, my test case has the "proxy" and the "export[er]" in different camel contexts (which is about as equivalent as I can make it to how it is running inside tc Server).

Steve Ardis
Reply | Threaded
Open this post in threaded view
|

Re: camel:proxy (CamelProxyFactoryBean) and CamelBeanMethodName

steve.ardis
I am using  Camel 2.12.1 for all components.

The test case (which works) is getting to line 128 of BeanProcessor, but I don't understand the "if (sameBean)" logic/comments there.  I would assume it also returning from line 133.

My real-world WAR file deployment (which fails / calls wrong method) is returning from BeanProcessor at line 166, which tells me it most likely didn't get into the "if (sameBean)" logic.  My gut tells me that, because I didn't explicitly set the "CamelBeanMethodName", it defaulted to the bean binding logic and (for some reason) picked the wrong method (and in one case gave me an AmbiguousMethodCallException.


Steve Ardis
Reply | Threaded
Open this post in threaded view
|

Re: camel:proxy (CamelProxyFactoryBean) and CamelBeanMethodName

steve.ardis
Continue to discover and try new things.  I've also determined that my unit test works when the "proxy" and "export" beans are in different Spring applicationContext(s).

So, still not sure why my real-world test fails (when the "proxy" and "export" beans are in different web applications).