On Thu, Jul 23, 2009 at 3:14 PM, Alen Vrecko <alen_vre...@yahoo.com> wrote:
> I have tons of free time till Tuesday so if you don't mind will take a
> stab at it.
>
I would wait until John Tamplin lands his IHM changes first, that would have
a huge impact on the solution.
> What I have in mind is: Make the special CL per Generator. I'd set the
> CL to the Thread therefore Generators can access this functionality
> transparently by currentThread().getContextClassLoader() and modify
> TypeOracle to return classes in annotations from the special CL.
> Shouldn't be that difficult.
>
Why would you propose a separate CL per Generator?
I'm not sure automatically setting the thread context CL is the best idea,
that would be a definite behavioral change and not necessarily the best
design. I'd prefer an accessor on GeneratorContext, so that such a CL could
be lazily created only by generators that actually need it. If an
individual Generator wants to push/pop the TCCL as part of its normal
operation for the benefit of some library, that seems better to me.
>
> On Jul 23, 8:15 pm, Scott Blum <sco...@google.com> wrote:
> > If I follow you, I think that basically is what I was thinking. Except
> > let's not continue calling it CCL (CompilingClassLoader, which is
> actually
> > even a misnomer these days). It's a similar idea but this would be
> > separate. Perhaps we can call it "ClientModelClassLoader" or
> > "ClientReflectingClassLoader" or "TypeOracleAsClassLoader".
> >
> > On Thu, Jul 23, 2009 at 12:16 PM, Alen Vrecko <alen_vre...@yahoo.com>
> wrote:
> >
> > > Separate the machine from the materials. I think this is good idea.
> >
> > > Right now if you do a rename let say rename FooModule to BarModule
> >
> > > @GinModules(FooModule.class) -> @GinModules(BarModule.class)
> > > public class MyInjector{....}
> >
> > > and refresh the TypeOracleMediator will blow up with an NPE when
> > > trying to get the annotation (ClassNotFound).
> >
> > > Maybe it should return BarModule.class from the special class loader?
> >
> > > It shouldn't break the generator unless it is a moving part of a
> > > generator.
> >
> > > How about a special classloader that is aware of the generator and
> > > gives only classes from ccl that are not a moving part of the
> > > generator (not in source or super source or recursive source/ssource
> > > of dependencies of the generator, libraries aren't in ccl anyway)?
> >
> > > In the above case MyInjector and BarModule would be loaded from CCL
> > > while GinModules from System (since it is part of the generator).
> >
> > > This way libraries and generators can be left in the system cl.
> >
> > > On Jul 22, 7:30 pm, Scott Blum <sco...@google.com> wrote:
> > > > Brian, do you know if Guice allows you to specify a ClassLoader other
> > > than
> > > > the "active" one?
> > > > In principle, I would be okay with GeneratorContext providing a
> special
> > > > "other" ClassLoader to generators that contained only client code; it
> > > would
> > > > have exactly what TypeOracle does.and just be another way to get the
> > > exact
> > > > same information.
> >
> > > > I just think we need to separate the machine from the materials. :)
> >
> >
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
