2008/11/26 Gili Tzabari <[EMAIL PROTECTED]> > > Stuart McCulloch wrote: > > it's the eager proxying that I'm worried about - could get hairy > > > > for example: how do I tell Guice about the class that should be proxied > > without actually loading that class (as Guice works primarily on types) > > Alternatively you could register the Guice classloader eagerly and > ensure that any types you refer to beyond that point would go through it > (by setting it as the Thread context CL for example). Any class injected > by Guice would automatically use the right CL. The only problem would > come from any classes loaded before the registration of the Guice CL. > Though, I suspect you should be able to do this very early on in most > cases. >
so essentially with this technique we'd be limiting how you could use Guice? sorry, but personally it sounds that this introduces problems for 90% of users while (possibly) fixing an issue that affects 10% at most - as Java developers we use sub-classing all over the place, why not use it when proxying? the issues about serialization and default constructors are solvable without redefining the original class - and I suspect you'd also run into serialization issues even when using class redefinition, as any method interception could distribute the state to fields in objects unknown to the original class [FYI, setting the TCCL doesn't work for legacy code that uses Class.forName] > however, two classes of the same name defined by two different loaders > > are distinct and incompatible (!A.equals(A')) which is the problem I have > > with redefining the class at runtime - as Johan says, it has to go into a > > separate classloader, unless you use an instrumentation agent > > I believe instrumentation agent wouldn't work in the context of a > web > container since you don't want to affect classes outside your webapp. > exactly, so you have to use a separate classloader and deal with visibility issues > there are also visibility limitations - if I have non-public classes A and > B > > in the same package "foo" then they can only see each other if they're > > loaded by the same classloader (delegation doesn't help here) > > Agreed, but I assume that if you're going to inject one class in a > package you're likely going to use injection for the rest of them too > (or load them from classes that *have* been injected). > and what happens if I (as a user of Guice) don't want to inject every class from a package? Even in the general case, how do I pass Guice a module with bindings for a package without loading that package first? I guess you'd have to ensure Guice was at the top of the classloader chain, and have some way of marking classes you wanted redefined early on - but you'd be limiting how people could use Guice (ie. no use as a bundle, no way to upgrade without restarting the process) - all to fix some issues which can be fixed using normal sub-classing (as I think javassist shows) Gili > -- 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 -~----------~----~----~----~------~----~------~--~---
