I have a web application (written using GWT) that used to load a Java applet in order to perform some tasks, such as writing/reading a file on a local filesystem and printing to multiple printers. Since Java applets are no longer supported in Chrome and are generally deprecated I need to find a suitable alternative.
My Web app should send and receive data from Desktop Java app. This communication should be implemented locally since it has to work even when client is offline (web app continues to work when user is offline).
I considered building a Chrome extension that uses Chrome Messaging API to communicate with Web app as well as Desktop app (pass data between them and act as a mediator). This can work but I am wondering if there is a cross-browser way of achieving this?
I've also considered building a web server inside Desktop Java app and then call http://localhost:port from the web app, but I'm not sure about possible negative security (and other) implications of this approach.
What would you recommend?
Thanks!
Since you use chrome, there is support for HTML5 Filesystem features.
For example as described here: http://www.noupe.com/design/html5-filesystem-api-create-files-store-locally-using-javascript-webkit.html
GWT supports no Filesystem access directly, only local browser storage. So you need to wrap it yourself or use the elemental.* api (http://www.gwtproject.org/articles/elemental.html) to gain access to the elements directly and wrap them into widgets.
You may find this discussion helpful as well: GWT Websockets with Elemental
Related
I'm building a Single Page Application (using AngularJS) that renders data from a REST API call it makes to a legacy system. This legacy system is very large, written in Java and takes minutes to deploy so we decided it would be more productive to develop the Single Page Application completely separate from the legacy system.
The problems occurred once we tried to communicate with the legacy system's REST API. Although both apps were deployed locally to the same host, they were deployed on different app servers so I needed to use different ports when communicating. But because the SPA was communicating to a REST API on a different port, the browsers prevented my requests to protect against Cross Site Scripting attacks.
We found this build tool name lineman (that leverages grunt) that made it easy to proxy http requests. This got us around the cross site scripting limitation but this was only suitable in development mode.
Now that we've got a proof of concept working, we want to know how we're supposed to deploy these apps together without the proxying. It's hard for me to find advice on how to do this because Angular doesn't assume you have a backend in the first place and most people that use Angular on the front end aren't using Java in the backend (if that even matters).
We're running into issues like, the context paths of the apps change depending on if they're deployed in prod mode vs dev mode so we've gotta think of clever ways to avoid broken links that work for both modes. I wonder if/where I took a wrong step here along the way. Should I avoid developing the SPA on a separate server from the backend?
We had the same issues. The URL situation is that you will have different URL paths to your java REST API because you are in different environments.
In order to make these paths cascade down to the angular application, we had to first externalize the base paths in the web app (the app that spawns Angular) to use values that are set during deployment depending on where it is deployed to. We have values in our app servers that link to XML values in config files that we then reference in the application.
Then we create a call from the Angular app to the webapp that spawns it (not the java REST API) that will return the URL that is correct for the environment.
In the angular application, we can then setup the resuorce with the correct base path (the rest of the URL should stay the same from environment to environment).
If you can get the first part working correctly with externalizing the environmental settings, the rest is not difficult.
I would put apache in front and use mod_proxy as a reverse proxy to the apps.
Say your REST API is at http ://localhost:9000. If the angular app is only static assets you can deploy it directly under apache. If not you reverse proxy it as well.
For the REST api yoivsetup a reverse proxy for say /api to localhost:9000. So any request hitting the apache at http://some.host.name/api will now be forwarded to the legacy system. Now fix the angular app and you are done.
For local development you can use node-http-proxy which is ease to setup in a similar fashion
I would know if there is a way to make a Java desktop application to communicate with an applet, in order to call Javascript functions from the desktop app (through applet).
The context :
In one hand, I'm having an ExtJS application (full-AJAX), which is located on a remote server.
In the other hand, a desktop Java application (netbeans application), which is resident (indeed).
What I would do :
Each time one of the apps is used, it sends events & data to the other app.
After a few research, I saw interesting posts here and here, and also an answer on how to communicate between applets (see also here).
The question is not about how to do cross-domain from the applet to the destktop app (see over there and here), but as said in the beginning how to communicate from a desktop java app to the javascript.
Notes
The webapp (ExtJS) is based on a remote server, the applet too. I can locate the applet locally, but it implies to deploy a local webserver.
The desktop app is very heavy, so I cannot convert it in an applet format.
I put the "reverse-AJAX" tag because it is the global concept of what I would do.
If all this is possible without an applet (no Flash please), it's okay too.
In order to call javascript methods from a Java applet in a browser you need to use the Netscape LiveConnect API, there are some examples here.
Basically this is an API that is implemented natively by the browser and allowed a java applet to access the javascript engine of the browser.
Once you have that sorted then you need to call methods in applet from the desktop application, this is a little more tricky. The most easy way would probably be to have an Enum that you exchange serialised instances of to describe the type of event.
There is an example of using sockets for communication here.
We have an existing distributed application used by a small company to manage their customers.
The server side component is deployed in the cloud as a simple Java app that manages a connection to a MySQL database.
The client side is implemented as a Java Swing application deployed using JNLP and communicates with the server side using RMI.
This has worked quite well for us so far, but recently we've been looking at how our customers could access the application from mobile devices, tablets (both iOS and Android) as well as from the desktop.
At the minute I'm thinking we should be looking into developing RESTful web services on the server side to manage access to the MySQL database. On the client side, we could use Googles GWT to provide a quick and easy solution for accessing the services from all platforms. Going forward we could implement native iOS / Android apps to access the web services.
Am I am the right track here? Does anyone have any better approaches? Does anyone have any recommendations as to what tools I should be looking at?
The key thing I am interested in is being able to access the server side from any platform. I really don't want to have to implement separate server side implementations for each
Sounds like you are on the right track with the RESTFul web services. If you go this route, you should be covered for the backend. As long as your frontend can do http requests and handle JSON data you will be fine.
Going forward we could implement native iOS / Android apps to access the web services.
It is possible to design a mobile app for deployment on both android and iOS, this could save time on the development effort. To do that you could use, for example PhoneGap, which creates an abstraction layer over the phone hardware, along with something like jQuery Mobile, in which the UI is developed in HTML5 and javascript, and the same code is deployed via PhoneGap on both devices.
PhoneGap: http://phonegap.com/
jQuery Mobile: http://jquerymobile.com/
if there is some other option that lets you deploy the same frontend on android, iOS, AND the desktop, i would go with that, so that you only have one code base for the frontend.
I think your solution (GWT/HTML5) client talking to a server-side "business" layer is a good multi-client solution. RESTful web services are unneccesary in the context of what you have described since the GWT implmentation would take care of the comms between client and server:
GWT client <---> Server (GWT) <---> Database
If you are using a different client implementation (such as iOS), then RESTful services will be very handy indeed (and you wouldn't use GWT):
iOS client <---> Server (RESTful endpoints) <---> Database
HTML5 is becoming provides a decent compromise between broad applicability (many clients) and rich client features. I have seen an article in the past about using PhoneGap and GWT together which sounded like a good strategy for working with GWT (which I like) and gaining access to device-dependent capabilities. All whilst working in an environment where you can (Java-)debug even client code (incredibly useful GWT feature).
I have an existing Java application running on a linux box that monitors the state of relays and network information. This is a stand-alone device currently.
What I would like to further develop is a web server for the device to remotely monitor, configure, and control the device via an Ethernet connection. To achieve this, I need some way to interface between the web server, which could be configured as enabled/disabled, and the master device, which is always running.
Is there a good way to do this? I have looked at apache w/ tomcat and similar web servers but not sure if this is what I need. The key here is that the web server needs to be able to access the existing java application without interfering with its always running services.
You either develop a webapp, use your Java application's API inside the webapp, and deploy this webapp inside a web container. Or you can do the reverse and embed a web server inside your application (see here for documentation to embed Jetty).
If you want to keep the webapp and the original application in two separate JVMs, you'll need some wey to communicate between both, like sockets, RMI, or even files, but it will be more complex.
You might want to take a look at JMX http://docs.oracle.com/javase/tutorial/jmx/overview/index.html
Is it possible to make a Facebook desktop application in Java without using a servlet?
I am developing a Facebook desktop application. I am very close to completion, but a problem comes in getting an access token.
I successfully opened a browser through my Java code, but I can't read the URL of the web browser. I don't want to use a servlet.
Yes it is possible to do that, check out the Authentication documentation, the part you are most interested in is titled Desktop Apps, and it says:
Our OAuth 2.0 implementation does not include explicit desktop app
support. However, if your desktop app can embed a web browser (most
desktop frameworks such as .NET, AIR and Cocoa support embedding
browsers), you can use the client-side flow with one modification: a
specific redirect_uri.
You can read more and see exactly how there.