Am 04.07.2011 10:59, schrieb Timothy Ward:
Yes,
This is a slightly unpleasant issue which affects all our proxy
instances going back to 0.1 and before. The problem we have is that we
can't unwrap the proxy on its way into the ObjectOutputStream (there's
nothing we can hook into).
Hmm, what about writeReplace() and readResolve()?
Wicket has a generic solution for this in the wicket-ioc component, see
http://svn.apache.org/viewvc/wicket/releases/wicket-1.5-RC5.1/wicket-ioc/src/main/java/org/apache/wicket/proxy/LazyInitProxyFactory.java?view=markup
Integration components like wicket-spring, wicket-cdi or wicket-osgi
which have to deal with different flavours of injections
just need to provide a serializable IProxyTargetLocator which knows how
to look up the real (possibly not serializable) target object.
I've just implemented this for wicket-osgi in
https://github.com/wicketstuff/core/blob/master/jdk-1.5-parent/wicket-osgi-parent/wicket-osgi/src/main/java/org/wicketstuff/osgi/inject/impl/OsgiServiceProxyTargetLocator.java
This means, the Blueprint proxy is wrapped in another Wicket proxy,
which wouldn't be necessary if the Blueprint proxy already used a
similar mechanism to make itself serializable.
The current solution is just a first shot, I'm planning to add support
for service properties to handle the case of multiple service candidates
for the same interface.
Would this approach also work for Blueprint proxies?
Regards,
Harald
