I fear this is not easy to do. Either we use commons-proxy (which is exactly such an abstraction SPI layer) or we just do it ourselfs. The real work is no movin the proxy generation to ASM but to migrate our MethodHandlers to InvocationHandlers. It's not a huge effort, but it is certainly quite some homework.
An SPI only makes sense if it abstracts away something. In that case it is already there. I already looked at Davids code he uses for OpenEJB. It uses he java.lang.reflect.Proxy interfaces but contrary to the jdk proxy stuff he additionally creates subclasses as class-proxies. Thus I see no need for another SPI as we already use the standard Java interfaces for it. LieGrue, strub ----- Original Message ----- > From: Gurkan Erdogdu <gurkanerdo...@yahoo.com> > To: "dev@openwebbeans.apache.org" <dev@openwebbeans.apache.org> > Cc: > Sent: Thursday, August 9, 2012 8:51 PM > Subject: Yan: javassist removal > > Hello David > > I favor that we can implement a common SPI like other integrations and > refactor > code to use SPI (Pluggable way of using javassist or ASM). > > > Thanks. > > > Gurkan > > > > ________________________________ > Kimden: David Blevins <david.blev...@gmail.com> > Kime: dev@openwebbeans.apache.org > Gönderildiği Tarih: 9 Ağustos 2012 7:27 Perşembe > Konu: javassist removal > > Hey All, > > Heads up that I'd like to investigate removing javassist and replacing it > with some simple ASM code to create subclass based proxies. The proxy code > is > the small part, the bigger part is refactoring out the MethodHandler classes > and > replacing them with java.lang.reflect.InvocationHandler implementations. > > As usual I'll probably look for an intermediary step in refactoring it out, > maybe some way to keep the MethodHandlers and get all the code working with a > different proxy impl, then refactor the handlers. > > Any thoughts or comments welcome. > > > -David >
