[gwt-contrib] Re: Feature idea - reference Java methods as Javascript functions
On Fri, May 29, 2009 at 9:42 AM, John Tamplin j...@google.com wrote:
On Thu, May 28, 2009 at 8:18 PM, Vitali Lovich vlov...@gmail.com wrote:
It would be nice if there was a way to wrap Java methods with an opaque
Javascript function object so that you could pass them around in the native
code (obviously there are issues with compiler optimizations in this case).
You can do this now -- in a JSNI method:
static void bar(int arg) { ... }
var f = @org.example.Foo::bar(I);
I was thinking more along the lines of JavascriptFunction foo =
MyClass.bar.method or something like that. That way, you could do dynamic
function invocation without ever needing JSNI. It's also a lot easier to
write that code, maintain it, it's IDE friendly, meaning no typos syntax
checking (which is a major strength of GWT).
You can then pass/return it to Java/JSNI code as a JavaScriptObject, or
directly to external Javascript that looks for a function.
Ideally, you would be also able to execute any Javascript function object
from within Java code, although that does present some problems.
You have to have a JSNI method to do this now:
private static native JavaScriptObject callFunc(JavaScriptObject func, int
arg) /*-{
func(arg);
}-*/;
Yes - hence the feature request. I know it's non-trivial given that GWT
follows Java convention wraps varargs in an array which could cause
problems for the JS. Just trying to get some feedback on whether or not
it's a good idea.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Feature idea - reference Java methods as Javascript functions
On Fri, May 29, 2009 at 11:59 AM, John Tamplin j...@google.com wrote: On Fri, May 29, 2009 at 11:31 AM, Vitali Lovich vlov...@gmail.com wrote: The way you get a method reference in pure Java is via reflection, which in general is not feasible though there have been some discussions of allowing it when everything can be evaluated at compile time (ie, all constants for classes and method/field names) -- even that seems to be a long way away however. How about through GWT.create? Then it uses reflection to supply the actual function. Might be limited to JSNI functions unless you can compile code fragments. GWT.create takes a single class literal, so there is no way to describe a method. You could have it generate an object with a callback function, but that is going to be a lot more boilerplate than just having a simple JSNI method that returns the torn-off function. Not necessarily GWT.create - just something along those lines that provides enough static information for it to resolve the method yet also provide compile-time checking for that. I'm still thinking about it - it is difficult to think of a clean way of doing it (without the boilerplate code as you mentioned) since overloading is what causes problems. I haven't actually looked at the plugin yet. If you are worried about JSNI syntax or autocompletion, you really should. You also get a Deploy to Google button for AppEngine integration. I'm not actually - it would just be nice to not have to drop into JSNI for something that is seemingly so simple. Why not create a JsFunction class that extends from JavaScriptObject to represent a JS lambda function. However, since you can't have polymorphic dispatch on JSOs, that would reserve whatever name was chosen from all subclasses, so it would have to be something unlikely to collide. I'm not sure what you mean here. Why would you need to reserve a name? Because of how JSOs work (in that you can freely cast them to each other), JSO method calls have to be statically resolvable. If we put a call() method on JavaScriptObject, no other JSO subclass could have a call method with the same signature (and that restriction is enforced by requiring the method or class to be final). However, your suggestion of putting it on a JSO subclass solves that problem. The remaining complication is that you can't declare a JSNI method with varargs, so it is somewhat complicated to build the args list for the call. You would probably also have to have one for void returns and one for calls returning a value (it might be possible to handle that with a return type parameter on JsFunction like JsFunctionInt). Yeah - the varargs is the problem. I was thinking about maybe using eval, but I can't really see how. I concede that there's probably no way to do all this cleanly within the context of GWT (at least not without ugly hacks that break Java syntax). -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Comment on UsingOOPHM in google-web-toolkit
Worked for me. Did you use the XPI or XPCOM one? On Sun, May 24, 2009 at 5:11 PM, codesite-nore...@google.com wrote: Comment by henr...@yahoo.fr: The provided firefox plugin doesn't work for me (Linux x86_64). I had to build a new firefox plugin from SVN. For more information: http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add getElementsByClassName support
On Tue, May 12, 2009 at 4:49 PM, Joel Webber j...@google.com wrote:
On Tue, May 12, 2009 at 4:38 PM, Ray Cromwell cromwell...@gmail.comwrote:
On Tue, May 12, 2009 at 1:26 PM, j...@google.com wrote:
- This class also appears to be doing runtime detection of
(document.evaluate). I think we should be able to make this
solely dependent upon the browser overload and ditch the runtime
switch.
The problem is, firefox3 has this method, but firefox2 needs to use
document.evaluate, so you either have to add a deferred binding just
for this, or you do a runtime test and cache the result, something
like
public native void initGetElementsByClassName() /*-{
this.getElementsByClassName = nativeTest ?
th...@com.google.gwt.user.client.domimpl
::getElementsByClassNameNative(Ljava/lang/String;)
: th...@com.google.gwt.user.client.domimpl
::getElementsByClassNameXPath(Ljava/lang/String;);
}-*/;
I see. That makes sense. In this case, though, it would be nice to move
that logic into the DOMImplMozilla so that it doesn't clutter up the
standard case.
- Don't forget IE8 support (I slipped it into trunk as a new user-agent
value recently). They added support for querySelectorAll(), which is
nice.
I haven't looked at IE8 yet. It's fine to use querySelectorAll to
implement getElementsByClassName as a faster way for IE8. Eventually,
querySelectorAll needs to make it into the API by itself, although that will
require more effort probably since the Javascript emulation of that one is
probably far more complicated.
Yes, you can use querySelectorAll for this, although short-circuiting
to getElementsByClassName() if it's native is faster on some browsers.
Again, the IE6 vs IE8 issue will crop up requiring either another
deferred binding, or a runtime-test.
querySelectorAll would only make sense with IE8 no? I think it's the only
browser that didn't implement both at the same time (or in any case,
getElementsByClassName probably came first).
There will be some overlap between this and the Gwt Query based
selector stuff too.
Good point. If you guys could coordinate to make sure there's at least a
chance of GwtQuery using this interface (to the extent it needs
getElementsByClassName() at all), that would be great.
-Ray
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Add getElementsByClassName support
On Tue, May 12, 2009 at 4:26 PM, j...@google.com wrote:
Thanks for digging into this -- it'll be helpful for a lot of
developers.
And sorry I've taken so long to get around to reviewing -- I've been
pretty swamped lately.
I'm going to ask Ray to come back and review some of the DOM details a
bit more, but I'd like to address a couple of broader structural
questions myself.
- It's not entirely clear to me why DOMImplStandard.ElementsByClassName
is its own inner class.
This was so that the overhead was as low as possible.
1) Situation 1 - Program doesn't use getElementsByClassName. This whole
code path will be stripped out by the compiler (not a reason for the inner
class, just my thought process when I was writing this).
2) Situation 2 - Program does use getElementsByClassName. 2 ways to
implement. a) initialize the prototypes ahead of time with the appropriate
implementation. b) determine the appropriate function dynamically on every
invocation.
The inner class was the only way I could think of to satisfy 2a while
supporting 1 so that there's some minimal startup code to pick the right
implementation, but the invocation is as fast as can possibly be.
Optionally, I could have made the startup code common to everyone, but then
that just adds overhead for people who will never use this function. Or I
could have done something like
if (e.getElementsByClassName) {
return e.getElementsByClassName(class name);
}
Element.prototype.getElementsByClassName = function() { //whatever };
document.getElementsByClassName = function() { // whatever };
- I also don't think it should be adding methods to the document
object.
- It runs the risk of conflicting with other js libs, and there's
almost always a better way to hang onto those values
Considering the native versions added getElementsByClassName to the document
object, I don't see a potential conflict. All the libraries I looked at
were fixed a while back too because they clobbered the native version with
the emulated code. This code also checks for
document.getElementsByClassName first. That means if a user wants to use
the JS libraries version of it (I wouldn't know why since the GWT version
would be faster smaller), he would just have to make sure that it gets
registered first (the implementation I wrote doesn't clobber the existing
getElementsByClassName).
(remember you can add static fields to the DOMImpl classes if you
need to).
what is this in reference to?
- This class also appears to be doing runtime detection of
(document.evaluate). I think we should be able to make this
solely dependent upon the browser overload and ditch the runtime
switch.
As Ray pointed out, FF2 breaks this for us. Just to expand, so does every
standards compliant browser at some point (a while back I was asking about
supported browser versions for particularly this reason - all the versions
had, as far as I could tell, non-XPath, followed by XPath, followed by
native getElementsByClassName, hence the reason I made it standard.
- It would be nice to have a brief doc (even if it's just on the contrib
list), detailing which approaches work on which browsers.
Yes - I should have written this down to begin with. I'll have to look it
up again.
From what I can remember I believe it went like this:
* IE8 = DOM
IE8 = XPath through querySelectorAll (implementation still needs to be
written)
FF2 = DOM
FF3 = XPath through document.evaluate
*= FF3 = native
Safari 3 = XPath
*= Safari 3.1 = native
Safari 2 = not clear about this - might be XPath, might be DOM. Can't find
clear documentation on this don't have a Mac.
Opera = todo. They don't seem to have a good changelog (at least that I
can find) of when features like this were added.
But don't hold me to any of this - it's all from memory (except for those
marked *).
- Don't forget IE8 support (I slipped it into trunk as a new user-agent
value recently). They added support for querySelectorAll(), which is
nice.
Yup. Might pose a problem with quirks mode, but no probably no more so than
any of the other XPath methods.
- This could really use some tests. There is a lot of complex behavior
here, and it would be nice to have some confirmation that it works :)
Yes that would be nice. I've been on vacation for a while - this is on my
todo list.
- If you need a hand running tests across browsers, send me patches
and I'll be glad to do it here.
Sweet :D. I think first we need to come up with a matrix of browsers
versions. My list:
IE6, IE8 (IE7 optional - should be functionally equivalent to IE6)
Firefox 1.5, Firefox 2, Firefox 3
Safari 2, Safari 3, Safari 4 (Safari 3.1 is optional, but should be
functionally equivalent to 4)
Opera 8.5 (first free version about the same age as FF 1.5), Opera 9.0,
Opera 9.5
Bonus: Chrome, Konqueror
Is that a reasonable approximation? Too much? Too little? Wrong versions?
http://codereview.appspot.com/44041/diff/1/5
[gwt-contrib] Re: IE8 support
That's annoying.
On Wed, Apr 29, 2009 at 1:07 PM, Joel Webber j...@google.com wrote:
Not even close, unfortunately. If you look at the wiki page I wrote up:
http://code.google.com/p/google-web-toolkit/wiki/IE8Support
You'll see that the actual differences are pretty minimal. They fixed a
number of CSS things, added DOM storage, Ajax history, and other things like
that. But their event model is still wildly different. Most of the DOM
element methods and properties are still weird and different, and so forth.
I'm afraid Trident remains its own beast :(
On Wed, Apr 29, 2009 at 1:02 PM, Vitali Lovich vlov...@gmail.com wrote:
Does IE8 still have non-standards compliant behaviour? I thought they
were supposed to introduce pretty strict standards compliance with IE8 (in
fact, some/all? legacy non-standard stuff is unavailable). Shouldn't IE8
extend DOMImplStandard or are there still remaining issues?
On Mon, Apr 27, 2009 at 11:22 AM, j...@google.com wrote:
http://gwt-code-reviews.appspot.com/29803/diff/1/5
File user/src/com/google/gwt/dom/DOM.gwt.xml (right):
http://gwt-code-reviews.appspot.com/29803/diff/1/5#newcode56
Line 56: when-property-is name=user.agent value=ie6/
On 2009/04/24 20:34:56, jlabanca wrote:
too many spaces
Done.
http://gwt-code-reviews.appspot.com/29803/diff/1/12
File user/src/com/google/gwt/user/Form.gwt.xml (right):
http://gwt-code-reviews.appspot.com/29803/diff/1/12#newcode31
Line 31: when-property-is name=user.agent value=ie6/
On 2009/04/24 20:34:56, jlabanca wrote:
Spacing, and what are those two red arrows? »»
visual tab indicators.
Cleaned up tabs.
http://gwt-code-reviews.appspot.com/29803/diff/1/7
File user/src/com/google/gwt/user/RichText.gwt.xml (right):
http://gwt-code-reviews.appspot.com/29803/diff/1/7#newcode27
Line 27: when-property-is name=user.agent value=ie6 /
On 2009/04/24 20:34:56, jlabanca wrote:
Remove the »», which I assume are tabs.
Done.
http://gwt-code-reviews.appspot.com/29803/diff/1/8
File user/src/com/google/gwt/user/TextBox.gwt.xml (right):
http://gwt-code-reviews.appspot.com/29803/diff/1/8#newcode32
Line 32: when-property-is name=user.agent value=ie6/
On 2009/04/24 20:34:56, jlabanca wrote:
Remove »»
Done.
http://gwt-code-reviews.appspot.com/29803/diff/1/9
File user/src/com/google/gwt/user/UserAgent.gwt.xml (right):
http://gwt-code-reviews.appspot.com/29803/diff/1/9#newcode38
Line 38: if (v = 8000) {
On 2009/04/24 23:44:41, t.broyer wrote:
I believe ie8 here means X-UA-Compatibility: IE=8, so detecting
the version
from the navigator.userAgent is probably not enough [1], and
document.documentMode should be used instead [2], otherwise the ie8
implementation would have to do a
quirks-vs-standards-vs-super-standards-mode-detection, which would
make the
ie6 impl quite useless.
[1] Mike Ormond reports that a document can be displayed in IE=5 or
IE=7 mode
while the UA is still reported as MSIE 8.0
http://blogs.msdn.com/mikeormond/archive/2008/09/25/ie-8-compatibility-meta-tags-http-headers-user-agent-strings-etc-etc.aspx
[2]
http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx#GetModehttp://msdn.microsoft.com/en-us/library/cc288325%28VS.85%29.aspx#GetMode
Thanks for pointing out that blog in particular. Amazing that they
managed to turn quirks/standards into a 12-entry matrix :P
The good news is that In compatibility view, IE always reports its UA
as MSIE 7.0, which triggers the ie6 user-agent property.
When no X-UA-Compatible header is set, we're in normal mode (i.e., not
compatibility view), and no DOCTYPE is set, we end up in quirks-mode,
which appears to turn off some IE8 features (I've noticed that at least
IE8 history breaks, though everything else I've tried seems to work fine
and all of our tests pass). The only solution I'm aware of is to either
set a DOCTYPE or the X-UA-Compatible header (both of which will put you
in standards-mode). I realize there are still some GWT panels that
layout a bit oddly in standards-mode, and while we're working on solving
this, it's going to be a problem for some apps for a while yet.
I'll document this on the IE8 support wiki page for now. Before long, it
will be the right thing to always set a DOCTYPE, which should make
this problem go away.
http://gwt-code-reviews.appspot.com/29803/diff/1/6
File user/src/com/google/gwt/xml/XML.gwt.xml (right):
http://gwt-code-reviews.appspot.com/29803/diff/1/6#newcode39
Line 39: when-property-is name=user.agent value=ie6/
On 2009/04/24 20:34:56, jlabanca wrote:
tabs again »»
Done.
http://gwt-code-reviews.appspot.com/29803
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Feature idea
Kinda like with GCC, allow detection of constant values (i.e.
__builtin_constant_phttp://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/Other-Builtins.html).
This way, you could do something like
void addParameter (HashMap h, int size, String key, Object value)
{
if (GWT.isConstantValue(h, null)) {
if (GWT.isConstantValue(size, 0))
size = 10;
h = new HashMap(size);
}
h.put(key, value).
}
you could have the performance of
void addParameter (HashMap h?, int size?, String key, Object value)
as if you wrote overloaded methods without needing to write several
different methods that just supply default values back forth. Sometimes,
it's also possible to use a better algorithm if parameters have a known
constant value.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Feature idea
Yeah, probably from a compiler's perspective, the value check may be more
complicated (the value may only be available after the AST stage depending
on when optimization is done)
It can possibly bloat the resultant code (since I believe you may have to
build different implementations of each function and you may get overhead,
even if you inline). However, I think this might be an OK tradeoff since
the assumption would be that you are optimizing for speed as opposed to size
if you use something like GWT.isLiteral.
On Mon, Apr 27, 2009 at 3:45 AM, Ray Cromwell cromwell...@gmail.com wrote:
+1
I suggested a similar feature a few days ago privately, I called it
GWT.isLiteral(), since the underlying check is if its an AST literal
in the compiler, although in my example, you can't do value
comparisons, just assertions on the literal. The value checks would be
done via traditional operators.
On Mon, Apr 27, 2009 at 12:33 AM, Vitali Lovich vlov...@gmail.com wrote:
Kinda like with GCC, allow detection of constant values (i.e.
__builtin_constant_p). This way, you could do something like
void addParameter (HashMap h, int size, String key, Object value)
{
if (GWT.isConstantValue(h, null)) {
if (GWT.isConstantValue(size, 0))
size = 10;
h = new HashMap(size);
}
h.put(key, value).
}
you could have the performance of
void addParameter (HashMap h?, int size?, String key, Object value)
as if you wrote overloaded methods without needing to write several
different methods that just supply default values back forth.
Sometimes,
it's also possible to use a better algorithm if parameters have a known
constant value.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: New shopping new life!
Wow that takes me back. I've stopped using my hotmail actively for already about 2-3 years. I have my thunderbird on my desktop occassionally download filter through all the spam for archival purposes. It just annoys me how locked down it is. With gmail (not a plug, just the best web-based email I've used so far) you get free POP IMAP access there are no restrictions with forwarding (i.e. if you switch somewhere else). Hotmail was amazing back in the day - MS has just managed to strangle every single web-based strategy they had. On Mon, Apr 27, 2009 at 8:42 AM, Ed post2edb...@hotmail.com wrote: He Joel, Sorry for the trouble. Last night I came home and all of sudden my whole hotmail was changed and got all kind of failed mail deliveries :(... Yep, changed my password already. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Comment on UsingOOPHM in google-web-toolkit
There's a link on the website to download the xpi off the web. It does not come with GWT trunk (it's in a branch). The gwt-dev-oophm.jar is built when you build trunk. On Thu, Apr 23, 2009 at 10:15 PM, John Tamplin j...@google.com wrote: On Thu, Apr 23, 2009 at 9:45 PM, Freeland Abbott fabb...@google.comwrote: On that topic, I've been quietly lobbying to move the svn/tools directory into svn/trunk/..., although there's already a tools directory (which adds to the confusion; it's different), so it would have to be named something else. I think it'd be a lot simpler for this sort of confusion... but the downside is that every workspace you make would get its own, redundant copy of some fairly large stuff. Disk is cheap, maybe, but you also need to download it all at least to start; there is a downside.u Thoughts? It isn't small and is only getting larger. I currently have 8 separate checkouts on this machine, so having to have 8 separate copies of tools seems excessive. I think it is fine the way it is. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 support
Is FF3.5 on the plan as well? Safari 4? Opera 10? Chrome? Are there guidelines on when a browser version gets its own axis (i.e. HTML5 support) or is it just when it feels appropriate or there are significant changes? Shouldn't then we refactor the other browsers as well to be named after the layout engines (i.e. DOMImplGecko with DOMImplMozilla or DOMImplFirefox as specific subclasses, or DOMImplWebkit with DOMImplSafari and/or DOMImplChrome). Also, I'm still trying to find a good list of supported browser versions for browsers other than IE. Is FF really supported all the way back to FF 0.9? Probably not since I was told that MozillaImplOld is should disappear with 2.0, meaning presumably gecko 1.8 earlier browsers will become unsupported. What about Safari Opera. On a side note, the number of permutations is especially important as a developer-facing issue because time time again on the mailing list it comes up with people complaining about the compile time because that's how they think they should be developing (instead of using hosted mode for development or limiting to a specific configuration to fix a browser-specific problem). Adding more documentation doesn't seem to help because that doesn't seem to be read thoroughly - this seems to be more from the jump in with both feet hack till it works crowd (not that there's anything wrong with that approach :D). Maybe have the compiler print a warning with a reference to the documentation indicating it's not a good workflow to compile for development if the last successfully compiled code was like in the last 5 hours. On Thu, Apr 23, 2009 at 4:31 PM, j...@google.com wrote: Reviewers: jlabanca, Description: This monster of a patch adds what I believe to be full support for IE8. Review strategy to make your life easier: - All the .gwt.xml files, with the exception of DOM and History just add ie8 to the existing ie6 cases. - The giant diff around both DOMImpl's stems from the fact that in both cases I renamed DOMImplIE6 to DOMImplTrident (Trident is IE's rendering engine), and created IE6 and IE8 subclasses. The IE8 subclasses are currently empty, and I pushed down a few IE6/7-only method implementations into the DOMImplIE6's. - I would save the HistoryImpl changes for last. IE8 implements the HTML5 standard onhashchange event, which is going to be the proper way forward on new browsers, so I refactored the implementation such that HistoryImpl uses that. - I also ditched the no-longer-supported Safari 2 history implementation and collapsed the HistoryImplFrame/Safari/IE6 into a single HistoryImplIE6. - I added a new HistoryImplTimer which uses a timer to simulate the onhashchange event (this isn't actually a change, just a slight refactoring -- the Mozilla and Safari implementations have always worked this way). Also see this document for some more detail: http://code.google.com/p/google-web-toolkit/wiki/IE8Support Please review this at http://gwt-code-reviews.appspot.com/29803 Affected files: user/src/com/google/gwt/dom/DOM.gwt.xml user/src/com/google/gwt/dom/client/DOMImplIE6.java user/src/com/google/gwt/dom/client/DOMImplIE8.java user/src/com/google/gwt/dom/client/DOMImplTrident.java user/src/com/google/gwt/user/ClippedImage.gwt.xml user/src/com/google/gwt/user/DOM.gwt.xml user/src/com/google/gwt/user/Focus.gwt.xml user/src/com/google/gwt/user/Form.gwt.xml user/src/com/google/gwt/user/History.gwt.xml user/src/com/google/gwt/user/Hyperlink.gwt.xml user/src/com/google/gwt/user/Popup.gwt.xml user/src/com/google/gwt/user/RichText.gwt.xml user/src/com/google/gwt/user/SplitPanel.gwt.xml user/src/com/google/gwt/user/TextBox.gwt.xml user/src/com/google/gwt/user/Tree.gwt.xml user/src/com/google/gwt/user/UserAgent.gwt.xml user/src/com/google/gwt/user/Window.gwt.xml user/src/com/google/gwt/user/client/impl/DOMImplIE6.java user/src/com/google/gwt/user/client/impl/DOMImplIE8.java user/src/com/google/gwt/user/client/impl/DOMImplTrident.java user/src/com/google/gwt/user/client/impl/HistoryImpl.java user/src/com/google/gwt/user/client/impl/HistoryImplFrame.java user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java user/src/com/google/gwt/user/client/impl/HistoryImplMozilla.java user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java user/src/com/google/gwt/user/client/impl/HistoryImplStandard.java user/src/com/google/gwt/user/client/impl/HistoryImplTimer.java user/src/com/google/gwt/xml/XML.gwt.xml user/super/com/google/gwt/emul/EmulationWithUserAgent.gwt.xml --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Patch to add getElementsByClassName support
I signed the CLA. Should be OK for now since I haven't started my job yet.
I'm getting a HTTP SERVER 500 error creating the issue. I've tried both
upload.py the web interface.
On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber j...@google.com wrote:
Vitali,
Thanks for taking this on. I've been meaning to do it for ages, but haven't
had time. I haven't had a chance to look over the patch in detail yet, but
the general approach sounds good.
To answer your earlier question about DOMImplMozilla[Old], the old one
(not the best name, I know) maps to the user-agent gecko, which is the
fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, and
is also used to support later versions (e.g., Firefox 3 is Gecko 1.9). Older
versions of Gecko don't exist in any browser you're likely to encounter in
the wild, but is used by the hosted-mode browser on Linux. As soon as we
move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be
able to ditch support for old Geckos (yay!).
A couple of procedural things:
- Have you had a chance to sign a CLA yet? It's just a minor procedural
thing, but necessary.
(http://code.google.com/webtoolkit/makinggwtbetter.html#committers)
- Could I get you to create an issue to track this?
- Also, if you could upload this patch to
http://gwt-code-reviews.appspot.com/ it would make it easier for everyone
to view and discuss.
(Make sure to add google-web-toolkit-contributors@googlegroups.com to
the CC list)
Thanks again,
joel.
On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich vlov...@gmail.com wrote:
Oops - missed some compile errors in the JSNI code. This is meant to be
applied over top of the previous patches. I've verified that if
getElementsByClassName is not used then no code related to it appears in the
output (compiled the GWT samples grepped for getElementsByClassName).
I still need to test whether or not the implementations work write unit
tests.
Just for easy reference for myself, [].slice.call(nodeList, 0); is the
code to convert a nodelist into an array.
On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich vlov...@gmail.com wrote:
Here's my second attempt at the patch (2 of 2 is just a documentation
adjustment).
One caveat I forgot to mention is that there is slightly different
cross-platform behaviour right now. The native implementations return
NodeLists which are live whereas the Javascript implementations simply
return arrays.
The question is should I change it so that a JsArray is always returned
(i.e. copy the node list into an array) so that semantics are constant
across browsers or leave as is for performance with maybe a caveat that the
user should be careful when using with FF3, Safari 3.1 or Opera 9.5 copy
into an array if they need array semantics?
Changes from first patch:
getElementsByClassName should now display the HTML5 behaviour in quirks
mode if the browser supports the native implementation or doesn't provide
XPath (IE or really really old versions of FF, Safari friends). I'm not
sure how to get case insensitive string matching with XPath (so quirks mode
won't work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or
earlier). Is it even possible to do, or should I just fall back to using
the DOM implementation in quirks mode make a note that performance could
be improved drastically if quirks mode is turned off on browsers that
support XPath? Or just leave as is - it'll certainly have the same
behaviour as all the other JS libraries out there.
Only DOMImpl, DOMImplStandard, DOMImplSafari now require code changes.
DOMImpl: contains a native implementation using DOM. By default this
gets called.
DOMImplStandard now defines getElementsByXPath. The fastest approach is
assigned* to getElementsByClassName in the Element prototype document.
overrides getElementsByClassName
DOMImplSafari: getElementsByXPath calls the native one supplied by
Safari. I'm assuming that document._getElementsByXPath document.evaluate
came in with the same version of Safari (the one that implemented
XPath). If that's not the case, then I'll have to rework the code a bit.
Document: added isBackCompat(). Could use !isCSS1Compat() for now, but
this ensures no code change required if other compat modes are added in the
future ('cause !quirks is all we care about).
*I'm assuming that the way I wrote it ensures that if the developer
doesn't use getElementsByClassName, then there's 0-cost: the function is
never registered because the GWT compiler will recognize the dead code.
If it is used, then there's only the overhead of performing the
implementation selection once on startup.
Thank you,
Vitali
On 4/18/09, Vitali Lovich vlov...@gmail.com wrote:
Also, what's the difference between DOMImplMozilla DOMImplMozillaOld
in terms of Firefox versions?
And what versions of each browser are supported? Are all versions of
Safari, FF, Opera supported
[gwt-contrib] Re: Patch to add getElementsByClassName support
gwt-code-reviews
On Mon, Apr 20, 2009 at 12:04 PM, Ray Ryan rj...@google.com wrote:
Joel, you created an issue for this last month:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3441
Vitali, was the 500 you mentioned from the issue tracker or from
gwt-code-reviews?
rjrjr
On Mon, Apr 20, 2009 at 8:36 AM, Vitali Lovich vlov...@gmail.com wrote:
I signed the CLA. Should be OK for now since I haven't started my job
yet.
I'm getting a HTTP SERVER 500 error creating the issue. I've tried both
upload.py the web interface.
On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber j...@google.com wrote:
Vitali,
Thanks for taking this on. I've been meaning to do it for ages, but
haven't had time. I haven't had a chance to look over the patch in detail
yet, but the general approach sounds good.
To answer your earlier question about DOMImplMozilla[Old], the old one
(not the best name, I know) maps to the user-agent gecko, which is the
fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, and
is also used to support later versions (e.g., Firefox 3 is Gecko 1.9). Older
versions of Gecko don't exist in any browser you're likely to encounter in
the wild, but is used by the hosted-mode browser on Linux. As soon as we
move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be
able to ditch support for old Geckos (yay!).
A couple of procedural things:
- Have you had a chance to sign a CLA yet? It's just a minor procedural
thing, but necessary.
(http://code.google.com/webtoolkit/makinggwtbetter.html#committers)
- Could I get you to create an issue to track this?
- Also, if you could upload this patch to
http://gwt-code-reviews.appspot.com/ it would make it easier for
everyone to view and discuss.
(Make sure to add google-web-toolkit-contributors@googlegroups.com to
the CC list)
Thanks again,
joel.
On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich vlov...@gmail.comwrote:
Oops - missed some compile errors in the JSNI code. This is meant to be
applied over top of the previous patches. I've verified that if
getElementsByClassName is not used then no code related to it appears in
the
output (compiled the GWT samples grepped for getElementsByClassName).
I still need to test whether or not the implementations work write
unit tests.
Just for easy reference for myself, [].slice.call(nodeList, 0); is the
code to convert a nodelist into an array.
On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich vlov...@gmail.comwrote:
Here's my second attempt at the patch (2 of 2 is just a documentation
adjustment).
One caveat I forgot to mention is that there is slightly different
cross-platform behaviour right now. The native implementations return
NodeLists which are live whereas the Javascript implementations simply
return arrays.
The question is should I change it so that a JsArray is always returned
(i.e. copy the node list into an array) so that semantics are constant
across browsers or leave as is for performance with maybe a caveat that
the
user should be careful when using with FF3, Safari 3.1 or Opera 9.5 copy
into an array if they need array semantics?
Changes from first patch:
getElementsByClassName should now display the HTML5 behaviour in quirks
mode if the browser supports the native implementation or doesn't provide
XPath (IE or really really old versions of FF, Safari friends). I'm not
sure how to get case insensitive string matching with XPath (so quirks
mode
won't work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or
earlier). Is it even possible to do, or should I just fall back to using
the DOM implementation in quirks mode make a note that performance could
be improved drastically if quirks mode is turned off on browsers that
support XPath? Or just leave as is - it'll certainly have the same
behaviour as all the other JS libraries out there.
Only DOMImpl, DOMImplStandard, DOMImplSafari now require code
changes.
DOMImpl: contains a native implementation using DOM. By default this
gets called.
DOMImplStandard now defines getElementsByXPath. The fastest approach
is assigned* to getElementsByClassName in the Element prototype
document.
overrides getElementsByClassName
DOMImplSafari: getElementsByXPath calls the native one supplied by
Safari. I'm assuming that document._getElementsByXPath
document.evaluate
came in with the same version of Safari (the one that implemented
XPath). If that's not the case, then I'll have to rework the code a bit.
Document: added isBackCompat(). Could use !isCSS1Compat() for now,
but this ensures no code change required if other compat modes are added
in
the future ('cause !quirks is all we care about).
*I'm assuming that the way I wrote it ensures that if the developer
doesn't use getElementsByClassName, then there's 0-cost: the function is
never registered because the GWT compiler will recognize the dead code
[gwt-contrib] Re: Patch to add getElementsByClassName support
Oh I missed the open issue. Please mark 3582 a duplicate.
On Mon, Apr 20, 2009 at 12:18 PM, Vitali Lovich vlov...@gmail.com wrote:
gwt-code-reviews
On Mon, Apr 20, 2009 at 12:04 PM, Ray Ryan rj...@google.com wrote:
Joel, you created an issue for this last month:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3441
Vitali, was the 500 you mentioned from the issue tracker or from
gwt-code-reviews?
rjrjr
On Mon, Apr 20, 2009 at 8:36 AM, Vitali Lovich vlov...@gmail.com wrote:
I signed the CLA. Should be OK for now since I haven't started my job
yet.
I'm getting a HTTP SERVER 500 error creating the issue. I've tried both
upload.py the web interface.
On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber j...@google.com wrote:
Vitali,
Thanks for taking this on. I've been meaning to do it for ages, but
haven't had time. I haven't had a chance to look over the patch in detail
yet, but the general approach sounds good.
To answer your earlier question about DOMImplMozilla[Old], the old one
(not the best name, I know) maps to the user-agent gecko, which is the
fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, and
is also used to support later versions (e.g., Firefox 3 is Gecko 1.9).
Older
versions of Gecko don't exist in any browser you're likely to encounter in
the wild, but is used by the hosted-mode browser on Linux. As soon as we
move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be
able to ditch support for old Geckos (yay!).
A couple of procedural things:
- Have you had a chance to sign a CLA yet? It's just a minor procedural
thing, but necessary.
(http://code.google.com/webtoolkit/makinggwtbetter.html#committers)
- Could I get you to create an issue to track this?
- Also, if you could upload this patch to
http://gwt-code-reviews.appspot.com/ it would make it easier for
everyone to view and discuss.
(Make sure to add google-web-toolkit-contributors@googlegroups.com to
the CC list)
Thanks again,
joel.
On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich vlov...@gmail.comwrote:
Oops - missed some compile errors in the JSNI code. This is meant to
be applied over top of the previous patches. I've verified that if
getElementsByClassName is not used then no code related to it appears in
the
output (compiled the GWT samples grepped for getElementsByClassName).
I still need to test whether or not the implementations work write
unit tests.
Just for easy reference for myself, [].slice.call(nodeList, 0); is the
code to convert a nodelist into an array.
On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich vlov...@gmail.comwrote:
Here's my second attempt at the patch (2 of 2 is just a documentation
adjustment).
One caveat I forgot to mention is that there is slightly different
cross-platform behaviour right now. The native implementations return
NodeLists which are live whereas the Javascript implementations simply
return arrays.
The question is should I change it so that a JsArray is always
returned (i.e. copy the node list into an array) so that semantics are
constant across browsers or leave as is for performance with maybe a
caveat
that the user should be careful when using with FF3, Safari 3.1 or Opera
9.5
copy into an array if they need array semantics?
Changes from first patch:
getElementsByClassName should now display the HTML5 behaviour in
quirks mode if the browser supports the native implementation or doesn't
provide XPath (IE or really really old versions of FF, Safari friends).
I'm not sure how to get case insensitive string matching with XPath (so
quirks mode won't work according to the HTML5 spec in FF2, Safari 3,
Opera
9.4 or earlier). Is it even possible to do, or should I just fall back
to
using the DOM implementation in quirks mode make a note that
performance
could be improved drastically if quirks mode is turned off on browsers
that
support XPath? Or just leave as is - it'll certainly have the same
behaviour as all the other JS libraries out there.
Only DOMImpl, DOMImplStandard, DOMImplSafari now require code
changes.
DOMImpl: contains a native implementation using DOM. By default this
gets called.
DOMImplStandard now defines getElementsByXPath. The fastest approach
is assigned* to getElementsByClassName in the Element prototype
document.
overrides getElementsByClassName
DOMImplSafari: getElementsByXPath calls the native one supplied by
Safari. I'm assuming that document._getElementsByXPath
document.evaluate
came in with the same version of Safari (the one that implemented
XPath). If that's not the case, then I'll have to rework the code a bit.
Document: added isBackCompat(). Could use !isCSS1Compat() for now,
but this ensures no code change required if other compat modes are added
in
the future ('cause !quirks is all we care about).
*I'm assuming that the way I wrote it ensures that if the developer
doesn't
[gwt-contrib] Quirks mode by default?
Is there a compelling reason that the default HTML generated by the GWT project creator uses quirks mode instead of strict? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Patch to add getElementsByClassName support
I mentioned already I've uploaded http://codereview.appspot.com/44041/show On Mon, Apr 20, 2009 at 3:45 PM, Joel Webber j...@google.com wrote: I'll go ahead and start looking at it, but would you mind seeing if you can upload it to gwt-code-reviews.appspot.com? Makes it a bit easier to keep track of all gwt-related patches. Thanks, joel. On Mon, Apr 20, 2009 at 1:11 PM, Vitali Lovich vlov...@gmail.com wrote: Ok - got it to upload now. http://codereview.appspot.com/44041/show On Mon, Apr 20, 2009 at 12:19 PM, Vitali Lovich vlov...@gmail.comwrote: Oh I missed the open issue. Please mark 3582 a duplicate. On Mon, Apr 20, 2009 at 12:18 PM, Vitali Lovich vlov...@gmail.comwrote: gwt-code-reviews On Mon, Apr 20, 2009 at 12:04 PM, Ray Ryan rj...@google.com wrote: Joel, you created an issue for this last month: http://code.google.com/p/google-web-toolkit/issues/detail?id=3441 Vitali, was the 500 you mentioned from the issue tracker or from gwt-code-reviews? rjrjr On Mon, Apr 20, 2009 at 8:36 AM, Vitali Lovich vlov...@gmail.comwrote: I signed the CLA. Should be OK for now since I haven't started my job yet. I'm getting a HTTP SERVER 500 error creating the issue. I've tried both upload.py the web interface. On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber j...@google.com wrote: Vitali, Thanks for taking this on. I've been meaning to do it for ages, but haven't had time. I haven't had a chance to look over the patch in detail yet, but the general approach sounds good. To answer your earlier question about DOMImplMozilla[Old], the old one (not the best name, I know) maps to the user-agent gecko, which is the fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, and is also used to support later versions (e.g., Firefox 3 is Gecko 1.9). Older versions of Gecko don't exist in any browser you're likely to encounter in the wild, but is used by the hosted-mode browser on Linux. As soon as we move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be able to ditch support for old Geckos (yay!). A couple of procedural things: - Have you had a chance to sign a CLA yet? It's just a minor procedural thing, but necessary. (http://code.google.com/webtoolkit/makinggwtbetter.html#committers ) - Could I get you to create an issue to track this? - Also, if you could upload this patch to http://gwt-code-reviews.appspot.com/ it would make it easier for everyone to view and discuss. (Make sure to add google-web-toolkit-contribut...@googlegroups.comto the CC list) Thanks again, joel. On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich vlov...@gmail.comwrote: Oops - missed some compile errors in the JSNI code. This is meant to be applied over top of the previous patches. I've verified that if getElementsByClassName is not used then no code related to it appears in the output (compiled the GWT samples grepped for getElementsByClassName). I still need to test whether or not the implementations work write unit tests. Just for easy reference for myself, [].slice.call(nodeList, 0); is the code to convert a nodelist into an array. On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich vlov...@gmail.comwrote: Here's my second attempt at the patch (2 of 2 is just a documentation adjustment). One caveat I forgot to mention is that there is slightly different cross-platform behaviour right now. The native implementations return NodeLists which are live whereas the Javascript implementations simply return arrays. The question is should I change it so that a JsArray is always returned (i.e. copy the node list into an array) so that semantics are constant across browsers or leave as is for performance with maybe a caveat that the user should be careful when using with FF3, Safari 3.1 or Opera 9.5 copy into an array if they need array semantics? Changes from first patch: getElementsByClassName should now display the HTML5 behaviour in quirks mode if the browser supports the native implementation or doesn't provide XPath (IE or really really old versions of FF, Safari friends). I'm not sure how to get case insensitive string matching with XPath (so quirks mode won't work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or earlier). Is it even possible to do, or should I just fall back to using the DOM implementation in quirks mode make a note that performance could be improved drastically if quirks mode is turned off on browsers that support XPath? Or just leave as is - it'll certainly have the same behaviour as all the other JS libraries out there. Only DOMImpl, DOMImplStandard, DOMImplSafari now require code changes. DOMImpl: contains a native implementation using DOM. By default this gets called. DOMImplStandard now defines getElementsByXPath. The fastest approach is assigned* to getElementsByClassName in the Element prototype document. overrides
[gwt-contrib] Re: Patch to add getElementsByClassName support
Here's my second attempt at the patch (2 of 2 is just a documentation
adjustment).
One caveat I forgot to mention is that there is slightly different
cross-platform behaviour right now. The native implementations return
NodeLists which are live whereas the Javascript implementations simply
return arrays.
The question is should I change it so that a JsArray is always returned
(i.e. copy the node list into an array) so that semantics are constant
across browsers or leave as is for performance with maybe a caveat that the
user should be careful when using with FF3, Safari 3.1 or Opera 9.5 copy
into an array if they need array semantics?
Changes from first patch:
getElementsByClassName should now display the HTML5 behaviour in quirks mode
if the browser supports the native implementation or doesn't provide XPath
(IE or really really old versions of FF, Safari friends). I'm not sure
how to get case insensitive string matching with XPath (so quirks mode won't
work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or earlier).
Is it even possible to do, or should I just fall back to using the DOM
implementation in quirks mode make a note that performance could be
improved drastically if quirks mode is turned off on browsers that support
XPath? Or just leave as is - it'll certainly have the same behaviour as all
the other JS libraries out there.
Only DOMImpl, DOMImplStandard, DOMImplSafari now require code changes.
DOMImpl: contains a native implementation using DOM. By default this gets
called.
DOMImplStandard now defines getElementsByXPath. The fastest approach is
assigned* to getElementsByClassName in the Element prototype document.
overrides getElementsByClassName
DOMImplSafari: getElementsByXPath calls the native one supplied by
Safari. I'm assuming that document._getElementsByXPath document.evaluate
came in with the same version of Safari (the one that implemented
XPath). If that's not the case, then I'll have to rework the code a bit.
Document: added isBackCompat(). Could use !isCSS1Compat() for now, but this
ensures no code change required if other compat modes are added in the
future ('cause !quirks is all we care about).
*I'm assuming that the way I wrote it ensures that if the developer doesn't
use getElementsByClassName, then there's 0-cost: the function is never
registered because the GWT compiler will recognize the dead code.
If it is used, then there's only the overhead of performing the
implementation selection once on startup.
Thank you,
Vitali
On 4/18/09, Vitali Lovich vlov...@gmail.com wrote:
Also, what's the difference between DOMImplMozilla DOMImplMozillaOld
in terms of Firefox versions?
And what versions of each browser are supported? Are all versions of
Safari, FF, Opera supported as much as possible? Is there a minimum
version for any of them?
On Sat, Apr 18, 2009 at 4:05 AM, Vitali Lovich vlov...@gmail.com wrote:
If I put the check in a static block, then the check is only done once
on startup, right? Is this acceptable, or is it frowned upon because
it adds a slight penalty to the startup even if the developer never
uses the function.
Something like,
static {
ensureGetElementsByClassNameRegistered();
}
private static native void ensureGetElementsByClassNameRegistered() {
if (!document.getElementsByClassName) {
document.getElementsByClassName = function(element, class) {
// etc
}
}
}
On Sat, Apr 18, 2009 at 3:54 AM, Ray Cromwell cromwell...@gmail.com
wrote:
You don't want to create a separate property just for native
getElementsByClassName() as that would almost double the number of
permutations (except IE where is it known not to exist) What you
could provide is 3 implementations. IE gets raw DOM version,
Safari/Firefox/Opera get a version that checks
if(document.getElementsByClassName) exists, and if not, falls back to
document.evaluate.
-Ray
On Fri, Apr 17, 2009 at 11:03 PM, Vitali Lovich vlov...@gmail.com
wrote:
Do you have any suggestions regarding how to do the proper deferred
binding for the various versions? Should I just put the typical JS
check that regular libraries use? (i.e. if
(!document.getElementsByClassName) { // provide fallback }. I
thought
the whole point of deferred binding was to get around that.
What is the list of officially supported browsers? In particular the
specific minimum version for each?
I guess I'm going to have to install a virtual machine for this
because Safari refuses to work in wine 1.0.19 - chrome is useable
although no HTTPS sites.
Is there a guide somewhere on writing integrating the tests into
GWT, or just look at existing ones in the source.
On Sat, Apr 18, 2009 at 1:49 AM, Miroslav Pokorny
miroslav.poko...@gmail.com wrote:
Provide some tests and make sure it works on all officially
supported
browsers
[gwt-contrib] Re: Patch to add getElementsByClassName support
Oops - missed some compile errors in the JSNI code. This is meant to be
applied over top of the previous patches. I've verified that if
getElementsByClassName is not used then no code related to it appears in the
output (compiled the GWT samples grepped for getElementsByClassName).
I still need to test whether or not the implementations work write unit
tests.
Just for easy reference for myself, [].slice.call(nodeList, 0); is the code
to convert a nodelist into an array.
On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich vlov...@gmail.com wrote:
Here's my second attempt at the patch (2 of 2 is just a documentation
adjustment).
One caveat I forgot to mention is that there is slightly different
cross-platform behaviour right now. The native implementations return
NodeLists which are live whereas the Javascript implementations simply
return arrays.
The question is should I change it so that a JsArray is always returned
(i.e. copy the node list into an array) so that semantics are constant
across browsers or leave as is for performance with maybe a caveat that the
user should be careful when using with FF3, Safari 3.1 or Opera 9.5 copy
into an array if they need array semantics?
Changes from first patch:
getElementsByClassName should now display the HTML5 behaviour in quirks
mode if the browser supports the native implementation or doesn't provide
XPath (IE or really really old versions of FF, Safari friends). I'm not
sure how to get case insensitive string matching with XPath (so quirks mode
won't work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or
earlier). Is it even possible to do, or should I just fall back to using
the DOM implementation in quirks mode make a note that performance could
be improved drastically if quirks mode is turned off on browsers that
support XPath? Or just leave as is - it'll certainly have the same
behaviour as all the other JS libraries out there.
Only DOMImpl, DOMImplStandard, DOMImplSafari now require code changes.
DOMImpl: contains a native implementation using DOM. By default this gets
called.
DOMImplStandard now defines getElementsByXPath. The fastest approach is
assigned* to getElementsByClassName in the Element prototype document.
overrides getElementsByClassName
DOMImplSafari: getElementsByXPath calls the native one supplied by
Safari. I'm assuming that document._getElementsByXPath document.evaluate
came in with the same version of Safari (the one that implemented
XPath). If that's not the case, then I'll have to rework the code a bit.
Document: added isBackCompat(). Could use !isCSS1Compat() for now, but
this ensures no code change required if other compat modes are added in the
future ('cause !quirks is all we care about).
*I'm assuming that the way I wrote it ensures that if the developer doesn't
use getElementsByClassName, then there's 0-cost: the function is never
registered because the GWT compiler will recognize the dead code.
If it is used, then there's only the overhead of performing the
implementation selection once on startup.
Thank you,
Vitali
On 4/18/09, Vitali Lovich vlov...@gmail.com wrote:
Also, what's the difference between DOMImplMozilla DOMImplMozillaOld
in terms of Firefox versions?
And what versions of each browser are supported? Are all versions of
Safari, FF, Opera supported as much as possible? Is there a minimum
version for any of them?
On Sat, Apr 18, 2009 at 4:05 AM, Vitali Lovich vlov...@gmail.com
wrote:
If I put the check in a static block, then the check is only done once
on startup, right? Is this acceptable, or is it frowned upon because
it adds a slight penalty to the startup even if the developer never
uses the function.
Something like,
static {
ensureGetElementsByClassNameRegistered();
}
private static native void ensureGetElementsByClassNameRegistered() {
if (!document.getElementsByClassName) {
document.getElementsByClassName = function(element, class) {
// etc
}
}
}
On Sat, Apr 18, 2009 at 3:54 AM, Ray Cromwell cromwell...@gmail.com
wrote:
You don't want to create a separate property just for native
getElementsByClassName() as that would almost double the number of
permutations (except IE where is it known not to exist) What you
could provide is 3 implementations. IE gets raw DOM version,
Safari/Firefox/Opera get a version that checks
if(document.getElementsByClassName) exists, and if not, falls back to
document.evaluate.
-Ray
On Fri, Apr 17, 2009 at 11:03 PM, Vitali Lovich vlov...@gmail.com
wrote:
Do you have any suggestions regarding how to do the proper deferred
binding for the various versions? Should I just put the typical JS
check that regular libraries use? (i.e. if
(!document.getElementsByClassName) { // provide fallback }. I
thought
[gwt-contrib] Re: RPC HashSet HashMap deserialization bug/limitation
Verified that that test case does indeed work using regular Java
serialization.
Main.java
---
import java.io.*;
public class Main
{
public static void main(String [] args) throws Exception
{
PipedOutputStream output = new PipedOutputStream();
PipedInputStream input = new PipedInputStream(output);
ObjectOutputStream objWriter = new ObjectOutputStream(output);
ObjectInputStream objReader = new ObjectInputStream(input);
objWriter.writeObject(Foo.getData());
Foo result = (Foo) objReader.readObject();
System.out.println(result);
}
}
On Sun, Apr 19, 2009 at 11:04 AM, Paul Robinson ukcue...@gmail.com wrote:
I've created an issue for this:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3577
The issue includes a complete code example demonstrating the problem
(written for GWT 1.6.4), together with a detailed explanation of what
happens during deserialization to cause the effect.
Paul
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Eclipse Plugin and OSX woes
You asked on your blog how to quote spaces in bash. $@. bash understands that automatically does the right thing. On Sun, Apr 19, 2009 at 11:50 PM, Matt Mastracci matt...@mastracci.comwrote: Jason, Thanks for the idea, it works well. I blogged the full instructions below and included the final Python script I used to wrap the Java executable. I've now managed to deploy an AppEngine project that uses a 1.6 JVM to run (and is compatible with 1.6-level-compiled JAR files) along with the supporting GWT code. http://grack.com/blog/2009/04/19/the-final-word-on-google-eclipse-plugin-osx-crashes/ 8 #!/usr/bin/env python import sys import os print sys.argv cmd = os.path.dirname(sys.argv[0]) + '/java_wrapped' args = ['', '-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/ DataTreeNode,forwardDeltaWith', '-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/ lookup/ParameterizedTypeBinding,init', '-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/ lookup/ParameterizedMethodBinding,init'] args.extend(sys.argv[1:]) print cmd print args print os.execv(cmd, args) 8 On 17-Apr-09, at 12:41 PM, Jason Parekh wrote: Hey Matt, Unfortunately, it's not currently possible to specify arguments to the JVM that runs the GWT compile. We're aware of the demand for this feature though, so expect it in a future release. As an absolute workaround, could you rename your java binary and create a shell script in its place that launches the real java binary with whichever args you want (prepended to the args given to the shell script)? jason On Fri, Apr 17, 2009 at 2:34 PM, Matt Mastracci matt...@mastracci.com wrote: I'm running into the same JVM crash under Eclipse that I was running into from Ant a few weeks ago ( http://grack.com/blog/2009/04/14/gwt-16-crashes-and-a-fix/ ) while trying to deploy a test AppEngine+GWT project. The output from the compiler is pretty much: Compiling module ... Invalid memory access of location rip=01160767 Any ideas where the Eclipse Plugin gets the JVM and the JVM arguments to run to GWT portion of the compile? I tried adding the JIT overrides to the workspace JRE default JVM properties, but those don't seem to get picked up. -XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/ DataTreeNode,forwardDeltaWith -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ ParameterizedTypeBinding,init -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ ParameterizedMethodBinding,init The only argument I can see in the process list is -Xmx512m. Thoughts/ideas? Thanks, Matt. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Patch to add getElementsByClassName support
Do you have any suggestions regarding how to do the proper deferred
binding for the various versions? Should I just put the typical JS
check that regular libraries use? (i.e. if
(!document.getElementsByClassName) { // provide fallback }. I thought
the whole point of deferred binding was to get around that.
What is the list of officially supported browsers? In particular the
specific minimum version for each?
I guess I'm going to have to install a virtual machine for this
because Safari refuses to work in wine 1.0.19 - chrome is useable
although no HTTPS sites.
Is there a guide somewhere on writing integrating the tests into
GWT, or just look at existing ones in the source.
On Sat, Apr 18, 2009 at 1:49 AM, Miroslav Pokorny
miroslav.poko...@gmail.com wrote:
Provide some tests and make sure it works on all officially supported
browsers even if the implementation is suboptimal. There are many js
libs out there so it's not hard to find the best way to do it fir the
various browsers...
On 18/04/2009, at 12:39 PM, Vitali Lovich vlov...@gmail.com wrote:
Just my first attempt at adding some initial support for
getElementsByClassName. This is by no means tested or
Newer browsers support getElementsByClassName. This is my attempt
at a patch.
Caveats:
There's a bug in that quirks mode doesn't behave properly (I don't
know how to detect it in the deferred binding) for IE Firefox2
earlier. According to the HTML5 spec, it's supposed to be case
insensitive in quirks mode. However, this bug behaves the exact
same way as all the javascript wrappers do (since I based the XPath
RegExp code paths roughly around the implementations floating out
there).
I'm also not sure if I added the support correctly for Firefox.
getElementsByClassName only came in with FF3 requires the xpath
workaround for FF2 earlier (I believe I read xpath was introduced
with FF 1.5). I placed the xpath code in DOMImplMozillaOld for now
(not sure whether or not gecko1_8 represents FF2).
There's also no mention of the versions of Safari Opera that are
supported by GWT, so they're defaulting to using the native version
(which will not work if they don't provide it).
Safari in particular got it with version 3.1. if earlier versions are
supported, it's not too much work. Simply grab the expression built
in the FF xpath pass it to document._getElementsByXPath(query,
parent) for Safari versions that have xpath (not sure which those
are). Not sure how to distinguish Safari pre3.1 post3.1 in deferred
binding.
Opera got it with 9.5. Not sure when xPath support got into Opera
(should be a straightfoward copy of the mozilla code). Not sure how
to distinguish the two in the deferred binding.
Feedback would be appreciated.
Should this go as an enhancement request in the issue tracker?
diff --git a/user/src/com/google/gwt/dom/client/DOMImpl.java b/user/
src/com/google/gwt/dom/client/DOMImpl.java index 1d7e39b..581764b
100644 --- a/user/src/com/google/gwt/dom/client/DOMImpl.java +++ b/
user/src/com/google/gwt/dom/client/DOMImpl.java @@ -176,6 +176,8 @@
abstract class DOMImpl { return 0; }-*/; + public abstract NodeList
getElementsByClassName(Element parent, String className); + public
native Element getFirstChildElement(Element elem) /*-{ var child =
elem.firstChild; while (child child.nodeType != 1) diff --git a/
user/src/com/google/gwt/dom/client/DOMImplIE6.java b/user/src/com/
google/gwt/dom/client/DOMImplIE6.java index 04c205a..8c24a6c 100644
--- a/user/src/com/google/gwt/dom/client/DOMImplIE6.java +++ b/user/
src/com/google/gwt/dom/client/DOMImplIE6.java @@ -15,6 +15,8 @@ */
package com.google.gwt.dom.client; +import
com.google.gwt.core.client.JsArray; + /** * Internet Explorer 6
implementation of * {...@link com.google.gwt.user.client.impl.DOMImpl}.
@@ -184,6 +186,31 @@ class DOMImplIE6 extends DOMImpl { } @Override
+ public NodeList getElementsByClassName(Element parent, String
className) { + // TODO: detect quirks mode so that the regexps do a
case insensitive match as per the + // spec. when quirks mode
detected, pass i as the flags parameter + return
getElementsByClassName(parent, className.split( ), ).cast(); + }
+ + private native JsArray getElementsByClassName(Element parent,
String [] classes, String flags) /*-{ + var i, j, e, c, elements =
parent.all || parent.getElementsByTagName(*); + var regexps = [],
result = []; + for (i = classes.length - 1; i = 0; i--) { + c =
classes[i].replace(/^\s+|\s+$/g, ); + if (c.length) +
regexps.push(new RegExp(new Array((?:^|\\s), c, (?:\\s|
$)).join(), flags); + } + if (regexps.length) { + for (i = 0, c =
elements.length; i c; i++) { + e = elements[i]; + for (j =
regexps.length - 1; j = 0 regexps[j].test(e); j--) {} + j == -1
result.push(e); + } + } + return result; + }-*/; + + @Override
public native String getInnerText(Element elem) /*-{ return
elem.innerText; }-*/; diff --git a/user/src/com/google/gwt
[gwt-contrib] Re: Patch to add getElementsByClassName support
If I put the check in a static block, then the check is only done once
on startup, right? Is this acceptable, or is it frowned upon because
it adds a slight penalty to the startup even if the developer never
uses the function.
Something like,
static {
ensureGetElementsByClassNameRegistered();
}
private static native void ensureGetElementsByClassNameRegistered() {
if (!document.getElementsByClassName) {
document.getElementsByClassName = function(element, class) {
// etc
}
}
}
On Sat, Apr 18, 2009 at 3:54 AM, Ray Cromwell cromwell...@gmail.com wrote:
You don't want to create a separate property just for native
getElementsByClassName() as that would almost double the number of
permutations (except IE where is it known not to exist) What you
could provide is 3 implementations. IE gets raw DOM version,
Safari/Firefox/Opera get a version that checks
if(document.getElementsByClassName) exists, and if not, falls back to
document.evaluate.
-Ray
On Fri, Apr 17, 2009 at 11:03 PM, Vitali Lovich vlov...@gmail.com wrote:
Do you have any suggestions regarding how to do the proper deferred
binding for the various versions? Should I just put the typical JS
check that regular libraries use? (i.e. if
(!document.getElementsByClassName) { // provide fallback }. I thought
the whole point of deferred binding was to get around that.
What is the list of officially supported browsers? In particular the
specific minimum version for each?
I guess I'm going to have to install a virtual machine for this
because Safari refuses to work in wine 1.0.19 - chrome is useable
although no HTTPS sites.
Is there a guide somewhere on writing integrating the tests into
GWT, or just look at existing ones in the source.
On Sat, Apr 18, 2009 at 1:49 AM, Miroslav Pokorny
miroslav.poko...@gmail.com wrote:
Provide some tests and make sure it works on all officially supported
browsers even if the implementation is suboptimal. There are many js
libs out there so it's not hard to find the best way to do it fir the
various browsers...
On 18/04/2009, at 12:39 PM, Vitali Lovich vlov...@gmail.com wrote:
Just my first attempt at adding some initial support for
getElementsByClassName. This is by no means tested or
Newer browsers support getElementsByClassName. This is my attempt
at a patch.
Caveats:
There's a bug in that quirks mode doesn't behave properly (I don't
know how to detect it in the deferred binding) for IE Firefox2
earlier. According to the HTML5 spec, it's supposed to be case
insensitive in quirks mode. However, this bug behaves the exact
same way as all the javascript wrappers do (since I based the XPath
RegExp code paths roughly around the implementations floating out
there).
I'm also not sure if I added the support correctly for Firefox.
getElementsByClassName only came in with FF3 requires the xpath
workaround for FF2 earlier (I believe I read xpath was introduced
with FF 1.5). I placed the xpath code in DOMImplMozillaOld for now
(not sure whether or not gecko1_8 represents FF2).
There's also no mention of the versions of Safari Opera that are
supported by GWT, so they're defaulting to using the native version
(which will not work if they don't provide it).
Safari in particular got it with version 3.1. if earlier versions are
supported, it's not too much work. Simply grab the expression built
in the FF xpath pass it to document._getElementsByXPath(query,
parent) for Safari versions that have xpath (not sure which those
are). Not sure how to distinguish Safari pre3.1 post3.1 in deferred
binding.
Opera got it with 9.5. Not sure when xPath support got into Opera
(should be a straightfoward copy of the mozilla code). Not sure how
to distinguish the two in the deferred binding.
Feedback would be appreciated.
Should this go as an enhancement request in the issue tracker?
diff --git a/user/src/com/google/gwt/dom/client/DOMImpl.java b/user/
src/com/google/gwt/dom/client/DOMImpl.java index 1d7e39b..581764b
100644 --- a/user/src/com/google/gwt/dom/client/DOMImpl.java +++ b/
user/src/com/google/gwt/dom/client/DOMImpl.java @@ -176,6 +176,8 @@
abstract class DOMImpl { return 0; }-*/; + public abstract NodeList
getElementsByClassName(Element parent, String className); + public
native Element getFirstChildElement(Element elem) /*-{ var child =
elem.firstChild; while (child child.nodeType != 1) diff --git a/
user/src/com/google/gwt/dom/client/DOMImplIE6.java b/user/src/com/
google/gwt/dom/client/DOMImplIE6.java index 04c205a..8c24a6c 100644
--- a/user/src/com/google/gwt/dom/client/DOMImplIE6.java +++ b/user/
src/com/google/gwt/dom/client/DOMImplIE6.java @@ -15,6 +15,8 @@ */
package com.google.gwt.dom.client; +import
com.google.gwt.core.client.JsArray; + /** * Internet Explorer 6
implementation of * {...@link com.google.gwt.user.client.impl.DOMImpl}.
@@ -184,6 +186,31 @@ class DOMImplIE6 extends
[gwt-contrib] Re: Patch to add getElementsByClassName support
Also, what's the difference between DOMImplMozilla DOMImplMozillaOld
in terms of Firefox versions?
And what versions of each browser are supported? Are all versions of
Safari, FF, Opera supported as much as possible? Is there a minimum
version for any of them?
On Sat, Apr 18, 2009 at 4:05 AM, Vitali Lovich vlov...@gmail.com wrote:
If I put the check in a static block, then the check is only done once
on startup, right? Is this acceptable, or is it frowned upon because
it adds a slight penalty to the startup even if the developer never
uses the function.
Something like,
static {
ensureGetElementsByClassNameRegistered();
}
private static native void ensureGetElementsByClassNameRegistered() {
if (!document.getElementsByClassName) {
document.getElementsByClassName = function(element, class) {
// etc
}
}
}
On Sat, Apr 18, 2009 at 3:54 AM, Ray Cromwell cromwell...@gmail.com wrote:
You don't want to create a separate property just for native
getElementsByClassName() as that would almost double the number of
permutations (except IE where is it known not to exist) What you
could provide is 3 implementations. IE gets raw DOM version,
Safari/Firefox/Opera get a version that checks
if(document.getElementsByClassName) exists, and if not, falls back to
document.evaluate.
-Ray
On Fri, Apr 17, 2009 at 11:03 PM, Vitali Lovich vlov...@gmail.com wrote:
Do you have any suggestions regarding how to do the proper deferred
binding for the various versions? Should I just put the typical JS
check that regular libraries use? (i.e. if
(!document.getElementsByClassName) { // provide fallback }. I thought
the whole point of deferred binding was to get around that.
What is the list of officially supported browsers? In particular the
specific minimum version for each?
I guess I'm going to have to install a virtual machine for this
because Safari refuses to work in wine 1.0.19 - chrome is useable
although no HTTPS sites.
Is there a guide somewhere on writing integrating the tests into
GWT, or just look at existing ones in the source.
On Sat, Apr 18, 2009 at 1:49 AM, Miroslav Pokorny
miroslav.poko...@gmail.com wrote:
Provide some tests and make sure it works on all officially supported
browsers even if the implementation is suboptimal. There are many js
libs out there so it's not hard to find the best way to do it fir the
various browsers...
On 18/04/2009, at 12:39 PM, Vitali Lovich vlov...@gmail.com wrote:
Just my first attempt at adding some initial support for
getElementsByClassName. This is by no means tested or
Newer browsers support getElementsByClassName. This is my attempt
at a patch.
Caveats:
There's a bug in that quirks mode doesn't behave properly (I don't
know how to detect it in the deferred binding) for IE Firefox2
earlier. According to the HTML5 spec, it's supposed to be case
insensitive in quirks mode. However, this bug behaves the exact
same way as all the javascript wrappers do (since I based the XPath
RegExp code paths roughly around the implementations floating out
there).
I'm also not sure if I added the support correctly for Firefox.
getElementsByClassName only came in with FF3 requires the xpath
workaround for FF2 earlier (I believe I read xpath was introduced
with FF 1.5). I placed the xpath code in DOMImplMozillaOld for now
(not sure whether or not gecko1_8 represents FF2).
There's also no mention of the versions of Safari Opera that are
supported by GWT, so they're defaulting to using the native version
(which will not work if they don't provide it).
Safari in particular got it with version 3.1. if earlier versions are
supported, it's not too much work. Simply grab the expression built
in the FF xpath pass it to document._getElementsByXPath(query,
parent) for Safari versions that have xpath (not sure which those
are). Not sure how to distinguish Safari pre3.1 post3.1 in deferred
binding.
Opera got it with 9.5. Not sure when xPath support got into Opera
(should be a straightfoward copy of the mozilla code). Not sure how
to distinguish the two in the deferred binding.
Feedback would be appreciated.
Should this go as an enhancement request in the issue tracker?
diff --git a/user/src/com/google/gwt/dom/client/DOMImpl.java b/user/
src/com/google/gwt/dom/client/DOMImpl.java index 1d7e39b..581764b
100644 --- a/user/src/com/google/gwt/dom/client/DOMImpl.java +++ b/
user/src/com/google/gwt/dom/client/DOMImpl.java @@ -176,6 +176,8 @@
abstract class DOMImpl { return 0; }-*/; + public abstract NodeList
getElementsByClassName(Element parent, String className); + public
native Element getFirstChildElement(Element elem) /*-{ var child =
elem.firstChild; while (child child.nodeType != 1) diff --git a/
user/src/com/google/gwt/dom/client/DOMImplIE6.java b/user/src/com/
google/gwt/dom/client/DOMImplIE6.java index 04c205a..8c24a6c 100644
--- a/user/src/com
[gwt-contrib] Add getElementsByTagName to DOM class patch
getElementsByTagName missing from DOM class.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
diff --git a/user/src/com/google/gwt/user/client/DOM.java b/user/src/com/google/gwt/user/client/DOM.java
index 03721b8..ddbac26 100644
--- a/user/src/com/google/gwt/user/client/DOM.java
+++ b/user/src/com/google/gwt/user/client/DOM.java
@@ -751,6 +751,17 @@ public class DOM {
}
/**
+ * Gets all the elements with the given tag name within the entire
+ * document.
+ *
+ * @param tagName the HTML tag name whose associated elements are to be retrieved
+ * @return the associated elements, or codenull/code if none is found
+ */
+ public static NodeListElement getElementsByTagName(String tagName) {
+return Document.get().getElementsByTagName(tagName).cast();
+ }
+
+ /**
* Gets any named property from an element, as a string.
*
* @param elem the element whose property is to be retrieved
[gwt-contrib] Re: Add getElementsByTagName to DOM class patch
Yes I did (since the DOM one just wraps the Document one). It seems like the DOM methods wrap the Document ones, so it was just surprising it wasn't there. On Fri, Apr 17, 2009 at 7:58 PM, Ray Cromwell cromwell...@gmail.com wrote: Did you look at the Document/Element classes? It's there. I think of the DOM classes as semi-deprecated, in that many of the methods are now subsumed by overlay types. -Ray On Fri, Apr 17, 2009 at 4:54 PM, Vitali Lovich vlov...@gmail.com wrote: getElementsByTagName missing from DOM class. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RootPanel.get(string) not working any more (latest build from SVN)
I think the issue is broader from my understanding. The way I interpret the thread is that if you wrap any DOM element with a GWT widget, you cannot wrap any child DOM elements with GWT widgets (you can have nested DOM elements, but you can only wrap 1 of those elements with a GWT widget). On a sidenote, couldn't the whole architecture be more light-weight by using the existing DOM tree instead of creating a parallel widget tree that contains the exact same structure? Or are there technical reasons that it was done this way? On Wed, Apr 15, 2009 at 3:44 AM, loongest loong...@gmail.com wrote: Hi all, I just move the project from 1.4 to 1.6. I'm facing the same problem as describe above. Does it mean that div tag must close and cannot contains other div tags ? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RootPanel.get(string) not working any more (latest build from SVN)
Well that changes the layout doesn't it. Depends what you want to do. If you just want to add styles using Javascript, then use the DOM class. If you actually want GWT widgets out of them, consider building the page using GWT to begin with rather than trying to wrap existing HTML into GWT widgets. On Wed, Apr 15, 2009 at 4:31 AM, chee loong loong...@gmail.com wrote: Hi, thanks for reply, For example this is the original layout, should it modified to become after change ? Before div id=header span class=lt/spanspan class=rt/span div id=slot1 div id=slot2/div div id=slot3/div /div /div After div id=header/div span class=lt/spanspan class=rt/span div id=slot1/ div id=slot2/ div id=slot3/ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment
Hey guys, Rhino http://www.mozilla.org/rhino/ (one of Mozilla's javascript engines) is written entirely in Java supports JS 1.7 if that helps. I'm sure there's a parser component in there that can be extracted if the license is compatible (MPL/GPL). There's also GromJS http://www.bauk.ws/gromjs.html (public domain I think). On the other hand these are probably overkill for your needs. On Tue, Apr 14, 2009 at 12:33 AM, Lex Spoon sp...@google.com wrote: On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin j...@google.com wrote: On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum sco...@google.com wrote: If we were playing Mao, I would give you a card penalty for stating the obvious. :-) But uh, reliably tracking whether or not you're in a string literal is about as much fun as writing a JavaScript parser. In fact, it might be *exactly* as fun, if you know what I mean. String literals have to be known at parse time, so it seems to me all you have to look for is start/stop quotes (of both sorts) while handling embedded ones of the wrong variety and escaped ones of the right variety. That looks like it can be handled with a single character lookahead scanner, and very little complexity -- what am I missing? It would be awesome if there were a simple lexer available for JavaScript. Given a token stream, brace counting would sound feasible. However, from what I hear it's pretty complicated even to tokenize JavaScript. I don't know exactly what is so hard, but last time I asked, regex literals came up. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] TOT (rev 5208) broken?
I'd just like to confirm that ToT is indeed broken right now. Same thing happens when I try to run in hosted mode. Getting [java] Loading module 'module name' [java][ERROR] Unexpected error while processing XML [java] java.lang.IncompatibleClassChangeError: Found interface com.google.gwt.dev.jjs.SourceInfo, but class was expected [java] at com.google.gwt.dev.js.ast.JsProgramFragment.init(JsProgramFragment.java:28) [java] at com.google.gwt.dev.js.ast.JsProgram.setFragmentCount(JsProgram.java:241) [java] at com.google.gwt.dev.js.ast.JsProgram.init(JsProgram.java:85) [java] at com.google.gwt.dev.js.ast.JsProgram.init(JsProgram.java:64) [java] at com.google.gwt.dev.cfg.ModuleDefSchema.init(ModuleDefSchema.java:964) [java] at com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:241) [java] at com.google.gwt.dev.cfg.ModuleDefLoader$1.load(ModuleDefLoader.java:155) [java] at com.google.gwt.dev.cfg.ModuleDefLoader.doLoadModule(ModuleDefLoader.java:272) [java] at com.google.gwt.dev.cfg.ModuleDefLoader.loadFromClassPath(ModuleDefLoader.java:127) [java] at com.google.gwt.dev.Compiler.run(Compiler.java:176) [java] at com.google.gwt.dev.Compiler$1.run(Compiler.java:144) [java] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84) [java] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78) [java] at com.google.gwt.dev.Compiler.main(Compiler.java:151) Thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: TOT (rev 5208) broken?
Thanks, that fixed it. Shouldn't you be on vacation :D? On Thu, Apr 9, 2009 at 9:44 PM, Scott Blum sco...@google.com wrote: Try an 'ant clean' On Thu, Apr 9, 2009 at 9:30 PM, Vitali Lovich vlov...@gmail.com wrote: I'd just like to confirm that ToT is indeed broken right now. Same thing happens when I try to run in hosted mode. Getting [java] Loading module 'module name' [java][ERROR] Unexpected error while processing XML [java] java.lang.IncompatibleClassChangeError: Found interface com.google.gwt.dev.jjs.SourceInfo, but class was expected [java] at com.google.gwt.dev.js.ast.JsProgramFragment.init(JsProgramFragment.java:28) [java] at com.google.gwt.dev.js.ast.JsProgram.setFragmentCount(JsProgram.java:241) [java] at com.google.gwt.dev.js.ast.JsProgram.init(JsProgram.java:85) [java] at com.google.gwt.dev.js.ast.JsProgram.init(JsProgram.java:64) [java] at com.google.gwt.dev.cfg.ModuleDefSchema.init(ModuleDefSchema.java:964) [java] at com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:241) [java] at com.google.gwt.dev.cfg.ModuleDefLoader$1.load(ModuleDefLoader.java:155) [java] at com.google.gwt.dev.cfg.ModuleDefLoader.doLoadModule(ModuleDefLoader.java:272) [java] at com.google.gwt.dev.cfg.ModuleDefLoader.loadFromClassPath(ModuleDefLoader.java:127) [java] at com.google.gwt.dev.Compiler.run(Compiler.java:176) [java] at com.google.gwt.dev.Compiler$1.run(Compiler.java:144) [java] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84) [java] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78) [java] at com.google.gwt.dev.Compiler.main(Compiler.java:151) Thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: new test which demonstrates the infinite recursion bug
On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin j...@google.com wrote:
The attached patch, relative to trunk r5191, adds a new tests which fails
only in web mode and only for the JsniSuper case. It appears the problem
isn't directly related to super, but rather with making calls to private
methods polymorphic rather than virtual dispatch. This is the bug I ran
into with the CurrencyListGenerator changes I committed and then had to roll
back.
Ie:
public class A {
public void foo() {}
}
public class B extends A {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
public class C extends B {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
B's foo will always call B's callSuper, even when this is actually a C.
We handle this properly for Java code, but not when foo is a JSNI method.
Woudn't this cause infinite recursion when this is actually a C using
virtual dispatch?
c.foo - c.callSuper - b.foo - c.callSuper - b.foo - c.callSuper etc.
If it's a polymorphic call, I believe the call graph looks like:
c.foo - c.callSuper - b.foo - b.callSuper - a.foo
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Feature request: Better compiler error message
[java]Scanning for additional dependencies: file:/home/vlovich/workspace/sacred_heart/src/ece456/client/services/ResourceFactory.java [java] Computing all possible rebind results for 'ece456.client.services.comm.rpc.StaffService' [java] Rebinding ece456.client.services.comm.rpc.StaffService [java] Invoking generate-with class='com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator'/ [java]Generating client proxy for remote service interface 'ece456.client.services.comm.rpc.StaffService' [java] Analyzing 'ece456.client.services.comm.rpc.StaffService' for serializable types [java] Analyzing methods: [java] public abstract void addVisit(ece456.client.services.comm.types.DBPatientVisit visit) throws ece456.client.services.comm.types.RPCError [java]Parameter: ece456.client.services.comm.types.DBPatientVisit visit [java] ece456.client.services.comm.types.DBPatientVisit [java] [ERROR] Type 'ece456.client.services.comm.types.DBPatientVisit' was not serializable and has no concrete serializable subtypes Took me a good amount of time before I remembered I had missed the default constructor. At the very least it should print the requirements for serializability - it would be nicer if it actually told you the specific problem it found though. Would that be possible? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM
Interesting - didn't think of that, but I believe I had it set to -server (not in the compilation of GWT, but when I ran the 32-bit hosted mode). I'm so swamped right now I have no time to do anything but this one project then I have the first of my final exams Wednesday, so I dunno when I'll get a chance to look at this. On Thu, Apr 2, 2009 at 5:57 PM, Ray Cromwell cromwell...@gmail.com wrote: Another quick workaround is try to switch the jitter (from -client to -server). In JDK6 and below, these are in fact, separate compilers. I had similar crashes with Java6 on OSX at one point and switching the HotSpot compiler fixed them. -Ray On Thu, Apr 2, 2009 at 11:16 AM, Scott Blum sco...@google.com wrote: This looks to me like a HotSpot problem.. the jitter is crashing trying to compile some JDT code. Current thread (0x08ab8800): JavaThread CompilerThread0 daemon [_thread_in_native, id=2484, stack(0xe037f000,0xe040)] Current CompileTask: C2:498 org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding.init(Lorg/eclipse/jdt/internal/compiler/lookup/ParameterizedTypeBinding;Lorg/eclipse/jdt/internal/compiler/lookup/MethodBinding;)V (596 bytes) So here's how you could try to come up with a workaround / file an issue against the JVM: - Grab our JDT 3.4.2 jar out of the GWT tools repository - Open it up and find the source for ParameterizedMethodBinding - Add this source file to your project (you'll need to put gwt-dev-windows on your path if it's not) You should now be able to run a compile and repro the crash. If you *can't* repro the crash anymore, it's possible your compiler is producing a slightly different .class file for that class than the class file we ship (which was built by the JDT guys). Assuming you can repro the crash, start commenting out lines of code in the offending constructor until it no longer crashes. Or start refactoring out pieces of the constructor into individual methods. By playing around, you can probably figure out what's killing it. On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich vlov...@gmail.com wrote: Ugggh... you want me to do all the work don't you :D On a separate note 5094 compilation is broken (JUnitShell fails to compile). In 5096 the problem is resolved. On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum sco...@google.com wrote: I can has hs_err_pid17105.log? On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich vlov...@gmail.comwrote: [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer [java] # [java] # An unexpected error has been detected by Java Runtime Environment: [java] # [java] # SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968 [java] # [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) [java] # Problematic frame: [java] # V [libjvm.so+0x25665c] [java] # [java] # An error report file with more information is saved as: [java] # /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log [java] # [java] # If you would like to submit a bug report, please visit: [java] # http://java.sun.com/webapps/bugreport/crash.jsp [java] # The crash happened outside the Java Virtual Machine in native code. [java] # See problematic frame for where to report the bug. [java] # This is kind of annoying because GWT fails to build with the newer JDKs due to the issue mentioned before with the change to generics. So it's a two step workaround: Use the older sun JDK to compile the classes after it crashes, use run ant again with the newer JDK so that the GWT compiler doesn't crash the VM. This also happens if I try to use the older JDK with my projects, but that's not really an issue since I just use the latest OpenJDK in the Ubuntu repos. Might be relevant that I'm using 64-bit jdks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Feature request: RPC automagically transferred values
Hi, I've encountered this pattern a few times, and think it would be great if the RPC layer could be given a serializable object that is always transferred on every RPC call. In the GWT security documentation it says not to use cookies but instead pass the session id manually on every RPC call, which is a real hassle to maintain results in a lot of boilerplate. Instead it would be nice if the GWT layer could do it automatically for me, and then RemoteServiceServlet would provide it through a call like getSessionData() (templated for convenience) which would de-serialize the object return it. Additionally, the server side could also set the data manually with setSessionData() then the user side would never even need to know about it. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:
I think the issue is something to do with me using incubator it instantiating the RemoteLoggingService even though I don't use it. It might be due to the way incubator initializes the logger (using java's Logger.getLogger() whereas I use log4j directly). On Fri, Mar 27, 2009 at 11:57 AM, Scott Blum sco...@google.com wrote: Okay, I think the issue might be your using trunk then. My patch jar was for 1.6, and the commit you're commenting on here (r5077 r5078) were to 1.6. So I would not expect that to be fixed in trunk. On Thu, Mar 26, 2009 at 9:50 PM, Vitali Lovich vlov...@gmail.com wrote: On Thu, Mar 26, 2009 at 3:17 PM, Scott Blum sco...@google.com wrote: Vitali, are you positive all your stuff is in a legit state? I ask because it looks like you're mixing trunk and 1.6 stuff together. Can you clarify what you mean? How can I be mixing trunk 1.6 together? I'm only using trunk. At this point I don't event have the gwt-platform directory in my project path - I just imported the GWT projects made put them on my classpath. When I use a stock gwt-dev-windows.jar from 1...@r5090, I'm using trunk (@ 5084 right now). I haven't even tried stock because I'm on linux 64-bit I haven't bothered trying to get the 32-bit environment set up for the old hosted mode (relying solely on OOPHM). I can boot your project just fine whether log4j-1.2.15.jar is in WEB-INF/lib or not. (I can run it because I couldn't actually find a version of mosaic that you compile against cleanly, but the servlets all initialized just fine.) Right - I forgot that the code I sent you at that point already had my enhancements to mosaic (eventually a version of them should get into truck). In any case, you can just delete the code that throws up an error (unless its the constructor). My code runs fine (including servlets) the logging works. It's just that error that gets printed to the console when the project launches, so it's not a super-important issue. Is it possible it's a Linux-only issue? Here's a dump of the exact dir structure that's working for me: .classpath .project gwt-windows-0.0.0 gwt-windows-0.0.0/gwt-dev-windows.jar gwt-windows-0.0.0/gwt-ll.dll gwt-windows-0.0.0/gwt-user.jar gwt-windows-0.0.0/swt-win32-3235.dll lib lib/ftr-gwt-library-date-0.9.9.jar lib/ftr-gwt-library-date-emul-0.9.9.jar lib/gwt-beans-binding-0.2.3.jar lib/gwt-dnd-2.5.6.jar lib/gwt-incubator-trunk-r1543.jar lib/gwt-mosaic-0.2.0-rc1.jar lib/gwtx-1.5.2.jar lib/log4j-1.2.15.jar lib/org.cobogw.gwt-1.2.2.jar SacredHeart.launch src (omitted) war war/loading.gif war/SacredHeart.css war/SacredHeart.html war/WEB-INF war/WEB-INF/classes (omitted) war/WEB-INF/classes/ece456 war/WEB-INF/classes/log4j.properties war/WEB-INF/lib war/WEB-INF/lib/gwt-servlet.jar war/WEB-INF/lib/log4j-1.2.15.jar war/WEB-INF/lib/mysql-connector-java-5.1.7-bin.jar war/WEB-INF/web.xml I attached the .project, .classpath, and launch config I'm using. This configuration boots whether or not I have war/WEB-INF/lib/log4j-1.2.15.jar in there. On Wed, Mar 25, 2009 at 7:32 PM, Vitali Lovich vlov...@gmail.comwrote: On Wed, Mar 25, 2009 at 7:10 PM, Scott Blum sco...@google.com wrote: On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich vlov...@gmail.comwrote: If I don't put the log4j file into my WEB-INF/lib directory, then it's fine. If it is put there, then it gets the conflicting version (regardless of whether or not I launch HostedMode with log4j on the class path). So am I doing it wrong? i'm confused... if you don't have log4j on the classpath, how can you be loading it via Launcher$AppClassLoader? It must be hiding out in some other jar you have on the classpath? Sorry for the confusion. Here's what I meant: If I add the log4j library in the WEB-INF/lib to the classpath of the runtime configuration, I get the problem above. If I move the log4j library out of the WEB-INF/lib directory to somewhere else like project/lib add it to the classpath, then it works. Am I supposed to place it elsewhere then copy it over to WEB-INF/lib when I'm packaging it up only? That's not the intent... can you send me a small sample that repros this? I don't have time right now. If you want I can e-mail you my project privately. It's a school project, so there's no confidentiality to it or anything. I just don't want to spam the mailing list. Thanks Scott --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Please fix eclipse project files for cross-platform development
Hi, Would it be possible to update the Eclipse classpath for gwt-user to be platform agnostic? Since Eclipse doesn't support variable project references, one way would be to move .classpath to .classpath-template provide scripts that instrument the .classpath file based on the environment (requires 1 extra step by the user prior to importing the project). Even smoother would be if this could be an ant task (something like ant eclipse-config), although I'm not sure what kind of support ant might have for regular expression replacement in files.. Not super important (especially with git), but just annoying that I need to maintain the project files even if I'm not working on Eclipse. And I understand if you want to keep it as less handle for Windows users. Thoughts? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Please fix eclipse project files for cross-platform development
Right - good point. Thanks On Tue, Mar 31, 2009 at 7:14 AM, Eric Ayers zun...@google.com wrote: This will be coming in GWT 2.0. Currently, each platform's hosted mode has platform specific code that is bundled into separate .jar files. In GWT 2.0, the hosted mode will change to not include a bundled browser or container for an embedded browser, but an IPC connection to a browser plugin of your choosing. This will allow the gwt-dev-oophm.jar file to be platform agnostic. On Tue, Mar 31, 2009 at 2:54 AM, Vitali Lovich vlov...@gmail.com wrote: Hi, Would it be possible to update the Eclipse classpath for gwt-user to be platform agnostic? Since Eclipse doesn't support variable project references, one way would be to move .classpath to .classpath-template provide scripts that instrument the .classpath file based on the environment (requires 1 extra step by the user prior to importing the project). Even smoother would be if this could be an ant task (something like ant eclipse-config), although I'm not sure what kind of support ant might have for regular expression replacement in files.. Not super important (especially with git), but just annoying that I need to maintain the project files even if I'm not working on Eclipse. And I understand if you want to keep it as less handle for Windows users. Thoughts? -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] JVM crashes when using GWT compiler under Java 6 update 7 JVM
[java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer [java] # [java] # An unexpected error has been detected by Java Runtime Environment: [java] # [java] # SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968 [java] # [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) [java] # Problematic frame: [java] # V [libjvm.so+0x25665c] [java] # [java] # An error report file with more information is saved as: [java] # /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log [java] # [java] # If you would like to submit a bug report, please visit: [java] # http://java.sun.com/webapps/bugreport/crash.jsp [java] # The crash happened outside the Java Virtual Machine in native code. [java] # See problematic frame for where to report the bug. [java] # This is kind of annoying because GWT fails to build with the newer JDKs due to the issue mentioned before with the change to generics. So it's a two step workaround: Use the older sun JDK to compile the classes after it crashes, use run ant again with the newer JDK so that the GWT compiler doesn't crash the VM. This also happens if I try to use the older JDK with my projects, but that's not really an issue since I just use the latest OpenJDK in the Ubuntu repos. Might be relevant that I'm using 64-bit jdks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] GWTC compiler disallows using a derivative of AsyncCallback on async interface declaration
I tried to use my own custom class that extends AsyncCallback in the async interface, the compiler told me that the async version didn't match the sync version. For instance: public interface NoResultCallback extends AsyncCallbackVoid. It's not really an issue, but I prefer to use the more precise type to get the compiler to statically check the code. Is this by design for a reason? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM
Ugggh... you want me to do all the work don't you :D On a separate note 5094 compilation is broken (JUnitShell fails to compile). In 5096 the problem is resolved. On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum sco...@google.com wrote: I can has hs_err_pid17105.log? On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich vlov...@gmail.com wrote: [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer [java] # [java] # An unexpected error has been detected by Java Runtime Environment: [java] # [java] # SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968 [java] # [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) [java] # Problematic frame: [java] # V [libjvm.so+0x25665c] [java] # [java] # An error report file with more information is saved as: [java] # /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log [java] # [java] # If you would like to submit a bug report, please visit: [java] # http://java.sun.com/webapps/bugreport/crash.jsp [java] # The crash happened outside the Java Virtual Machine in native code. [java] # See problematic frame for where to report the bug. [java] # This is kind of annoying because GWT fails to build with the newer JDKs due to the issue mentioned before with the change to generics. So it's a two step workaround: Use the older sun JDK to compile the classes after it crashes, use run ant again with the newer JDK so that the GWT compiler doesn't crash the VM. This also happens if I try to use the older JDK with my projects, but that's not really an issue since I just use the latest OpenJDK in the Ubuntu repos. Might be relevant that I'm using 64-bit jdks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- hs_err_pid2473.log Description: Binary data
[gwt-contrib] Re: GWTC compiler disallows using a derivative of AsyncCallback on async interface declaration
hmm... i looked and there appears to be a simple fix.
private static String computeInternalSignature(JMethod method) {
StringBuffer sb = new StringBuffer();
sb.setLength(0);
sb.append(method.getName());
JParameter[] params = method.getParameters();
int i = 0;
for (JParameter param : params) {
sb.append(/);
JType paramType = param.getType();
if (i++ == params.length - 1) {
paramType = getAsyncCallbackSignature(paramType);
}
sb.append(paramType.getErasedType().getQualifiedSourceName());
}
return sb.toString();
}
getAsyncCallbackSignature simply checks to see if there's a way to
cast the paramType to AsyncCallback. If there is, then it returns the
equivalent AsyncCallback JType. If there isn't, it returns the
original JType.
Haven't looked at the JType API to see how getAsyncCallbackSignature
would be written. I'll try to look at it Tuesday evening when I have
some time.
On Fri, Mar 27, 2009 at 2:10 PM, Scott Blum sco...@google.com wrote:
I'm sure it's unintentional. Here's where you would go to fix it:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/rebind/rpc/RemoteServiceAsyncValidator.java#185
On Fri, Mar 27, 2009 at 2:00 PM, Vitali Lovich vlov...@gmail.com wrote:
I tried to use my own custom class that extends AsyncCallback in the async
interface, the compiler told me that the async version didn't match the
sync version.
For instance: public interface NoResultCallback extends
AsyncCallbackVoid. It's not really an issue, but I prefer to use the more
precise type to get the compiler to statically check the code.
Is this by design for a reason?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM
You can also has the hs_err for the 32-bit vm On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich vlov...@gmail.com wrote: Ugggh... you want me to do all the work don't you :D On a separate note 5094 compilation is broken (JUnitShell fails to compile). In 5096 the problem is resolved. On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum sco...@google.com wrote: I can has hs_err_pid17105.log? On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich vlov...@gmail.com wrote: [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer [java] # [java] # An unexpected error has been detected by Java Runtime Environment: [java] # [java] # SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968 [java] # [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) [java] # Problematic frame: [java] # V [libjvm.so+0x25665c] [java] # [java] # An error report file with more information is saved as: [java] # /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log [java] # [java] # If you would like to submit a bug report, please visit: [java] # http://java.sun.com/webapps/bugreport/crash.jsp [java] # The crash happened outside the Java Virtual Machine in native code. [java] # See problematic frame for where to report the bug. [java] # This is kind of annoying because GWT fails to build with the newer JDKs due to the issue mentioned before with the change to generics. So it's a two step workaround: Use the older sun JDK to compile the classes after it crashes, use run ant again with the newer JDK so that the GWT compiler doesn't crash the VM. This also happens if I try to use the older JDK with my projects, but that's not really an issue since I just use the latest OpenJDK in the Ubuntu repos. Might be relevant that I'm using 64-bit jdks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- hs_err_pid13507.log Description: Binary data
[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM
Sorry - forgot to mention that this happened when I tried to load the hosted mode browser. On Fri, Mar 27, 2009 at 3:57 PM, Vitali Lovich vlov...@gmail.com wrote: Might be related. Just set up my project to run under the regular hosted mode w/ 32-bit JVM: LoadPlugin: failed to initialize shared library /home/vlovich/.mozilla/plugins/libflashplayer.so [/home/vlovich/.mozilla/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64] LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-6-sunjre/lib/amd64/libnpjp2.so [/usr/lib/jvm/java-6-sunjre/lib/amd64/libnpjp2.so: wrong ELF class: ELFCLASS64] # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0625665c, pid=20124, tid=3607796624 # # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) # Problematic frame: # V [libjvm.so+0x25665c] # # An error report file with more information is saved as: # /home/vlovich/workspace/sacred_heart/hs_err_pid20124.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # On Fri, Mar 27, 2009 at 3:07 PM, Vitali Lovich vlov...@gmail.com wrote: You can also has the hs_err for the 32-bit vm On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich vlov...@gmail.com wrote: Ugggh... you want me to do all the work don't you :D On a separate note 5094 compilation is broken (JUnitShell fails to compile). In 5096 the problem is resolved. On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum sco...@google.com wrote: I can has hs_err_pid17105.log? On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich vlov...@gmail.com wrote: [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer [java] # [java] # An unexpected error has been detected by Java Runtime Environment: [java] # [java] # SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968 [java] # [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) [java] # Problematic frame: [java] # V [libjvm.so+0x25665c] [java] # [java] # An error report file with more information is saved as: [java] # /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log [java] # [java] # If you would like to submit a bug report, please visit: [java] # http://java.sun.com/webapps/bugreport/crash.jsp [java] # The crash happened outside the Java Virtual Machine in native code. [java] # See problematic frame for where to report the bug. [java] # This is kind of annoying because GWT fails to build with the newer JDKs due to the issue mentioned before with the change to generics. So it's a two step workaround: Use the older sun JDK to compile the classes after it crashes, use run ant again with the newer JDK so that the GWT compiler doesn't crash the VM. This also happens if I try to use the older JDK with my projects, but that's not really an issue since I just use the latest OpenJDK in the Ubuntu repos. Might be relevant that I'm using 64-bit jdks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM
Ok - i'm almost positive it is the same problem. I think the loadplugin thing is a misdirection. The project appears to crash compiling the code. On Fri, Mar 27, 2009 at 3:59 PM, Vitali Lovich vlov...@gmail.com wrote: Sorry - forgot to mention that this happened when I tried to load the hosted mode browser. On Fri, Mar 27, 2009 at 3:57 PM, Vitali Lovich vlov...@gmail.com wrote: Might be related. Just set up my project to run under the regular hosted mode w/ 32-bit JVM: LoadPlugin: failed to initialize shared library /home/vlovich/.mozilla/plugins/libflashplayer.so [/home/vlovich/.mozilla/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64] LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-6-sunjre/lib/amd64/libnpjp2.so [/usr/lib/jvm/java-6-sunjre/lib/amd64/libnpjp2.so: wrong ELF class: ELFCLASS64] # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0625665c, pid=20124, tid=3607796624 # # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) # Problematic frame: # V [libjvm.so+0x25665c] # # An error report file with more information is saved as: # /home/vlovich/workspace/sacred_heart/hs_err_pid20124.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # On Fri, Mar 27, 2009 at 3:07 PM, Vitali Lovich vlov...@gmail.com wrote: You can also has the hs_err for the 32-bit vm On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich vlov...@gmail.com wrote: Ugggh... you want me to do all the work don't you :D On a separate note 5094 compilation is broken (JUnitShell fails to compile). In 5096 the problem is resolved. On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum sco...@google.com wrote: I can has hs_err_pid17105.log? On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich vlov...@gmail.com wrote: [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer [java] # [java] # An unexpected error has been detected by Java Runtime Environment: [java] # [java] # SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968 [java] # [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) [java] # Problematic frame: [java] # V [libjvm.so+0x25665c] [java] # [java] # An error report file with more information is saved as: [java] # /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log [java] # [java] # If you would like to submit a bug report, please visit: [java] # http://java.sun.com/webapps/bugreport/crash.jsp [java] # The crash happened outside the Java Virtual Machine in native code. [java] # See problematic frame for where to report the bug. [java] # This is kind of annoying because GWT fails to build with the newer JDKs due to the issue mentioned before with the change to generics. So it's a two step workaround: Use the older sun JDK to compile the classes after it crashes, use run ant again with the newer JDK so that the GWT compiler doesn't crash the VM. This also happens if I try to use the older JDK with my projects, but that's not really an issue since I just use the latest OpenJDK in the Ubuntu repos. Might be relevant that I'm using 64-bit jdks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Public git repository
Is there by any chance a public git repository (preferably one that tracks trunk fairly closely)? git svn clone takes forever. Thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Public git repository
Thx. The initial checkout's a pain because Google code also limits you to like 50 kbs/s On Fri, Mar 27, 2009 at 6:34 PM, Scott Blum sco...@google.com wrote: We don't have a public one... but I do have a repo with the whole svn history in it that would git you started. You can grab a copy from a personal webpage of mine... http://www.shaftnet.org/~sinth/gwt-repo.tgz Just download, unpack, checkout, and you should be g2g. git svn fetch isn't so painful if you're nearly up to date already. On Fri, Mar 27, 2009 at 6:09 PM, Vitali Lovich vlov...@gmail.com wrote: Is there by any chance a public git repository (preferably one that tracks trunk fairly closely)? git svn clone takes forever. Thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:
On Thu, Mar 26, 2009 at 3:17 PM, Scott Blum sco...@google.com wrote: Vitali, are you positive all your stuff is in a legit state? I ask because it looks like you're mixing trunk and 1.6 stuff together. Can you clarify what you mean? How can I be mixing trunk 1.6 together? I'm only using trunk. At this point I don't event have the gwt-platform directory in my project path - I just imported the GWT projects made put them on my classpath. When I use a stock gwt-dev-windows.jar from 1...@r5090, I'm using trunk (@ 5084 right now). I haven't even tried stock because I'm on linux 64-bit I haven't bothered trying to get the 32-bit environment set up for the old hosted mode (relying solely on OOPHM). I can boot your project just fine whether log4j-1.2.15.jar is in WEB-INF/lib or not. (I can run it because I couldn't actually find a version of mosaic that you compile against cleanly, but the servlets all initialized just fine.) Right - I forgot that the code I sent you at that point already had my enhancements to mosaic (eventually a version of them should get into truck). In any case, you can just delete the code that throws up an error (unless its the constructor). My code runs fine (including servlets) the logging works. It's just that error that gets printed to the console when the project launches, so it's not a super-important issue. Is it possible it's a Linux-only issue? Here's a dump of the exact dir structure that's working for me: .classpath .project gwt-windows-0.0.0 gwt-windows-0.0.0/gwt-dev-windows.jar gwt-windows-0.0.0/gwt-ll.dll gwt-windows-0.0.0/gwt-user.jar gwt-windows-0.0.0/swt-win32-3235.dll lib lib/ftr-gwt-library-date-0.9.9.jar lib/ftr-gwt-library-date-emul-0.9.9.jar lib/gwt-beans-binding-0.2.3.jar lib/gwt-dnd-2.5.6.jar lib/gwt-incubator-trunk-r1543.jar lib/gwt-mosaic-0.2.0-rc1.jar lib/gwtx-1.5.2.jar lib/log4j-1.2.15.jar lib/org.cobogw.gwt-1.2.2.jar SacredHeart.launch src (omitted) war war/loading.gif war/SacredHeart.css war/SacredHeart.html war/WEB-INF war/WEB-INF/classes (omitted) war/WEB-INF/classes/ece456 war/WEB-INF/classes/log4j.properties war/WEB-INF/lib war/WEB-INF/lib/gwt-servlet.jar war/WEB-INF/lib/log4j-1.2.15.jar war/WEB-INF/lib/mysql-connector-java-5.1.7-bin.jar war/WEB-INF/web.xml I attached the .project, .classpath, and launch config I'm using. This configuration boots whether or not I have war/WEB-INF/lib/log4j-1.2.15.jar in there. On Wed, Mar 25, 2009 at 7:32 PM, Vitali Lovich vlov...@gmail.com wrote: On Wed, Mar 25, 2009 at 7:10 PM, Scott Blum sco...@google.com wrote: On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich vlov...@gmail.comwrote: If I don't put the log4j file into my WEB-INF/lib directory, then it's fine. If it is put there, then it gets the conflicting version (regardless of whether or not I launch HostedMode with log4j on the class path). So am I doing it wrong? i'm confused... if you don't have log4j on the classpath, how can you be loading it via Launcher$AppClassLoader? It must be hiding out in some other jar you have on the classpath? Sorry for the confusion. Here's what I meant: If I add the log4j library in the WEB-INF/lib to the classpath of the runtime configuration, I get the problem above. If I move the log4j library out of the WEB-INF/lib directory to somewhere else like project/lib add it to the classpath, then it works. Am I supposed to place it elsewhere then copy it over to WEB-INF/lib when I'm packaging it up only? That's not the intent... can you send me a small sample that repros this? I don't have time right now. If you want I can e-mail you my project privately. It's a school project, so there's no confidentiality to it or anything. I just don't want to spam the mailing list. Thanks Scott --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:
This didn't fix my log4j issue, but there's a workaround:
adding -Dlog4j.ignoreTCL to the VM arguments fixes it.
On Wed, Mar 25, 2009 at 3:51 PM, Toby Reyelts to...@google.com wrote:
Overall, the change to treat server classes vs system classes separately,
such that system classes are API classes and server classes are
implementation classes looks good.
I'm concerned that there will still be places where things will clash -
such as the sharing of log4j across both server and webapps. Given the
complexity of the situation, I understand the desire to change behavior as
little as possible in this area, though. There's also an argument that,
since this is the way Jetty currently functions, you're just exposing Jetty
behavior, as is.
I think the situation would be simpler if GWT didn't treat the system
classpath as a user-level classpath.
On Wed, Mar 25, 2009 at 9:15 AM, codesite-nore...@google.com wrote:
Author: sco...@google.com
Date: Wed Mar 25 05:43:19 2009
New Revision: 5078
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Log:
Amending r5077:
- Catch ClassNotFound in outside loader and allow internal load
- Allow system resources to be loaded internally if they're not found
externally
- jat suggestion to extract constant
- Fix comments
Review by: tobyr (TBR)
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
==
---
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
(original)
+++
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Wed Mar 25 05:43:19 2009
@@ -249,6 +249,8 @@
*/
private class WebAppClassLoaderExtension extends WebAppClassLoader {
+ private static final String META_INF_SERVICES =
META-INF/services/;
+
public WebAppClassLoaderExtension() throws IOException {
super(bootStrapOnlyClassLoader, WebAppContextWithReload.this);
}
@@ -257,17 +259,21 @@
public URL findResource(String name) {
// Specifically for
META-INF/services/javax.xml.parsers.SAXParserFactory
String checkName = name;
-if (checkName.startsWith(META-INF/services/)) {
- checkName = checkName.substring(META-INF/services/.length());
+if (checkName.startsWith(META_INF_SERVICES)) {
+ checkName = checkName.substring(META_INF_SERVICES.length());
}
-// For system/server path, just try the outside world quietly.
+// For a system path, load from the outside world.
+URL found;
if (isSystemPath(checkName)) {
- return systemClassLoader.getResource(name);
+ found = systemClassLoader.getResource(name);
+ if (found != null) {
+return found;
+ }
}
// Always check this ClassLoader first.
-URL found = super.findResource(name);
+found = super.findResource(name);
if (found != null) {
return found;
}
@@ -303,14 +309,18 @@
@Override
protected Class? findClass(String name) throws
ClassNotFoundException {
-// For system/server path, just try the outside world quietly.
+// For system path, always prefer the outside world.
if (isSystemPath(name)) {
- return systemClassLoader.loadClass(name);
+ try {
+return systemClassLoader.loadClass(name);
+ } catch (ClassNotFoundException e) {
+ }
}
try {
return super.findClass(name);
} catch (ClassNotFoundException e) {
+ // Don't allow server classes to be loaded from the outside.
if (isServerPath(name)) {
throw e;
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:
og4j:ERROR A org.apache.log4j.ConsoleAppender object is not assignable to
a org.apache.log4j.Appender variable.
log4j:ERROR The class org.apache.log4j.Appender was loaded by
log4j:ERROR [sun.misc.launcher$appclassloa...@64601bb1] whereas object of
type
log4j:ERROR org.apache.log4j.ConsoleAppender was loaded by
[contextloa...@null([file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/classes/,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/gwt-servlet.jar,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/log4j-1.2.15.jar,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/mysql-connector-java-5.1.7-bin.jar])
/
com.google.gwt.dev.shell.jetty.jettylauncher$webappcontextwithreloa...@e1651fe
].
log4j:ERROR Could not instantiate appender named dest.
log4j:WARN No appenders could be found for logger
(org.apache.jasper.compiler.JspRuntimeContext).
log4j:WARN Please initialize the log4j system properly.
Seems like GWT is loading log4j (at least partially) but then I'm using the
actual log4j form the website, so the class loader throws up. This could
also be fixed by just bundling log4j into gwt-servlet - odds are, people are
going to want to use log4j on the server anyways.
On Wed, Mar 25, 2009 at 4:17 PM, Scott Blum sco...@google.com wrote:
Vitali, can you remind me what your issue is?
On Wed, Mar 25, 2009 at 4:10 PM, Vitali Lovich vlov...@gmail.com wrote:
This didn't fix my log4j issue, but there's a workaround:
adding -Dlog4j.ignoreTCL to the VM arguments fixes it.
On Wed, Mar 25, 2009 at 3:51 PM, Toby Reyelts to...@google.com wrote:
Overall, the change to treat server classes vs system classes separately,
such that system classes are API classes and server classes are
implementation classes looks good.
I'm concerned that there will still be places where things will clash -
such as the sharing of log4j across both server and webapps. Given the
complexity of the situation, I understand the desire to change behavior as
little as possible in this area, though. There's also an argument that,
since this is the way Jetty currently functions, you're just exposing Jetty
behavior, as is.
I think the situation would be simpler if GWT didn't treat the system
classpath as a user-level classpath.
On Wed, Mar 25, 2009 at 9:15 AM, codesite-nore...@google.com wrote:
Author: sco...@google.com
Date: Wed Mar 25 05:43:19 2009
New Revision: 5078
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Log:
Amending r5077:
- Catch ClassNotFound in outside loader and allow internal load
- Allow system resources to be loaded internally if they're not found
externally
- jat suggestion to extract constant
- Fix comments
Review by: tobyr (TBR)
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
==
---
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
(original)
+++
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Wed Mar 25 05:43:19 2009
@@ -249,6 +249,8 @@
*/
private class WebAppClassLoaderExtension extends WebAppClassLoader
{
+ private static final String META_INF_SERVICES =
META-INF/services/;
+
public WebAppClassLoaderExtension() throws IOException {
super(bootStrapOnlyClassLoader, WebAppContextWithReload.this);
}
@@ -257,17 +259,21 @@
public URL findResource(String name) {
// Specifically for
META-INF/services/javax.xml.parsers.SAXParserFactory
String checkName = name;
-if (checkName.startsWith(META-INF/services/)) {
- checkName =
checkName.substring(META-INF/services/.length());
+if (checkName.startsWith(META_INF_SERVICES)) {
+ checkName = checkName.substring(META_INF_SERVICES.length());
}
-// For system/server path, just try the outside world quietly.
+// For a system path, load from the outside world.
+URL found;
if (isSystemPath(checkName)) {
- return systemClassLoader.getResource(name);
+ found = systemClassLoader.getResource(name);
+ if (found != null) {
+return found;
+ }
}
// Always check this ClassLoader first.
-URL found = super.findResource(name);
+found = super.findResource(name);
if (found != null) {
return found;
}
@@ -303,14 +309,18 @@
@Override
protected Class? findClass(String name) throws
ClassNotFoundException {
-// For system/server path, just try the outside world quietly.
+// For system path, always prefer the outside world.
if (isSystemPath(name)) {
- return systemClassLoader.loadClass(name);
+ try {
+return systemClassLoader.loadClass(name);
+ } catch
[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:
I think I found the problem.
If I don't put the log4j file into my WEB-INF/lib directory, then it's
fine. If it is put there, then it gets the conflicting version (regardless
of whether or not I launch HostedMode with log4j on the class path). So am
I doing it wrong?
Am I supposed to place it elsewhere then copy it over to WEB-INF/lib when
I'm packaging it up only?
On Wed, Mar 25, 2009 at 5:13 PM, Scott Blum sco...@google.com wrote:
Hmm, but GWT doesn't use log4j internally. Is it possible you've got
conflicting versions, one on the system classpath and one in your war
directory?
On Wed, Mar 25, 2009 at 4:40 PM, Vitali Lovich vlov...@gmail.com wrote:
og4j:ERROR A org.apache.log4j.ConsoleAppender object is not assignable
to a org.apache.log4j.Appender variable.
log4j:ERROR The class org.apache.log4j.Appender was loaded by
log4j:ERROR [sun.misc.launcher$appclassloa...@64601bb1] whereas object of
type
log4j:ERROR org.apache.log4j.ConsoleAppender was loaded by
[contextloa...@null([file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/classes/,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/gwt-servlet.jar,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/log4j-1.2.15.jar,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/mysql-connector-java-5.1.7-bin.jar])
/
com.google.gwt.dev.shell.jetty.jettylauncher$webappcontextwithreloa...@e1651fe
].
log4j:ERROR Could not instantiate appender named dest.
log4j:WARN No appenders could be found for logger
(org.apache.jasper.compiler.JspRuntimeContext).
log4j:WARN Please initialize the log4j system properly.
Seems like GWT is loading log4j (at least partially) but then I'm using
the actual log4j form the website, so the class loader throws up. This
could also be fixed by just bundling log4j into gwt-servlet - odds are,
people are going to want to use log4j on the server anyways.
On Wed, Mar 25, 2009 at 4:17 PM, Scott Blum sco...@google.com wrote:
Vitali, can you remind me what your issue is?
On Wed, Mar 25, 2009 at 4:10 PM, Vitali Lovich vlov...@gmail.comwrote:
This didn't fix my log4j issue, but there's a workaround:
adding -Dlog4j.ignoreTCL to the VM arguments fixes it.
On Wed, Mar 25, 2009 at 3:51 PM, Toby Reyelts to...@google.com wrote:
Overall, the change to treat server classes vs system classes
separately, such that system classes are API classes and server classes
are implementation classes looks good.
I'm concerned that there will still be places where things will clash -
such as the sharing of log4j across both server and webapps. Given the
complexity of the situation, I understand the desire to change behavior as
little as possible in this area, though. There's also an argument that,
since this is the way Jetty currently functions, you're just exposing
Jetty
behavior, as is.
I think the situation would be simpler if GWT didn't treat the system
classpath as a user-level classpath.
On Wed, Mar 25, 2009 at 9:15 AM, codesite-nore...@google.com wrote:
Author: sco...@google.com
Date: Wed Mar 25 05:43:19 2009
New Revision: 5078
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Log:
Amending r5077:
- Catch ClassNotFound in outside loader and allow internal load
- Allow system resources to be loaded internally if they're not
found
externally
- jat suggestion to extract constant
- Fix comments
Review by: tobyr (TBR)
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
==
---
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
(original)
+++
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Wed Mar 25 05:43:19 2009
@@ -249,6 +249,8 @@
*/
private class WebAppClassLoaderExtension extends
WebAppClassLoader {
+ private static final String META_INF_SERVICES =
META-INF/services/;
+
public WebAppClassLoaderExtension() throws IOException {
super(bootStrapOnlyClassLoader,
WebAppContextWithReload.this);
}
@@ -257,17 +259,21 @@
public URL findResource(String name) {
// Specifically for
META-INF/services/javax.xml.parsers.SAXParserFactory
String checkName = name;
-if (checkName.startsWith(META-INF/services/)) {
- checkName =
checkName.substring(META-INF/services/.length());
+if (checkName.startsWith(META_INF_SERVICES)) {
+ checkName =
checkName.substring(META_INF_SERVICES.length());
}
-// For system/server path, just try the outside world
quietly.
+// For a system path, load from the outside world.
+URL found;
if (isSystemPath(checkName)) {
- return systemClassLoader.getResource(name);
+ found = systemClassLoader.getResource(name);
+ if (found != null
[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:
On Wed, Mar 25, 2009 at 7:10 PM, Scott Blum sco...@google.com wrote: On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich vlov...@gmail.com wrote: If I don't put the log4j file into my WEB-INF/lib directory, then it's fine. If it is put there, then it gets the conflicting version (regardless of whether or not I launch HostedMode with log4j on the class path). So am I doing it wrong? i'm confused... if you don't have log4j on the classpath, how can you be loading it via Launcher$AppClassLoader? It must be hiding out in some other jar you have on the classpath? Sorry for the confusion. Here's what I meant: If I add the log4j library in the WEB-INF/lib to the classpath of the runtime configuration, I get the problem above. If I move the log4j library out of the WEB-INF/lib directory to somewhere else like project/lib add it to the classpath, then it works. Am I supposed to place it elsewhere then copy it over to WEB-INF/lib when I'm packaging it up only? That's not the intent... can you send me a small sample that repros this? I don't have time right now. If you want I can e-mail you my project privately. It's a school project, so there's no confidentiality to it or anything. I just don't want to spam the mailing list. Thanks Scott --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
What IDE are you using? I know there are issues with hot-swap between JDT and Javac, so if you aren't using Eclipse you may have some hot-swap issues (Eclipse and GWT both use JDT), which allows you to change some classes without doing a refresh. That is independent of a refresh, which is basically tossing the running classes and reloading them. I'm seeing this problem again. Debugging in Eclipse, change code hotswapping fails. I was wrong before though - the debugged code is actually stale, so this is a problem in that I have to relaunch HostedMode to get the changes (refreshing the page alone doesn't work) Thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
2009/3/25 John Tamplin j...@google.com What version of eclipse are you using? I only see this when I make structural changes to a class. That might be it. Eclipse 3.5 Eclipse 3.4. I'll watch out for the kind of change I make when this happens. j...@google.com (from Android) On Mar 25, 2009 8:13 PM, Vitali Lovich vlov...@gmail.com wrote: What IDE are you using? I know there are issues with hot-swap between JDT and Javac, so if you ar... I'm seeing this problem again. Debugging in Eclipse, change code hotswapping fails. I was wrong before though - the debugged code is actually stale, so this is a problem in that I have to relaunch HostedMode to get the changes (refreshing the page alone doesn't work) Thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] OOPHM HostedMode not compatible with FF3.1?
I just tested the XPCOM plugin in FF3.1 got the following on startup: 00:00:21.687 [WARN] JSNI method '__defineStatic' returned a value of type boolean but was declared void; it should not have returned a value at all 00:00:21.891 [WARN] JSNI method '@com.google.gwt.dom.client.Style::setPropertyPxImpl(Ljava/lang/String;I)' returned a value of type boolean but was declared void; it should not have returned a value at all 00:00:21.891 [WARN] JSNI method '@com.google.gwt.dom.client.Style::setPropertyPxImpl(Ljava/lang/String;I)' returned a value of type boolean but was declared void; it should not have returned a value at all 00:00:21.891 [WARN] JSNI method '@com.google.gwt.dom.client.Element::setPropertyString(Ljava/lang/String;Ljava/lang/String;)' returned a value of type boolean but was declared void; it should not have returned a value at all 00:00:21.891 [WARN] JSNI method '@com.google.gwt.dom.client.Element::setPropertyString(Ljava/lang/String;Ljava/lang/String;)' returned a value of type boolean but was declared void; it should not have returned a value at all 00:00:21.891 [WARN] JSNI method '@com.google.gwt.dom.client.Element::setPropertyInt(Ljava/lang/String;I)' returned a value of type boolean but was declared void; it should not have returned a value at all . etc 00:00:22.141 [ERROR] Unable to load module entry point class ece456.client.SacredHeart (see associated exception for details) com.google.gwt.dev.shell.HostedModeException: Something other than a Java object was returned from JSNI method '@com.google.gwt.user.client.impl.DOMImpl::getEventListener(Lcom/google/gwt/user/client/Element;)': JS value of type boolean, expected java.lang.Object at com.google.gwt.dev.shell.JsValueGlue.get(JsValueGlue.java:173) at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:275) at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91) at com.google.gwt.user.client.impl.DOMImpl.getEventListener(DOMImpl.java) at com.google.gwt.user.client.DOM.getEventListener(DOM.java:794) at com.google.gwt.user.client.Event$.getEventListener(Event.java:434) at com.google.gwt.user.client.ui.RootPanel.isElementChildOfWidget(RootPanel.java:271) at com.google.gwt.user.client.ui.RootPanel.detachOnWindowClose(RootPanel.java:122) at com.google.gwt.user.client.ui.RootPanel.get(RootPanel.java:197) at com.google.gwt.user.client.ui.RootPanel.get(RootPanel.java:137) at com.google.gwt.user.client.ui.PopupPanel$ResizeAnimation.setState(PopupPanel.java:168) at com.google.gwt.user.client.ui.PopupPanel.setState(PopupPanel.java:1175) at com.google.gwt.user.client.ui.PopupPanel.show(PopupPanel.java:786) at org.gwt.mosaic.ui.client.InfoPanel.show(InfoPanel.java:91) at org.gwt.mosaic.ui.client.InfoPanel.show(InfoPanel.java:132) at org.gwt.mosaic.ui.client.InfoPanel.show(InfoPanel.java:99) at ece456.client.SacredHeart.dbg(SacredHeart.java:235) at ece456.client.SacredHeart.onModuleLoad(SacredHeart.java:202) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:367) at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:169) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:148) at java.lang.Thread.run(Thread.java:636) 00:00:22.141 [ERROR] Failed to load module 'sacredheart' from user agent 'Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3) Gecko/20090307 Ubuntu/8.10 (intrepid) Shiretoko/3.1b3' at localhost:54169 Loading the same page under 3.0.7 w/ the XPCOM plugin works. Neither browser has GWT listed in about:plugins - is this correct for XPCOM? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Announcing GWT 1.6 Release Candidate
I just tried the patch with trunk (5072) got java.lang.NullPointerException at sun.misc.MetaIndex.mayContain(MetaIndex.java:243) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:761) at sun.misc.URLClassPath.getResource(URLClassPath.java:185) at sun.misc.URLClassPath.getResource(URLClassPath.java:237) at java.lang.ClassLoader.getBootstrapResource(ClassLoader.java:1130) at java.lang.ClassLoader.getResource(ClassLoader.java:991) at java.lang.ClassLoader.getResource(ClassLoader.java:989) at com.google.gwt.dev.OophmHostedModeBase.loadImageIcon(OophmHostedModeBase.java:293) at com.google.gwt.dev.HostedMode.getWebServerIcon(HostedMode.java:431) at com.google.gwt.dev.OophmHostedModeBase.openAppWindow(OophmHostedModeBase.java:495) at com.google.gwt.dev.HostedModeBase.doStartup(HostedModeBase.java:493) at com.google.gwt.dev.OophmHostedModeBase.doStartup(OophmHostedModeBase.java:420) at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:363) at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:609) at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:402) at com.google.gwt.dev.HostedMode.main(HostedMode.java:264) on trying to launch OOPHM in HostedMode. Is this patch compatible? I'm trying to fix the issue with the log4j that I'm getting: log4j:ERROR A org.apache.log4j.ConsoleAppender object is not assignable to a org.apache.log4j.Appender variable. log4j:ERROR The class org.apache.log4j.Appender was loaded by log4j:ERROR [sun.misc.launcher$appclassloa...@64601bb1] whereas object of type log4j:ERROR org.apache.log4j.ConsoleAppender was loaded by [contextloa...@null]. log4j:ERROR Could not instantiate appender named O. I think there's some interference going on due to me launching HostedMode. On Tue, Mar 24, 2009 at 7:41 AM, Alejandro D. Garin aga...@gmail.comwrote: Hi Scott, Yes, this fixes the problem for my configuration, the spring container started now :) Thanks. On 3/24/09, Scott Blum sco...@google.com wrote: Hey, can you guys do me a favor and try out a fix? Just take the attached jar and put it on your classpath ahead of gwt-dev-platform.jar. See if it fixes the not and instance of Servlet problem (and doesn't cause other problems). Lemme know if that works, thanks, Scott On Mon, Mar 23, 2009 at 9:09 PM, Alejandro D. Garin aga...@gmail.comwrote: Are the spring jar and its dependencies in your WEB-INF/lib folder? We did introduce an extra convenience mode recently, hence the message Hi Bruce, Yes, the spring.jar is in the lib folder, no other dependences needed. If you want I can send to you a little demo project based on the webAppCreator default example plus an Spring bean loaded in the server. The demo project work fine in 1.6.1 Thanks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
I think it might be a good idea to also reference the -localWorkers flag. I find that it cuts down on my startup time significantly (especially on my desktop which is quad-core, but even on my dual-core laptop). With OOPHM I find this to be particularly more annoying because the browser freezes on startup while the server is compiling the code. Also, perhaps a mention that every refresh of the page launches a fresh compilation of the code thus the browser locks up for a while there as well. The other thing I noticed is that after changing client-side code refreshing, although the debugger claims the source is out of sync, it works perfectly with the changed code. On Tue, Mar 24, 2009 at 3:20 PM, John Tamplin j...@google.com wrote: On Fri, Mar 6, 2009 at 7:27 PM, John Tamplin j...@google.com wrote: I will write up a document next week about how to use OOPHM with trunk (it isn't going to be usable with 1.6). Sorry for the delay, but I finally got around to writing it up -- see UsingOOPHM http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHMon the wiki. Let me know if that doesn't address any issues you have. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
On Tue, Mar 24, 2009 at 4:59 PM, John Tamplin j...@google.com wrote: On Tue, Mar 24, 2009 at 3:59 PM, Vitali Lovich vlov...@gmail.com wrote: I think it might be a good idea to also reference the -localWorkers flag. I find that it cuts down on my startup time significantly (especially on my desktop which is quad-core, but even on my dual-core laptop). With OOPHM I find this to be particularly more annoying because the browser freezes on startup while the server is compiling the code. I don't know that the OOPHM document is the right place to discuss other compiler flags. Also, I don't think -localWorkers will have any impact on hosted mode at all, since it is used to compile different permutations in parallel. it will speedup web-mode compilation if you have more than one permutation, but nothing for hosted mode. Sorry my mistake. It was probably just the placebo effect :D. However, it does take about 11 seconds between when the OOPHM connection is established (request for module in log) when the onModuleLoad starts executing (8 seconds between Request for module Refreshing module from source). My IDE takes about 1 second to compile my project cleanly (same with ant). On my laptop which takes 4 seconds to build using ant, takes 28 seconds to go from Request for module to Refreshing module from source then takes 7 seconds to compile. When I run HostedMode using the release configuration, then the times drop to 1/7 for the desktop, 1/25 for the laptop (compilation time/module request time). Also, this happens on every launch regardless of whether or not code was actually changed. Also, perhaps a mention that every refresh of the page launches a fresh compilation of the code thus the browser locks up for a while there as well. It is doing a bytecode compile (including of generated code), not a web-mode compile, so it should be very long unless you have a really large app. There is a project we call instant hosted mode which will allow reuse of your IDE's bytecode compilation rather than having to recompile, but it isn't ready yet (soon though). Sorry, my mistake. Refreshing isn't actually slow. But if it's doing a bytecode compile, why is it even taking any time on the initial startup when there was no source code change the compiled classes haven't changed? Shouldn't it notice this not do anything? The other thing I noticed is that after changing client-side code refreshing, although the debugger claims the source is out of sync, it works perfectly with the changed code. What IDE are you using? I know there are issues with hot-swap between JDT and Javac, so if you aren't using Eclipse you may have some hot-swap issues (Eclipse and GWT both use JDT), which allows you to change some classes without doing a refresh. That is independent of a refresh, which is basically tossing the running classes and reloading them. Using Eclipse. The IDE warns me that hot swapping failed on save. The debugger claims the source is out of sync, but like I said, it actually hits the breakpoints correctly executes the changed code. I can't reproduce it right now (I can't remember if it was a persistent problem and it was fixed by me updating the trunk today or if it was an intermittent problem). If it happens again, I'll let you know. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM disconnects when using gwt-mosaic Viewport
Gotcha. I was stupid and for some reason thought XPCOM had something to do with COM would be linux only. I've been getting no sleep thanks to this databases project :(. On Tue, Mar 24, 2009 at 3:29 PM, John Tamplin j...@google.com wrote: On Tue, Mar 24, 2009 at 3:10 PM, Vitali Lovich vlov...@gmail.com wrote: As an update, I just realized that the error Error: Bad NPObject as private data! Source File: http://localhost:9000/module/hosted.html?module Line: 84 Keeps showing up whenever there's any kind of event (i.e. mouse move, key press, window resize, etc). Attaching the script. This is probably because the OOPHM connection is broken, so it's unable to deliver the events from the browser to the The NPAPI plugin is not really going to work -- you need to use the XPCOM pluginhttp://code.google.com/p/google-web-toolkit/source/browse/branches/oophm/plugins/xpcom/prebuilt/oophm-xpcom.xpiinstead. The issue is that whenever window.enableScrolling is changed, Firefox rebuilds the page and in the process unloads and reloads the plugin. Aside from losing state in the plugin, this is problematic since the unloaded plugin is still on the call stack, and things go bad when it returns to that code after a new instance of the plugin is created. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] GWT Generated HTML quirks mode
In the HTML file created by GWT's project creator, it puts the browser into quirks mode by default. Shouldn't it put in a standards compliant mode by default (AFAIK, doesn't Google push for standards adoption) provide a comment saying that the user should change it to quirks if they really really need to support a quirks-mode browser (I'm assuming here that that pretty much includes IE only, so perhaps make that explicit too). With IE8 on the horizon supporting standards mode, that means that all major browsers will soon support standards-compliant mode. Thoughts? Thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] GWT Generated HTML quirks mode
In the HTML file created by GWT's project creator, it puts the browser into quirks mode by default. Shouldn't it put in a standards compliant mode by default (AFAIK, doesn't Google push for standards adoption) provide a comment saying that the user should change it to quirks if they really really need to support a quirks-mode browser (I'm assuming here that that pretty much includes IE only, so perhaps make that explicit too). With IE8 on the horizon supporting standards mode, that means that all major browsers will soon support standards-compliant mode. Thoughts? Thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] HashSet throwing incorrect exception possible compiler bug
First major concern is that I got a ConcurrentModificationException when
iterating over a HashSet - this exception is completely meaningless in the
context of the browser (no threading). There's also not really any
meaningful message in the stack trace:
00:20:24.446 [ERROR] Uncaught exception escaped
java.util.ConcurrentModificationException: null at
java.util.HashMap$HashIterator.nextEntry(HashMap.java:810) at
java.util.HashMap$KeyIterator.next(HashMap.java:845)
The relevant code that causes this is:
private HashMapModelAction, HashSetModelListener models;
// .
HashSetModelListener listeners = models.get(action);
if (listeners != null) {
for (ModelListener listener : listeners)
listener.modelUpdated(action, info);
}
Replacing it with a regular iterator:
IteratorModelListener iterator = listeners.iterator();
while (iterator.hasNext())
iterator.next().modelUpdated(action, info);
somehow fixes the problem. Is the compiler screwing up in converting the
Java for-each notation into the iterator equivalent, or am I missing
something?
Some background: this succeeds the first time it is called from within an
event handler context (to notify the model to perform a login attempt).
However, it fails the second time it is called when it is called from an
AsyncCallback context (returning the result that it was a successful
login). However, at no point is the HashSet used modified (after startup
where it contains currently 1 element).
Thanks
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: HashSet throwing incorrect exception possible compiler bug
On Wed, Mar 18, 2009 at 6:10 PM, Ray Cromwell cromwell...@gmail.com wrote: On Wed, Mar 18, 2009 at 2:57 PM, Vitali Lovich vlov...@gmail.com wrote: First major concern is that I got a ConcurrentModificationException when iterating over a HashSet - this exception is completely meaningless in the context of the browser (no threading). There's also not really any meaningful message in the stack trace: It applies equally well to single-thread scenarios, see the JavaDoc: http://java.sun.com/j2se/1.5.0/docs/api/java/util/ConcurrentModificationException.html Right - I was just implying that seeing as how my code in no way actually modifies the set while iterating over it, the concurrent modification exception is meaningless. http://java.sun.com/j2se/1.5.0/docs/api/java/util/ConcurrentModificationException.html somehow fixes the problem. Is the compiler screwing up in converting the Java for-each notation into the iterator equivalent, or am I missing something? Some background: this succeeds the first time it is called from within an event handler context (to notify the model to perform a login attempt). However, it fails the second time it is called when it is called from an AsyncCallback context (returning the result that it was a successful login). However, at no point is the HashSet used modified (after startup where it contains currently 1 element). It's possible there's a bug, but perhaps you should try wrapping things in Collections.unmodifableSet()/Map() to make sure it's not being modified in some way. Nope - still throws an exception. Nothing in the code example above modifies the hashset (I print a message when I register a listener, and I'm not getting that) - I'm going to verify this though (step through the first successful call) -Ray --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashSet throwing incorrect exception possible compiler bug
Sorry - it was my fault. I tracked it down. Within the listener, I was unregistering it - stupid me. Thanks for your help Vitali On Wed, Mar 18, 2009 at 6:43 PM, Ray Cromwell cromwell...@gmail.com wrote: On Wed, Mar 18, 2009 at 3:31 PM, Vitali Lovich vlov...@gmail.com wrote: Nope - still throws an exception. Nothing in the code example above modifies the hashset (I print a message when I register a listener, and I'm not getting that) - I'm going to verify this though (step through the first successful call) Is this happening in web mode, hosted mode, or both? Does it happen in hosted mode? -Ray -Ray --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashSet throwing incorrect exception possible compiler bug
It's actually not event listeners - it's just a simple messaging delivery system I wrote. I was more referring to me being stupid not stepping remembering that I had modified the map. I just saw ConcurrentModificationException, no obvious modification of the map within the iteration, and just got confused about what's going on. On Wed, Mar 18, 2009 at 7:18 PM, Ray Ryan rj...@google.com wrote: FWIW, the HandlerManager class introduced in 1.6 allows concurrent mods. Because really you're not so silly to want to do that. rjrjr On Wed, Mar 18, 2009 at 3:53 PM, Vitali Lovich vlov...@gmail.com wrote: Sorry - it was my fault. I tracked it down. Within the listener, I was unregistering it - stupid me. Thanks for your help Vitali On Wed, Mar 18, 2009 at 6:43 PM, Ray Cromwell cromwell...@gmail.com wrote: On Wed, Mar 18, 2009 at 3:31 PM, Vitali Lovich vlov...@gmail.com wrote: Nope - still throws an exception. Nothing in the code example above modifies the hashset (I print a message when I register a listener, and I'm not getting that) - I'm going to verify this though (step through the first successful call) Is this happening in web mode, hosted mode, or both? Does it happen in hosted mode? -Ray -Ray --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changed gwt.xml not picked up buy webserver
HostedMode w/ OOPHM. rev 5009 if that helps. On Mon, Mar 16, 2009 at 11:41 AM, Scott Blum sco...@google.com wrote: Is this using old-style GWTShell, or the new HostedMode? On Mon, Mar 16, 2009 at 2:30 AM, Vitali Lovich vlov...@gmail.com wrote: I'm just wondering if this is a bug or expected behaviour. If I change the module descriptor that was used to launch the Jetty server, I am unable to refresh the app - the webserver complains about not being able to find the module. Shouldn't it detect this recompile as necessary? I think there might be a related bug where this failure to find the module doesn't disconnect the server's OOPHM connection (even though the browser made a new one because I hit refresh). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changed gwt.xml not picked up buy webserver
I dunno - I applied the patch for hosted mode that was posted a while back. I'm pretty sure it's hosted mode - otherwise, my project wouldn't run without me having to redo the 1.5 project structure. Maybe I'm not understanding what you mean by GWTShell. The main class that is launched is HostedMode. So what I was trying to do was change the theme that was being used by my module by updating the gwt.xml file. Then I reloaded the web-page to get it to pick up the change, but instead I got the error unable to find module My set up is as follows: MyModule.gwt.xml - contains my project description - rename-to set to mymodule MyModuleHosted.gwt.xml - contains project description w/ user-agent set 1 localization set so that compilation is faster (renamed to same name as MyModule). Load ModuleHosted. Hit website to ensure that everything is working fine. Change the theme (inherits name='com.google.gwt.user.theme.standard.Standard'/ to some other valid theme). Hit Refresh Message [ERROR] Unable to find 'mymodule.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source? So it looks like it may be trying to lookup the wrong descriptor - instead of trying to lookup the description of the original file it was loaded with, it gets confused tries to load the module name. Thanks, On Mon, Mar 16, 2009 at 4:34 PM, Scott Blum sco...@google.com wrote: OOPHM is still using GWTShell (I still owe John a review). Can you give us a little more detail about what you're doing? What exact errors are you seeing? On Mon, Mar 16, 2009 at 3:53 PM, Vitali Lovich vlov...@gmail.com wrote: HostedMode w/ OOPHM. rev 5009 if that helps. On Mon, Mar 16, 2009 at 11:41 AM, Scott Blum sco...@google.com wrote: Is this using old-style GWTShell, or the new HostedMode? On Mon, Mar 16, 2009 at 2:30 AM, Vitali Lovich vlov...@gmail.comwrote: I'm just wondering if this is a bug or expected behaviour. If I change the module descriptor that was used to launch the Jetty server, I am unable to refresh the app - the webserver complains about not being able to find the module. Shouldn't it detect this recompile as necessary? I think there might be a related bug where this failure to find the module doesn't disconnect the server's OOPHM connection (even though the browser made a new one because I hit refresh). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changed gwt.xml not picked up buy webserver
Yeah, sorry if I haven't made that clear. I am using the patch that was posted earlier that enables OOPHM for HostedMode. I'll try increasing the log level. On Mon, Mar 16, 2009 at 11:01 PM, John Tamplin j...@google.com wrote: On Mon, Mar 16, 2009 at 10:58 PM, Scott Blum sco...@google.com wrote: There's something I'm not understanding about your setup. You say you're using HostedMode and the 1.6 project structure, but then you also said you were using OOPHM. How is that possible? OOPHM doesn't support the new project structure. He said he was using the patch posted earlier, so I presume he means the one you are reviewing. That said, that has not been thoroughly vetted so it is possible there is an issue there. I have successfully refreshed a .gwt.xml change, but I don't have exactly the same setup as you. Can you increase the log level and see if an earlier log message after refreshing gives any clues? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: code review requested - add OOPHM support for HostedMode
I'm not 100% sure if this is related to the patch, but I'm seeing an issue in the following situation: Started a project in OOPHM HostedMode Firefox 3.1 with plugin (version bumpbed to 3.1). Put laptop to sleep On wakeup, Firefox locks up. Now some variables do change - the connection drops out temporarily while the wireless is reconnecting to a different network (the laptop is moved to a different location while it's sleeping). Can anyone else confirm this issue? Obviously it's not the ideal set-up with FF3.1. On Mon, Mar 16, 2009 at 11:42 PM, John Tamplin j...@google.com wrote: On Mon, Mar 16, 2009 at 11:16 PM, Scott Blum sco...@google.com wrote: - The whole PlatformSpecific - CheckForUpdates stuff.. I think that looks good, but can we do that first as a separate commit? Ok. - The BrowserListener diff seems unrelated also unless I'm missing something Well, I ran into the problem while testing this and it seemed like a good idea to fix it (the problem is avoiding a crash if the OOPHM socket was already in use). It can be separated out if you prefer. - HostedModeBase: why are the two old protected methods being added back in? Hmm, looks like merge issues or getting overzealous moving stuff up from OOPHM/GWTShell, along with the call to doShouldCheckForUpdates in doStartup(). If we are moving the CheckForUpdates changes into a separate commit, then this file would be unchanged for now. - OophmBrowserWidgetHostImpl should just subclass BrowserWidgetHostImpl, right? This would remove a lot of duplicate code I think. What code could it use? I don't see any method which is the same as HostedModeBase.BrowserWidgetHostImpl? - ArgHandlerStartupURLsExtra should be in GWTShell, not OophmHostedModeBase Ok. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: code review requested - add OOPHM support for HostedMode
Oh I wasn't complaining. It's not an issue at all since FF has session restore. Just wondering if it was a known issue if I should file a bug. On Tue, Mar 17, 2009 at 12:08 AM, John Tamplin j...@google.com wrote: On Mon, Mar 16, 2009 at 11:59 PM, Vitali Lovich vlov...@gmail.com wrote: I'm not 100% sure if this is related to the patch, but I'm seeing an issue in the following situation: I doubt this has anything to do with the patch -- basically the issue is that with the plugin, Firefox is dependent upon the link to the OOPHM server since the plugin makes synchronous RPC calls from native code that block the UI event loop until it gets a response (since the calls to Java methods from JS and vice-versa have to be synchronous). If that connection goes away, it can hang the browser until the OS notices the connection has died. If your TCP connection goes to another machine, then the connection will be killed by the other end due to keep-alive being set, but the process running on the laptop won't notice for a while after it comes up -- but it should eventually come back. If both the OOPHM server and the browser are running on your laptop, I am surprised that there would be any issues here (though frequently after waking up everything has to be paged back in from disk so you can experience sluggish behavior while that happens), but this is not something that has been tested as far as I know. This is probably a good time to mention that OOPHM isn't the default because it has a lot of unpolished edges. If you aren't willing to put up with them or use workarounds (like closing the OOPHM session in your browser before suspending if that is causing an issue), then perhaps you shouldn't be using it until we get it more polished. We do want to know about issues such as these, but it will probably be a while longer before everything is the way we want it. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT trunk compile errors rev5009
Ahh - gotcha. Wouldn't this be a backwards compatability issue with the JDK? I thought Sun took those seriously (or is that only for the JVM itself)? Also as an aside, for some reason update-alternatives for javac was insufficient. I have a feeling that ant looks at the java that it was run with to find the path to javac instead of looking at the javac on the path, so I also had to do an update-alternatives for java. On Fri, Mar 13, 2009 at 3:58 AM, John Tamplin j...@google.com wrote: On Fri, Mar 13, 2009 at 3:53 AM, Vitali Lovich vlov...@gmail.com wrote: Don't feel like you need to do this workaround just because I said I was using OpenJDK - that's just the default install. I have no qualms about installing Sun's version (it's just an apt-get away and I'm not a GPL purist). The problem is that the same code is making its way into Sun's 1.7 JDK, so if they don't fix the bug we will have to add the workaround to keep it possible to build with the latest JDK. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
I'm getting the plugins from the gwt-oophm branch. The current install.rdf says 3.0.*. I manually set it to 3.1.*. Installs fine now in 3.1. I just built the thing from trunk, applied the previous patch for HostedMode, and now have my gwt 1.6 project running successfully on 64-bit Ubuntu 8.10. I might try, just for the hell of it to reboot see if it'll work in Windows. One comment is that even after the patch, I still need to include the platform specific dev (gwt-dev-linux) or there are unresolved class references (i.e. HostedModeBase). I think the ant build script needs to be updated to pull in the appropriate files from core/. Otherwise, thanks keep up the amazing work. On Mon, Mar 9, 2009 at 8:27 AM, Vitali Lovich vlov...@gmail.com wrote: *S*orry meant to put this in my previous e-mail. GWT OOPHM Plugin File name: npOOPHM.dll GWT OOPHM Plugin MIME Type Description Suffixes Enabled application/x-gwt-hosted-mode Plugin to allow debugging of GWT applications in hosted mode. Yes On Mon, Mar 9, 2009 at 8:26 AM, Vitali Lovich vlov...@gmail.com wrote: The OOPHM is registered in Firefox 3.0. Firefox 3.1 doesn't have it registered (which used the XPCOM plugin instead of the Firefox one). On Mon, Mar 9, 2009 at 1:03 AM, Vitali Lovich vlov...@gmail.com wrote: OK - I'll check as soon as I get the chance to work on my GWT project. On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin j...@google.com wrote: On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich vlov...@gmail.comwrote: It said that the (firefox) plugin is incompatible with this version of firefox. It's probably just the version number - you need to bump it up to 3.1. Even if the ABI remains the same, AFAIK, plugins still have to have their versions bumped if they specify a maximum. The XPCOM plugin installs on both. Registering the dll does nothing for IE (I made sure to launch the 32-bit version). I believe the version was set to 3.*, so that should be compatible, though I need to check the version actually checked into the branch. I didn't look in the about:plugins - just the add-ons menu. Would there be a difference? The machine with my project is in Linux for the time being (until some-time Monday), so if there is a difference, I can only check after then. The add-ons simply shows the XPI is installed. The install registers a plugin for a specific MIME type used to access it from the hosted.html, and that should show up in about:plugins. if not, then it was unable to actually load the plugin, which in the past has tended to be library version issues. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
Oh - one question I had is if there's a way to set the browser path? On Fri, Mar 13, 2009 at 7:22 AM, Vitali Lovich vlov...@gmail.com wrote: I'm getting the plugins from the gwt-oophm branch. The current install.rdf says 3.0.*. I manually set it to 3.1.*. Installs fine now in 3.1. I just built the thing from trunk, applied the previous patch for HostedMode, and now have my gwt 1.6 project running successfully on 64-bit Ubuntu 8.10. I might try, just for the hell of it to reboot see if it'll work in Windows. One comment is that even after the patch, I still need to include the platform specific dev (gwt-dev-linux) or there are unresolved class references (i.e. HostedModeBase). I think the ant build script needs to be updated to pull in the appropriate files from core/. Otherwise, thanks keep up the amazing work. On Mon, Mar 9, 2009 at 8:27 AM, Vitali Lovich vlov...@gmail.com wrote: *S*orry meant to put this in my previous e-mail. GWT OOPHM Plugin File name: npOOPHM.dll GWT OOPHM Plugin MIME Type Description Suffixes Enabled application/x-gwt-hosted-mode Plugin to allow debugging of GWT applications in hosted mode. Yes On Mon, Mar 9, 2009 at 8:26 AM, Vitali Lovich vlov...@gmail.com wrote: The OOPHM is registered in Firefox 3.0. Firefox 3.1 doesn't have it registered (which used the XPCOM plugin instead of the Firefox one). On Mon, Mar 9, 2009 at 1:03 AM, Vitali Lovich vlov...@gmail.com wrote: OK - I'll check as soon as I get the chance to work on my GWT project. On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin j...@google.com wrote: On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich vlov...@gmail.comwrote: It said that the (firefox) plugin is incompatible with this version of firefox. It's probably just the version number - you need to bump it up to 3.1. Even if the ABI remains the same, AFAIK, plugins still have to have their versions bumped if they specify a maximum. The XPCOM plugin installs on both. Registering the dll does nothing for IE (I made sure to launch the 32-bit version). I believe the version was set to 3.*, so that should be compatible, though I need to check the version actually checked into the branch. I didn't look in the about:plugins - just the add-ons menu. Would there be a difference? The machine with my project is in Linux for the time being (until some-time Monday), so if there is a difference, I can only check after then. The add-ons simply shows the XPI is installed. The install registers a plugin for a specific MIME type used to access it from the hosted.html, and that should show up in about:plugins. if not, then it was unable to actually load the plugin, which in the past has tended to be library version issues. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
That's not the problem. I'm running FF3.1 beta which is firefox-3.1 on the path (MOZ_NO_REMOTE doesn't apply since they are different profiles). I'm probably just going to make a symlink in $HOME/bin have that prepended to the environment path when launching OOPHM. On Fri, Mar 13, 2009 at 10:17 AM, John Tamplin j...@google.com wrote: On Fri, Mar 13, 2009 at 7:24 AM, Vitali Lovich vlov...@gmail.com wrote: Oh - one question I had is if there's a way to set the browser path? Right now it just execs firefox URL, so if you set the PATH GWT sees to include the Firefox you want to run it will use that. If you have multiple version though, you have to have different profiles and use MOZ_NO_REMOTE=1, so you will have to write a wrapper script for that. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Scaling images in resource bundles
Would it be possible to have the annotation in the image bundle also include the desired size, so that the GWT compiler can auto-scale the source image to the appropriate size. That way we wouldn't have to maintain a high-res version of the icons in addition to the scaled down version we want. Is this a good idea? Thanks, Vitali --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
The OOPHM is registered in Firefox 3.0. Firefox 3.1 doesn't have it registered (which used the XPCOM plugin instead of the Firefox one). On Mon, Mar 9, 2009 at 1:03 AM, Vitali Lovich vlov...@gmail.com wrote: OK - I'll check as soon as I get the chance to work on my GWT project. On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin j...@google.com wrote: On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich vlov...@gmail.com wrote: It said that the (firefox) plugin is incompatible with this version of firefox. It's probably just the version number - you need to bump it up to 3.1. Even if the ABI remains the same, AFAIK, plugins still have to have their versions bumped if they specify a maximum. The XPCOM plugin installs on both. Registering the dll does nothing for IE (I made sure to launch the 32-bit version). I believe the version was set to 3.*, so that should be compatible, though I need to check the version actually checked into the branch. I didn't look in the about:plugins - just the add-ons menu. Would there be a difference? The machine with my project is in Linux for the time being (until some-time Monday), so if there is a difference, I can only check after then. The add-ons simply shows the XPI is installed. The install registers a plugin for a specific MIME type used to access it from the hosted.html, and that should show up in about:plugins. if not, then it was unable to actually load the plugin, which in the past has tended to be library version issues. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
*S*orry meant to put this in my previous e-mail. GWT OOPHM Plugin File name: npOOPHM.dll GWT OOPHM Plugin MIME Type Description Suffixes Enabled application/x-gwt-hosted-mode Plugin to allow debugging of GWT applications in hosted mode. Yes On Mon, Mar 9, 2009 at 8:26 AM, Vitali Lovich vlov...@gmail.com wrote: The OOPHM is registered in Firefox 3.0. Firefox 3.1 doesn't have it registered (which used the XPCOM plugin instead of the Firefox one). On Mon, Mar 9, 2009 at 1:03 AM, Vitali Lovich vlov...@gmail.com wrote: OK - I'll check as soon as I get the chance to work on my GWT project. On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin j...@google.com wrote: On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich vlov...@gmail.com wrote: It said that the (firefox) plugin is incompatible with this version of firefox. It's probably just the version number - you need to bump it up to 3.1. Even if the ABI remains the same, AFAIK, plugins still have to have their versions bumped if they specify a maximum. The XPCOM plugin installs on both. Registering the dll does nothing for IE (I made sure to launch the 32-bit version). I believe the version was set to 3.*, so that should be compatible, though I need to check the version actually checked into the branch. I didn't look in the about:plugins - just the add-ons menu. Would there be a difference? The machine with my project is in Linux for the time being (until some-time Monday), so if there is a difference, I can only check after then. The add-ons simply shows the XPI is installed. The install registers a plugin for a specific MIME type used to access it from the hosted.html, and that should show up in about:plugins. if not, then it was unable to actually load the plugin, which in the past has tended to be library version issues. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
On Sun, Mar 8, 2009 at 2:13 PM, John Tamplin j...@google.com wrote: On Sun, Mar 8, 2009 at 12:00 AM, Vitali Lovich vlov...@gmail.com wrote: Yup - using Firefox. No warnings came up. I grabbed the XPCOM plugin from the oophm branch it installed on both FF3.1 FF3.0. The one in the firefox directory only installed in FF3.0. That is odd, since there should be no difference between 3.0 and 3.1 as far as the ABI goes -- did it give you an error message? It said that the (firefox) plugin is incompatible with this version of firefox. It's probably just the version number - you need to bump it up to 3.1. Even if the ABI remains the same, AFAIK, plugins still have to have their versions bumped if they specify a maximum. The XPCOM plugin installs on both. Registering the dll does nothing for IE (I made sure to launch the 32-bit version). On Windows though, the browser JVM are still 32-bit - is this still unsupported? Is x64 Linux supported - that has a 64-bit browser 64-bit JVM. The JVM doesn't matter for OOPHM, what matters is the browser. If the browser is 32-bit on Windows it should work. Does it show up in about:plugins? I didn't look in the about:plugins - just the add-ons menu. Would there be a difference? The machine with my project is in Linux for the time being (until some-time Monday), so if there is a difference, I can only check after then. The 64-bit Linux plugin works, though I have seen weirdness on some distros. I use it on 64-bit Ubuntu 8 and FC9, though for some reason the plugin doesn't initialize on FC10. I suspect library version issues, and getting it where it installs on every distro is one of the polish things that needs to be done before we can replace legacy hosted mode. Luckily I'm using Ubuntu, so I'll try this out as soon as I get back to my GWT project. I'm juggling my last (hopefully) 3 assignments of university right now :D. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
OK - I'll check as soon as I get the chance to work on my GWT project. On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin j...@google.com wrote: On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich vlov...@gmail.com wrote: It said that the (firefox) plugin is incompatible with this version of firefox. It's probably just the version number - you need to bump it up to 3.1. Even if the ABI remains the same, AFAIK, plugins still have to have their versions bumped if they specify a maximum. The XPCOM plugin installs on both. Registering the dll does nothing for IE (I made sure to launch the 32-bit version). I believe the version was set to 3.*, so that should be compatible, though I need to check the version actually checked into the branch. I didn't look in the about:plugins - just the add-ons menu. Would there be a difference? The machine with my project is in Linux for the time being (until some-time Monday), so if there is a difference, I can only check after then. The add-ons simply shows the XPI is installed. The install registers a plugin for a specific MIME type used to access it from the hosted.html, and that should show up in about:plugins. if not, then it was unable to actually load the plugin, which in the past has tended to be library version issues. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
Wait - I'm confused. I am running with trunk I've been unable to get OOPHM working. Thanks. On Sat, Mar 7, 2009 at 10:50 AM, John Tamplin j...@google.com wrote: On Sat, Mar 7, 2009 at 8:40 AM, Allahbaksh Asadullah a.allahba...@gmail.com wrote: I am also using OOPHM from past one month. I see lot of productivity improvement by that. But I am scared when I will move GWT 1.6 then I have to again go back to the Hosted Mode browser. Can't we have very basic functionality available for GWT 1.6. Let it be in trunk so that people interested may build it themselve depending upon their need. But definately I can't wait for one more quarter for OOPHM. I'm sorry but it would be too much work to try and port it back and then maintain two separate branches of OOPHM. It is already enough of a hassle when we merge from 1.6-trunk, making corresponding changes to OOPHM. The answer is if you need OOPHM, you are going to need to be running trunk. I realize it is not ready for production use yet, but you can still do debugging with trunk and do production compiles with 1.6 if necessary. Is GWT 1.6 release is due on Google IO? I'm not the one to comment on release schedules, but you have seen the announcements about the milestones and that the next public build will be a release candidate, so we are getting close. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
I've been using Vista x64. I'll try it out on Linux x64 once I get the chance - I have to get some other stuff done before Monday. On Sat, Mar 7, 2009 at 5:40 PM, John Tamplin j...@google.com wrote: On Sat, Mar 7, 2009 at 3:41 PM, Vitali Lovich vlov...@gmail.com wrote: Wait - I'm confused. I am running with trunk I've been unable to get OOPHM working. I am sure it is something simple as many people, both internally and externally, are successfully using it. When I write up the detailed instructions that should help you get going. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
Yup - using Firefox. No warnings came up. I grabbed the XPCOM plugin from the oophm branch it installed on both FF3.1 FF3.0. The one in the firefox directory only installed in FF3.0. On Windows though, the browser JVM are still 32-bit - is this still unsupported? Is x64 Linux supported - that has a 64-bit browser 64-bit JVM. On Sat, Mar 7, 2009 at 9:36 PM, John Tamplin j...@google.com wrote: On Sat, Mar 7, 2009 at 8:55 PM, Vitali Lovich vlov...@gmail.com wrote: I've been using Vista x64. I'll try it out on Linux x64 once I get the chance - I have to get some other stuff done before Monday. I don't believe the plugin has been built for Windows x86_64 in the branch (I built it XPCOM Windows x86_64 on my machine, but I have no way to test it currently). What browser are you using? If you are using Firefox, it should have told you that the plugin did not support your architecture when you tried to install it. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
Darn. Would there be any branch that does work? On Fri, Mar 6, 2009 at 6:27 PM, John Tamplin j...@google.com wrote: On Fri, Mar 6, 2009 at 6:14 PM, Bruce Johnson br...@google.com wrote: [+John Tamplin, lead dev on OOPHM] @John: Would you have any time to write a short wiki article about how to do this? It does seem like a good way to help people in the community get started trying it out. I will write up a document next week about how to use OOPHM with trunk (it isn't going to be usable with 1.6). -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
