1) A generator uses the SystemCL. Not recommended because it won't see
changes in client code unless hot-replace is working.
2) A generator uses TypeOracle. Recommended; changes are picked up on
refresh.
3) A generator uses the TypeOracleClassLoader. Useful for interacting with
On Fri, Jul 24, 2009 at 6:01 AM, Alen Vrecko alen_vre...@yahoo.com wrote:
1) A generator uses the SystemCL. Not recommended because it won't see
changes in client code unless hot-replace is working.
2) A generator uses TypeOracle. Recommended; changes are picked up on
refresh.
3)
in GIN's case we could then do
ctx.getTypeOracleClassLoader().useSystemFor().startingWith
(com.google.gwt.inject.).create(); and not worry about any
surprises.
That seems, complicated and unnecessary. If you really, really need the
SystemCL version of a class, you'd just access it
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
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
Cool. I can think of a few more GeneratorsClassLoader or
GeneratorsClientModelClassLoader or NonGeneratorClientCodeClassLoader.
Naming classes truly is an art in its own.
I have tons of free time till Tuesday so if you don't mind will take a
stab at it.
What I have in mind is: Make the special
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:
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
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
On Thu, Jul 23, 2009 at 6:37 PM, Alen Vrecko alen_vre...@yahoo.com wrote:
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
Hi Scott,
Gin uses reflection because it reuses the heavy lifting from Guice, which is
not GWT-aware.
Seems like both issues could be resolved if generators were loaded in the
client code ClassLoader. Is there a technical or philosophical problem with
doing so? I can understand it might not be at
@Scott: Hasn't there been a subtle shift in this regard? With GWT 1.5,
didn't we conclude that loading classes at least for annotations would make
the most sense?
I think now that we have enhanced the CCL, for deRPC, to delegate to grey
area classes that aren't strictly in the client space, maybe
But there is no CCL when running the compiler. We never go through the
trouble of constructing a client class loader environment for generators
to access, they just run in the system class loader. Supposing we did build
a client classloader and run the generators there, how would generators then
Hey guys.
Imho having Generators in the CCL club is icing on the cake...very
cool but not really essential.
I can confirm using JavaRebel solves both problems (generator code
change, and gin module changes, @Inject added etc). For the time being
I think this is a reasonable compromise for
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
15 matches
Mail list logo
