I spoke to Scott offline and he thinks that the client code should
never get to these operations due to compile errors. At the same time,
many of the functions can't throw exceptions since even though client
code does not call them, the class itself will call some of them (even
though they are no-o
On Wed, May 5, 2010 at 2:15 PM, Ray Ryan wrote:
> You should be able to throw subclasses of RuntimeException, no?
For example, UnsupportedOperationException. -Lex
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM.
Since you don't actually implement most of that public API in our
emulation library, I believe you get a compile error even in dev mode if
client code tries to call it. So I would expect that (unless you add
those functions to the JRE in the future) those methods will never get
called from
huh - I didn't know that (I seem to learn something new about java
every day...) I'll do that - thanks!
- Unnur
On Wed, May 5, 2010 at 11:15 AM, Ray Ryan wrote:
> You should be able to throw subclasses of RuntimeException, no?
>
> On Wed, May 5, 2010 at 11:03 AM, wrote:
>>
>> I also added delega
http://gwt-code-reviews.appspot.com/437801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
You should be able to throw subclasses of RuntimeException, no?
On Wed, May 5, 2010 at 11:03 AM, wrote:
> I also added delegation for the other public functions. It's "broken",
> in the sense that it'll work in dev mode while the JRE is still being
> used for the client stuff and break in web mo
I also added delegation for the other public functions. It's "broken",
in the sense that it'll work in dev mode while the JRE is still being
used for the client stuff and break in web mode, but that's true for any
JRE emulation classes that don't implement all of the functions. Does
that sound rea
LG, but having removed all the of the public API delegation makes me
slightly nervous. You're sure this is ok? If those calls are no-ops in
web mode, you could explicitly model it that way instead of letting
client code get access to the server log manager super.
http://gwt-code-reviews.appspo
http://gwt-code-reviews.appspot.com/437801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2010/05/04 21:59:45, unnurg wrote:
OK - it turns out that delegating to another LogManager for the server
code is not working correctly. Specifically, there's something in the
configurations that isn't getting passed on to the serverLogManager. I
spent about 3 hours trying to figure this out
http://gwt-code-reviews.appspot.com/437801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
http://gwt-code-reviews.appspot.com/437801/diff/8001/9003
File /dev/core/src/com/google/gwt/dev/shell/DevModeLogManager.java
(right):
http://gwt-code-reviews.appspot.com/437801/diff/8001/9003#newcode33
/dev/core/src/com/google/gwt/dev/shell/DevModeLogManager.java:33:
protected static class LogMa
LGTM, just a few style nits.
http://gwt-code-reviews.appspot.com/437801/diff/8001/9003
File /dev/core/src/com/google/gwt/dev/shell/DevModeLogManager.java
(right):
http://gwt-code-reviews.appspot.com/437801/diff/8001/9003#newcode33
/dev/core/src/com/google/gwt/dev/shell/DevModeLogManager.java:33
http://gwt-code-reviews.appspot.com/437801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
all done
http://gwt-code-reviews.appspot.com/437801/diff/1/3
File /dev/core/src/com/google/gwt/dev/shell/BrowserChannelServer.java
(right):
http://gwt-code-reviews.appspot.com/437801/diff/1/3#newcode43
/dev/core/src/com/google/gwt/dev/shell/BrowserChannelServer.java:43: *
should be instantiatin
I think DevModeLogManager still needs some work, the rest is just style
stuff.
http://gwt-code-reviews.appspot.com/437801/diff/1/3
File /dev/core/src/com/google/gwt/dev/shell/BrowserChannelServer.java
(right):
http://gwt-code-reviews.appspot.com/437801/diff/1/3#newcode43
/dev/core/src/com/googl
16 matches
Mail list logo
