I'm having a bit of trouble with deploying an application to google app engine.
I've got the google plugin set up in eclipse. I want to deploy to the app engine but a few of the classes are not allowed by the GWT compiler. javax.mail.* for instance.
However the GAE docs (https://cloud.google.com/appengine/docs/java/mail/usingjavamail) seem to be perfectly happy with using javamail (And I'm pretty sure I had an application working with it deployed before).
What am I doing wrong?
Is there really no way to use these classes?!
On using GWT you will code for two environment. The front-end (when the code will be translated to javascript) and the back-end that is a regular Servlet.
In the back-end you are free to use all jre/jdk API, for example, java-mail api. But in front-end you are limited to use classes describe in JRE emulation.
Check if your are not using a classes outside of JRE Emulation in front-end (generally an EntryPoint) and try to move the code to back-end (your servlet).
Related
I have a multi-module GAE Application that is structured like this:
a Python27 module, that is a regular web application. This Python app uses the Datastore API. Regular, boring web app.
a Java module (another web application) that hooks on the Datastore calls (calls made by the Python web app), and displays aggregated data about the recorded Datastore calls.
I have been able to deploy this application on the GAE cloud, and everything works fine.
However, problems arise when I want to run my application on localhost.
The Python module must be started using the Python SDK. The Java module must be started using the Java SDK.
However, the 2 SDK's do not seem to share the same datastore (I believe the 2 SDKs write/read to separate files on disk).
It seems to me that the 2 SDK's also differ in the advancement of the Development Console implementation.
The Python SDK sports a cleaner, more "recent-looking" Development Console (akin to the new console.developers.google.com console) than the Java SDK, which has the old-looking version of the Development Console (akin to the old appspot.com console)
So my question is, is there a way to boot 2+ modules (in different languages: Python, Java) that share the same Datastore files? That'd be nice, since it would allow the Java module to hook on the Python Datastore calls, which does not seem to be possible at the moment.
You might be able to do something similar by using "appscale" (an open source project that could be able to help you, if you setup Virtual Box and load the image on it). Look at community.appscale.com
Another way (mind you, this is tricky) would be to :
1- deploy your python as a standalone project on localhost:9000
2- deploy your java as a standalone project on localhost:8000
3- Change your python and java code so that when they are in Dev, they hit the right localhost (java
hits localhost:9000 and python hits localhost:8000)
4- Try, like #tx802 suggested, to specify a path to local_db.
I am not sure either method works, but I figure they are both worth trying at the very least.
I would like to know what is the relationship between Java and FatWire.
I know it is possible to create templates using JSP but does it involve any standard Java programming? Also, is it possible to integrate it with MVC frameworks such as Spring or Grails?
Fatwire (now Oracle WebCenter Sites) is a CMS system originally based on an XML language. A JSP API (with the same features of the original XML language) was added later and it became prevalent. One of the biggest drawback of this design is that most of your coding must be done in JSP (that is a view only technology). So you have the (content) model and the view but not a controller layer.
But the real problem is that either you extend the Fatwire application with Java code (restarting the application server at each change, or using JRebel) or you have to code everything in JSP. Almost the website implementation I have seen so far uses a lot of JSP and some spare java classes, so websites have the tendency to be written with the crippled java available in JSP (you cannot share a class for example, or leverage the full Java OOP).
If you want to use full Java, you may use frameworks that implements MVC. For example, AgileSites (Disclaimer: I am the main developer of AgileSites). AgileSites basically uses JSP as interface to the CMS (as the documentation recommends) but those JSPs calls java code stored in hot swappable jar, built automatically while you do your development. So you can code everything using plain Java, without having to restart the application server at each change (only the jar, that is small, is rebuilt, when you save a file). On top of this Java enabling technology, AgileSites gives you plenty of features: clean separation of presentation from controller, using pure java controllers and pure html views, embedded unit testing support, an integrated build for continuous integration, scaffolding, a very simplified API covering 80% of normal needs (while giving full access to the full API) and more.
Fatwire templates can be developed using JSP, XML and HTML. Developing it using JSP has many advantages and Fatwire comes with JSP tags (called ICS tags) for standard based development. Most commonly you can see a JSP based template containing scriptlets of Java code invoking Fatwire's asset api which is implemented in Java.
Latest addition to this is Fatwire Web Experience Management (WEM) framework which are a collection of REST services with SSO that will enable you to write applications around Fatwire.
For example, I have developed REST based applications to integrate SVN, Translation systems and provisioning systems with Fatwire using Java.
Also, the latest Fatwire (Oracle Webcenter Sites) comes with set of developer tools called CSDT which is actually a Eclipse plugin that lets you develop templates within Eclipse (that has all the good features such as versioning, syntax checking) and facilitates local development, versioning of templates and continuous integration.
Yes, Java and FatWire can be used mutually. Code your java classes, wrap them and deploy in war or jar format in your app server lib folder. While coding inside JSPs, call your java classes or methods in JSPs and use them as required.
I made a GAE-Project with JPA2 for db access. I store some Strings which are more than 500 Characters, so I use com.google.appengine.api.datastore.Text.
I got an interface Script.java which defines the value as String, and an ScriptImpl.java which has internally a Text member, and converts for getting and setting.
Because one requirement of the project is, that it is still able tu run on an simple tomcat with a database behind. So it must be possible to run inside and outside the google environment.
Is there some realistic way to implement my application so I can switch to a normal tomcat environment (e.g. via a spring configuration to use different beans...).
What else do I have to pay attention to to make this work in both environments and how do I take care of the parts that are seamed thight to GAE?
Update: So far I found the following critic issues: Google User Service & Login Process, Text Class in Domain Models, Wicket-GAE-Initializer (since I use Wicket)
GAE has it's own proprietary API. If you wrote application using this API then if you want to move off of the GAE you have two options:
Rewrite your code, obviously.
Use a API wrapper that implements GAE API but runs on other platforms. An example of such wrappers are AppScale and CapeDwarf. AppScale is older and probably more mature and supports both Java and Python. Also it supports more platforms (private servers + clouds). OTOH, CapeDwarf is targeted at JBossAS7, so it's probably better fit if you use that server (or OpenShift cloud). Also I guess you can expect better support from a mature open-source leader such as RedHat.
While in theory it might be possible to wrap GAE functionality and then delegate it to either app engine or your "normal" environment it's probably a lot of effort.
Possibly another approach would be easier. Are you aware of CapeDwarf?
JBoss CapeDwarf
Deploy and run your Java App Engine applications on your own private
JBoss Application Server (AS7) cluster or on RedHat’s OpenShift cloud.
JBoss CapeDwarf is an implementation of the Google App Engine API,
which allows applications to be deployed on JBoss Application Servers
without modification. Behind the scenes, CapeDwarf uses existing JBoss
APIs such as Infinispan, JGroups, PicketLink, HornetQ and others.
If it really needs to be "simple tomcat with a database" then more information or constraints will be helpful to know.
I have developed a JavaFX app and I am going to distribute it as a Native Package to avoid headaches with users having a Java version lower than 7 (and thus, without JavaFX) or having no Java at all.
However, I also want to be able to deliver updates of my application. One solution is for the app to call home (its already communicating with the backend via XMLRPC), fetch a JAR and self-update. I can see potential problems with the actual update process though (would need to build a separate updater program, but how do you update the updater?).
I know about and would love to use Java Web Start. However, I have no idea if this will work with the Native Package thing. If the user already has Java installed, it will disregard my bundled JRE. If he has no Java... well, he can't use Java Web Start, right?
How can I solve this problem in an elegant way that will not have a detrimental effect on user experience? (and preferably won't be very long to implement)
note: I am using e(fx)clipse as build tool.
If he has no Java... well, he can't use Java Web Start, right?
True, but as mentioned in the JWS tag Wiki:
Java Rich Internet Applications Deployment Advice. Describes the deployJava.js
script designed to ensure a suitable minimum version of Java is installed before
providing a link to a
JWS app.
or launching an
applet.
Note that JWS also offers fine grained versioning as detailed in Java Web Start - Runtime Versioning.
Saying that, JWS can allow you to support earlier systems by adding the JavaFX 2 API selectively to those earlier systems. That is achieved using a version based resources section in the launch file.
So, JWS combined with deployJava.js would actually be 'the alternative' to the Native Package that page discusses.
So i have been looking into GWT and it does look pretty interesting as i do have experience in programming in java and being able to create webapps does look very interesting to me.
I have looked at some of the basic tutorials and have got GWT working in my eclipse environment. Now, If i was to begin creating webapps with it how would i go about uploading and hosting my app. I have only used PHP and MySQL for web development so i would always just use Apache, I am not to sure about GWT hosting. Does it require the app to be hosted on googles App Engine platform or can I setup a server like to usually do when using Apache?
Thanks.
Using GWT does not require you to host your app on App Engine. You can host a GWT app on any host.
If you want your server to be written in Java, to take advantage of some of the more useful features of GWT, you will obviously need to find a host that allows you to run Java. But you can write a GWT app that communicates with a PHP server, or a Python server, or anything else.
If you're familiar with PHP + MySQL it's not a bad idea to stick to that and just add your compiled GWT output as another component that you upload. Switching to App Engine requires a fundamental change in the way you write and design your application which means you'll be learning new front-end and back-end technologies at the same time. Just as an example, a simple full-text search on one field is pretty trivial for a small php + mysql app but because App Engine forces you to write extremely scalable code it's not trivial on GAE.