> > 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 am thinking that the TypeOracleClassLoader would define the client classes minus the client classes of the generator. In the example the special CL would include FooModule and MyInjector but not @GinModules since it is part of the generator. Should by any chance @GinModules be loaded in the TOCL and returned by MyInjector the Generator would fail with ClassCastException since it is expecting @GinModules loaded from SystemCL. At least this is to my understanding of CL. Besides reloading parts of the generator code, this includes the generator client code, I think that we agree is better to leave it out. I guess it could be just 1 TypeOracleClassLoader but it should know which client classes to ignore and return the ignored classes from SystemCL. I was thinking if the generator doesn't touch the TypeOracleClassLoader there is no loss. But if it wants something from it then the TOCL should inspect the generator and remove any possible client classes of the generator. Should there be just 1 CL it should remove the client code from all known generators since we don't want any surprises later on? > > 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. The reason why I wanted to do this is that Gin could work with new classes without any changes to source. Yeah. Not the way to design code. Could have thought about it better. You're right there are better ways. > I'd prefer an accessor on GeneratorContext, so that such a CL could > be lazily created only by generators that actually need it. Ok. This sounds fine to me. In Compile only mode I think we should return just the CL that loaded the hosted mode. > 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. Agreed. Good point. > > > > > > > On Jul 23, 8:15 pm, Scott Blum <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
