Hi,

I had previously had an issue with passing a JmsInvokerProxyFactoryBean which was hiding a daoService to a bean that was expecting a daoService. Later I found that if I created my own type, say JmsInvokerInfrastructureProxyFactoryBean, which extends InfrastructureProxy I was able to pass the JmsInvokerProxy around without any issues.

InfrastructureProxy comes with the following javadoc:

Code:
 * Interface to be implemented by transparent resource proxies that need to be
 * considered as equal to the underlying resource, for example for consistent
 * lookup key comparisons. Note that this interface does imply such special
 * semantics and does not constitute a general-purpose mixin!
 *
 * <p>Such wrappers will automatically be unwrapped for key comparisons in
 * {@link org.springframework.transaction.support.TransactionSynchronizationManager}.
 *
 * <p>Only fully transparent proxies, e.g. for redirection or service lookups,
 * are supposed to implement this interface. Proxies that decorate the target
 * object with new behavior, such as AOP proxies, do <i>not</i> qualify here!
My new class does not really conform to this since arguments which are modified during a method call are not returned to the remotely-invoking JVM and thus it is NOT a transparent proxy.

I was going to write a proper InfrastructureProxy version of the JMSInvoker but was wondering if people though this is at all appropriate? (like appropriate enough to submit as a patch)

By appropriate I mean relying on arguments to be changed by a method instead of passing back changes through the methods return type. In particular I was remotely invoking all of my Dao calls and since I am using Hibernate all of my dao's happen to have a void Save(Object obj) method and it doesn't really work remotely unless you do:

Code:
obj = new obj()
remoteDaoProxy.save(obj)
obj = remoteDaoProxy.load(obj)
Otherwise the id assigned by hibernate (on the other side of the proxy) will not be propagated to my object.

Another option is:

Code:
obj = new obj();
id = remoteDaoProxy.save(obj);
obj.setId(id)
but this is as much a hack (though at least 2x as efficient) as the above code. Especially since my code is NOT aware of these proxies, and I intend to keep it this way.

Any opinions? Should I just hack it, I could move my factories to the JMS Exporter side and then I wouldn't have this issue but I lose a layer of flexibility if I cannot have locally configured factories (perhaps that cache Dao-fetched objects), or I could create a JMSInvoker that passes the arguments back with the RemoteInvocationResults (but the API doesn't quite look set up for this change so it will be messy).

Advice?

I'm hacking it for now but a clean solution would be better.