2008/11/26 Gili Tzabari <[EMAIL PROTECTED]>

>        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...


yep, I think proxying deserves more attention - especially wrt. annotation
support
(unfortunately at the moment it's easier to workaround it than deal with it
upfront)

I don't recall hearing of a single project that tried to improve the
> situation.


well I haven't looked that closely, but javassist tried (not sure how
successfully)

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.
>

definitely - making this pluggable/optional should make everyone happy


> 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
> >
> > >
>
> >
>


-- 
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to