Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 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: file:/D:/Devel/open-source/gwt-distributed-compiler/agent/0002/src/hr/tkd/orka/client/panels/MainPanel.java Computing all possible rebind results for 'hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder' Rebinding hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder Invoking generator com.google.gwt.uibinder.rebind.UiBinderGenerator [ERROR] Generator 'com.google.gwt.uibinder.rebind.UiBinderGenerator' threw an exception while rebinding 'hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder' java.lang.RuntimeException: java.io.FileNotFoundException: D:\Devel\open-source\gwt-distributed-compiler\agent\hr\tkd\orka\client\panels\MainPanel.ui.xml (The system cannot find the path specified) Obviously the resource is being looked for at the wrong place... It should be D:\Devel\open-source\gwt-distributed-compiler\agent\0002\src\hr\tkd\orka\client\panels\MainPanel.ui.xml the program is run from the location D:\Devel\open-source\gwt-distributed-compiler\agent\ and the files needed for compile perms are located in folder 0002\src, 0002\lib and 0002\work. The relevant part of the context class path is set to D:\Devel\open-source\gwt-distributed-compiler\agent\0002\src but when resource is fetched from the resource oracle the path is not constructed correctly. I reckon the resource should be added as 0002\src\hr\tkd\orka\client\panels\MainPanel.ui.xml... On Tue, Jun 1, 2010 at 10:05 PM, Marko Vuksanovic markovuksano...@gmail.com wrote: 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 that all the parent class loaders would be checked prior to checking the actual class loader. So checking the context class loader would result in checking all the class loaders above it (in the hierarchy) - and if the hierarchy wasn't explicitly changed this should be perfectly ok. On Tue, Jun 1, 2010 at 9:17 PM, Lex Spoon sp...@google.com wrote: On Tue, Jun 1, 2010 at 2:35 PM, Marko Vuksanovic markovuksano...@gmail.com wrote: 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 class loader, all parent class loaders have been checked. Somebody correct me if I'm wrong. 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. That said, if it's not on the context loader, you might want to ignore it if you can get away with it. For that matter, the same goes for things not in the resource oracle. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 +
File.separator).toURI().toURL());
File uncompressedLib = new File(uuid + File.separator + lib +
File.separator);
for (File f : uncompressedLib.listFiles()) {
classpathURLs.add(f.toURI().toURL());
}
...
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader =
URLClassLoader.newInstance(classpathURLs.toArray(new URL[] {}),
prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
//urlClassLoader.getResource(hr/tkd/orka/client/panels/MainPanel.ui.xml);
new CompilePerms(options).run(logger);
Thread.currentThread().setContextClassLoader(prevClassLoader);
This is where UiBinder has some problems
private Document getW3cDoc(MortalLogger logger, String templatePath)
throws UnableToCompleteException {
URL url =
UiBinderGenerator.class.getClassLoader().getResource(templatePath);
if (null == url) {
logger.die(Unable to find resource: + templatePath);
}
On Mon, May 31, 2010 at 8:46 PM, Marko Vuksanovic markovuksano...@gmail.com
wrote:
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, 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 transfer all the files to
the remote machine (that is src, required jars and result emitted by
precompile step) I changed the classpath context and executed compile
perms as follows:
new CompilePerms(options).run(logger);
where options is an instance of CompilePermsOptions.
the error I get is
Scanning for additional dependencies: file:/D:/Devel/open-source/
gwt-distributed-compiler/agent/0002/src/hr/example/orka/client/panels/
MainPanel.java
Computing all possible rebind results for
'hr.example.orka.client.panels.MainPanel.MainPanelUiBinder'
Rebinding
hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder
Invoking generator
com.google.gwt.uibinder.rebind.UiBinderGenerator
[ERROR] Unable to find resource: hr/example/orka/client/
panels/MainPanel.ui.xml
This is the primary error. Are you sure that file is showing up on the
remote machine? Before you invoke the compiler, you can try doing a
classLoader.getResource(hr/example/orka/client/panels/MainPanel.ui.xml)
and make sure it's found.
I'm sure that the file is located on the remote machine. I have
checked it manually and the other thing is that once I transfer files
to the remote machine and execute compile perms manually as described
here (http://code.google.com/p/google-web-toolkit/wiki/
DistributedBuilds - java -cp ... com.google.gwt.dev.CompilePerms
com.google.gwt.sample.hello.Hello -workDir work -perms 0 (I adjusted
this to my needs, off course)). So, I'm sure that the files are where
they should be... I'll try classLoader.getResource(hr/example/orka/
client/panels/MainPanel.ui.xml) in an hour or so - will post the
result here.
Second problem is that once I transfer files to the other machine,
where the CompilePerms is executed - once everything is finished the
jar files, which were added to the ClasspathContext using
URLClasspathLoader don't seem to be unloaded even when the context is
reverted to what it was before and all the references are set to null.
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader = URLClassLoader.newInstance(
classpathURLs.toArray(new URL[] {}), prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
new CompilePerms(options).run(logger);
//System.gc();
//System.gc();
Thread.currentThread().setContextClassLoader(prevClassLoader);
urlClassLoader = null;
classpathURLs = null;
Is it possible that some other classloader, within the gwt code, has
set some references to hose jars?
It's probably the refs in ResourceOracleImpl. We keep them around for
hosted mode refresh to be faster. Take a look at that, describe your
use
case, and we can talk about how those things can get cleaned up.
Well, the use case is basically that I want to have a machine that
will be used for compiling different projects. So, once precompile is
done and all the necessary data are transfered to the remote machine
for compilePerms - the remote machine does the compile perms step and
emits
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 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 +
File.separator).toURI().toURL());
File uncompressedLib = new File(uuid + File.separator + lib +
File.separator);
for (File f : uncompressedLib.listFiles()) {
classpathURLs.add(f.toURI().toURL());
}
...
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader =
URLClassLoader.newInstance(classpathURLs.toArray(new URL[] {}),
prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
//urlClassLoader.getResource(hr/tkd/orka/client/panels/MainPanel.ui.xml);
new CompilePerms(options).run(logger);
Thread.currentThread().setContextClassLoader(prevClassLoader);
This is where UiBinder has some problems
private Document getW3cDoc(MortalLogger logger, String templatePath)
throws UnableToCompleteException {
URL url =
UiBinderGenerator.class.getClassLoader().getResource(templatePath);
if (null == url) {
logger.die(Unable to find resource: + templatePath);
}
On Mon, May 31, 2010 at 8:46 PM, Marko Vuksanovic
markovuksano...@gmail.com wrote:
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, 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 transfer all the files
to
the remote machine (that is src, required jars and result emitted by
precompile step) I changed the classpath context and executed compile
perms as follows:
new CompilePerms(options).run(logger);
where options is an instance of CompilePermsOptions.
the error I get is
Scanning for additional dependencies: file:/D:/Devel/open-source/
gwt-distributed-compiler/agent/0002/src/hr/example/orka/client/panels/
MainPanel.java
Computing all possible rebind results for
'hr.example.orka.client.panels.MainPanel.MainPanelUiBinder'
Rebinding
hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder
Invoking generator
com.google.gwt.uibinder.rebind.UiBinderGenerator
[ERROR] Unable to find resource:
hr/example/orka/client/
panels/MainPanel.ui.xml
This is the primary error. Are you sure that file is showing up on the
remote machine? Before you invoke the compiler, you can try doing a
classLoader.getResource(hr/example/orka/client/panels/MainPanel.ui.xml)
and make sure it's found.
I'm sure that the file is located on the remote machine. I have
checked it manually and the other thing is that once I transfer files
to the remote machine and execute compile perms manually as described
here (http://code.google.com/p/google-web-toolkit/wiki/
DistributedBuilds - java -cp ... com.google.gwt.dev.CompilePerms
com.google.gwt.sample.hello.Hello -workDir work -perms 0 (I adjusted
this to my needs, off course)). So, I'm sure that the files are where
they should be... I'll try classLoader.getResource(hr/example/orka/
client/panels/MainPanel.ui.xml) in an hour or so - will post the
result here.
Second problem is that once I transfer files to the other machine,
where the CompilePerms is executed - once everything is finished the
jar files, which were added to the ClasspathContext using
URLClasspathLoader don't seem to be unloaded even when the context is
reverted to what it was before and all the references are set to
null.
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader = URLClassLoader.newInstance(
classpathURLs.toArray(new URL[] {}), prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
new CompilePerms(options).run(logger);
//System.gc();
//System.gc();
Thread.currentThread().setContextClassLoader(prevClassLoader);
urlClassLoader = null;
classpathURLs = null;
Is it possible that some other classloader, within the gwt code, has
set some references to hose jars?
It's probably the refs in ResourceOracleImpl. We keep them around for
hosted mode refresh to be faster. Take a look at that, describe your
use
case, and we can talk about how those things can get cleaned up.
Well, the use case is basically that I
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 Vuksanovic
markovuksano...@gmail.com wrote:
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 +
File.separator).toURI().toURL());
File uncompressedLib = new File(uuid + File.separator + lib +
File.separator);
for (File f : uncompressedLib.listFiles()) {
classpathURLs.add(f.toURI().toURL());
}
...
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader =
URLClassLoader.newInstance(classpathURLs.toArray(new URL[] {}),
prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
//urlClassLoader.getResource(hr/tkd/orka/client/panels/MainPanel.ui.xml);
new CompilePerms(options).run(logger);
Thread.currentThread().setContextClassLoader(prevClassLoader);
This is where UiBinder has some problems
private Document getW3cDoc(MortalLogger logger, String templatePath)
throws UnableToCompleteException {
URL url =
UiBinderGenerator.class.getClassLoader().getResource(templatePath);
if (null == url) {
logger.die(Unable to find resource: + templatePath);
}
On Mon, May 31, 2010 at 8:46 PM, Marko Vuksanovic
markovuksano...@gmail.com wrote:
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, 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 transfer all the files
to
the remote machine (that is src, required jars and result emitted by
precompile step) I changed the classpath context and executed
compile
perms as follows:
new CompilePerms(options).run(logger);
where options is an instance of CompilePermsOptions.
the error I get is
Scanning for additional dependencies: file:/D:/Devel/open-source/
gwt-distributed-compiler/agent/0002/src/hr/example/orka/client/panels/
MainPanel.java
Computing all possible rebind results for
'hr.example.orka.client.panels.MainPanel.MainPanelUiBinder'
Rebinding
hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder
Invoking generator
com.google.gwt.uibinder.rebind.UiBinderGenerator
[ERROR] Unable to find resource:
hr/example/orka/client/
panels/MainPanel.ui.xml
This is the primary error. Are you sure that file is showing up on
the
remote machine? Before you invoke the compiler, you can try doing a
classLoader.getResource(hr/example/orka/client/panels/MainPanel.ui.xml)
and make sure it's found.
I'm sure that the file is located on the remote machine. I have
checked it manually and the other thing is that once I transfer files
to the remote machine and execute compile perms manually as described
here (http://code.google.com/p/google-web-toolkit/wiki/
DistributedBuilds - java -cp ... com.google.gwt.dev.CompilePerms
com.google.gwt.sample.hello.Hello -workDir work -perms 0 (I adjusted
this to my needs, off course)). So, I'm sure that the files are where
they should be... I'll try classLoader.getResource(hr/example/orka/
client/panels/MainPanel.ui.xml) in an hour or so - will post the
result here.
Second problem is that once I transfer files to the other machine,
where the CompilePerms is executed - once everything is finished
the
jar files, which were added to the ClasspathContext using
URLClasspathLoader don't seem to be unloaded even when the context
is
reverted to what it was before and all the references are set to
null.
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader = URLClassLoader.newInstance(
classpathURLs.toArray(new URL[] {}),
prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
new CompilePerms(options).run(logger);
//System.gc();
//System.gc();
Thread.currentThread().setContextClassLoader(prevClassLoader);
urlClassLoader = null;
classpathURLs = null;
Is it possible that some other classloader, within the gwt code, has
set some references to hose jars?
It's probably the refs in ResourceOracleImpl. We keep them around for
hosted mode refresh to be faster. Take a look
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 wrote:
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 Vuksanovic
markovuksano...@gmail.com wrote:
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 +
File.separator).toURI().toURL());
File uncompressedLib = new File(uuid + File.separator + lib +
File.separator);
for (File f : uncompressedLib.listFiles()) {
classpathURLs.add(f.toURI().toURL());
}
...
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader =
URLClassLoader.newInstance(classpathURLs.toArray(new URL[] {}),
prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
//urlClassLoader.getResource(hr/tkd/orka/client/panels/MainPanel.ui.xml);
new CompilePerms(options).run(logger);
Thread.currentThread().setContextClassLoader(prevClassLoader);
This is where UiBinder has some problems
private Document getW3cDoc(MortalLogger logger, String templatePath)
throws UnableToCompleteException {
URL url =
UiBinderGenerator.class.getClassLoader().getResource(templatePath);
if (null == url) {
logger.die(Unable to find resource: + templatePath);
}
On Mon, May 31, 2010 at 8:46 PM, Marko Vuksanovic
markovuksano...@gmail.com wrote:
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, 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 transfer all the files
to
the remote machine (that is src, required jars and result emitted
by
precompile step) I changed the classpath context and executed
compile
perms as follows:
new CompilePerms(options).run(logger);
where options is an instance of CompilePermsOptions.
the error I get is
Scanning for additional dependencies: file:/D:/Devel/open-source/
gwt-distributed-compiler/agent/0002/src/hr/example/orka/client/panels/
MainPanel.java
Computing all possible rebind results for
'hr.example.orka.client.panels.MainPanel.MainPanelUiBinder'
Rebinding
hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder
Invoking generator
com.google.gwt.uibinder.rebind.UiBinderGenerator
[ERROR] Unable to find resource:
hr/example/orka/client/
panels/MainPanel.ui.xml
This is the primary error. Are you sure that file is showing up on
the
remote machine? Before you invoke the compiler, you can try doing a
classLoader.getResource(hr/example/orka/client/panels/MainPanel.ui.xml)
and make sure it's found.
I'm sure that the file is located on the remote machine. I have
checked it manually and the other thing is that once I transfer files
to the remote machine and execute compile perms manually as described
here (http://code.google.com/p/google-web-toolkit/wiki/
DistributedBuilds - java -cp ... com.google.gwt.dev.CompilePerms
com.google.gwt.sample.hello.Hello -workDir work -perms 0 (I adjusted
this to my needs, off course)). So, I'm sure that the files are where
they should be... I'll try classLoader.getResource(hr/example/orka/
client/panels/MainPanel.ui.xml) in an hour or so - will post the
result here.
Second problem is that once I transfer files to the other machine,
where the CompilePerms is executed - once everything is finished
the
jar files, which were added to the ClasspathContext using
URLClasspathLoader don't seem to be unloaded even when the context
is
reverted to what it was before and all the references are set to
null.
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader = URLClassLoader.newInstance(
classpathURLs.toArray(new URL[] {}),
prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
new CompilePerms(options).run(logger);
//System.gc();
//System.gc();
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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. Then check wherever it looks now (the system class loader?). IIRC, that's what Bob has ClientBundle doing in general. Should the resource oracle itself be doing this? Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 oracle. Next check the context class loader, as in Marko's email. Then check wherever it looks now (the system class loader?). IIRC, that's what Bob has ClientBundle doing in general. Should the resource oracle itself be doing this? Yeah, this is correct. Although, I'm not sure if the last one is strictly necessary. The exception to the rule is when you're trying to look up things that you are confident are bundled *with* the generator. For example, when looking up a resource you bundled into the same jar as a generator, you can do something like this.getClass().getResource(some-bundled-resource-in-this-package). But anything that a USER might provide has to be looked up through the context class loader (or the resource oracle, which is essentially an optimized way of checking the context class loader). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 wrote: 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 oracle. Next check the context class loader, as in Marko's email. Then check wherever it looks now (the system class loader?). IIRC, that's what Bob has ClientBundle doing in general. Should the resource oracle itself be doing this? Yeah, this is correct. Although, I'm not sure if the last one is strictly necessary. The exception to the rule is when you're trying to look up things that you are confident are bundled *with* the generator. For example, when looking up a resource you bundled into the same jar as a generator, you can do something like this.getClass().getResource(some-bundled-resource-in-this-package). But anything that a USER might provide has to be looked up through the context class loader (or the resource oracle, which is essentially an optimized way of checking the context class loader). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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: 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 oracle. Next check the context class loader, as in Marko's email. Then check wherever it looks now (the system class loader?). IIRC, that's what Bob has ClientBundle doing in general. Should the resource oracle itself be doing this? Yeah, this is correct. Although, I'm not sure if the last one is strictly necessary. The exception to the rule is when you're trying to look up things that you are confident are bundled *with* the generator. For example, when looking up a resource you bundled into the same jar as a generator, you can do something like this.getClass().getResource(some-bundled-resource-in-this-package). But anything that a USER might provide has to be looked up through the context class loader (or the resource oracle, which is essentially an optimized way of checking the context class loader). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 it's better to just use it. But in theory, if you've only got one generator and it only looks for a few files, it's slower to build the resource oracle. On Tue, Jun 1, 2010 at 1:06 PM, Marko Vuksanovic markovuksano...@gmail.comwrote: 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: 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 oracle. Next check the context class loader, as in Marko's email. Then check wherever it looks now (the system class loader?). IIRC, that's what Bob has ClientBundle doing in general. Should the resource oracle itself be doing this? Yeah, this is correct. Although, I'm not sure if the last one is strictly necessary. The exception to the rule is when you're trying to look up things that you are confident are bundled *with* the generator. For example, when looking up a resource you bundled into the same jar as a generator, you can do something like this.getClass().getResource(some-bundled-resource-in-this-package). But anything that a USER might provide has to be looked up through the context class loader (or the resource oracle, which is essentially an optimized way of checking the context class loader). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 loader. Ok, there are several places in the i18n generators that need to be fixed then. Is just checking the context class loader sufficient (ie, will it chain to the system classloader)? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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.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. Ok, there are several places in the i18n generators that need to be fixed then. Is just checking the context class loader sufficient (ie, will it chain to the system classloader)? It should be sufficient for any user-provided resources. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 class loader, all parent class loaders have been checked. Somebody correct me if I'm wrong. On Tue, Jun 1, 2010 at 8: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.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. Ok, there are several places in the i18n generators that need to be fixed then. Is just checking the context class loader sufficient (ie, will it chain to the system classloader)? It should be sufficient for any user-provided resources. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 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 it's better to just use it. But in theory, if you've only got one generator and it only looks for a few files, it's slower to build the resource oracle. On Tue, Jun 1, 2010 at 1:06 PM, Marko Vuksanovic markovuksano...@gmail.com wrote: 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: 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 oracle. Next check the context class loader, as in Marko's email. Then check wherever it looks now (the system class loader?). IIRC, that's what Bob has ClientBundle doing in general. Should the resource oracle itself be doing this? Yeah, this is correct. Although, I'm not sure if the last one is strictly necessary. The exception to the rule is when you're trying to look up things that you are confident are bundled *with* the generator. For example, when looking up a resource you bundled into the same jar as a generator, you can do something like this.getClass().getResource(some-bundled-resource-in-this-package). But anything that a USER might provide has to be looked up through the context class loader (or the resource oracle, which is essentially an optimized way of checking the context class loader). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 there, next child will be checked... and so on... So if something is found in context class loader, all parent class loaders have been checked. Somebody correct me if I'm wrong. 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. That said, if it's not on the context loader, you might want to ignore it if you can get away with it. For that matter, the same goes for things not in the resource oracle. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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 that all the parent class loaders would be checked prior to checking the actual class loader. So checking the context class loader would result in checking all the class loaders above it (in the hierarchy) - and if the hierarchy wasn't explicitly changed this should be perfectly ok. On Tue, Jun 1, 2010 at 9:17 PM, Lex Spoon sp...@google.com wrote: On Tue, Jun 1, 2010 at 2:35 PM, Marko Vuksanovic markovuksano...@gmail.com wrote: 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 class loader, all parent class loaders have been checked. Somebody correct me if I'm wrong. 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. That said, if it's not on the context loader, you might want to ignore it if you can get away with it. For that matter, the same goes for things not in the resource oracle. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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: file:/D:/Devel/open-source/gwt-distributed-compiler/agent/0002/src/hr/tkd/orka/client/panels/MainPanel.java Computing all possible rebind results for 'hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder' Rebinding hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder Invoking generator com.google.gwt.uibinder.rebind.UiBinderGenerator [ERROR] Generator 'com.google.gwt.uibinder.rebind.UiBinderGenerator' threw an exception while rebinding 'hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder' java.lang.RuntimeException: java.io.FileNotFoundException: D:\Devel\open-source\gwt-distributed-compiler\agent\hr\tkd\orka\client\panels\MainPanel.ui.xml (The system cannot find the path specified) Obviously the resource is being looked for at the wrong place... It should be D:\Devel\open-source\gwt-distributed-compiler\agent\0002\src\hr\tkd\orka\client\panels\MainPanel.ui.xml the program is run from the location D:\Devel\open-source\gwt-distributed-compiler\agent\ and the files needed for compile perms are located in folder 0002\src, 0002\lib and 0002\work. The relevant part of the context class path is set to D:\Devel\open-source\gwt-distributed-compiler\agent\0002\src but when resource is fetched from the resource oracle the path is not constructed correctly. I reckon the resource should be added as 0002\src\hr\tkd\orka\client\panels\MainPanel.ui.xml... On Tue, Jun 1, 2010 at 10:05 PM, Marko Vuksanovic markovuksano...@gmail.com wrote: 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 that all the parent class loaders would be checked prior to checking the actual class loader. So checking the context class loader would result in checking all the class loaders above it (in the hierarchy) - and if the hierarchy wasn't explicitly changed this should be perfectly ok. On Tue, Jun 1, 2010 at 9:17 PM, Lex Spoon sp...@google.com wrote: On Tue, Jun 1, 2010 at 2:35 PM, Marko Vuksanovic markovuksano...@gmail.com wrote: 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 class loader, all parent class loaders have been checked. Somebody correct me if I'm wrong. 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. That said, if it's not on the context loader, you might want to ignore it if you can get away with it. For that matter, the same goes for things not in the resource oracle. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors ui-binder-generator.patch Description: Binary data
[gwt-contrib] Re: CompilePerms and classpath loading problem.
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 transfer all the files to
the remote machine (that is src, required jars and result emitted by
precompile step) I changed the classpath context and executed compile
perms as follows:
new CompilePerms(options).run(logger);
where options is an instance of CompilePermsOptions.
the error I get is
Scanning for additional dependencies: file:/D:/Devel/open-source/
gwt-distributed-compiler/agent/0002/src/hr/example/orka/client/panels/
MainPanel.java
Computing all possible rebind results for
'hr.example.orka.client.panels.MainPanel.MainPanelUiBinder'
Rebinding
hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder
Invoking generator
com.google.gwt.uibinder.rebind.UiBinderGenerator
[ERROR] Unable to find resource: hr/example/orka/client/
panels/MainPanel.ui.xml
This is the primary error. Are you sure that file is showing up on the
remote machine? Before you invoke the compiler, you can try doing a
classLoader.getResource(hr/example/orka/client/panels/MainPanel.ui.xml)
and make sure it's found.
I'm sure that the file is located on the remote machine. I have
checked it manually and the other thing is that once I transfer files
to the remote machine and execute compile perms manually as described
here (http://code.google.com/p/google-web-toolkit/wiki/
DistributedBuilds - java -cp ... com.google.gwt.dev.CompilePerms
com.google.gwt.sample.hello.Hello -workDir work -perms 0 (I adjusted
this to my needs, off course)). So, I'm sure that the files are where
they should be... I'll try classLoader.getResource(hr/example/orka/
client/panels/MainPanel.ui.xml) in an hour or so - will post the
result here.
Second problem is that once I transfer files to the other machine,
where the CompilePerms is executed - once everything is finished the
jar files, which were added to the ClasspathContext using
URLClasspathLoader don't seem to be unloaded even when the context is
reverted to what it was before and all the references are set to null.
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader = URLClassLoader.newInstance(
classpathURLs.toArray(new URL[] {}), prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
new CompilePerms(options).run(logger);
//System.gc();
//System.gc();
Thread.currentThread().setContextClassLoader(prevClassLoader);
urlClassLoader = null;
classpathURLs = null;
Is it possible that some other classloader, within the gwt code, has
set some references to hose jars?
It's probably the refs in ResourceOracleImpl. We keep them around for
hosted mode refresh to be faster. Take a look at that, describe your use
case, and we can talk about how those things can get cleaned up.
Well, the use case is basically that I want to have a machine that
will be used for compiling different projects. So, once precompile is
done and all the necessary data are transfered to the remote machine
for compilePerms - the remote machine does the compile perms step and
emits some result. That result is then returned to the client which
sent the data for processing (compilation). That data, which was sent
to be processed, is not necessary on the remote machine, not any more
so it should be cleaned up.
Scott
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.
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, 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 transfer all the files to
the remote machine (that is src, required jars and result emitted by
precompile step) I changed the classpath context and executed compile
perms as follows:
new CompilePerms(options).run(logger);
where options is an instance of CompilePermsOptions.
the error I get is
Scanning for additional dependencies: file:/D:/Devel/open-source/
gwt-distributed-compiler/agent/0002/src/hr/example/orka/client/panels/
MainPanel.java
Computing all possible rebind results for
'hr.example.orka.client.panels.MainPanel.MainPanelUiBinder'
Rebinding
hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder
Invoking generator
com.google.gwt.uibinder.rebind.UiBinderGenerator
[ERROR] Unable to find resource: hr/example/orka/client/
panels/MainPanel.ui.xml
This is the primary error. Are you sure that file is showing up on the
remote machine? Before you invoke the compiler, you can try doing a
classLoader.getResource(hr/example/orka/client/panels/MainPanel.ui.xml)
and make sure it's found.
I'm sure that the file is located on the remote machine. I have
checked it manually and the other thing is that once I transfer files
to the remote machine and execute compile perms manually as described
here (http://code.google.com/p/google-web-toolkit/wiki/
DistributedBuilds - java -cp ... com.google.gwt.dev.CompilePerms
com.google.gwt.sample.hello.Hello -workDir work -perms 0 (I adjusted
this to my needs, off course)). So, I'm sure that the files are where
they should be... I'll try classLoader.getResource(hr/example/orka/
client/panels/MainPanel.ui.xml) in an hour or so - will post the
result here.
Second problem is that once I transfer files to the other machine,
where the CompilePerms is executed - once everything is finished the
jar files, which were added to the ClasspathContext using
URLClasspathLoader don't seem to be unloaded even when the context is
reverted to what it was before and all the references are set to null.
prevClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader = URLClassLoader.newInstance(
classpathURLs.toArray(new URL[] {}), prevClassLoader);
Thread.currentThread().setContextClassLoader(urlClassLoader);
new CompilePerms(options).run(logger);
//System.gc();
//System.gc();
Thread.currentThread().setContextClassLoader(prevClassLoader);
urlClassLoader = null;
classpathURLs = null;
Is it possible that some other classloader, within the gwt code, has
set some references to hose jars?
It's probably the refs in ResourceOracleImpl. We keep them around for
hosted mode refresh to be faster. Take a look at that, describe your use
case, and we can talk about how those things can get cleaned up.
Well, the use case is basically that I want to have a machine that
will be used for compiling different projects. So, once precompile is
done and all the necessary data are transfered to the remote machine
for compilePerms - the remote machine does the compile perms step and
emits some result. That result is then returned to the client which
sent the data for processing (compilation). That data, which was sent
to be processed, is not necessary on the remote machine, not any more
so it should be cleaned up.
Scott
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
