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();
>>>>> > > 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
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to