Hi, Brian.
> So that
> essentially means that a generator that acts reflectively over parts of the
> client source won't see changes in the client source?
Yes. To put it in more concrete words. The client code is loaded in
CompilingClassLoader. For example you cannot do
Foo.class.getClassLoader() in client code for obvious reasons. But if
you are debugging hosted mode and inspect the Foo class with the
debugger you can see that the class loader is of type
CompilingClassLoader.
On the other hand if you debug the generator code and inspect the same
Foo class (technically it really isn't the same class since Class is
also determined by the ClassLoader not just byte[] ;) ) you will see
it is loaded by some derivate of the System ClassLoader usually
sun.misc.Launcher..some inner class. What matters is that it is not
the same ClassLoader (:
> Could you try reporting this (with any patch you have) to the GWT mailing
> list? Would be great to get a proper fix there.
Sure. Gladly. I have a very long day behind me so will write to gwt
mailing list tomorrow.
Agreed. We have a perfectly valid use case here to use reflection. It
should just work.
As far as my solution goes it is more of a proof of concepts. I
thought about patching gwt itself but it was easier for me to just to
modify gin. I am a big fan of TDD and stuff like Mockito but the code
I wrote is just for seeing how things works and not some production
code. Will post it later on gwt mailing list.
On the other hand I have tons of free time on my hands. I just might
write a proper gwt fix for this (no promises) - I am thinking in the
lines of loading the generators in the CompilingClassLoader or
something similar...
Btw: Thank you guys for your work on GIN. For me it is a must have if
I am writing gwt code:) A pleasure to work with.
Cheers
Alen
>
> Thanks,
> -brian
>
> 2009/7/20 Alen Vrecko <
alen_vre...@yahoo.com>