Re: File download using GWT?
rlaferla schrieb: I have already searched this forum and there is a thread on doing a file download but that's for a file that exists on disk and for various reasons, my application cannot write the string to a file first. There are already a couple of threads covering that topic and if the URL that is used for downloading a file is leading to the execution of e.g. a servlet, the data doesn't need to reside on the filesystem but can be created dynamically. Actually in my current application most of the file downloads is data being created in memory only. Regards, Lothar --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ClickListener problem
tapan schrieb: I have 3 buttons each having their own ClickListener . The problem is that after clicking once on a button the ClickListener does not work second time until the page has been refreshed. How can i correct this error without refreshing the page every time. Some source showing the problem should help. The effect you describe I never had, so I'm quite sure that you do something wrong. Most likely there is an exception happening in the code being executed inside the listener. This stops the execution of the application and needs the reload of the page. Regards, Lothar --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
IE7 Error in cache.html's Javascript
Hi everyone,
I'm running into a really weird problem with IE7 when I view my site
that was created using GWT. The client makes several calls to the
server to retrieve Lists of information. This problem does not occur
in Firefox 3 nor in Safari. The error I'm getting is
Line: 2818
Char: 3
Error: Exception thrown and not caught
Code: 0
URL: http://domain/997866B17568BBEABF330CD77D093CE1.cache.html
From what I gather, it seems this file is the my application logic
tailored for IE. When I look into the file at line 2818, I find:
2817: function java_util_AbstractList_indexOutOfBounds__II(index, size)
{
2818: throw java_lang_IndexOutOfBoundsException_
$IndexOutOfBoundsException__Ljava_lang_IndexOutOfBoundsException_2Ljava_lang_String_2
(new java_lang_IndexOutOfBoundsException(), $intern_130 + index +
$intern_131 + size);
2819: }
I tried to find where the callers of this method were and there were
3 of them:
(1) function java_util_ArrayList_
$add__Ljava_util_ArrayList_2ILjava_lang_Object_2(this$static, index,
o)
(2) function java_util_LinkedList_
$listIterator__Ljava_util_LinkedList_2I(this$static, index)
(3) function java_util_AbstractList_checkIndex__II(index, size)
I'm guessing this means somewhere my application is trying to access
an index in a List that's not within bounds of it. The puzzling thing
is, how come this only happens on SOME IE7 browsers and does not occur
at all in Firefox or Safari.
Any ideas or fixes would be much appreciated.
Kevin
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
You're asking me if some Reinier Approved algorithm would meet with my approval? Uh, yes. I have a question for you, though: Does a gregor approved method of shooting a puppy meet with your approval? If not, can you explain why? On Nov 28, 9:02 pm, gregor [EMAIL PROTECTED] wrote: @Reinier gregor: What do you mean 'bad idea because the session ID would be visible on the wire'? All session IDs are visible on the wire, unless you set up a scheme where the client javascript does some hashing or encryption. Suppose I replaced: sessionID = someSessionIDCookieGrabbingMethod(); with: sessionID = someReinierApprovedEncryptionAlgorithm(); would this meet with your approval? If not can you explain why? regards gregor It's been floated as an idea many times on this forum, and it is certainly feasible, but its very much outside of the norm. Virtually nobody on the entire web is doing this today. There are a number of issues I don't really want to get into. Suffice to say: Yes, doable. Yes, very cool. No, not standard or required by any stretch of the imagination. Such a scheme would still be significantly less secure than SSL, because it won't hold up to a man in the middle attack (the man in the middle will just modify your GWT code to send the password to his secret server in nigerussomania. On Nov 28, 12:52 pm, Patrick Ratelband [EMAIL PROTECTED] wrote: Hey everyone, I have been working a while now on properly defending my GWT app against Cross Site Request Forgery (XRSF) with a minimal change in the code of the application itself. My idea has been to create a new RPC call that will be the same from the programmers points of view as the normal, but which will add some value (a sessionID for instance) to the list of supplied parameters just before the call is send. Then, on the server side, the programmer would extend the SecureRemoteServiceSevlet (SRSS) instead of the normal one. This secure version will simply remove the extra paramater, check it's validity and only execute the requested method if the authentication succeeds. So far I have been able to subclass the RemoteServiceServlet (RSS) into the SRSS. It overrides the processCall(String payload) method to implement the verification (in my case the last argument, but that can easily be changed), thus working exactly the same as the normal RSS without any change needed in the code other than changing the extend. The problem is that I really do not understand where I might add the code to modify the sending of the request client side. I have studied the RPC diagrams and almost everything I could find on the group concerning RPC, but I still do not understand what I need to change or override to create a custom RPC call. I have thought about making a subclass of the ServiceDefTarget so that the calling URL could be modified, but this is an interface and not a class, so is not going to work. Does anyone have any idea's on this? Patrick PS: If I succeed at making something useful, I will create a package and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Timer In Gwt
Not A Problem - Just Add The Timer Behaviour To Your Custom Subclass
Of Label. For Example, You Could Add A SetVisible Method To This Label
Subclass That Also Includes a Milliseconds Parameter (The Time To
Display The Message). All Your Method Does Is Call Super.SetVisible
(X), And Then Start The Timer. The Timer Code You Pasted Looks Fine,
So You Can Just Use That. If You Are Concerned That Thirty Timers Are
Too Much To Handle, I Wouldn't Worry Too Much. However, If Practical
Testing Really Reveals That Is A Problem, You Can Do This. I'd Still
Go The Route Of A Custom Class, though. Basically, Create A Mapping Of
Event Times (The Time In Milliseconds When The Message Should
Disappear) And Store This In A TreeMap. Then, Set Up A Single Timer
That Waits Until The First Time In The Mapping Is 'Up'. The Code Sort
Of Writes Itself From There. If A New Timer Is Added, You Should Check
If It's Up Sooner Than The First Thing In The Map, And If So, Cancel
And Restart The Timer With The New Shorter Time.
NB: It Is More Common In The English Language To Capitalize The Word
I And The First Letter In Every Sentence. Your Style Of Capitalizing
At Random Is Not So Much Of A Standard. I Admit, It Looks Hilarious
Though. Ta!
On Nov 29, 7:48 am, jagadesh [EMAIL PROTECTED] wrote:
Hi Guys,
I am Working On A Screen Where i Need to Display some Error Message
and Some Success Messages.What i did is i created my own widget of
some Label type . when ever i need to show a message i would set the
text to label and display it on the top of the screen much like gmail.
the issue i added a timer for the label so that it disappears
automatically after some time.
i have written the code like this,
Timer t = new Timer() {
public void run() {
header.setErrorMessage(Error
Message);
header.setVisible(true);
setWidget(0, 1, header);
}
};
t.schedule(500);
header is my label type of element. i was displaying some 30 types of
different message. so my timer code has increased a lot . can any one
suggest me how to use a single timer class for all.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: TextArea cannot be resolved to a type
Go through the GWT Getting started guide. You've screwed up your installation somehow, or you're not using the right command line. It's not a matter of code, it's just that some tool in the chain can't find the TextArea class code. For the rest - really, this is a forum, not a university. Just go through the getting started guide and learn GWT. You should also have a look at the javadoc for all GWT classes. For example, the TextArea javadoc has a getText() method, and a setText() method. You can not use URL in GWT. The GWT Documentation (Notice a pattern?) has a nice listing of which classes are supported. java.net.* is not in it. This isn't because the GWT team is lazy, it's simply because javascript simply can't do this, so there's no way the GWT compiler can compile that code for you. If the URL you want to read in is from the same server that served the webpage (the EXACT same server. Same protocol, same exact server name, same port), then you can use RequestBuilder (A GWT class. Look it up in the .. (drum roll please!) documentation!) which is capable of downloading the contents. On the web, you can pretty much only ever download everything in one go, there are no streams, just complete data. If you need to process a couple megabytes on the client... you're out of luck, then. Maybe your server can download the big data in chunks and pass it to the client in a flurry of requests instead. On Nov 29, 7:50 am, moe374 [EMAIL PROTECTED] wrote: Hello. I have just begun learning java (about 2 months ago) and am now trying to develop a couple applications for the web using java and the GWT. I am having some difficulty and hoping someone can help me out. My first problem I am having is I am getting this error message TextArea cannot be resolved to a type when I am trying to create a text area. I get the error message twice, and for the same line in my code which is TextArea ta = new TextArea(); Is there a line (or multiple lines) of code I have to implement before I can implement the TextArea object? Also, I need to allow the user to paste some information into this text box and allow me to store that information in a variable, and then do something with the information, and then output some information to the user (even in the same text box is fine). Can some one please help me get started on this? Finally, I was wondering if the GWT supports reading the HTML file of a URL, which would normally be done by something like this: URL results = new URL(http://www.some-url.com;); BufferedReader in2 = new BufferedReader( new InputStreamReader( results.openStream())); String inputLine = in2.readLine(); Thank you very 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Body Background disappear
Yes, you are right Ian. I found out after I got the idea that it must be some CSS that's overriding my body styles. The hard part was finding out where this CSS was and it turned out to be a theme that's used in a GWT library I was including in my class path. Sigh... took me a while to find it. Thanks for the input though guys. Much appreciated. On Nov 18, 6:23 am, Ian Bambury [EMAIL PROTECTED] wrote: My guess is that you are using a theme. Ian http://examples.roughian.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Problems adding a Digg This link
Can't you just add the script element to your host page, the same way you would in HTML? That is to say, don't try to recreate the script element in Java and have GWT insert it, just put it on the host page (the same place you put the gwt script tag, etc). On Nov 27, 11:33 pm, mayop100 [EMAIL PROTECTED] wrote: I'm trying to add a Digg This link to my gwt website. If my website were just an html page, all I would need to do is include this line in my HTML: script src=http://digg.com/tools/diggthis.js; type=text/ javascript/script I've tried adding a new element to the page with DOM.createElement (script), but it ends up replacing the entire contents of the page with my digg link. I've also tried a JSNI solution, but with no success. It seems to me there should be an easy solution for this... anyone? Thanks - -Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: XML to UI Forms
I don't think this is exactly what you are asking, but the GWT declarative UI track is aiming to make UI building a bit easier by making it, well, declarative. You might find some more ideas, or clarification, at least regarding XML to UI widgets, in those threads. http://code.google.com/p/google-web-toolkit-incubator/wiki/DeclarativeUi http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder On Nov 28, 2:15 pm, Startworld67 [EMAIL PROTECTED] wrote: Hi, Maybe, I am too lazy but is there a way for gwt to convert whats in XML (formatted according to gwt requirements) which can parse and construct the form and allow the users to edit and once done, saves to the xml again for future processing. I am trying to avoid learning GWT specific UI elements and gain control from some wrappers which load from xml and save to xml. Something close would behttp://extjs.com/examples/grid/editable.htmlhttp://extjs.com/examples/forms/advanced.html but they should be read from xml and built upon. Sure, I can write the wrappers but I was checking if someone has done this before. A UI-xml framework? Thanks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Sorry Reiner, I wasn't being trying to be facetious. I just wanted to understand exactly what you are saying really. As I understand it so far: a) Don't send sessionID as cookies - deliberately configure app server to stop it using cookies for tracking sessionIDs b) Don't send sessionID as request parameters - or am I wrong here (you say instead lifting the session out of the parameters)? c) You could send sessionID as part of a, say, RPC payload object, but it should be hashed or otherwise encrypted otherwise it's still easily read by a determined black hat. However, nobody actually does this. In any case encryption libraries available for java script are not Mallory proof) d) The only bomb proof way to serious security (i.e. Mallory proof) is via SSL. I suppose my question is this really: Say you do not want to use SSL (apart from maybe initial log in), but you also don't really want to send session ID's that any old Eve (using your Mallory Eve thing) can read falling off a log, it's not really clear to me what to if you don't do something like c). Reading your posts back in October last year: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/59f3aafcf4951523 my understanding is: 1) Unless you use SSL across the board you cannot defend against Mallory. However Mallory is rare. 2) Invest $60 in a SSL certificate and run your log-in/lost p/w stuff through SSL otherwise a determined Eve can get uid/pw and simply use the front door 3) To defend against Eve discovering the session, you need a procedure like the one you describe (e.g. key = sessionID + + counter + + SHA256_HASH(sessionBase,counter++); 4) from Eve's point of view, it doesn't really matter where (key = sessionID + + counter + + SHA256_HASH(sessionBase,counter++) is in the packet (request parameter, buried in RPC payload whatever) she will find it and either she can crack it or she can't. Therefore your point is (I think, and I appreciate you've been trying to explain this for months until you are blue in the face) there is no point at all in doing something like I was suggesting above for the simple reason that a) if the encryption of the session id is strong enough to defeat Eve, it doesn't matter where it goes in the packet, and b) if it isn't strong enough to defeat Eve, it equally doesn't matter where it goes in the packet. Forgive me if I'm being dense, Reinier, and my applogies if my previous comment offended you, it wasn't meant to. regards gregor On Nov 29, 11:29 am, Reinier Zwitserloot [EMAIL PROTECTED] wrote: You're asking me if some Reinier Approved algorithm would meet with my approval? Uh, yes. I have a question for you, though: Does a gregor approved method of shooting a puppy meet with your approval? If not, can you explain why? On Nov 28, 9:02 pm, gregor [EMAIL PROTECTED] wrote: @Reinier gregor: What do you mean 'bad idea because the session ID would be visible on the wire'? All session IDs are visible on the wire, unless you set up a scheme where the client javascript does some hashing or encryption. Suppose I replaced: sessionID = someSessionIDCookieGrabbingMethod(); with: sessionID = someReinierApprovedEncryptionAlgorithm(); would this meet with your approval? If not can you explain why? regards gregor It's been floated as an idea many times on this forum, and it is certainly feasible, but its very much outside of the norm. Virtually nobody on the entire web is doing this today. There are a number of issues I don't really want to get into. Suffice to say: Yes, doable. Yes, very cool. No, not standard or required by any stretch of the imagination. Such a scheme would still be significantly less secure than SSL, because it won't hold up to a man in the middle attack (the man in the middle will just modify your GWT code to send the password to his secret server in nigerussomania. On Nov 28, 12:52 pm, Patrick Ratelband [EMAIL PROTECTED] wrote: Hey everyone, I have been working a while now on properly defending my GWT app against Cross Site Request Forgery (XRSF) with a minimal change in the code of the application itself. My idea has been to create a new RPC call that will be the same from the programmers points of view as the normal, but which will add some value (a sessionID for instance) to the list of supplied parameters just before the call is send. Then, on the server side, the programmer would extend the SecureRemoteServiceSevlet (SRSS) instead of the normal one. This secure version will simply remove the extra paramater, check it's validity and only execute the requested method if the authentication succeeds. So far I have been able to subclass the RemoteServiceServlet (RSS) into the SRSS. It overrides the processCall(String payload) method to implement the verification (in my case the last argument, but that can easily be changed),
Debug problem
I debug using netbeans and recently updated to 6.5 and tested GWT support for debug etc. Everything worked as expected. Today for some reason when I go and debug by right clicking debug on the project in netbeans the normal process begins and the GWT shell and browser startup. Then the operating system prompts me to open or save the html file. When I select open it is loaded in the default web browser. The GWT browser URL is empty and if I type in the expected URL into the GWT broswer and hit GO I get the same popup. It could be netbeans 6.5 related but it was working after the upgrade and when I ran in 6.1 I get the same behavior as in 6.5 but they are both sharing the same project directory. Has anyone else seen this problem? Any suggestions? Thanks Scooter --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Replies inline... On Nov 29, 2:08 pm, gregor [EMAIL PROTECTED] wrote: a) Don't send sessionID as cookies - deliberately configure app server to stop it using cookies for tracking sessionIDs This does mean that sessions don't survive the user reloading the page or closing his browser. This is generally speaking not acceptable to most GWT developers. My point was: They are in the cookie -anyway-, so worrying about the session ID hitting the wire, while fruitful and of some concern, is outside of the norm. 99% of all websites take this risk. The Sheep Routine (be like everybody else) is *NOT* in general a wise path to take in regards to security, but unless there are a non- trivial amount of non-insane security gurus preaching doom and gloom, you should be okay. In this case, I'm saying that sharing session IDs is generally okay, and I'm not aware of any security gurus preaching doom and gloom. So, session IDs hitting the wire is no (practically solvable) problem. If you have a very sensitive app, you should obviously use SSL, and you may want to invalidate them once in a while. Many sites do this (google invalidates biweekly (fair enough), paypal invalidates every time you breathe to the general annoyance of all, ebay every 24h (similarly ridiculous), et cetera). General Rule: Security does not trump user friendliness. Don't invalidate sessions unless you have a pressing reason to do so. If a tiny, rarely used part of your app is sensitive but the rest isn't, use time-sensitive servlets: Give servlets the time since the session was created and allow a servlet to say that this is no good, which should lead to a login screen. b) Don't send sessionID as request parameters - or am I wrong here DO send sessionID as parameters. ALWAYS do this. The cookie is there ONLY for the benefit of the client GWT code so that it can fish the sessionID out of the cookie in order to survive reloads and browser quits. If we could tell the browser to stop sending the cookie along, we would. In practice you shouldn't do this (you CAN take down the cookie and add a window closing hook to put it back, but the window closing hook is more of a prayer / hopeful suggestion than something that gets reliably called). You could more reasonably take out the cookie right before you send a request and put it back right after if you're sufficiently paranoid, but there's no serious benefit here unless you also go for the other outside-of-the-norm maneuvre of cryptographically hiding the session ID. So, let me make this perfectly clear: Attempting to keep the session ID out of the hands of people listening on the line is technically possible but something you SHOULD NOT DO unless you are a security expert and/or in the mood to tinker and experiment. It's not something anybody really does right now, though being the first is nice. If you are a tinkerer / experimenter / guru. Not if you're just trying to get on with your project. The reason you, as a server, look ONLY at the session ID transfered in the BODY of the incoming request (instead of the cookie, which would also be there), is to avoid XSRF (a.k.a. seasurf a.k.a. Cross Site Request Forgery, see wikipedia) attacks. In order to properly protect against XSRF, you should also NOT use x-www-form-encoded as your wire format. Use JSON (add session ID as a key/value pair in the top-level map), GWT-RPC (Add it as a field in the class you are passing along the wire), or some non-x-www-form-encoded-fakable format of your own devices, if you have very weird requirements or some such. Don't use XML, obviously - as wire format it's ridiculous. It would be good if you are consistent with this mechanism (for JSON, always call it 'sessionID' and always transfer dictionaries, not arrays, and for GWT-RPC, make everything extend something simple that contains just a getSessionId() method). This way, you can write one generic session ID checker that passes the session ID onwards to your server framework's session system. That's a lot better than forcing every individual servlet to manually fish out the session ID and chat to the session system. It helps ensure that you don't forget to use this alternative session mechanism if you can somehow tell your framework's session system to not mess with cookies (neither write nor read them). Instead, your login servlet will manually generate one (e.g. HttpSession.newSession), send it along to your GWT code, and then your GWT code uses the GWT Cookie class to set the cookie. Similarly, it will retrieve the cookie via GWT's Cookies class, and send that right away to the server if its there (in its entrypoint). This comes back to the reason you're using the cookie in the first place: To let the session survive browser shutdowns and reloads. It's not a reliable authentication mechanism due to XSRF. c) You could send sessionID as part of a, say, RPC payload object, but it should be hashed or otherwise encrypted otherwise it's still easily read by a
Re: Problems adding a Digg This link
I doubt digg's js thingie is written by an intelligent developer (digg has a track record of sorts). There IS a way to write such widget scripts so they work in all situations, including the peculiar way GWT builds webpages, but not many web widgets work this way. So, assuming for a moment that won't fly, here's the easiest alternative: Use com.google.gwt.user.ui.HTML. On Nov 29, 1:48 pm, Charlie Collins [EMAIL PROTECTED] wrote: Can't you just add the script element to your host page, the same way you would in HTML? That is to say, don't try to recreate the script element in Java and have GWT insert it, just put it on the host page (the same place you put the gwt script tag, etc). On Nov 27, 11:33 pm, mayop100 [EMAIL PROTECTED] wrote: I'm trying to add a Digg This link to my gwt website. If my website were just an html page, all I would need to do is include this line in my HTML: script src=http://digg.com/tools/diggthis.js; type=text/ javascript/script I've tried adding a new element to the page with DOM.createElement (script), but it ends up replacing the entire contents of the page with my digg link. I've also tried a JSNI solution, but with no success. It seems to me there should be an easy solution for this... anyone? Thanks - -Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Problems adding a Digg This link
Reinier is correct there, it's more complicated than I was making it. That Digg script works quite a bit differently than I was guessing before I actually looked at it. What I meant is still possible, but probably not what you want depending on the situation. If your host page has a separate div for your GWT content, and a separate div for the little Digg script, what I originally said should work - but it would always just link (digg) to your host page (which would be your entire GWT app in the canonical case). To do this right, it looks like you would need to make sure your GWT app uses History and then you need to Digg the correct state with the tokens and so on. You could use HTML as Reinier suggests, and make sure to change the URL for the Digg button each time you have different state: script type=text/javascript digg_url = 'WEBSITE_URL'; /script script src=http://digg.com/tools/diggthis.js; type=text/ javascript/script Looks like they also have a submit your own thing that you could just make a GET request to to submit: http://digg.com/submit?url=example.comtitle=TITLEbodytext=DESCRIPTIONmedia=MEDIAtopic=TOPIC. (With that you could make your own buttons or links or whatever, and then just make the digg request with proper params. You could use that and make a Digg GWT Widget? Sorry I piped up though, I don't really know much about Digg in particular, I was just trying to make suggestions in the general GWT sense.) On Nov 29, 10:39 am, Reinier Zwitserloot [EMAIL PROTECTED] wrote: I doubt digg's js thingie is written by an intelligent developer (digg has a track record of sorts). There IS a way to write such widget scripts so they work in all situations, including the peculiar way GWT builds webpages, but not many web widgets work this way. So, assuming for a moment that won't fly, here's the easiest alternative: Use com.google.gwt.user.ui.HTML. On Nov 29, 1:48 pm, Charlie Collins [EMAIL PROTECTED] wrote: Can't you just add the script element to your host page, the same way you would in HTML? That is to say, don't try to recreate the script element in Java and have GWT insert it, just put it on the host page (the same place you put the gwt script tag, etc). On Nov 27, 11:33 pm, mayop100 [EMAIL PROTECTED] wrote: I'm trying to add a Digg This link to my gwt website. If my website were just an html page, all I would need to do is include this line in my HTML: script src=http://digg.com/tools/diggthis.js; type=text/ javascript/script I've tried adding a new element to the page with DOM.createElement (script), but it ends up replacing the entire contents of the page with my digg link. I've also tried a JSNI solution, but with no success. It seems to me there should be an easy solution for this... anyone? Thanks - -Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Generating JARs of client code?
Hello, I created the usual eclipse project layout with the applicationCreator and so... Now I want to generate a JAR file representing my client- side GWT code including the RPC interface I defined. My intention is to use this JAR file in another JAVA project to implement the RPC interface, so that the GWT client is able to communicate with this separate server side project. Is this possible or am I missing something? The problem is that my server-side is written in C#. My plan is using GrassHopper to implement this JAVA interface in C# (this would be technically no prob). Also I have access to the whole server side GWT java package with C#. But Grasshopper needs this JAR file to import the java classes into C# So how can I get GWT to generate this JAR file from my client code? Or should I just put all CLASS-files in a zip and rename it to JAR? regards chris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Unable to store current user in session due to badly behaving getThreadLocalRequest()
Hi,
I'm trying to the remeber/store the current user in the HttpSession
object returned by RemoteServiceServlet.getThreadLocalRequest
().getSession(). Unfortunately
RemoteServiceServlet.getThreadLocalRequest() returns null, causing a
subsequent NPE when I call getSession().
public class ClientManagerImpl extends RemoteServiceServlet implements
ClientManager {
private HttpSession getHttpSession() {
return this.getThreadLocalRequest().getSession(true);
}
private void rememberLoggedInUser(User loggedInUser) {
HttpSession session = getHttpSession();
if (session!=null) {
session.setAttribute(currentUser, loggedInUser);
logger.info(session found and currentUser set);
} else {
logger.error(session not found!);
}
}
}
The idea is that the login method will call rememberLoggedInUser
(User) and store the user for future calls to the
RemoteServiceServlet.
All this code is being run from a Spring-based WAR on top of JBoss
4.0.3.
Are there any known issues with thread local variables or
getThreadLocalRequest() that is causing it to work in some conditions
and not in others ?
Many thanks,
Ijonas.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Computers
A computer is a machine that manipulates data according to a list of instructions. The first devices that resemble modern computers date to the mid-20th century (1940–1945), although the computer concept and various machines similar to computers existed earlier. Modern computers are based on tiny integrated circuits and are millions to billions of times more capable while occupying a fraction of the space The ability to store and execute lists of instructions called programs makes computers extremely versatile and distinguishes them from calculators. First Computers was founded in 1988 under the aegis of Brilliant Tutorials, the now 3-decade old national leader with complete COMMITMENT and DEDICATION to EDUCATION. First Computers has been constantly upgrading the contents of their courses to be in line with the changing demands of the industry. http://www.freewebs.com/amplifieir/ http://www.adbrite.com/mb/commerce/purchase_form.php?other_product_id=877737afsid=1 http://www.bidvertiser.com/ http://www.amigos.com/ http://www.clickbank.com/index.html http://www.bigchurch.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Captcha
Micky, I came across this one on SourceForge.net: http://sourceforge.net/search/?type_of_search=softwords=skewpassimage I wasn't able to get the jar file to work in my environment so I included the source in with mine and made the modifications to it needed to get it to run properly in my environment. So far I like the results. David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Unable to store current user in session due to badly behaving getThreadLocalRequest()
Hi
The only issue you may encounter is to call getThreadLocalRequest
in another thread ...
On Sat, Nov 29, 2008 at 9:13 AM, ijonas [EMAIL PROTECTED] wrote:
Hi,
I'm trying to the remeber/store the current user in the HttpSession
object returned by RemoteServiceServlet.getThreadLocalRequest
().getSession(). Unfortunately
RemoteServiceServlet.getThreadLocalRequest() returns null, causing a
subsequent NPE when I call getSession().
public class ClientManagerImpl extends RemoteServiceServlet implements
ClientManager {
private HttpSession getHttpSession() {
return this.getThreadLocalRequest().getSession(true);
}
private void rememberLoggedInUser(User loggedInUser) {
HttpSession session = getHttpSession();
if (session!=null) {
session.setAttribute(currentUser, loggedInUser);
logger.info(session found and currentUser set);
} else {
logger.error(session not found!);
}
}
}
The idea is that the login method will call rememberLoggedInUser
(User) and store the user for future calls to the
RemoteServiceServlet.
All this code is being run from a Spring-based WAR on top of JBoss
4.0.3.
Are there any known issues with thread local variables or
getThreadLocalRequest() that is causing it to work in some conditions
and not in others ?
Many thanks,
Ijonas.
--
Si l'ignorance peut servir de consolation, elle n'en est pas moins illusoire.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: TextArea cannot be resolved to a type
Thank you for your response. I did actually find the getText() and setText() methods before writting this, I was just a little unsure as to how to implement them. the URL feature is an essential element of the program I am trying to write. Since I can't do this with GWT and I can't do this using an applet either (applets can only connect to the same server as well i believe), I think I have hit a dead end. What other options do I have? What do you recommend I use to create this type of web application? Thanks for your help. On Nov 29, 11:40 am, Reinier Zwitserloot [EMAIL PROTECTED] wrote: Go through the GWT Getting started guide. You've screwed up your installation somehow, or you're not using the right command line. It's not a matter of code, it's just that some tool in the chain can't find the TextArea class code. For the rest - really, this is a forum, not a university. Just go through the getting started guide and learn GWT. You should also have a look at the javadoc for all GWT classes. For example, the TextArea javadoc has a getText() method, and a setText() method. You can not use URL in GWT. The GWT Documentation (Notice a pattern?) has a nice listing of which classes are supported. java.net.* is not in it. This isn't because the GWT team is lazy, it's simply because javascript simply can't do this, so there's no way the GWT compiler can compile that code for you. If the URL you want to read in is from the same server that served the webpage (the EXACT same server. Same protocol, same exact server name, same port), then you can use RequestBuilder (A GWT class. Look it up in the .. (drum roll please!) documentation!) which is capable of downloading the contents. On the web, you can pretty much only ever download everything in one go, there are no streams, just complete data. If you need to process a couple megabytes on the client... you're out of luck, then. Maybe your server can download the big data in chunks and pass it to the client in a flurry of requests instead. On Nov 29, 7:50 am, moe374 [EMAIL PROTECTED] wrote: Hello. I have just begun learning java (about 2 months ago) and am now trying to develop a couple applications for the web using java and the GWT. I am having some difficulty and hoping someone can help me out. My first problem I am having is I am getting this error message TextArea cannot be resolved to a type when I am trying to create a text area. I get the error message twice, and for the same line in my code which is TextArea ta = new TextArea(); Is there a line (or multiple lines) of code I have to implement before I can implement the TextArea object? Also, I need to allow the user to paste some information into this text box and allow me to store that information in a variable, and then do something with the information, and then output some information to the user (even in the same text box is fine). Can some one please help me get started on this? Finally, I was wondering if the GWT supports reading the HTML file of a URL, which would normally be done by something like this: URL results = new URL(http://www.some-url.com;); BufferedReader in2 = new BufferedReader( new InputStreamReader( results.openStream())); String inputLine = in2.readLine(); Thank you very much.- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
For what this files?
I compile my GWT application with gwt-ext. After that gwt create some files: GwtExt.css js Directory But I don't use this files in my HTML file. For what this file? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Problem with the import java.security.*;
If you are trying to use the java.security package on the client it is
unlikely that GWT supports them.
On Nov 28, 6:08 am, Phani [EMAIL PROTECTED] wrote:
Hi All,
In my application i have to implement a unique number generation i.e
UUID using SecureRandom class of java.security package. Please refer
the below code.
try {
// Create a secure random number generator
SecureRandom sr = SecureRandom.getInstance(SHA1PRNG);
// Get 1024 random bits
byte[] bytes = new byte[1024/8];
sr.nextBytes(bytes);
// Create two secure number generators with the same seed
int seedByteCount = 10;
byte[] seed = sr.generateSeed(seedByteCount);
sr = SecureRandom.getInstance(SHA1PRNG);
sr.setSeed(seed);
SecureRandom sr2 = SecureRandom.getInstance(SHA1PRNG);
sr2.setSeed(seed);
} catch (NoSuchAlgorithmException e) {
}
But i'm facing a problem stating that java.security cannot be resolved
to a type. Please help me.Whether GWT doesn't support java.security
package?
Thanks in Advance,
Phani.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: @EJB annotation during junit testing doesn't work
If you are running outside of a container then you will need to
instantiate your EJBs yourself ('new). This is unrelated to GWT.
On Nov 27, 7:53 am, jolero [EMAIL PROTECTED] wrote:
Hello everybody.
While developing junit tests in GWT app I have stucked on a problem
that I cannot solve for couple of days now.
In normal runtime I can normally call RPC services that use JPA
(Toplink and Glassfish Appserver) for data access purposes, but during
Junit tests (My tests extends GWTTestCase and use delayTestFinish and
finishTest for asynchronous calls as described in GWT documentation)
RPC methods that use injected objects are failing with
NullPointerException. In other words @EJB annotatnion doesn't work,
Beans are not injected and references to them are nulls.
Have anybody had that issue? Does anybody know a solution? Thx in
advance.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Problems adding a Digg This link
Thanks for the prompt feedback guys. I played around with the HTML widget, but I wasn't able to get it to actually execute the script. I didn't want to just include it in my index.html file... I plan to have multiple digg this links on the site, and each one will need to jump to the appropriate place using history tokens. I managed to get it working without running any javascript though. The digg script just creates an iframe with some URL-encoded arguments, so I simply created my own iframe and encoded the URL myself. The only downside is that I'll have to watch out if digg ever changes their API. If anyone does find a way to use the HTML widget to actually create and _execute_ javascript code I'd love to hear about it though. -Andrew On Nov 29, 9:48 am, Charlie Collins [EMAIL PROTECTED] wrote: Reinier is correct there, it's more complicated than I was making it. That Digg script works quite a bit differently than I was guessing before I actually looked at it. What I meant is still possible, but probably not what you want depending on the situation. If your host page has a separate div for your GWT content, and a separate div for the little Digg script, what I originally said should work - but it would always just link (digg) to your host page (which would be your entire GWT app in the canonical case). To do this right, it looks like you would need to make sure your GWT app uses History and then you need to Digg the correct state with the tokens and so on. You could use HTML as Reinier suggests, and make sure to change the URL for the Digg button each time you have different state: script type=text/javascript digg_url = 'WEBSITE_URL'; /script script src=http://digg.com/tools/diggthis.js; type=text/ javascript/script Looks like they also have a submit your own thing that you could just make a GET request to to submit:http://digg.com/submit?url=example.comtitle=TITLEbodytext=DESCRIPTI (With that you could make your own buttons or links or whatever, and then just make the digg request with proper params. You could use that and make a Digg GWT Widget? Sorry I piped up though, I don't really know much about Digg in particular, I was just trying to make suggestions in the general GWT sense.) On Nov 29, 10:39 am, Reinier Zwitserloot [EMAIL PROTECTED] wrote: I doubt digg's js thingie is written by an intelligent developer (digg has a track record of sorts). There IS a way to write such widget scripts so they work in all situations, including the peculiar way GWT builds webpages, but not many web widgets work this way. So, assuming for a moment that won't fly, here's the easiest alternative: Use com.google.gwt.user.ui.HTML. On Nov 29, 1:48 pm, Charlie Collins [EMAIL PROTECTED] wrote: Can't you just add the script element to your host page, the same way you would in HTML? That is to say, don't try to recreate the script element in Java and have GWT insert it, just put it on the host page (the same place you put the gwt script tag, etc). On Nov 27, 11:33 pm, mayop100 [EMAIL PROTECTED] wrote: I'm trying to add a Digg This link to my gwt website. If my website were just an html page, all I would need to do is include this line in my HTML: script src=http://digg.com/tools/diggthis.js; type=text/ javascript/script I've tried adding a new element to the page with DOM.createElement (script), but it ends up replacing the entire contents of the page with my digg link. I've also tried a JSNI solution, but with no success. It seems to me there should be an easy solution for this... anyone? Thanks - -Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: TextArea cannot be resolved to a type
Do it on the server. If that is no option, write desktop software (something you install and that doesn't run in a browser at all). You can also use web based platforms that allow signing / trusting, such as applets, but be aware that users will need to hand the keys to the kingdom to your app, and in general, the vomitous stream of text filled with red, screamy words, and dangerous looking symbols in the popup that shows up when you ask for this trust makes users have a mild heart infarction, and blame you for it. On Nov 29, 9:06 pm, moe374 [EMAIL PROTECTED] wrote: Thank you for your response. I did actually find the getText() and setText() methods before writting this, I was just a little unsure as to how to implement them. the URL feature is an essential element of the program I am trying to write. Since I can't do this with GWT and I can't do this using an applet either (applets can only connect to the same server as well i believe), I think I have hit a dead end. What other options do I have? What do you recommend I use to create this type of web application? Thanks for your help. On Nov 29, 11:40 am, Reinier Zwitserloot [EMAIL PROTECTED] wrote: Go through the GWT Getting started guide. You've screwed up your installation somehow, or you're not using the right command line. It's not a matter of code, it's just that some tool in the chain can't find the TextArea class code. For the rest - really, this is a forum, not a university. Just go through the getting started guide and learn GWT. You should also have a look at the javadoc for all GWT classes. For example, the TextArea javadoc has a getText() method, and a setText() method. You can not use URL in GWT. The GWT Documentation (Notice a pattern?) has a nice listing of which classes are supported. java.net.* is not in it. This isn't because the GWT team is lazy, it's simply because javascript simply can't do this, so there's no way the GWT compiler can compile that code for you. If the URL you want to read in is from the same server that served the webpage (the EXACT same server. Same protocol, same exact server name, same port), then you can use RequestBuilder (A GWT class. Look it up in the .. (drum roll please!) documentation!) which is capable of downloading the contents. On the web, you can pretty much only ever download everything in one go, there are no streams, just complete data. If you need to process a couple megabytes on the client... you're out of luck, then. Maybe your server can download the big data in chunks and pass it to the client in a flurry of requests instead. On Nov 29, 7:50 am, moe374 [EMAIL PROTECTED] wrote: Hello. I have just begun learning java (about 2 months ago) and am now trying to develop a couple applications for the web using java and the GWT. I am having some difficulty and hoping someone can help me out. My first problem I am having is I am getting this error message TextArea cannot be resolved to a type when I am trying to create a text area. I get the error message twice, and for the same line in my code which is TextArea ta = new TextArea(); Is there a line (or multiple lines) of code I have to implement before I can implement the TextArea object? Also, I need to allow the user to paste some information into this text box and allow me to store that information in a variable, and then do something with the information, and then output some information to the user (even in the same text box is fine). Can some one please help me get started on this? Finally, I was wondering if the GWT supports reading the HTML file of a URL, which would normally be done by something like this: URL results = new URL(http://www.some-url.com;); BufferedReader in2 = new BufferedReader( new InputStreamReader( results.openStream())); String inputLine = in2.readLine(); Thank you very much.- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Compilation Problem
I am seeing the same issue with 1.5.3. I am seeing a NullPointerException when I edit my app sources in Eclipse and use the Compile/Browse option in the Hosted browser. Rahul On Nov 28, 12:16 pm, Sandile [EMAIL PROTECTED] wrote: I get an error every time that I try to compile my code: [ERROR] Errors in 'jar:file:/C:/dev/gwt-windows-1.5.3/gwt- windows-1.5.3/gwt-dev-windows.jar!/com/google/gwt/dev/jjs/intrinsic/ com/google/gwt/lang/Stats.java' [ERROR] Missing message: compilation_internalError in: org.eclipse.jdt.internal.compiler.messages java.lang.NullPointerException at com.google.gwt.dev.javac.JdtCompiler $CompilationUnitAdapter.getContents(JdtCompiler.java:65) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java: 9236) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java: 9208) at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse (Parser.java:7864) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile (Compiler.java:587) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile (Compiler.java:357) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java: 371) at com.google.gwt.dev.jdt.AbstractCompiler$CompilerImpl.compile (AbstractCompiler.java:84) at com.google.gwt.dev.jdt.AbstractCompiler$CompilerImpl.compile (AbstractCompiler.java:180) at com.google.gwt.dev.jdt.AbstractCompiler$CompilerImpl.access$400 (AbstractCompiler.java:70) at com.google.gwt.dev.jdt.AbstractCompiler.compile (AbstractCompiler.java:493) at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.getCompilationUnitDeclaratio ns (WebModeCompilerFrontEnd.java:73) at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.init (JavaToJavaScriptCompiler.java:277) at com.google.gwt.dev.GWTCompiler.distill(GWTCompiler.java:353) at com.google.gwt.dev.GWTShell.compile(GWTShell.java:639) at com.google.gwt.dev.GWTShell$BrowserWidgetHostImpl.compile (GWTShell.java:220) [ERROR] java.lang.NullPointerException java.lang.NullPointerException: null at com.google.gwt.dev.javac.JdtCompiler $CompilationUnitAdapter.getContents(JdtCompiler.java:65) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java: 9236) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java: 9208) at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse (Parser.java:7864) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile (Compiler.java:587) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile (Compiler.java:357) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java: 371) at com.google.gwt.dev.jdt.AbstractCompiler$CompilerImpl.compile (AbstractCompiler.java:84) at com.google.gwt.dev.jdt.AbstractCompiler$CompilerImpl.compile (AbstractCompiler.java:180) at com.google.gwt.dev.jdt.AbstractCompiler$CompilerImpl.access$400 (AbstractCompiler.java:70) at com.google.gwt.dev.jdt.AbstractCompiler.compile (AbstractCompiler.java:493) at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.getCompilationUnitDeclaratio ns (WebModeCompilerFrontEnd.java:73) at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.init (JavaToJavaScriptCompiler.java:277) at com.google.gwt.dev.GWTCompiler.distill(GWTCompiler.java:353) at com.google.gwt.dev.GWTShell.compile(GWTShell.java:639) at com.google.gwt.dev.GWTShell$BrowserWidgetHostImpl.compile (GWTShell.java:220) at com.google.gwt.dev.GWTShell$BrowserWidgetHostImpl.compile (GWTShell.java:227) at com.google.gwt.dev.shell.BrowserWidget$Toolbar.widgetSelected (BrowserWidget.java:132) at org.eclipse.swt.widgets.TypedListener.handleEvent (TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java: 3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at com.google.gwt.dev.GWTShell.pumpEventLoop(GWTShell.java:720) at com.google.gwt.dev.GWTShell.run(GWTShell.java:593) at com.google.gwt.dev.GWTShell.main(GWTShell.java:357) Somebody please explain and/or help! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: IE7 Error in cache.html's Javascript
Ok, I found the issue... seems it was a programming error on my part.
Not waiting for all Lists to come back from the server before
processing it in the client. I wish there was some easy way to handle
this kind of thing. Is there some way to make some requests
synchronous? It seems the reason this occurred was due to asynchronous
request/processing.
On Nov 29, 2:45 am, KevinF [EMAIL PROTECTED] wrote:
Hi everyone,
I'm running into a really weird problem with IE7 when I view my site
that was created using GWT. The client makes several calls to the
server to retrieve Lists of information. This problem does not occur
in Firefox 3 nor in Safari. The error I'm getting is
Line: 2818
Char: 3
Error: Exception thrown and not caught
Code: 0
URL: http://domain/997866B17568BBEABF330CD77D093CE1.cache.html
From what I gather, it seems this file is the my application logic
tailored for IE. When I look into the file at line 2818, I find:
2817: function java_util_AbstractList_indexOutOfBounds__II(index, size)
{
2818: throw java_lang_IndexOutOfBoundsException_
$IndexOutOfBoundsException__Ljava_lang_IndexOutOfBoundsException_2Ljava_lang_String_2
(new java_lang_IndexOutOfBoundsException(), $intern_130 + index +
$intern_131 + size);
2819: }
I tried to find where the callers of this method were and there were
3 of them:
(1) function java_util_ArrayList_
$add__Ljava_util_ArrayList_2ILjava_lang_Object_2(this$static, index,
o)
(2) function java_util_LinkedList_
$listIterator__Ljava_util_LinkedList_2I(this$static, index)
(3) function java_util_AbstractList_checkIndex__II(index, size)
I'm guessing this means somewhere my application is trying to access
an index in a List that's not within bounds of it. The puzzling thing
is, how come this only happens on SOME IE7 browsers and does not occur
at all in Firefox or Safari.
Any ideas or fixes would be much appreciated.
Kevin
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
FileUpload and Chrome
Hi,
I have a panel with a FileUpload widget. It works fine in hosted mode,
Internet Explorer and Mozilla, but not in Chrome. In Chrome, it looks
slightly different, and the upload fails at the server end. In the
others, the upload works just fine.
In the other browsers (ie not Chrome), the panel shows a box, in which
the filename appears after I have selected it from the filesystem.
Next to that there is a button, labelled 'BROWSE'. Under that is the
submit button.
In Chrome, there is a label, which says 'Choose File' and next to
that, it says 'No file chosen'. So there isn't the usual box.
Underneath that is again the submit button. I can choose a file in
Chrome in the usual way (by pressing Choose File), but then if I
submit it, the upload fails on the server end, with the following
error:
org.apache.commons.fileupload.FileUploadException: Processing of
multipart/form-
data request failed. Connection reset
at org.apache.commons.fileupload.FileUploadBase.parseRequest
(FileUploadB
ase.java:384)
at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(
ServletFileUpload.java:116)
at ac.otago.flags.server.FileUploadServlet.doPost
(FileUploadServlet.java
:74)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationF
ilterChain.java:206)
My DoPost method in the upload servlet looks like this (as far as it
gets)
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException
{
try {
ServletRequestContext ctx = new
ServletRequestContext(request);
if (ServletFileUpload.isMultipartContent(ctx) == false)
{
sendResponse(response, new FormResponse(
HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
The servlet can only handle
multipart requests.
+ This is
probably a software bug.));
return;
}
// Create a new file upload handler
ServletFileUpload upload = new ServletFileUpload(
new DiskFileItemFactory());
// Parse the request
ListFileItem items = upload.parseRequest(request);
And this final line throws the exception. (It's line 74)
I have posted this question on apache commons forum, but go no
response.
Why would this happen in Chrome, or how can I proceed to solve this
problem?
Thank you for your help,
Michel
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
