Generators don't have client classes. Poor choice of words. What I had
in mind is that when Generators are loaded they might reference a
couple of client classes that are defined in some module. Now from
Generators perspective this is all loaded in SystemCL. I am afraid
that the TypeOracleClassLoader would not ignore these and the
generator would blow up with ClassCastException.
On Jul 24, 12:37 am, Alen Vrecko <alen_vre...@yahoo.com> wrote:
> > > 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 <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
-~----------~----~----~----~------~----~------~--~---
