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 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
>>
>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
