We are building a project and will be using gwt 2.7 with rest ( spring) and weblogic server.
The problem which we face is that I want to run the gwt module on superdev mode (which runs on 8888 port by default) but the rest is deployed on 7001 port on weblogic server.
I cannot call the rest services from superdev mode as it gives a cross site scripting error.
How can get my super dev mode running so that I can test and develop UI and connect to rest services on different port.
I know there has been topic on use a different server for dev mode. But i don't see any examples.
Can some please suggest wat needs to be done. Even if it requires changing the project structure to get the dev mode working with rest.
This is a common problem for web-development. It can be solved by using:
CORS (at the REST server)
Using a proxy servlet (I use this approach, but with a handwritten servlet)
Disable the browser security (I would not do this)
did you try running GWT module on external server mode?
Related
I created a restful web service with java in eclipse
I used Eclipse toolkit to deploy my WS.
I'm just wondering how to test http requests? I mean there is the default URL to the app porvided by azure myapp.azurewebsites.com
but how to do a POST or GET?
and also DO I need to chose the same tomcat version when deploying my app in azure?
I have tomcat 6 on my computer, but in azure i chose tomcat 8 for example
thank you all for your answers.
I don understand your question. You can perform a GET request in any browser and a Post using tools like Postman or Fiddler (just to name a few). We can' tell you which path you have to use because it depends on your application but it should be the same as if you run it local (except the different host address). Also whether you have to choose the same tomecat version depends on your application and the component it uses - you are the only person who can answer that.
The project I work at is quite specific. We use GWT with SAP backend. We run the Dev Mode using the following configuration (as program arguments; I run the project directly using IntelliJ IDEA)
-noserver -logLevel INFO -startupUrl http://server-url:8000/aaa -whitelist ^http[:][/][/]server-url[.]eu[:]8000/aaa com.company.project.main.Main
Note, we didn't use a local server (-noserver).
After familiarizing myself with the Super Dev Mode, I understood, that it works similar to GWT Web Mode, i.e. it compiles JavaScript (the folder to compile to can be specified) and then runs the code server with that script hosted.
Due to the specifics of the project, the compiled JavaScript is deployed to the remote server using maven via WebDav. So simply specifying -workDir as a parameter will not deploy the scripts on the remote server. Nor can we run (at least at the moment) a Java server on the server-url address.
Can we use the Super Dev Mode in this situation?
Yes you can.
EDIT 2016-11-27: I built a devserver that can use -launcherDir-style SuperDevMode without the need to write to the server, by using a webpack-like proxy: https://github.com/tbroyer/gwt-devserver
EDIT: there are a few issues re. deferred-binding properties. The recommended use of SDM (since GWT 2.7) is to use -launcherDir which means using a local server.
SuperDevMode works much like DevMode with -noserver, which means you have to deploy your app at least once to your server. In the case of SuperDevMode, it means you have to compile and deploy with the xsiframe linker and devModeRedirectEnabled property set to true.
Then you run SuperDevMode on your machine, create your bookmarklets if not done already, load your app from the remote server and click the Dev Mode On bookmarklet.
This will store something in the browser's sessionStorage so that reloading the page will now load the permutation from the SuperDevMode running on your machine rather than the remote server.
More info about how SuperDevMode works: http://blog.ltgt.net/how-does-gwts-super-dev-mode-work/
For now, I see only one possible solution, which is to run the gwt-codeserver.jar somehow on the SAP server (with the address, say, http://server-url:8000/bbb) and write a servlet, that will redirect all requests to http://server-url:8000/aaa. However, this is not very easy to implement. The SAP server has "tricky" authentication mechanism, where user first sees the logon page and then they are redirected to a generated session-specific URL.
Other ideas are very welcome.
I have a GWT project that contains both the GWT UI and the server backend. The server backend contains the Java GWT Services that are exposed via GWT's RPC to the UI.
Since the project has grown quite a bit, with the backend requiring more and more time to start, I am considering moving the UI to a separate project, with the idea to run the backend in a separate VM. The backend is relatively stable, and it is the UI where we spent most time. With the two in separate VMs, we could work on the UI much more efficiently, since we would only reload the UI (in GWT development mode) and leave the backend running.
My question: Is it possible to configure the Google Eclipse Plugin in such a way that it runs the UI and backend in separate VMs and I can still use the GWT development mode?
The project uses GWT 2.4 and we will update to 2.5 as soon as it is out. We use Maven as the build system.
There are two things to consider:
You don't always have to reload the server - usually it's enough to just reload the browser page [*] For an overview of when to reload/restart, ... please see https://stackoverflow.com/a/6150736/291741
You can deploy to an external server. In an Eclipse Run Configuration, go to the Server tab, and uncheck "Run built-in server". This will disable the web server (default port 8888), but will still run the Code Server (default port 9997, see the GWT tab). Then just run your external server (e.g. Tomcat) on port 8888. It should serve the web content, and handle the servlet requests.
If you want to create a really cool fully automated Eclipse-JavaEE + GWT setup, with separate server-side redeploy on any server you like (even with two debugger instances, if you want), see https://stackoverflow.com/a/11700678/291741
[*] I know, there are certain situations, e.g. when changing Gin configuration or Validation annotations, where reloading the web page is unfortunately not enough. But in most cases it just works fine (as long as you run DevMode with "Run As...", not with "Debug As...") If you want to run with a debugger attached, then I'd recommend the external server solution, of course.
Building a Play 2.0 scala app and deploying it to the ROOT context on Tomcat (from what I understand, a Play app must be deployed to ROOT context). There are other web apps running on this server at different contexts, but with the Play app at root, it is intercepting every request and failing if it is a route it does not understand.
Is there any way to have Play ignore a route in order to have Tomcat continue dispatching it to a servlet that is registered for that context?
thanks,
brian
In fact the limitation you have seams to be linked to sub-context deploiement. The play2 war plugin does not support it until Play 2.1
It could be possible to trick with tomcat conf to do what you want. I don't know tomcat enough to give you the right conf.
You can still deploy your Play app as a standalone app (not embedded in Tomcat) and use a front-end HTTP server to handle reverse-proxy to the right HTTP server. You will have to define for each HTTP server the right port to run on and then configure your reverse-proxy to route the request depending on the domain/port to the right local port. I use Nginx for that. Maybe Tomcat can handle this also.
Actually, it turns out that this was not a problem after all. I had inadvertently not had the other apps deployed in the same tomcat server I was testing with (doh!). Once I deployed them properly, then the Play Framework app got the requests that were correctly bound for it and the other apps got the requests that were bound for them in the sub-contexts. So, false alarm.
I'm trying to call a web service in my back end java code when it's
running in hosted mode. Everything loads fine, the GWT RPC call works
and I can see it on the server, then as soon as it tries to call an
external web service (using jax-ws) the jetty falls over with a
Internal Server Error (500).
I have cranked the log all the way up to
ALL but I still don't see any stack traces or cause for this error. I just get one line about the 500 Error with the request header and response.
Does anyone know if the internal jetty keeps a log file somewhere, or
how I can go about debugging what's wrong?
I'm running GWT 1.7 on OS X 10.6.1
Edit: I know that I can use the -noserver option, but I'm genuinely interested in finding out where this thing lives!
From the documentation:
You can also use a real production
server while debugging in hosted mode.
This can be useful if you are adding
GWT to an existing application, or if
your server-side requirements have
become more than the embedded web
server can handle. See this article on
how to use an external server in
hosted mode.
So the simplest solution would be to use the -noserver option and use your own Java server - much less limitations that way, without any drawbacks (that I know of).
If you are using the Google Plugin for Eclipse, it's easily set up in the properties of the project. Detailed information on configuration can be found on the official site.
Edit: you could try bypassing the Hosted Mode TreeLogger, as described here: http://blog.kornr.net/index.php/2009/01/27/gently-asking-the-gwt-hosted-mode-to-not):
Just create a file called
"commons-logging.properties" at the
root of your classpath, and add the
following line:
[to use the Log4j backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
[to use the JDK14 backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
[to use the SimpleLog backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
Edit2: the trunk of GWT now also supports the -logfile parameter to enable file logging, but it probably won't help in this case, since the problem lies in the way the Hosted Mode treats the exceptions, not the way it presents them.