Re: css background image

2014-04-06 Thread Jos Flores
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

2014-04-05 Thread Jos Flores
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

2014-04-05 Thread Jos Flores
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

2009-08-12 Thread jos

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

2009-01-26 Thread jos

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

2009-01-25 Thread jos

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

2009-01-25 Thread jos

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!

2009-01-24 Thread jos

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

2009-01-20 Thread jos

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)

2009-01-19 Thread jos

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

2009-01-17 Thread jos

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

2009-01-15 Thread jos

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

2008-12-15 Thread jos

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

2008-10-15 Thread jos

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
-~--~~~~--~~--~--~---