[gwt-contrib] Re: OOPHM development branches
It looks to be more serious than a warning. Immediately after this warning
is printed, the module is unloaded and the oophm plugin is disconnected from
the hosted mode server.
Could it be something to do with my module serializing ArrayList ?
Cam
On Tue, Dec 16, 2008 at 8:40 AM, BobV wrote:
>
> > This isn't a compiler bug, it's caused by hosted mode being perhaps
> slightly
> > overeager? The deal is, the custom field serializer for Arrays.asList()
> >
> (com.google.gwt.user.client.rpc.core.java.util.Arrays.ArrayList_CustomFieldSerializer),
> > has a method getArray0() that uses a JSNI reference that's only valid
> > against our own JRE emulation classes... it's not valid against a real
> JRE.
> > This is okay, because the call to that method is guarded by a
> > GWT.isScript() block.
> > Bob, thoughts?
>
> The problem here is that we need to rewrite the JSNI method with the
> numeric dispatch ids before we inject the code into the browser.
> Previously, dispatch was string-based so it wasn't a problem. We
> could add an @SuppressWarnings("jsni") to the method to squelch
> warnings like this.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
On Mon, Dec 15, 2008 at 9:45 AM, Cameron Braid wrote: > b) bug in hosted.html - see overlay-hosted.html.patch > > The patch for hosted.html is required because I need gwt to support a url > encoded gwt.hosted value My webapp re-writes urls to pass along some query > string parameters from page to page. It converts 127.0.1.1:9997 into > 127.0.1.1%3A9997 when it url encodes it, and hosted.html currently doesn't > unescape it. > > I've added an issue to track this bug. http://code.google.com/p/google-web-toolkit/issues/detail?id=3291&can=4 Its a pretty simple patch - is someone able to check it out and apply it to trunk ? Cheers Cameron --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
> This isn't a compiler bug, it's caused by hosted mode being perhaps slightly
> overeager? The deal is, the custom field serializer for Arrays.asList()
> (com.google.gwt.user.client.rpc.core.java.util.Arrays.ArrayList_CustomFieldSerializer),
> has a method getArray0() that uses a JSNI reference that's only valid
> against our own JRE emulation classes... it's not valid against a real JRE.
> This is okay, because the call to that method is guarded by a
> GWT.isScript() block.
> Bob, thoughts?
The problem here is that we need to rewrite the JSNI method with the
numeric dispatch ids before we inject the code into the browser.
Previously, dispatch was string-based so it wasn't a problem. We
could add an @SuppressWarnings("jsni") to the method to squelch
warnings like this.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
On Sun, Dec 14, 2008 at 6:45 PM, Cameron Braid wrote: > a) bug in compiler - see attached oophm-stacktrace.txt > This isn't a compiler bug, it's caused by hosted mode being perhaps slightly overeager? The deal is, the custom field serializer for Arrays.asList() (com.google.gwt.user.client.rpc.core.java.util.Arrays.ArrayList_CustomFieldSerializer), has a method getArray0() that uses a JSNI reference that's only valid against our own JRE emulation classes... it's not valid against a real JRE. This is okay, because the call to that method is guarded by a GWT.isScript() block. Bob, thoughts? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
I've been giving OOPHM a try and have run into a couple of issues a) bug in compiler - see attached oophm-stacktrace.txt b) bug in hosted.html - see overlay-hosted.html.patch The patch for hosted.html is required because I need gwt to support a url encoded gwt.hosted value My webapp re-writes urls to pass along some query string parameters from page to page. It converts 127.0.1.1:9997 into 127.0.1.1%3A9997 when it url encodes it, and hosted.html currently doesn't unescape it. Cheers Cameron On Fri, Dec 12, 2008 at 9:41 AM, John Tamplin wrote: > On Thu, Dec 11, 2008 at 6:12 PM, Sam Gross wrote: > >> In which branch is OOPHM development taking place? I see trunk/dev/oophm, >> but this project seems to cause compile errors for the gwt-user project, >> since the version of GWTShell in trunk/dev/oophm is missing some expected >> methods. >> > > The main code will be maintained in trunk -- the plugins will be in > branches/oophm while we figure out their long-term location. The idea is > that we refactor further to reduce the overlaid classes, and then when we > are ready we just move the files from gwt-dev-oophm into gwt-dev (doing away > with the various platforms at the same time). > > What errors do you get? I see dev (core and oophm) build errors depending > on the Java version I use related to inferring generic types (the fix is to > assign the result of artifacts.find to a local variable before using it in > the enhanced for, I haven't tracked down exactly why it works some places or > others and I have some open changes in that area is why I haven't submitted > them), but nothing specific to OOPHM. With those fixed in > StandardGeneratorContext, GWTShell (both core and oophm), > SelectionScriptLinker, and StandardLinkerContext, it compiles and runs fine > for me. > > >> What are the key things that need to be done before OOPHM is the default >> hosted-mode in trunk? >> > > I think the primary thing is time with people using it so we can feel > confident that it won't break anyone. The UI needs some improvement (though > it is usable as-is), and there are some testing issues that need to be > addressed. The reason for putting it in trunk as an overlay is so that > people could test it without breaking people who couldn't use it for > whatever reason, and to hopefully keep it up to date as the trunk is > changed. There is also the issue of competing priorities, as usual. > > Next week I have a task to get it OOPHM usable (in its overlay form) for > some internal projects, so anything preventing it from being useful as it is > in trunk currently should be shaken out then. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- 00:00:37.355 [WARN] Member 'array' in JSNI reference '@java.util.Arrays$ArrayList::array' could not be found; expect subsequent failures java.lang.NoSuchFieldError: array at com.google.gwt.dev.shell.CompilingClassLoader$DispatchClassInfoOracle.getDispId(CompilingClassLoader.java:132) at com.google.gwt.dev.shell.CompilingClassLoader.getDispId(CompilingClassLoader.java:559) at com.google.gwt.dev.util.Jsni$JsSourceGenWithJsniIdentFixup.visit(Jsni.java:105) at com.google.gwt.dev.js.ast.JsNameRef.traverse(JsNameRef.java:120) at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438) at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413) at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96) at com.google.gwt.dev.js.JsToStringGenerationVisitor.visit(JsToStringGenerationVisitor.java:694) at com.google.gwt.dev.js.ast.JsReturn.traverse(JsReturn.java:45) at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438) at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413) at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96) at com.google.gwt.dev.js.JsToStringGenerationVisitor.printJsBlockOptionalTruncate(JsToStringGenerationVisitor.java:819) at com.google.gwt.dev.js.JsSourceGenerationVisitor.visit(JsSourceGenerationVisitor.java:48) at com.google.gwt.dev.js.ast.JsBlock.traverse(JsBlock.java:43) at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438) at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413) at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96) at com.google.gwt.dev.util.Jsni.generateJavaScriptForHostedMode(Jsni.java:253) at com.google.gwt.dev.util.Jsni.getJavaScriptForHostedMode(Jsni.java:240) at com.google.gwt.dev.shell.ModuleSpaceOOPHM.createNativeMethods(ModuleSpaceOOPHM.java:50) at com.google.gwt.dev.shell.CompilingClassLoader.injectJsniFor(CompilingClassLoader.java:736) at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:653) at java.lang.ClassLoader.loadClass(Cla
[gwt-contrib] Re: OOPHM development branches
On Thu, Dec 11, 2008 at 6:12 PM, Sam Gross wrote: > In which branch is OOPHM development taking place? I see trunk/dev/oophm, > but this project seems to cause compile errors for the gwt-user project, > since the version of GWTShell in trunk/dev/oophm is missing some expected > methods. > The main code will be maintained in trunk -- the plugins will be in branches/oophm while we figure out their long-term location. The idea is that we refactor further to reduce the overlaid classes, and then when we are ready we just move the files from gwt-dev-oophm into gwt-dev (doing away with the various platforms at the same time). What errors do you get? I see dev (core and oophm) build errors depending on the Java version I use related to inferring generic types (the fix is to assign the result of artifacts.find to a local variable before using it in the enhanced for, I haven't tracked down exactly why it works some places or others and I have some open changes in that area is why I haven't submitted them), but nothing specific to OOPHM. With those fixed in StandardGeneratorContext, GWTShell (both core and oophm), SelectionScriptLinker, and StandardLinkerContext, it compiles and runs fine for me. > What are the key things that need to be done before OOPHM is the default > hosted-mode in trunk? > I think the primary thing is time with people using it so we can feel confident that it won't break anyone. The UI needs some improvement (though it is usable as-is), and there are some testing issues that need to be addressed. The reason for putting it in trunk as an overlay is so that people could test it without breaking people who couldn't use it for whatever reason, and to hopefully keep it up to date as the trunk is changed. There is also the issue of competing priorities, as usual. Next week I have a task to get it OOPHM usable (in its overlay form) for some internal projects, so anything preventing it from being useful as it is in trunk currently should be shaken out then. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
