Re: css background image
Agree with Jens. You can also check the style in dev tools. If it's not being found, it's a problem with the path to the image. --- phone.brevity.typos.cheers On 6 Apr 2014 09:43, Jens jens.nehlme...@gmail.com wrote: Check your browsers dev tools to see if the image / css file gets loaded by the browser or if an HTTP 404 NOT FOUND occurs (see network tab in dev tools). If it is a 404 you should see what the browser tries to load and this should already be enough information to fix the problem. -- J. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/snOppc2tWnA/unsubscribe . To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
offsetheight not changing in button when fontsize is changed
Hi there, I am creating a button (b) and changing its font size. The offset width changes automatically, but the height is always the default. b.getOffsetWidth() changes accordingly to the font size, but b.getOffsetHeight() is always 26 (the initial size of the button). Anyone seen something similar? I am using GWT 2.5.1, but have tried with 2.6.0 with the same result. Am I using the offsets incorrectly? Many thanks for any info! -- You received this message because you are subscribed to the Google Groups Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: css background image
You can try using quotes around the name of the image, and using a relative path. something like: background-image: url(img/wood.jpg); note that there is no / before img (a relative instead of an absolute path to the image). Would that work? On Saturday, 5 April 2014 13:17:05 UTC-4, Dima Redko wrote: Hello everyone) I've recently faced a problem. I don't know how to set the background of the page using css (not in java code) while using GWT framework. What I did: 1) I've created a folder named img in the war folder of my gwt project 2) Then I've coppied there a.jpg image called wood.jpg. 3) Then in my css file I've got the following written: body{ background-image: url(/img/wood.jpg) repeat; } 4) Surely I've added a link to that css file in my HTML Welcome page When I run this project the background is white. My java code has nothing that affects the backround. So, would you please help me to handle this problem? Thanks in advance))) -- You received this message because you are subscribed to the Google Groups Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
GMaps controls not getting ClickEvents
I am no longer getting ClickEvents on google maps controls I add to map I have a simple GoogleMaps control, just an image in html: HTML infoWidget = new HTML(div id='tip-of-the-day-control'img src='/oeg/images/info_32.png' title='Helpful Tips'//div); Which I place on the map using Mapitz (yes I know, but I have a working version thats updated if anyone is interested), this code literally just puts the html element on the map as a control. GControlPosition infoPosition = new GControlPosition(GControlAnchor.G_ANCHOR_TOP_RIGHT(), new GSize(7, 30)); getGmap().addControl(new GControl(infoWidget, infoPosition)); to get ClickEvents I used to do this... infoWidget.addClickListener(new ClickListener() { public void onClick(Widget sender) { doTipOfTheDay(); } }); which I changed to this in the 1.6.0 world, infoWidget.addClickHandler(new ClickHandler() { public void onClick(ClickEvent ce) { doTipOfTheDay(); } }); neither of which work in GWT-1.6.0/1.7.0 - anyone else run into event issues w/ controls? With other Gmaps objects I have no problems w/. I'm getting mouse clicks on the map, on markers etc, but controls, not so much --~--~-~--~~~---~--~~ 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-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: Search Engine Indexing
Quick answer for me - no, never expected it to be indexed so there was never any wondering The trade off that Eric mentions was always made pretty clear by the search engines and in my case, we decided to render pages we wanted indexed outside of GWT and we have a parallel application structure to render these pages with a minimum of javascript. We still have some problems: 1. a slide show of multiple pictures is not so easy to deal with 2. we use a couple of 3rd party embedded components, that we like, but we'll have to replace at some point because the content in them doesn't get indexed I think your second question makes a presumption that a GWT rendered webpage has only a single URL. This is not necessarily the case. There are some GWT apps out there that have large URL spaces based on content that they render. They have an indexing problem if they cannot provide the same content sans GWT execution. On Jan 25, 7:12 am, Peter Ondruška peter.ondru...@gmail.com wrote: Following discussion on indexing AJAX applications I have to ask if those who wonder why their GWT applications cannot be indexed if you expect search engines to index Java applets or Flash out there on the web, or compressed files and executable files? And if somehow GWT application get indexed what links do you expect to be shown insearch results--it can only be yourapp#variables. Is it not enough to have the application entry html indexed and available in results? Peter 2009/1/25, Eric Ayers zun...@google.com: Here are some official answers on the subject: Notes on Ajax: http://www.google.com/support/webmasters/bin/answer.py?hl=enanswer=8... Don't be evil, Guidelines for Webmasters: http://www.google.com/support/webmasters/bin/answer.py?answer=35769 On Sun, Jan 25, 2009 at 5:04 AM, jos jot...@gmail.com wrote: Eric Just to make sure I understood your last point, we should be looking for a search bot indicator like a URL parameter or something, and if we see it we should render our page as statically and flat as possible? Thanks, jos On Jan 24, 5:01 am, Eric Ayers zun...@google.com wrote: Hi Bryan, I understand your frustration. Unfortunately, due to the extremely competitive nature of web search, we here at Google can't say a lot about the Google bot or the roadmap for future improvements. Indexing JavaScript apps is a general problem not particular to GWT. Obviously, this is one of those problems everyone in the web apps search community needs to keep coming back to in order to find better ways to solve it. Just to give you an idea of the complexity involved, the first page of JavaScript for GWT basically runs a big switch statement that loads a different script depending on which browser is running (which browser should the googlebot run. Which bugs should it emulate?). It doesn't actually create the DOM until after the body of the document is finished loading (when does it know to start looking at the DOM?). Your app might be perfectly happy for the bot to index just the front page, but that is still going to leave a huge swath of unhappy app developers. Another page might present something on the first page that is not very indicative of the content, like: this browser is not supported or Login or create an account or choose your region using images before continuing. A page might have tabs or a menu with content that doesn't actually get attached to the DOM until after the tabs are clicked and has a message (click on the menu to ...). Here's some spin for you: I think the message from the search side of search engines isn't Don't use JavaScript. Instead, the message is to provide a page of HTML that faithfully describes your app and/or its content when the search engine crawls your page. I know its more work, but think about how that might actually be an opportunity for Web 2.0 authors. -Eric. On Sat, Jan 24, 2009 at 2:59 AM, bryanb webbt...@gmail.com wrote: That's the point of my query/question, Why can't the Google bot understand Javascript ? As I said originally, using Firebug I can see what the Javascript has rendered to the DOM, so there's no good reason the Google bot can;t do the same. Granted, it cannot follow links or any of the possibly unlimited execution paths in the Javascript, but it should be able to render the initial state of the page, and consequently index stuff on that page. Likewise if there is a site map with history tags, it should be able to render the initial state of each of those pages and index accordingly. The initial state is really all you want indexed anyway - if I do a Google search for fubar, I reasonably expect the URLs returned to point to a page with fubar on it somewhere i.e. for a GWT app the initial state of that page. It just seems a bit strange that one part
Re: Search Engine Indexing
Eric Just to make sure I understood your last point, we should be looking for a search bot indicator like a URL parameter or something, and if we see it we should render our page as statically and flat as possible? Thanks, jos On Jan 24, 5:01 am, Eric Ayers zun...@google.com wrote: Hi Bryan, I understand your frustration. Unfortunately, due to the extremely competitive nature of web search, we here at Google can't say a lot about the Google bot or the roadmap for future improvements. Indexing JavaScript apps is a general problem not particular to GWT. Obviously, this is one of those problems everyone in the web apps search community needs to keep coming back to in order to find better ways to solve it. Just to give you an idea of the complexity involved, the first page of JavaScript for GWT basically runs a big switch statement that loads a different script depending on which browser is running (which browser should the googlebot run. Which bugs should it emulate?). It doesn't actually create the DOM until after the body of the document is finished loading (when does it know to start looking at the DOM?). Your app might be perfectly happy for the bot to index just the front page, but that is still going to leave a huge swath of unhappy app developers. Another page might present something on the first page that is not very indicative of the content, like: this browser is not supported or Login or create an account or choose your region using images before continuing. A page might have tabs or a menu with content that doesn't actually get attached to the DOM until after the tabs are clicked and has a message (click on the menu to ...). Here's some spin for you: I think the message from the search side of search engines isn't Don't use JavaScript. Instead, the message is to provide a page of HTML that faithfully describes your app and/or its content when the search engine crawls your page. I know its more work, but think about how that might actually be an opportunity for Web 2.0 authors. -Eric. On Sat, Jan 24, 2009 at 2:59 AM, bryanb webbt...@gmail.com wrote: That's the point of my query/question, Why can't the Google bot understand Javascript ? As I said originally, using Firebug I can see what the Javascript has rendered to the DOM, so there's no good reason the Google bot can;t do the same. Granted, it cannot follow links or any of the possibly unlimited execution paths in the Javascript, but it should be able to render the initial state of the page, and consequently index stuff on that page. Likewise if there is a site map with history tags, it should be able to render the initial state of each of those pages and index accordingly. The initial state is really all you want indexed anyway - if I do a Google search for fubar, I reasonably expect the URLs returned to point to a page with fubar on it somewhere i.e. for a GWT app the initial state of that page. It just seems a bit strange that one part of Google has created a tool for making really usable web sites, but the search side of Google says don''t use Javascript if you want to be indexed. -- Eric Z. Ayers - GWT Team - Atlanta, GA USAhttp://code.google.com/webtoolkit/ --~--~-~--~~~---~--~~ 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-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: Search Engine Indexing
Hi Bryan I recently had the chance to speak with some good SEO types and the subject of javascript did come up. The bottom line is don't hold your breath waiting for this to happen in any search engine. I think its easy to appreciate how difficult it would be for a search engine to do this. You'd essentially be creating a virtual browser machine which would be loading a page and executing it (as you point out) but it's not so simple, how much execution should be done? How to does the engine know when to stop? It's kind of a halting problem. The other thing we have to keep in mind is that the cost of this is pretty high and there are a *lot* of pages out there to index. I feel your pain, I'd like to create a commenting system using GWT, but any of the content in that commenting system is going to have to be sent down to the client in HTML if I want it indexed. I was discussing another similar problem I have where we use a component that is wrapped by an iframe, how much of the content in that iframe is going to get parsed? Not clear. jos On Jan 23, 11:59 pm, bryanb webbt...@gmail.com wrote: That's the point of my query/question, Why can't the Google bot understand Javascript ? As I said originally, using Firebug I can see what the Javascript has rendered to the DOM, so there's no good reason the Google bot can;t do the same. Granted, it cannot follow links or any of the possibly unlimited execution paths in the Javascript, but it should be able to render the initial state of the page, and consequently index stuff on that page. Likewise if there is a site map with history tags, it should be able to render the initial state of each of those pages and index accordingly. The initial state is really all you want indexed anyway - if I do a Google search for fubar, I reasonably expect the URLs returned to point to a page with fubar on it somewhere i.e. for a GWT app the initial state of that page. It just seems a bit strange that one part of Google has created a tool for making really usable web sites, but the search side of Google says don''t use Javascript if you want to be indexed. --~--~-~--~~~---~--~~ 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-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: problem with rpc!
I use the actual type in my rpc definitions so, public interface Service extends RemoteService { public ArrayListString method(); } Lore, is correct though this is the right way to go, you do need to supply the parametrized type On Jan 23, 10:50 am, Lore laurent.vanderlin...@gmail.com wrote: Any time you want to send a List over RPC, you need to specify the type of the list using generics. So your method becomes: public interface Service extends RemoteService { public ListString method(); } On 23 jan, 18:44, frankCostello smar...@gmail.com wrote: hi, I have a problem about rpc. In practice the client should receive a list of strings from the server. if I use a method that returns an arraylist public interface Service extends RemoteService { public ArrayList method();} public interface ServiceAsync { public void method(AsyncCallbackArrayList callback);} public class ServiceImpl extends RemoteServiceServlet implements Service { public ArrayList method() {}} give me an error, compare the error at onfailure of async callback of the client. but if i make a method that returns a String there aren't any problem!! how do I do? --~--~-~--~~~---~--~~ 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-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: RPC call returning ListString fails
OK, I've finally had a chance to look into this some more and updated the gwt-sl.jar version I was using (fairly old as previously stated) I downloaded the 0.1.5b (latest version still using Hibernate4GWT) and put everything back to ListString and it worked inside and outside of eclipse. Given this was the only thing I changed, possibly a problem in the old library. Thanks for replies... jos On Jan 19, 12:05 am, alex.d alex.dukhov...@googlemail.com wrote: I remember a thread not that long time ago where someone experienced same trouble with waiting on NNN bytes. I'm not sure what the problem exactly was. Using ListString is ok(but in case of some black magic used - try it anyway ;-) On 17 Jan., 19:22, jos jot...@gmail.com wrote: yes, new ArrayListString followed by several add(some string) What's got me stuck is the backend saying it's waiting on 153 bytes from the client, like it's not event fired off the RPC call yet So List is OK, I don't need to use ArrayList ? On Jan 15, 11:30 pm, alex.d alex.dukhov...@googlemail.com wrote: It is actually. I'm using a lot of structures like this(and more complex) for data transfer. The problem ist somewhere else - do you initialize your List properly? On 15 Jan., 18:36, jos jot...@gmail.com wrote: I have an RPC call with a signature like public ListString SomeCall (SomeObj) { return anArrayList; } which failed. Policy file was deployed and the file had ArrayList, true in the file. The only real information available was the stack trace it left in catalina.out (see below). I'm running gwt1.52, a Spring/Hibernate stack on the back end with (a probably early version of) gwt-sl. The problem manifested itself in eclipse. When I changed the return value to String[] eveything worked fine. Does anyone know, is it not OK to use ListString as a return specifier? 2009-01-14 16:41:08,569 ERROR [org.apache.catalina.core.ContainerBase. [Catalina].[localhost].[/geo]] - Exception while dispatching incoming RPC call javax.servlet.ServletException: Client did not send 158 bytes as expected at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsUtf8 (RPCServletUtils.java:148) at com.google.gwt.user.server.rpc.RemoteServiceServlet.readContent (RemoteServiceServlet.java:335) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost (RemoteServiceServlet.java:77) at org.gwtwidgets.server.spring.GWTRPCServiceExporter.handleRequest (GWTRPCServiceExporter.java:169) at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle (HttpRequestHandlerAdapter.java:49) at org.springframework.web.servlet.DispatcherServlet.doDispatch (DispatcherServlet.java:874) at org.springframework.web.servlet.DispatcherServlet.doService (DispatcherServlet.java:808) at org.springframework.web.servlet.FrameworkServlet.processRequest (FrameworkServlet.java:476) at org.springframework.web.servlet.FrameworkServlet.doPost (FrameworkServlet.java:441) --~--~-~--~~~---~--~~ 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-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: ServletException Client did not send 139 bytes as expected when testing a gwt-gadget via iGoogle (during RPC call)
I'm getting the same behavior in a completely different scenario see my post where use of a return value ListString causes this failure, but after changing the return to String[], problem goes away... The interesting bits here are that we're both using different stacks so what's your call signature look like? http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/e689e7f110369e43/607c58c8e6f407c2?hl=enlnk=gstq=lient+did+not+send+bytes+#607c58c8e6f407c2 On Dec 7 2008, 4:14 am, rintcius rintc...@gmail.com wrote: Hi, I am trying to get a gwt-gadget running, but I am getting the exception below on the RPC call. Anybody has an idea what could be going on? The stacktrace below is when deployed on jetty, but I get a similar exception on glassfish v2. GWT version: 1.5.3. gwt-gadget version: 1.0.1 Thanks for any help, Rintcius [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. 2008-12-06 21:40:49.329:/:WARN: Exception while dispatching incoming RPC call javax.servlet.ServletException: Clientdidnotsend139bytesas expected at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsUtf8 (RPCServletUtils.java:148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.groovy.reflection.CachedMethod.invoke (CachedMethod.java:86) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226) at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java: 1094) at groovy.lang.ExpandoMetaClass.invokeStaticMethod (ExpandoMetaClass.java:957) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod (InvokerHelper.java:748) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN (ScriptBytecodeAdapter.java:167) at org.codehaus.groovy.grails.plugins.gwt.GrailsRemoteServiceServlet.readConte nt (GrailsRemoteServiceServlet.groovy:28) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost (RemoteServiceServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1097) at org.codehaus.groovy.grails.web.mapping.filter.UrlMappingsFilter.processFilt erChain (UrlMappingsFilter.java:157) at org.codehaus.groovy.grails.web.mapping.filter.UrlMappingsFilter.doFilterInt ernal (UrlMappingsFilter.java:148) at org.springframework.web.filter.OncePerRequestFilter.doFilter (OncePerRequestFilter.java:75) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1088) at org.codehaus.groovy.grails.web.sitemesh.GrailsPageFilter.parsePage (GrailsPageFilter.java:119) at org.codehaus.groovy.grails.web.sitemesh.GrailsPageFilter.doFilter (GrailsPageFilter.java:82) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1088) at org.codehaus.groovy.grails.web.servlet.filter.GrailsReloadServletFilter.doF ilterInternal (GrailsReloadServletFilter.java:142) at org.springframework.web.filter.OncePerRequestFilter.doFilter (OncePerRequestFilter.java:75) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1088) at org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequestFilter.doFilterI nternal (GrailsWebRequestFilter.java:68) at org.springframework.web.filter.OncePerRequestFilter.doFilter (OncePerRequestFilter.java:75) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1088) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal (CharacterEncodingFilter.java:96) at org.springframework.web.filter.OncePerRequestFilter.doFilter (OncePerRequestFilter.java:75) at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate (DelegatingFilterProxy.java:183) at org.springframework.web.filter.DelegatingFilterProxy.doFilter (DelegatingFilterProxy.java:138) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1088) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle (SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle (SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle (ContextHandler.java:729) at org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle
Re: RPC call returning ListString fails
yes, new ArrayListString followed by several add(some string) What's got me stuck is the backend saying it's waiting on 153 bytes from the client, like it's not event fired off the RPC call yet So List is OK, I don't need to use ArrayList ? On Jan 15, 11:30 pm, alex.d alex.dukhov...@googlemail.com wrote: It is actually. I'm using a lot of structures like this(and more complex) for data transfer. The problem ist somewhere else - do you initialize your List properly? On 15 Jan., 18:36, jos jot...@gmail.com wrote: I have an RPC call with a signature like public ListString SomeCall (SomeObj) { return anArrayList; } which failed. Policy file was deployed and the file had ArrayList, true in the file. The only real information available was the stack trace it left in catalina.out (see below). I'm running gwt1.52, a Spring/Hibernate stack on the back end with (a probably early version of) gwt-sl. The problem manifested itself in eclipse. When I changed the return value to String[] eveything worked fine. Does anyone know, is it not OK to use ListString as a return specifier? 2009-01-14 16:41:08,569 ERROR [org.apache.catalina.core.ContainerBase. [Catalina].[localhost].[/geo]] - Exception while dispatching incoming RPC call javax.servlet.ServletException: Client did not send 158 bytes as expected at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsUtf8 (RPCServletUtils.java:148) at com.google.gwt.user.server.rpc.RemoteServiceServlet.readContent (RemoteServiceServlet.java:335) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost (RemoteServiceServlet.java:77) at org.gwtwidgets.server.spring.GWTRPCServiceExporter.handleRequest (GWTRPCServiceExporter.java:169) at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle (HttpRequestHandlerAdapter.java:49) at org.springframework.web.servlet.DispatcherServlet.doDispatch (DispatcherServlet.java:874) at org.springframework.web.servlet.DispatcherServlet.doService (DispatcherServlet.java:808) at org.springframework.web.servlet.FrameworkServlet.processRequest (FrameworkServlet.java:476) at org.springframework.web.servlet.FrameworkServlet.doPost (FrameworkServlet.java:441) --~--~-~--~~~---~--~~ 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-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 -~--~~~~--~~--~--~---
RPC call returning ListString fails
I have an RPC call with a signature like public ListString SomeCall (SomeObj) { return anArrayList; } which failed. Policy file was deployed and the file had ArrayList, true in the file. The only real information available was the stack trace it left in catalina.out (see below). I'm running gwt1.52, a Spring/Hibernate stack on the back end with (a probably early version of) gwt-sl. The problem manifested itself in eclipse. When I changed the return value to String[] eveything worked fine. Does anyone know, is it not OK to use ListString as a return specifier? 2009-01-14 16:41:08,569 ERROR [org.apache.catalina.core.ContainerBase. [Catalina].[localhost].[/geo]] - Exception while dispatching incoming RPC call javax.servlet.ServletException: Client did not send 158 bytes as expected at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsUtf8 (RPCServletUtils.java:148) at com.google.gwt.user.server.rpc.RemoteServiceServlet.readContent (RemoteServiceServlet.java:335) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost (RemoteServiceServlet.java:77) at org.gwtwidgets.server.spring.GWTRPCServiceExporter.handleRequest (GWTRPCServiceExporter.java:169) at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle (HttpRequestHandlerAdapter.java:49) at org.springframework.web.servlet.DispatcherServlet.doDispatch (DispatcherServlet.java:874) at org.springframework.web.servlet.DispatcherServlet.doService (DispatcherServlet.java:808) at org.springframework.web.servlet.FrameworkServlet.processRequest (FrameworkServlet.java:476) at org.springframework.web.servlet.FrameworkServlet.doPost (FrameworkServlet.java:441) --~--~-~--~~~---~--~~ 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-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: J2EE and debug in hosted mode
Bandesz, Gregor is pointing you in the right direction w/ option #1, and the link he gives is enough to eventually get you there, but there is one thing you have to do in your GWT code or it will never work. Your RPC servlets all have a setServiceEntryPoint() call that is made to tell them where they hookup. By default in hosted mode the GWT runtime will tell your GWT application that the app server is on localhost so you need to override that by changing the following code which should be in your onModuleLoad() method. The code example below is in my deployment setup, when I'm debugging the application I comment in the first two lines and comment out the 3rd line. Note in the second statement I'm telling GWT where the the service entry point really lives. The third statement would point it back to the localhost because that's where hosted mode lives. There is a second important step that I'll mention here. After compiling your GWT code, it does need to be deployed to your testing server so that the hosted mode browser takes the code from that server. Once you switch to -noserver the local tomcat goes away and there's nothing serving up your application. When you run the hosted mode debugger, you just need to type in the address of your application on the address bar like you would if you were really deployed, your application will be served by your test server and load up into the hosted mode debug browser. Try the GWT documentation link and these two points, and it should work. Admittedly it is a painful process the first time you try to get it to work, but it does work. /** ECLIPSE CODE - comment in the next 2 lines and comment out the line directly * after these three to run with backend server in eclipse System.out.println(GWT module base URL - + GWT.getModuleBaseURL()); geoServiceTarget.setServiceEntryPoint(http:// staging.abaqus.net/geo/gcb/geoservice); */ geoServiceTarget.setServiceEntryPoint(GWT.getModuleBaseURL() + geoservice); On Dec 7, 7:34 pm, gregor greg.power...@googlemail.com wrote: couple of approaches 1) Simply use -noserver option. You need a build script to deploy your RPC servlets and your EJB layer to Glassfish on demand and activate remote debugging to make this work effectively, but lots of people do it this way. See http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5s=goog... 2) You can run your RPC servlets in hosted mode Tomcat instance leaving your session beans on Glassfish with a bit more work. You need to use trad JNDI to try for a local reference to your session beans, and if that fails go for the remote reference instead. I don't think the new annotation stuff works for this.That way you get a local ref in production and a remote one in dev from the same code. If you use the ServiceLocator pattern it makes this easier. On Dec 7, 2:26 pm, Bandesz band...@blog.hu wrote: I'm developing a J2EE application with GWT using NetBeans 6.5, Glassfish v2. If I debugging only the web project, I can't use any Session Beans from EJB project, becase I get Cannot resolve reference Unresolved Ejb-Ref... error. I tried in every way to make ejb-local-ref tags in web.xml (or in ejb-jar.xml), but the error stays. (I see now that it's a dead end) If I debugging the enterpise project, everythings works except the hosted mode. I searched a lot, but I can't make this work, please help. Thanks, Bandesz --~--~-~--~~~---~--~~ 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-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: -noserver 1.5 RPC Help
Hi Christopher I had a tough time getting this to work at first too (using 1.5). One of the changes I made that I have not seen mentioned in this thread is that I had to change the service entry point to something different than what Bruce had in his initial post I had to use a full URL to my server, see example of my service entry point below. Also a couple of other things - you need to copy the compiled GWT application directory to the server directories (and recopy if you change the interface) and don't forget that you need to alter the address in the hosted mode browser to the actual page on your server or the application won't load. from bruce johnson's post 5) Make sure that your client-side code references the right service entrypoint using ServiceDefTarget. In this case, it would be something like serviceDefTarget.setServiceEntryPoint(/myproject/myservice). example of what I put in my code geoServiceTarget.setServiceEntryPoint(http://staging.abaqus.net/geo/ gcb/geoservice); hope this helps jos On Oct 14, 9:34 am, Christopher Venning [EMAIL PROTECTED] wrote: I cannot seem to get the -noserver mode working with RPCs. I got it to work in 1.4 but have changed environments in the last year. There don't appear to be any Group postings about getting it going since 1.5 was released. Bruce Johnson's original posting (http:// groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/ 338c4b765d7dfc39) doesn't appear to be the 1.5-supported method, based on the current Developer's Guide (yes, I tried it anyways and failed). Working off ofhttp://code.google.com/docreader/#p=google-web-toolkit-doc-1-5t=FAQ_..., Hosted Mode hooks in appropriately (changing Java code and refreshing the Hosted Browser changes content). However, the RPCs fail. I am probably doing something dumb, and would appreciate someone pointing that out. Relevant Environment: GWT 1.5.2, Eclipse 3.4.0, Tomcat 5.5.27, jdk 1.6u7, XP SP3 Relevant Error --- Throwable type: - com.google.gwt.user.client.rpc.StatusCodeException Message content: - html page from external Tomcat (has been confirmed) - 404 report - description: The requested resource (/ServerTest/testService) is not available. Relevant module code --- from TestService.java (extends RemoteService): @RemoteServiceRelativePath(/testService) from ServerTest.gwt.xml: servlet path=/testService class=org.server.TestServiceImpl / from ServerTest.launch (arguments): -noserverhttp://localhost:8080/ServerTest/ServerTest.html Sum Total of changes to Tomcat --- created %TOMCAT_HOME%/webapps/ServerTest copied into that directory (from compilation): - clear.cache.gif - history.html - hosted.html - org.ServerTest.nocache.js - ServerTest.html - 5BA8A5B3E35F40698BB0BF65F390BCF2.gwt.rpc - 9DA92932034707C17CFF15F95086D53F.cache.png - 548CDF11D6FE9011F3447CA200D7FB7F.cache.png --~--~-~--~~~---~--~~ 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-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---