I guess I agree with you for the most part. Thing is, for all this talk
about how "it's all fixable" no one actually done so... I don't recall
hearing of a single project that tried to improve the situation. I might
sound silly saying this... but it really ticks me off. I hate using APIs
that force no-op constructors and inappropriate method accessibility on
me. CGLIB acts more like a framework than a library in the sense that it
forces its bad design on you :( Anyway, end of rant. I'll be happy when
I can avoid CGLIB altogether in Guice.
Gili
Stuart McCulloch wrote:
> 2008/11/26 Gili Tzabari <[EMAIL PROTECTED]
> <mailto:[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 google-guice@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
