Re: Ant test: class file for org.apache.tools.ant.Task not found
+1 on this problem. Tried w/ ant 1.8.2 and 1.7.1, on ubuntu 12.10 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/-55iesM8ED8J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Issue while upgrading to to GWT 2.5RC build
You might have a corrupt gwt-user.jar; if your SHA checksum doesn't match the one from code.google.com/p/google-web-toolkit/ then you should unzip a fresh copy. Either that, or your IDE is recompiling the classes as the builder is running, so it gets an IO exception when trying to lookup classes. A good rule of thumb, if you have Build Automatically enabled in your IDE, don't save any files until your compile hits the Compiling Permutations stage. On Friday, July 13, 2012 2:00:50 AM UTC-6, Sandeep Shetty wrote: I am getting the below error when updating to GWT 2.5RC from GWT 2.4. I updated the following jars: gwt-dev.jar,gwt-servlet.jar,gwt-servlet-deps.jar, gwt-user.jar. Please let me know solutions or if i am doing something wrong. Any help will be appreciate. The error: [java][WARN] Unable to read: jar:file:/E:/Sandeep/views/Sandeep_vblrwndv002_build-catfish-ui/cn/tools/gwt/core/gwt-user.jar!/com/google/gwt/user/User.gwtar. Skipping: java.io.InvalidClassException: com.google.gwt.dev.jjs.SourceOrigin$1; local class incompatible: stream classdesc serialVersionUID = -2407201776821563037, local class serialVersionUID = 4713379764594032837 [java][WARN] Unable to read: jar:file:/E:/Sandeep/views/Sandeep_vblrwndv002_build-catfish-ui/cn/tools/gwt/core/gwt-user.jar!/com/google/gwt/core/Core.gwtar. Skipping: java.io.InvalidClassException: com.google.gwt.dev.jjs.SourceOrigin$1; local class incompatible: stream classdesc serialVersionUID = -2407201776821563037, local class serialVersionUID = 4713379764594032837 [java][WARN] Unable to read: jar:file:/E:/Sandeep/views/Sandeep_vblrwndv002_build-catfish-ui/cn/tools/gwt/core/gwt-user.jar!/com/google/gwt/user/User.gwtar. Skipping: java.io.InvalidClassException: com.google.gwt.dev.jjs.SourceOrigin$1; local class incompatible: stream classdesc serialVersionUID = -2407201776821563037, local class serialVersionUID = 4713379764594032837 [java][WARN] Unable to read: jar:file:/E:/Sandeep/views/Sandeep_vblrwndv002_build-catfish-ui/cn/tools/gwt/core/gwt-user.jar!/com/google/gwt/core/Core.gwtar. Skipping: java.io.InvalidClassException: com.google.gwt.dev.jjs.SourceOrigin$1; local class incompatible: stream classdesc serialVersionUID = -2407201776821563037, local class serialVersionUID = 4713379764594032837 [java][WARN] Unable to read: jar:file:/E:/Sandeep/views/Sandeep_vblrwndv002_build-catfish-ui/cn/tools/gwt/core/gwt-user.jar!/com/google/gwt/xml/XML.gwtar. Skipping: java.io.InvalidClassException: com.google.gwt.dev.jjs.SourceOrigin$1; local class incompatible: stream classdesc serialVersionUID = -2407201776821563037, local class serialVersionUID = 4713379764594032837 [java][WARN] Unable to read: jar:file:/E:/Sandeep/views/Sandeep_vblrwndv002_build-catfish-ui/cn/tools/gwt/core/gwt-user.jar!/com/google/gwt/xml/XML.gwtar. Skipping: java.io.InvalidClassException: com.google.gwt.dev.jjs.SourceOrigin$1; local class incompatible: stream classdesc serialVersionUID = -2407201776821563037, local class serialVersionUID = 4713379764594032837 [java]Validating units: [java] Ignored 2 units with compilation errors in first pass. [java] Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors. [java]Validating units: [java] Ignored 2 units with compilation errors in first pass. [java] Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors. [java][ERROR] An internal compiler exception occurred [java] com.google.gwt.dev.jjs.InternalCompilerException: Unexpected error during visit. [java] at com.google.gwt.dev.jjs.ast.JVisitor.translateException(JVisitor.java:109) [java] at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:276) [java] at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265) [java] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116) [java] at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:41) [java] at com.google.gwt.dev.jjs.ast.JModVisitor$ListContextImmutable.traverse(JModVisitor.java:170) [java] at com.google.gwt.dev.jjs.ast.JModVisitor.acceptWithInsertRemoveImmutable(JModVisitor.java:336) [java] at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:83) [java] at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) [java] at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273) [java] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:137) [java] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:133) [java] at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:82) [java] at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) [java] at
Re: Issue while upgrading to to GWT 2.5RC build
Also, if you are using an IBM JDK, please look here: https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/5iL8i06mhC0 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/ozmVLzl6X6sJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: SuperDevMode and APT
In addition to the aforementioned .rpc file lookup fix, you may also want to put up a servlet filter to catch all requests for files on a given module's base url (easy if your rpc urls don't have . in them;), and simply proxy those file requests to the codeserver (HttpClient / UrlFetch) when on localhost (or if config property set). This way, from the client's perspective, all files originate from the application host. Doing this will also enable source map support and avoid any cross-domain server issues if you're serving files into a restricted zone, like flash player. If you catch 404s to the code server, you can just forward the request to the production-mode static files compiled in your war. The other option same-domain option is to proxy requests that the code server misses to the application server, but this is much, much slower, since it costs more to tax every ajax request instead of every static file request. On Thursday, June 14, 2012 3:15:03 PM UTC-6, Stefano Ciccarelli wrote: Great idea! It should work on GAE too using UrlFetch api to talk with the code server. Could you share some pieces of code, please? -- Inviato con Sparrow http://www.sparrowmailapp.com/?sig Il giorno giovedì 14 giugno 2012, alle ore 11:33, Paul Robinson ha scritto: On 13/06/12 18:53, Andrea Boscolo wrote: I can confirm that copying the CodeServer's .gwt.rpc files in the local war dir, works but it's a pain: every time they change, they need to be copied. There's an alternative to copying gwt.rpc files. I've changed my app so that when it looks for the serialization policy, and it can't find it, it will ask the code server for it. You just need to parse the module base URL to get the module name, and then use the strong name provided to generate the appropriate URL, something like: http://localhost:9876/modulename/strongname.gwt.rpc All I need to do now is to add the codeserver URL as a parameter in web.xml so that this feature can be enabled/disabled so it doesn't happen in production. I don't know whether this technique would work on GAE as well. Paul -- -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Dq2M3AhmDJMJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: SuperDevMode stuck on compiling
A note on bad practices leading to frail code... Calling values.hasOwnProperty will likely be fine if the values object only ever comes from generated gwt code, but from experience elsewhere, I always try to do Object.prototype.hasOwnProperty.call(values, prop); Obviously if anyone wrecks .hasOwnPropety, they can't honestly expect support, but for objects created with Object.create(null), there will be no Object prototype and .hasOwnProperty won't exist. Not really relevant to this bug, but for the sake of promoting good practices, I thought I'd mention it. On Thursday, July 12, 2012 2:24:06 PM UTC-6, Chris Gamache wrote: Posted... http://code.google.com/p/google-web-toolkit/issues/detail?id=7513 Thank you for all your help! On Wednesday, July 11, 2012 12:16:31 PM UTC-4, Thomas Broyer wrote: On Wednesday, July 11, 2012 5:46:16 PM UTC+2, Chris Gamache wrote: I am using Ext-Js LGPL via GWT-Ext, and they have indeed modified the Array prototype. Not much I can do about that. I'm stuck there. I hacked in the modification, and it will get through to compile now. Is there already an issue in the tracker for the xsiframe generator bug/bad practice? I don't know of any, and this __getPropMap seems to only be used for SuperDevMode so it's not surprising that this bug hadn't been discovered yet. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/PuWBAWcxIQkJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: hard time to get GWTTestCase to work
Anywhere you find yourself re-writing the same code more than three times, you would likely benefit from a generator. Can you give some examples? - GWT.runAsync(); same boilerplate every time, but in order to work, each call must be behind a method of its own. The lightweight dependency injection code I'm working on now wraps all this up behind a generated provider method. It creates a RunAsyncCallback subclass for every marked async, and generates all the boilerplate to inject the implementation behind a code split. To write by hand, you must, at the very least, implement the RunAsyncCallback class, plus some kind of sanity-check to avoid dupping the provided object. Using a generator, it's a single line to annotate the target type, and a single method which takes an interface class and a callback to do DI + code split. Another good example is DTO objects. How many bean objects have you had to make just to pass around a couple strings and ints? Using an interface + generator (like autobeans), you can just write out the type of data you want, and let the generator supply implementations on client (and server, if you're crafty). One example I'm working on here is to present the client with raw JSOs to implement the interface, which translate directly to/from enhanced entities on the server which can access my datastore. When I get my appengine virtualization layer finished, my DTO interfaces will also have .toEntity(), .fromEntity() methods, as well as .save() and .delete(). to/fromEntity() will be used mainly on the server to translate to datastore types, but also on the client to translate a statically typed object into a hash-bag object for use in CellWidgets. .save() and .delete() will, on the client, call up (or queue up) requests to delete the entities on the server, and on the server, the objects will perform the actual deletions. This way, I can help erase the client/server boundary. Finally, and maybe most importantly, generators are great at spitting out boilerplate code. If you have a specific procedure you must do (like un/marshalling data, or validating data), you will often find yourself writing, essentially the same code using different accessors for different objects. These processes cannot be handled by a concrete class, unless you can implement accessor interfaces for every object (which you must still write by hand). Instead, if you use a generator, you can just dream up any annotation to tell your code check this, throw X if !Y, and let the generator write the dirty details itself. Not only does the generator remove messy, error-prone boilerplate, it also updates and adapts as your app changes; if you change a field's requirements, you just have to update that field's annotation, rather than lookup every place that field is validated and update by hand. Basically, anywhere you need to repeat a process, but cannot hide it behind a simple concrete abstraction layer, a generator will probably help. And what is your experience concerning debugging? For debugging, it can be frustrating if you just run compiles and check output. Instead, I specify the -gen directory to point to a project where I have symlinked in all relevant code. The generated folder is the only concrete source folder, and all other source is just linked in. This way, any compile errors or warnings or mistakes in the generated code can be picked up immediately, and I can trace through the generated code easily. Obviously, if the generator fails and produces no output, you are going to have some headache. This is where using a subclassed SourceWriter which can debug to console while working can help you pick out errors; turn a debug flag on, and your console will spew out the generated classes as it writes them, so you can see where the errors are. If you have the symlinked gen project, you can just copy+paste broken generated code into it, and see where the compile errors are immediately. Were I a little more ambitious, I would have the subclasses SourceWriter print the generated code to console, to the generator, and to the gen-view project, so a simply F5 in the gen project will immediately show all compile errors... Though, I haven't hit any bugs bad enough that I couldn't fix just as easily with debugging output, and maybe java debugger for NPEs here and there. =} -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/2-JaaESzh6UJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: hard time to get GWTTestCase to work
Not everything can be tested with unit tests. I write a lot of generator + linker code, so, by necessity, I must use GWTTestCase, as I am testing the compilation process. If your tests don't involve the gwt generator, then definitely don't incur the overhead of GWTTestCase, but if you are working in the generator layer, or if you want to test a functional gui in the browser, then you should use GWTTestCase. It might be possible with selenium to achieve the in-browser tests, but you will likely need to run the gwt compile anyway, so you might as well just use the testing suite provided. =} On Sunday, September 16, 2012 3:49:38 PM UTC-6, Ed wrote: @ tanteanni : Easiest solution: don't use GWTTestCase... It simple doesn't work well and if you have it working, it's hard to maintain... Try to do everything through unit testing... Nowedays I can test almost everything through unit tests, and works well. Google around for awesome testing with IsWidget, if I remember correctly, and you find some forum posts of me that might help you in the correct direction... - Ed -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/VE4aPJxwRuQJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: hard time to get GWTTestCase to work
Anywhere you find yourself re-writing the same code more than three times, you would likely benefit from a generator. Linkers are only useful if you need to translate java source into artifacts other than the embedded js. For gadgets and files that require xml configurations, it may be more work up front to write a generator + linker combo, but it will save piles of frustration because your config file comes from your source code, rather than being edited by hand. Currently, I'm doing a lot of work with creating my own cross-platform dependency injection framework (by implementing java.util.ServiceLoader for gwt). The easy part was getting the generated javascript to work; the hard part was getting dev mode to work correctly, since it does not honor super-source overrides. I prefer to work with interfaces and annotations as much as possible, and generators really help fill the gap without having to manually bind an interface to a factory or, even worse, just hardcoding an implementation. My next task for code generation will be to subclass java.lang.Thread and have it export a generated artifact to a web worker. Rather than manually export multiple modules for the web workers and test them with trial, error and lots of recompiles, I'm just going to write a generator which acts as a generic ThreadFactory, spits out a controller interface that will speak through to the web worker (or js object if web worker unavailable), and link the actual worker code into a separate js compile. This way, I can get the boilerplate right exactly once, and then reuse that boilerplate by calling GWT.create(GwtThread.class) any time I want to offload tasks to a web worker. On Monday, September 17, 2012 3:11:38 PM UTC-6, Ed wrote: Just curious: where do you use your linker and generators for? (I always tried to avoid them as much as possible, don't like hem). Op maandag 17 september 2012 20:06:10 UTC+2 schreef Ajax het volgende: Not everything can be tested with unit tests. I write a lot of generator + linker code, so, by necessity, I must use GWTTestCase, as I am testing the compilation process. If your tests don't involve the gwt generator, then definitely don't incur the overhead of GWTTestCase, but if you are working in the generator layer, or if you want to test a functional gui in the browser, then you should use GWTTestCase. It might be possible with selenium to achieve the in-browser tests, but you will likely need to run the gwt compile anyway, so you might as well just use the testing suite provided. =} On Sunday, September 16, 2012 3:49:38 PM UTC-6, Ed wrote: @ tanteanni : Easiest solution: don't use GWTTestCase... It simple doesn't work well and if you have it working, it's hard to maintain... Try to do everything through unit testing... Nowedays I can test almost everything through unit tests, and works well. Google around for awesome testing with IsWidget, if I remember correctly, and you find some forum posts of me that might help you in the correct direction... - Ed -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Gmv3jx9lTTkJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: hard time to get GWTTestCase to work
Your problem is that your test classpath does not include all required source, or your test class is not in a package explicitly included by your test .gwt.xml module file. Please post your package / directory structure for the test class, the test gwt.xml, and possibly your maven build / execution configuration. On Friday, January 27, 2012 2:41:22 AM UTC-7, tanteanni wrote: i just tried my first GWTTestCase but it fails. My setup is Eclipse/Maven (not the happiest couple on the planet) - the pom was initially generated by gwt-tool (webappcreator?). I use MVP,gin, guice (testing views is not #1 priority but i want it to work). Normal Unit-Tests work just fine. But with GWTTestCase i got different kinds of trouble: if i try it with Eclipse' run as GWT Test i got: com.google.gwt.junit.JUnitFatalLaunchException: The test class 'client.view.DynamicLayoutViewImplTest' was not found in module '...integration'; no compilation unit for that type was seen at com.google.gwt.junit.JUnitShell.checkTestClassInCurrentModule(JUnitShell.java:743) at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1346) at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1309) at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:653) at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:441) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:296) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) (The Test is in same package as the view, the module used inherits the normal module but it includes all permutations) If i run mvn test i got a much bigger exception: for some reasen the app is deployed on jetty together with all server side stuff and i get an guice-error!? mvn gwt:test does absolutly nothing. The first question is: is this a source-code problem or a configuration problem or both? Here is the source: public class DynamicLayoutViewImplTestGWT extends GWTTestCase { @Override public String getModuleName() { return ...Integration; } private DynamicLayoutViewImpl testObject; @Before public final void init() { AdbResources resources = GWT.create(AdbResources.class); testObject = new DynamicLayoutViewImpl(Unit.EM, resources); } @Test public final void testIt() { System.out.println(here); } } as you see i just tried to get an instance of my testobject. thx in advance (i also tried gwt-test-utils is also failed) -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/MxdAYjhJR6oJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: SuggestBox with server side update and UrlFetch Service
Okay, I figured it out myself, again it had to do with sloppy coding. When getting the JSONArray I was assuming the the second element in name would be the Result I want to retrieve. This was the case running in development but not the case when I deployed it. So instead I will just retrieve by Result. Brian On Dec 31 2009, 9:09 am, Ajax-Gadgets brivi...@gmail.com wrote: Hello, I was wonder if anyone has implemented the SuggestBox with server side update using the following codehttp://groups.google.kg/group/google-web-toolkit/browse_thread/thread I updated the ItemSuggestionImpl.java below to retrieve my suggestion box values using Url Fetch Service. This works great in the development environment but when I deploy it to lensticker.appspot.com it no long returns item suggestions. I would suspect that it has something to do with Url Fetch I just don't know what the issue is. Thanks Brian public class ItemSuggestServiceImpl extends RemoteServiceServlet implements ItemSuggestService { private static final String startingURL = http://d.yimg.com/ autoc.finance.yahoo.com/autoc?query=; private static final String endingURL = callback=YAHOO.Finance.SymbolSuggest.ssCallback; public SuggestOracle.Response getSuggestions(SuggestOracle.Request req) { SuggestOracle.Response resp = new SuggestOracle.Response(); // Create a list to hold our suggestions (pre-set the length to the limit specified by the request) ListSuggestion suggestions = null; if (req.getQuery().length() == 0) { suggestions = new ArrayListSuggestion(0); } try { URLFetchService fetcher = URLFetchServiceFactory.getURLFetchService(); URL url = new URL(String.format(%s%s%s, startingURL, req.getQuery(), endingURL)); HTTPRequest fetchreq = new HTTPRequest(url); HTTPResponse fetchresp = fetcher.fetch(fetchreq); byte[] bytes = fetchresp.getContent(); String line = new String(bytes); line = line.replace(YAHOO.Finance.SymbolSuggest.ssCallback (, ); line = line.replace(), ); JSONObject json = new JSONObject(line); String[] name = JSONObject.getNames(json); json = json.getJSONObject(name[0]); name = JSONObject.getNames(json); JSONArray jArray = json.getJSONArray(name[1]); suggestions = new ArrayListSuggestion(jArray.length()); for(int i=0; i jArray.length(); i++) { JSONObject j = jArray.getJSONObject(i); String sSymbol = j.getString(symbol); String sName = j.getString(name); String sExch = j.getString(exch); String sType = j.getString(type); String sTypeDisp = ; String sExchDisp = ; if ((sType.compareTo(S)) == 0) { sExchDisp = j.getString(exchDisp); } else { try { sTypeDisp = j.getString(typeDisp); } catch (Exception se) { sTypeDisp = sType; } } String sDisplay = ; String format = %1$-6s %2$-20s %3$-8s; if ((sType.compareTo(S)) == 0) { sDisplay = String.format(format, sSymbol, sName, sExchDisp); } else { sDisplay = String.format(format, sSymbol, sName, sTypeDisp + - + sExch); } suggestions.add(new ItemSuggestion(sDisplay, sSymbol)); } } catch (MalformedURLException e) { //log.info(e.getMessage()); } catch (IOException ex2) { //log.info(ex2.getMessage()); } catch (JSONException ex3) { //log.info(ex3.getMessage()); } // Now set the suggestions in the response resp.setSuggestions(suggestions); // Send the response back to the client return resp; } } -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
SuggestBox with server side update and UrlFetch Service
Hello, I was wonder if anyone has implemented the SuggestBox with server side update using the following code http://groups.google.kg/group/google-web-toolkit/browse_thread/thread/56942afe0c404d86. I updated the ItemSuggestionImpl.java below to retrieve my suggestion box values using Url Fetch Service. This works great in the development environment but when I deploy it to lensticker.appspot.com it no long returns item suggestions. I would suspect that it has something to do with Url Fetch I just don't know what the issue is. Thanks Brian public class ItemSuggestServiceImpl extends RemoteServiceServlet implements ItemSuggestService { private static final String startingURL = http://d.yimg.com/ autoc.finance.yahoo.com/autoc?query=; private static final String endingURL = callback=YAHOO.Finance.SymbolSuggest.ssCallback; public SuggestOracle.Response getSuggestions(SuggestOracle.Request req) { SuggestOracle.Response resp = new SuggestOracle.Response(); // Create a list to hold our suggestions (pre-set the length to the limit specified by the request) ListSuggestion suggestions = null; if (req.getQuery().length() == 0) { suggestions = new ArrayListSuggestion(0); } try { URLFetchService fetcher = URLFetchServiceFactory.getURLFetchService(); URL url = new URL(String.format(%s%s%s, startingURL, req.getQuery(), endingURL)); HTTPRequest fetchreq = new HTTPRequest(url); HTTPResponse fetchresp = fetcher.fetch(fetchreq); byte[] bytes = fetchresp.getContent(); String line = new String(bytes); line = line.replace(YAHOO.Finance.SymbolSuggest.ssCallback (, ); line = line.replace(), ); JSONObject json = new JSONObject(line); String[] name = JSONObject.getNames(json); json = json.getJSONObject(name[0]); name = JSONObject.getNames(json); JSONArray jArray = json.getJSONArray(name[1]); suggestions = new ArrayListSuggestion(jArray.length()); for(int i=0; i jArray.length(); i++) { JSONObject j = jArray.getJSONObject(i); String sSymbol = j.getString(symbol); String sName = j.getString(name); String sExch = j.getString(exch); String sType = j.getString(type); String sTypeDisp = ; String sExchDisp = ; if ((sType.compareTo(S)) == 0) { sExchDisp = j.getString(exchDisp); } else { try { sTypeDisp = j.getString(typeDisp); } catch (Exception se) { sTypeDisp = sType; } } String sDisplay = ; String format = %1$-6s %2$-20s %3$-8s; if ((sType.compareTo(S)) == 0) { sDisplay = String.format(format, sSymbol, sName, sExchDisp); } else { sDisplay = String.format(format, sSymbol, sName, sTypeDisp + - + sExch); } suggestions.add(new ItemSuggestion(sDisplay, sSymbol)); } } catch (MalformedURLException e) { //log.info(e.getMessage()); } catch (IOException ex2) { //log.info(ex2.getMessage()); } catch (JSONException ex3) { //log.info(ex3.getMessage()); } // Now set the suggestions in the response resp.setSuggestions(suggestions); // Send the response back to the client return resp; } } -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.