I've created a patch (and submitted it for code review -
http://gwt-code-reviews.appspot.com/579801/show). It seems to be working
correctly for me
On Tue, Jun 1, 2010 at 10:54 PM, Marko Vuksanovic markovuksano...@gmail.com
wrote:
I have modified the code to check the resource oracle (patch
I just narrowed down the problem to the following - even thought the
classpath context is changed before running CompilePerms (as shown below),
UiBinder's classpath loader isn't able to access the resources.
classpathURLs.add(new File(uuid + File.separator + src +
Sounds like UiBinder might be using its own classLoader instead of the
thread context classLoader in some cases to find resources?
On Tue, Jun 1, 2010 at 7:28 AM, Marko Vuksanovic
markovuksano...@gmail.comwrote:
I just narrowed down the problem to the following - even thought the
classpath
Yup. Is the fix to make it use the resource oracle?
On Tue, Jun 1, 2010 at 8:15 AM, Scott Blum sco...@google.com wrote:
Sounds like UiBinder might be using its own classLoader instead of the
thread context classLoader in some cases to find resources?
On Tue, Jun 1, 2010 at 7:28 AM, Marko
The problem could be fixed by changing the way that url is fetched within
the W3cDoc method of UiBinderGenerator
URL url =
Thread.currentThread().getContextClassLoader().getResource(templatePath);
This seems to be resolving the issue...
On Tue, Jun 1, 2010 at 5:56 PM, Ray Ryan rj...@google.com
On Tue, Jun 1, 2010 at 11:56 AM, Ray Ryan rj...@google.com wrote:
Yup. Is the fix to make it use the resource oracle?
To play it safe:
First check resource oracle.
Next check the context class loader, as in Marko's email.
Then check wherever it looks now (the system class loader?).
Lex
--
On Tue, Jun 1, 2010 at 9:25 AM, Lex Spoon sp...@google.com wrote:
On Tue, Jun 1, 2010 at 11:56 AM, Ray Ryan rj...@google.com wrote:
Yup. Is the fix to make it use the resource oracle?
To play it safe:
First check resource oracle.
Next check the context class loader, as in Marko's email.
On Tue, Jun 1, 2010 at 12:33 PM, Ray Ryan rj...@google.com wrote:
On Tue, Jun 1, 2010 at 9:25 AM, Lex Spoon sp...@google.com wrote:
On Tue, Jun 1, 2010 at 11:56 AM, Ray Ryan rj...@google.com wrote:
Yup. Is the fix to make it use the resource oracle?
To play it safe:
First check resource
By the way, this also applies when doing a Class.forName(). If the class
you're trying to get might be a user-supplied class (as opposed to something
in gwt-user), you need to use the 3-arg version and pass the context class
loader.
On Tue, Jun 1, 2010 at 1:00 PM, Scott Blum sco...@google.com
or the resource oracle, which is essentially an optimized way of checking
the context class loader).
Does this mean that if context class loader is checked, then it is not
necessary to check resource oracle? And vice versa.
On Tue, Jun 1, 2010 at 7:00 PM, Scott Blum sco...@google.com wrote:
The resource oracle will generally be faster in the limit. Essentially, it
just scans the context classloader and caches everything. It takes some
time to build, but afterwards access is really fast. It is created lazily
when a generator asks for it, and generally some other generator will, so
On Tue, Jun 1, 2010 at 1:01 PM, Scott Blum sco...@google.com wrote:
By the way, this also applies when doing a Class.forName(). If the class
you're trying to get might be a user-supplied class (as opposed to something
in gwt-user), you need to use the 3-arg version and pass the context class
But again, resource oracle is better.
On Tue, Jun 1, 2010 at 2:31 PM, Scott Blum sco...@google.com wrote:
On Tue, Jun 1, 2010 at 2:10 PM, John Tamplin j...@google.com wrote:
On Tue, Jun 1, 2010 at 1:01 PM, Scott Blum sco...@google.com wrote:
By the way, this also applies when doing a
Class Loaders are checked in parent to child direction - so if you try to
fetch a resource from a context class loader, system class loader is the
first that will be checked and only after resource is not found there, next
child will be checked... and so on... So if something is found in context
On Tue, Jun 1, 2010 at 2:31 PM, Scott Blum sco...@google.com wrote:
But again, resource oracle is better.
Even for Class.forName()? In this case, this is a class which has to get
loaded and executed while running the generator (in some cases, such as
plural rules, it is also compiled to JS).
So, I guess, the solution to the problem with UiBinderGenerator not loading
resources correctly would be to check only resourceOracle (as it will check
for classpath context, and checking classpath context results in all parent
class loaders being checked.)
On Tue, Jun 1, 2010 at 8:02 PM, Scott
On Tue, Jun 1, 2010 at 2:35 PM, Marko Vuksanovic
markovuksano...@gmail.comwrote:
Class Loaders are checked in parent to child direction - so if you try to
fetch a resource from a context class loader, system class loader is the
first that will be checked and only after resource is not found
I don't believe it's necessarily true for the system loader to be a parent
of the context loader. It's common, but not necessary. The only loader you
can't get away from is the boot class loader.
Ok, I wasn't totally precise. You're right about the boot and system class
loader. The point was
I have modified the code to check the resource oracle (patch is attached).
If the way i did it is correct - one more problem arose - The path is not
reconstructed correctly. I get the error is
Scanning for additional dependencies:
On May 31, 7:20 pm, Scott Blum sco...@google.com wrote:
On Mon, May 31, 2010 at 12:41 PM, Marko Vuksanovic
markovuksano...@gmail.com wrote:
I'm working on a distributed build system for gwt and I seem to have
run into 2 problems.
First problem is related to UiBinder. Once I
I just tried
classLoader.getResource(hr/example/orka/
client/panels/MainPanel.ui.xml)
and this worked ok. The resource was correctly fetched.
On Mon, May 31, 2010 at 7:42 PM, Marko Vuksanovic markovuksano...@gmail.com
wrote:
On May 31, 7:20 pm, Scott Blum sco...@google.com wrote:
On Mon,
21 matches
Mail list logo
