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