I followed these instructions
http://code.google.com/webtoolkit/usingeclipse.html
There appears to be no entry point function for the server? How do I run background threads or code not related to the rpc services that the server exports?
For example, what if some embedded database needs to be updated every 5 minutes. So then a background thread would fetch this new data to do the updating
GWT is client-side technology and has nothing to do with server-side. You can use any servers-side technology with it. If you use java/servlets then you can optionally use GWT-RPC, which is nice, but not required.
Web applications are based around request-reply paradigm: when there is a request, they handle it and send back the reply. Servlets are designed around this paradigm. They are used at some of the largest sites and are not just a toy (as you noted in other comment).
When you need something to run periodically, then this is usually the job for Job Schedulers. I'd recommend Quartz, which has great documentation. There is also an example how to initialize it in servlet environment.
thats not how web applications are supposed to work. Read http://code.google.com/intl/de-AT/webtoolkit/doc/latest/tutorial/clientserver.html
If you want to run some processing when request comes and potentially include some dynamic parts, you can just make your pages to be JSP or servlets. GWT does not need to be used in HTML files. Just the page served by server need to be HTML. So something like server side entry point is either JSP or servlet. Otherwise you need to use PRC. But if you needed to run RPC for every page loaded, you could consider this tip of embedding RPC in the base response.
Related
We have a working web application, which has been developed with ExtJS for client side, and Struts, Spring, Hibernate for server side. now, we are considering to migrate to GXT (or may be GWT itself). The thing is I'm very new to GWT/GXT. and we are trying to decide whether we go down this road or not.
1) Until now, we have 2 domains for our web-app. one is that the application (Struts+...) have been deployed to, and the other is mainly a cookie-less custom CDN. The transfer between client and server is mostly XHR requests, sending/receiving JSON and/or JSONP. But with the new approach ahead of us, I began to understand that we are supposed to have only ONE domain, for the whole GXT application. Is it correct or I forgot to consider something here?
and if not, Is it possible that we deployed just part of the application (i.e. com.ourcompany.webapp.gxt.server.*) to the main server, and the contents that have been compiled and generated by the GWT compiler to the other CDN-like domain?
2) The other big issue we are facing is that the current application is consists of mostly 3 huge modules. One is responsible for "SignIn", the other is for "Webtop", and the third one is "Modules which each users has access to". The latter has been generated on the server due to "access rights" of each users, and obviously could be different from one user to the other.
The only thing I could find on this matter, which might be related is Code Splitting. Although I'm not totally sure if this would be the right solution for this.
We want that the application, on Start Up, checks whether user has been logged in or not. if not, loads the SignIn sets of javascript files (i.e webapp.signin.nocache.js), then after user has entered the correct username/password, unloads this signin file and loads webtop.nocache.js AND modules.nocache.js.
I would be really appreciated if you could help me out.
1) If your GWT app is loaded from a different domain than you have to face the same origin policy. You can not do a xhr to a different domain. You could use the ScriptTagProxy to get around this. But it does not feel very netural.
2) You can use CodeSplitting in order to automatically load a particular part of your application dynamically. All you have to do is to warp your splitt point into an async call.
A detailed compile report gives you a pretty good overview how well code splitting is working.
But CodeSplitting does not unload already loaded code. If its really importend to do so you have to redirect the user to another url in order to load the appropriate user depended module.
Once Javascript code has been loaded and executed its impossible to remove the code from the browsers memory.
Grettings,
Peter
After many support cases we are realizing the biggest problem we have with our GWT-based application is that users are leaving it open for weeks at a time. This means when we do a hotfix every week or two the RPC stubs are out of sync and cause silent exceptions to be thrown making the site look "broken". Does anybody know of a way to auto-detect and avoid this issue? A few ideas I have had are...
On catching an RPC mismatch exception refresh the browser.
When loading the host page inject the version number in source control the build came from, have a status checker/timer that check that the number did not change. When it does reload.
Reload on an arbitrary timer (perhaps twice daily).
Any ideas?
I'd like to present a fourth option.
Create an RPC Proxy and UI Object proxy that all UI requests and RPC requests are routed through. This way whenever this proxy detects that something is out of date it can dynamically load the widget or change it's expected RPC models.
This is pretty how Vaadin does things and it works great. Vaadin is a UI toolkit built on GWT in case you're not aware. We have several long running production applications using this over the last couple of years and we have made some tweaks in their UI Def language (UIDL) to add version mismatch.
This diagram is a good representation of what they do and if you don't want to build something like this yourself I'd of course recommend moving to Vaadin.
Implement security that logs users out after an hour of idle time. Assuming your releases are overnight or on weekends, the users are logging in after the release. No need to refresh the app.
this is viable especially if your site eventually needs users to login.
While using the GWT application, I deployed the new version of the application.
Once deployment is complete my application freezes until I do the full refresh.
I originally thought this was caching problem, so I assigned all the files to be no-cache by setting all response headers using the filter. But still with this filter application freezes when I deploy a new version.
What could be a cause of this?
What I am trying to achieve here is to be able to deploy a new version of GWT application while user is using the application. This means when the JavaScript changes I want user to get it from the server instead of using the cached one without any glitch (maybe slow response time since request need to go to the server in this case).
Note:
This is observed when deployed with the changes in the code, so I am
guessing one of the cache.js file.
When deployed without any changes to a code this is not observed.
Your question is not clear because it does not tell which situation you are in:
You deploy the new GWT app and you want the new server-side to respond to the old client-side.
You deploy the new GWT app and you want the client browser to immediately replace the GWT client with the new version.
I would like to speak about situation 2, first. I am thinking you came from a background of servlets and JSP, plus dynamically generated HTML and Javascript. In those env, the client is immediately replaced everytime your client places requests the server. That is because the client UI is refreshed by new response generated by the server.
In GWT, the root panel is not refreshed. The root panel is held by the hosting html page. If the hosting html page is not refreshed, the GWT client will forever be the old version. That is the very idea of AJAX and GWT. You don't want to have to refresh the web page and yet allowing the web page to continuously emit/receiv async requests/responses.
You might be reminded that GWT is compiled into javascript.
In order to get the new version, you have to refresh the web page. There is no way in GWT technology for the new javascript to sneak into the browser to replace the old sets of javascript, unless you refresh the page.
The script tag source link is already read when the GWT javascripts are loaded. Those links will not be reread unless you refresh the page. If those links are not re-read, then the new javascripts will never be reloaded.
You need to detach your JSP/servlet experience when dealing with AJAX.
Back to situation 1 ..
Since the new GWT UI version was not loaded, because you did not perform a refresh, you would have incongruences between the data structure expected by the old UI version with that of the new server-side version. If you can guarantee the stability of RPC or client-server data structure and sequences of exchange, I believe you should not have a problem.
However, with GAE, the serialization id is important. You may have changed the data structure of a POJO without updating the serialization id. That would confuse the GAE client-server traffic, because ... hmmm ... I can faintly recall the exact sequence of problem I had faced - You better read up on GAE pojo serialization id yourself.
I also had such problem. In such case you should have one table which keeps every new upload information. And also you should have one async request (maybe in your EntryPoint) for checking whether you have new upload or not.
public void success(String version) {
if(!Cookies.getCookie("version").equals(version)){
Window.open(currentUrl, "_self", "");
}
}
This is what i've done and working without any problem...
The problem is from your web server not the GWT itself. You should see if your Web Server supports hot-deployment or not and how it works with it.
UPDATE :
For example Tomcat prior to version 7 does not support Hot-deployment and you have to restart the server on every update whereas Tomcat 7 supports Hot-deployment and you only have to reload the page to get the new module.
I have a small app running in JBoss that uses web services and every time they are called, it parses the WSDL and tries to fetch from xmlsoap.org [1] in order to validate it (the WSDL).
Is there a way to avoid this validations? The problem is that:
It's slowing down the system and
Many times xmlsoap.org [1] doesn't return correctly (returns broken HTML instead of XML).
I could make schemas.xmlsoap.org point to localhost and serve the schema from there, but it seems like a very dirty solution. There must be a way to run JBoss/xerces in non-validating mode or something.
[1] http://schemas.xmlsoap.org/wsdl/
It does look like there's a way to run xerces in non-validating mode.
1) Use a resolver to cleanly deliver the schema from classpath.
2) Turn off validation. It's pretty unlikely that JBoss lacks a way to configure that.
I have an apache2 / mod_perl website. On one page, I need to do some server/server communication via SOAP.
The results of this communication are not required for the rendering of the page (but user input is required to trigger this communication).
The SOAP communication is very slow.
So what I want to do is process and print the page for the user, then do all the SOAP stuff behind the scenes.
What's the best way to achieve this? start some fork? write the job to a file and have a cronjob pick it up?
Thanks
There are two types of solutions: First you can do what Randal Schwartz suggested here. Second you could use a Message Queue like Beanstalk or Gearman. Beanstalk has a Perl Client and is now persistent and is ideal for lightweight stuff. Gearman on the other hand has more features, more worked on. There is also TheSchwartz - use it if you can do without too much documentation. cron is ideal for systematically repeating tasks. For the kind of application you have, it appears that Schedule::At might be more appropriate if you prefer a more generic "message-queue"
Also see an old StackOverflow Thread here