I have a Restlet API and a GWT web application in two seperate web applications. I have added the Restlet GWT jar to the GWT web application and written proxy classes for each of the API server resources.
How do I now link up the two? Do i need to add in a servlet into web.xml?
This is probably a beginner question and I might be being very silly but this is my first GWT app.
Yes, You need to setup your Restlet Servlet in the web.xml from your GWT project.
Then, start you gwt project in debug mode (that will launch the jetty servlet) and you will have acces to http://127.0.0.1:8888/YourServlet/...
You can eventually deploy the Restlet Servlet in another server.
Finally write your client services using RequestBuilder.
Have in mind that if you dispose your Restlet Services in another host different that the one where you serves you gwt pages (eg. your restlet is accesed in http://another_host:another_port/YourServlet) then you will have to deal with SOP (http://en.wikipedia.org/wiki/Same_origin_policy).
I recommend you to have different projects one for the server and another for the gwt. The first deployed in Server1 and the second served by Server2. And then deal with SOP using a http proxy which you need to install in Server2.
Related
I want to create a Spring MVC rest application for web browser, android and ios
For web browser, I am using angular2 and my web server is apache tomcat.
So I am confused that I need to put the angular code inside my Spring mvc appllication project directory or create a separate instance for angular.If I have to create separate instance for both then how I will deploy angular code to the tomcat server.
You can do the both.
If you want to put the angular2 files to the tomcat then look here. This is might not straight forward.
If you want to deploy separately, I mean server(spring REST) and client(angular2) then angular2 app can deploy using the ng command or any web server like apache, nginx. You can look here for example
You can do that in any of the ways.
But
with a SPA + REST technology stack, I prefer separating front end and
back end with rest api because static resources are best served from front-server. Since Front-End servers (e.g. nginx,apache2) are very powerful and since you can use Cache for static resources, you can manage with a single deployment of your static resources (which should be all HTML content, JS, CSS, Images).
I want to develop a standalone java application, with web browser as front end. This application will run locally and won't be making any remote server calls. I'm essentially using java, as web-browser cannot perform file operations.
I want this application to be portable: no need of installation. Just copying a folder should be enough. I want to know how it can be done, how will javascript communicate with java code.
In continuation of #Quentin's answer.
Yes, you need web server.
There are 2 principal architectures:
Create stand alone application with embedded web server
Create ordinary web application and run it on proprietary web server.
IMHO I think that the second approach is better, however it strongly depend on your application functionality.
You can take jetty or grizzly as a web container. Both can run as in embedded or stand alone modes. You are welcome to share other details of your application with the community if you need concrete advises concerning to the design of your application.
The application would need to implement an HTTP server. Then all communication would be done over HTTP.
Write a small web application as you need and Deploy it using Jetty. Jetty is a pure Java-based HTTP server and Java Servlet container. You can use it by embedded mode also.
Deployment is so easy if you use Jetty-Runner
java -jar jetty-runner.jar my.war
You don't need a local web server. Take JavaFX (embedded webkit) and implement a URL protocol handler for say "myprotocol". Then you can access it from the browser using something myprotocol://xxx.yyy.zzz
I was just wondering, whether is it possible to deploy a JAX-WS and access it from a browser without the need to install any software or proxy classes ..
Of course, JAX-WS is just a library built on top of SOAP, which is built on top of XML, which is built on top of HTTP (duh!)
If you have SOAP web services (the fact that it was developed using JAX-WS is irrelevant), any application capable of sending and receiving XML over HTTP can call it. We are successfully accessing our back-end web services using AJAX POST (the web services must be deployed on the same domain as your front-end due to same-origin-policy).
As far as I've seen it's not possible, since you need to have proxy classes in order to call the JAX-WS functions ... but maybe I'm wrong !
I have a java web application that I am developing in Netbeans (and running through Tomcat). Is there any way to put this application on Sharepoint?
This is my first time doing this. I've read that to post the application to a tomcat server you just have to copy the .war file over, but I haven't been able to find an easy solution for Sharepoint.
Sharepoint isn't a Java Application Server. You'll have to use Tomcat (or another Java Application Server) to host your application. If you need to interact with Sharepoint from your application, you'll have to use web services, a shared database or something else to communicate.
That's not possible out of the box. SharePoint only runs ASP.NET applications, not java projects.
You can deploy the solution to a Tomcat server and then use the Page Viewer Web Part to show external content.
We have the following architecture in mind:
To an existing application, we would like to add a web service front end.
The web service will be used from a web portal, which runs on a different web server.
So, we will not use a database on this different web server and just forward entries from the web portal to the web service and show what the web service returns.
First question: what do you think about this architecture?
Second question: Can you recommend a java framework for this web server?
On the second question: one possibility is to use WSRP with Java Portlets.