2008/11/26 Gili <[EMAIL PROTECTED]> > > Hi Stuart, > > It is my understanding that all of the difficulties come from proxing > concrete classes, not interfaces (the latter can be proxied quite > easily using the core API).
that's why I always prefer to program to interfaces ;) > I think it's well worth using two > different implementations for interfaces and concrete classes so long > as the differences can be abstracted away from end-users and it really > overcomes all the limitations I and you listed (i.e. EJB containers). > for testing it is a really cool idea, but for server-side I would be cautious my main concern is how you'd handle the situation where someone else is using class (A) but Guice wants to "proxy" it by rewriting - the new definition (A') would need to be loaded into another classloader, but that means that class A and class A' are incompatible, and people who expect A wouldn't be able to use A' (unless they cast it to a common superclass, but if you were going to do this then you wouldn't mind whether the proxy had subclassed A to begin with!) I think this is an issue, but I'd be interested to hear what other people think Let's ask Johan, perhaps he's already investigated EJB space. > certainly, although having discussed this with him before I believe his focus is still on testing (at least for the near future) as it's much easier to rewrite classes in the "set-up/tear-down" model where you can throw away loaders between tests... Gili > > On Nov 25, 4:01 am, "Stuart McCulloch" <[EMAIL PROTECTED]> wrote: > > 2008/11/25 Gili <[EMAIL PROTECTED]> > > > > > > > > > Johan Haleby brought up an interesting approach to proxing classes > > > without the limitations introduced by ASM/CGLIB such as: > > > > > - requiring no-op constructors > > > - preventing the use of final or private methods > > > - losing annotations on the original class > > > > > I would love to get your opinion on it because frankly if we can get > > > rid of these limitations I would be *that* much happier :) Take a > > > look: > > >http://groups.google.com/group/mockito/browse_thread/thread/2a85cace2. > .. > > > > FWIW, I wouldn't call this a proxy per se - this is bytecode manipulation > > which requires access to the original bytes (it uses javassist to do > this) > > and only works on non-interface classes... but you can easily fall back > > to using standard proxies for interfaces - downside is you end up with > > two approaches to maintain > > > > however I would be wary of calling this a 'silver' bullet because there > are > > several limitations wrt. bytecode manipulation (security notwithstanding) > > - for example, I don't know if javassist works with custom classloaders > as > > used in EJB containers (and OSGi, etc.) where the original class bytes > > may not be available, or where the original class may already be in-use > > elsewhere in the JVM > > > > just warning we may be jumping from known issues into the unknown ;) > > > > Gili > > > > > > > > -- > > Cheers, Stuart > > > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
