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.
> 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.
> 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).
Gili
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
