Re: It should be registered via or entry in your .gwt.xml ?
On Thursday, December 31, 2015 at 12:45:11 AM UTC+1, cellepo wrote: > > It doesn't look like is a possible Element type in GWT 2.7? > > I can add , but when I add a ... > > *The content of element type "module" must match > "(inherits|source|public|super-source|entry-point|stylesheet|* > > * > script|servlet|replace-with|generate-with|define-property|extend-property|set-property|set-property-fallback|* > > * > clear-configuration-property|define-configuration-property|extend-configuration-property|set-configuration-* > > * > property|property-provider|define-linker|add-linker|collapse-all-properties|collapse-property)*".* > > > Unless I'm missing it, I don't see resource in that list, which seems to > be why I can't add a . Unless I'm missing something? > GWT doesn't validate the XML (using a DTD or schema); so this error message doesn't come from GWT. …and yes the DTD is out of date. Patch welcome (real "schema" is defined in ModuleDefSchema class) > > On Tuesday, March 24, 2015 at 1:58:01 PM UTC-4, MacWiz wrote: >> >> Thanks Thomas. Adding a fixed these. I >> thought I had tried that, but apparently not. As far as the location of >> the images, we are discussing moving them, as you suggest. They've been in >> our public area since the beginning of our GWT based work many years ago >> (starting with GWT v1.3, I believe.) >> > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: It should be registered via or entry in your .gwt.xml ?
It doesn't look like is a possible Element type in GWT 2.7? I can add , but when I add a ... *The content of element type "module" must match "(inherits|source|public|super-source|entry-point|stylesheet|* * script|servlet|replace-with|generate-with|define-property|extend-property|set-property|set-property-fallback|* * clear-configuration-property|define-configuration-property|extend-configuration-property|set-configuration-* * property|property-provider|define-linker|add-linker|collapse-all-properties|collapse-property)*".* Unless I'm missing it, I don't see resource in that list, which seems to be why I can't add a . Unless I'm missing something? On Tuesday, March 24, 2015 at 1:58:01 PM UTC-4, MacWiz wrote: > > Thanks Thomas. Adding a fixed these. I > thought I had tried that, but apparently not. As far as the location of > the images, we are discussing moving them, as you suggest. They've been in > our public area since the beginning of our GWT based work many years ago > (starting with GWT v1.3, I believe.) > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Getting rid of Dev mode for future GWT releases
Well, except that JsInterop doesn't work in legacy dev mode. -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Getting rid of Dev mode for future GWT releases
In the past, I had encountered situations that the code works fine under Dev-Mode, but things went wrong in production mode, or acted differently in production mode. At the beginning I had a hard time to switch from Dev-Mode to SDM. It took me "forever" to trace the bugs in my code. I found that things got a lot easier when I start new project from the very beginning using SDM. More Java code in the Browser-end means more stuff GWT needs to convert into JavaScript. With using SDM, it encourages me to use more HTML / CSS / JavaScript instead of using GWT-Java only. -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Getting rid of Dev mode for future GWT releases
> With that being said, I'd really love to reattain the level of > productivity that I perceive with DevMode when it comes to debugging. SDBG > just doesn't even come close to what I consider a real debugger. Stepping > and watching variables is just by far not enough by today's IDE standards. > I'm not an expert in native browser's JavaScript debugger capabilities. > What keeps SDBG from providing the above list of features? If the compiler > can map expressions to JavaScript, why can't SDM map those same expressions > to something that the native JavaScript debugger can evaluate in-place for > the current stack frame? Don't native JavaScript debuggers support > conditional breakpoint? It would also come down to injecting the compiled > expressions as breakpoint conditions. Don't native JavaScript debuggers > support drop-to-frame? If not, can we expect this to change in the future? > And what about the dynamic value changes in a native JavaScript debugger? > Javascript debuggers can do most of the things you are asking for. The Chrome debugger can do conditional breakpoints, restart a frame (drop-in-frame), and I think it can also override JS values just fine. It can break on any exception (caught and uncaught) and inside the browser dev tools you can hover certain expressions and see their value. Some of these features also work in IDEs using SDBG or plain IntelliJ. For example conditional break points just work in IntelliJ, but you have to use JS expressions as you are debugging JS and not Java (how should the IDE dynamically convert a any possible Java expression to a JS expression on the fly as the browser debugger only understands JS ?!). Never tried the drop-to-frame feature but I guess it might also work. AFAICT to make cross language debugging better, the source maps spec needs to be updated. Currently it seems to lack some information. For example I think it misses variable/parameter names, otherwise chrome debugger would probably show java names instead of JS names in the debugger. On the other hand it is handy that I can see JS variable names as that makes conditional breakpoints possible as I need to use JS expressions ;-) By the way you would have the same issues with any language compiling to JS, not just GWT. The only exception might be Dart as there is a Dart VM for Chrome. But once you have compiled Dart to JS you are probably in the same situation as with GWT if you need to debug the JS code and use source maps. -- J. -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Remove unused code of external JavaScript file?
I have an external JavaScript file which I use using JSNI or JS Interop. I only use parts of this js file/ library. *Is it possible to reduce the code of this external js file using GWT?* -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Getting rid of Dev mode for future GWT releases
@Axel: thanks for sharing and you are 100% spot on I also like to know if/how SDBG can be improved to benefit the full debugging power -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: How to solve RPC error: Character Encoding is 'text/'. Expected 'UTF-8'
@Thomas: thanks for the tips, I will perform some logging of the Content-Type to see where it's coming from. -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Getting rid of Dev mode for future GWT releases
I've been using GWT now since about version 1.3. I chose it at the time because I really liked the manifesto and in particular the line "Java debugging is non-negotiable" (see http://www.gwtproject.org/makinggwtbetter.html). I admire folks who live without a debugger. Maybe they have the rigor to write code that simply doesn't require it. Or they have most of their code reside on the server, as one of the fellows wrote above. Or they have client code that for other reasons does not have to perform complicated tasks, maybe because the application is simple in its requirements. However, when these factors are not given (and the GWT architecture has helped and guided us to exploit a lot more of the powerful browser platforms by shifting significant elements of our applications to the client), having a powerful debugger is a tool that makes me much more productive in my work. Features that I subsume under "powerful" are in particular (in decreasing degree of importance to me) - instant expression inspection (Eclipse: Shift-Ctrl-i to inspect the expression you just marked; works even on hover over fields and stack variables) - conditional breakpoints (provide a boolean expression and break if true; or break upon reaching an invocation count which I don't use that often) - drop to frame (after meticulously moving to where the problem is, hitting F6 one time too often...; no problem with drop to frame) - dynamically altering field and variable values (makes for a powerful couple in conjunction with drop to frame as it allows me to play "what if") Inserting print statements may work for some. It doesn't if that code is a library that isn't easy to change. I don't want to have to unpack all sources first only in order to get "conditional breaking." Apart from that, the SDBG / GWT 2.7 combo is really "surprising" at times when I do an F6 to step over a line or expression and I end up in some Iterator or Collection implementation because that's how that for-loop is actually happening. Also, the subtle differences in behavior of F6 for multi-line statements between native Java/JVM and SDBG/SDM debugging increasingly annoy me. For Java, F6 goes to the next line, e.g., in a multi-line expression embedded in a statement. For SDM, F6 executes the entire statement. Bad luck if what you wanted to check was in the third line of your three lines long statement (and there is no drop to frame, either...). It really takes some getting used to and to me feels far from usable for my every-day work. I really appreciate the speed that SDM provides. I've been using it since more than a year now, also together with SDBG in Eclipse. The incremental compile works like a charm, even when radically switching branches. There are clearly benefits in having the browser's JavaScript engine execute "the real thing" instead of running the client in the JVM and then having the costly browser integration that in several dimensions doesn't feel "real" (performance and stability, mostly). I also understand that browsers have changed in ways that make maintaining the existing DevMode plugin impossible. With that being said, I'd really love to reattain the level of productivity that I perceive with DevMode when it comes to debugging. SDBG just doesn't even come close to what I consider a real debugger. Stepping and watching variables is just by far not enough by today's IDE standards. I'm not an expert in native browser's JavaScript debugger capabilities. What keeps SDBG from providing the above list of features? If the compiler can map expressions to JavaScript, why can't SDM map those same expressions to something that the native JavaScript debugger can evaluate in-place for the current stack frame? Don't native JavaScript debuggers support conditional breakpoint? It would also come down to injecting the compiled expressions as breakpoint conditions. Don't native JavaScript debuggers support drop-to-frame? If not, can we expect this to change in the future? And what about the dynamic value changes in a native JavaScript debugger? Removal of DevMode without adequate improvements in SDM as outlined above, despite the promises of further performance improvements beyond 2.8, could be a valid reason to never upgrade beyond 2.8 anymore and keep a good old FF or IE version around that helps us with the heavy-lifting of debugging when it is really required. Best, -- Axel (sapsailing.com) -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Getting rid of Dev mode for future GWT releases
I don't think it's technically impossible to keep DevMode running. I was able to get DevMode to work using JavaFx as the browser instead of Chrome, and it seemed to work ok for basic stuff. It might also be possible to port the GWT UI framework to Elemental, and I've also been able to get Elemental to run in Java on top of JavaFx. I suppose it's even possible to make special versions of Firefox or Chrome that have the features needed to support the DevMode plugin directly. I doubt that Google sees any value in maintaining DevMode for itself though. But I imagine if you have a support contract with an enterprise software firm selling GWT stuff like Vaadin or RedHat, you could probably bug them to do the necessary work to make it happen. -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
ArrayIndexOutOfBoundsException in GWT Compiler for non-trivial type arg in RPC service parameter
Hi there, we've been encountering a strange compiler error when making special use of generics in GWT RPC service parameters. I've tried to boil it down to an example that you can find here as a ready-to-fail Eclipse project: https://drive.google.com/file/d/0BzPFwCC87Ht6VVVoQ0hjY3BoREU/view?usp=sharing The exception the compiler throws is this: Compiling module gwt.generics.bug.Gwt_generics_bug Computing all possible rebind results for 'gwt.generics.bug.client.GreetingService' Rebinding gwt.generics.bug.client.GreetingService Invoking generator com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator [ERROR] Generator 'com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator' threw an exception while rebinding 'gwt.generics.bug.client.GreetingService' java.lang.ArrayIndexOutOfBoundsException: 1 at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.getFlowInfo(TypeParameterExposureComputer.java:420) at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.access$200(TypeParameterExposureComputer.java:40) at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.getFlowInfo(TypeParameterExposureComputer.java:322) at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.recordCausesExposure(TypeParameterExposureComputer.java:329) at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.computeIndirectExposureCauses(TypeParameterExposureComputer.java:269) at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.initializeExposure(TypeParameterExposureComputer.java:195) at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.updateFlowInfo(TypeParameterExposureComputer.java:169) at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.computeTypeParameterExposure(TypeParameterExposureComputer.java:398) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.getFlowInfo(SerializableTypeOracleBuilder.java:1373) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.getTypeParameterExposure(SerializableTypeOracleBuilder.java:1006) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:1330) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:1176) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:1262) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:994) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:1337) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:1176) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:1262) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:994) at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.build(SerializableTypeOracleBuilder.java:792) at com.google.gwt.user.rebind.rpc.ProxyCreator.create(ProxyCreator.java:324) at com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator.generateIncrementally(ServiceInterfaceProxyGenerator.java:67) at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:754) at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:160) at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:79) at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:276) at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:265) at com.google.gwt.dev.DistillerRebindPermutationOracle.getAllPossibleRebindAnswers(DistillerRebindPermutationOracle.java:87) at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.createStaticRebindExpression(UnifyAst.java:485) at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.createRebindExpression(UnifyAst.java:443) at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.handleMagicMethodCall(UnifyAst.java:576) at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.endVisit(UnifyAst.java:306) at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:248) at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:381) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:293) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:285) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:128) at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:42) at com.google.gwt.dev.jjs.ast.JModVisitor$ListContext.traverse(JModVisitor.ja
Re: How to solve RPC error: Character Encoding is 'text/'. Expected 'UTF-8'
Somehow your HttpServletRequest is "broken" and returns "text/" as character encoding: https://github.com/gwtproject/gwt/blob/ad8ed35116bf22efdfdcf6984a3a3d79e26ded04/user/src/com/google/gwt/user/server/rpc/RPCServletUtils.java#L425 This might be due either to bad parsing somewhere (Tomcat?), a broken servlet filter that passes a broken request down the chain, or a ill-formed Content-Type header received by Tomcat. Logging of Content-Type request headers at different stages could help identify what's broken. On Wednesday, December 30, 2015 at 5:00:09 PM UTC+1, Ed wrote: > > Sometimes I do get the following stacktrace during RPC communication with > the Tomcat backend. > Any idea how to solve this, and what could cause this ? > - Ed > > javax.servlet.ServletException: Character Encoding is 'text/'. Expected > 'UTF-8' > > at > com.google.gwt.user.server.rpc.RPCServletUtils.checkCharacterEncodingIgnoreCase(RPCServletUtils.java:439) > > > at > com.google.gwt.user.server.rpc.RPCServletUtils.readContent(RPCServletUtils.java:212) > > > at > com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsGwtRpc(RPCServletUtils.java:252) > > > at > com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.readContent(AbstractRemoteServiceServlet.java:182) > > > > > > > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
How to solve RPC error: Character Encoding is 'text/'. Expected 'UTF-8'
Sometimes I do get the following stacktrace during RPC communication with the Tomcat backend. Any idea how to solve this, and what could cause this ? - Ed javax.servlet.ServletException: Character Encoding is 'text/'. Expected 'UTF-8' at com.google.gwt.user.server.rpc.RPCServletUtils.checkCharacterEncodingIgnoreCase(RPCServletUtils.java:439) at com.google.gwt.user.server.rpc.RPCServletUtils.readContent(RPCServletUtils.java:212) at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsGwtRpc(RPCServletUtils.java:252) at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.readContent(AbstractRemoteServiceServlet.java:182) -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: JsInterop & 2.8.0-SNAPSHOT : calling Java Object in Javascript
> Same behaviour with -*draftCompile*, I've also tried *optimizationLevel* > to 0 > Hmm and you are double sure that the compiler is really called with - *generateJsInteropExports* and not just SuperDevMode? Also in some rare cases the incremental compile cache of SuperDevMode can cause strange behavior (e.g. make things work that are broken, or the other way around). If you want to be double sure that SuperDevMode works you can start SDM, visit localhost:9876, hit the small "clean" button and then restart SDM. This will cause SDM to start fresh without any caches. -- J. -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: JsInterop & 2.8.0-SNAPSHOT : calling Java Object in Javascript
Same behaviour with -*draftCompile*, I've also tried *optimizationLevel* to 0 Le mercredi 30 décembre 2015 00:35:12 UTC+1, Jens a écrit : > > I *think* it does not look too bad. You can compile your app using -mode > PRETTY (or DETAILED if you also need package infos) so you can read the > final JS output to see what went wrong. The only difference between > SuperDevMode and a normal compile is that a normal compile optimizes your > code. When you do a normal compile using -draftCompile then its pretty > similar to SuperDevMode. When it works this way then you have probably > found a bug caused by optimizations. > > -- J. > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
