I am trying to understand application deployment on Google App Engine using java. Looks like if java is used it is more like deployment of a web application which extends java servlet ( HttpServlet ). Let me know if java application can be deployed without using servlet or jsp.
I agree in addition to standard web application deployment it will require GAE specific configuration i.e. appengine-web.xml. But my question is mainly on requirement of servlet for java based deployment.
Sorry for very basic question, but all code samples pointed me to servlet but in document there is no mention about servlet.
As I understand you want to communicate with the server via HTTP. Servlets are most common way to support this protocol in JVM, unless you want to implement protocol in something low level, like in Netty.
Servlet is a set of java interfaces, but it is not required to implement them by yourself. Most Java web frameworks provide some implementation for you. I mean someone should write this servlet once, but most likely it was written by frameworks authors many years ago, you don't even need to think about its implementation.
For example I don't remember writing any Servlet since 2003, but I have plenty of working web apps on GAE. Most of them are Spring based, it have Spring Dispatcher Servlet which does all processing HTTP request/response for you.
So the answer is: yes App Engine is Servlet based app container and you need one, but it's very unlikely you'll write any servlet by yourself
Depending on which tools (frameworks) you are using in App Engine you may OR NOT write Servlets and JSPs. For example if you use Google Endpoints (https://cloud.google.com/endpoints/docs/frameworks/java/about-cloud-endpoints-frameworks), you will not write any servlet yourself: they will be automatically generated by the framework itself.
On the other hand it is totally possible to deploy your own servlets and JSPs, and adapt the web.xml file accordingly.
Related
I am new in JSF and I am starting an application with se following architecture:
JSF Server
Android Client
Some functionalities will be common in Android and JSF (web pages), only the interface will change.
I know how to communicate an Android client with a servlet, but I don't know how to do it with a JSF server. I have searched a lot in web, but nothing was found.
Can someone help me?
JSF is a framework that deals with UI generation (HTML). It is not a "server", but a tool that you can use in a server and that many server offer with its default instalation. In fact, it works on top of servlets.
Given that is HTML, its use would make sense only when you are using an HTML client (web browser). If you are using an android app, you will be better off using messaging frameworks (v.g., SOAP and WS, or directly servlets. You can use bare servlets together with JSF just by mapping the servlets to URLs that do not collide with the JSF ones (if you recall JSF configuration, what you tell the webserver is which URLs will be served by the JSF servlet).
For my Java project I need to embed a web server to provide various web pages to the user. Until now we used the "official" com.sun.net.httpserver.HttpServer class, which basically works fine.
However, now we want to extend our application in order to not only serve static HTML pages via the embeded HTTP server, but also dynamic content (PHP if possible).
Any recommendations?
EDIT: Nevermind, I found it quite easy to integrate Jython within my Java application :)
I'm trying to develop a small server which would include one restful webservice.
I'd like to use JAX-RS for the webservice part, but every example I'm seeing is using a tomcat server, and I can't use any 'application' server (meaning I can create a server in my code, but can't run it from the outside).
Well anyway I was wondering if anyone had any sample to show, and any advice on which light library I could use to run such a simple server into my code (can't use any gpl /lgpl etc licence, so no jersey for example).
Thank you.
It's possible to embed Tomcat in your application, see here for an example: http://java.dzone.com/articles/embedded-tomcat-minimal
Another popular choice for an embedded servlet container is Jetty, they have a tutorial here.
Edit
The examples provided with Jersey can also be helpful, here's one for running using the Grizzly HTTP library: https://github.com/jersey/jersey/blob/master/examples/helloworld/src/main/java/org/glassfish/jersey/examples/helloworld/App.java
You can even use the HTTP server that's bundled with the JDK (probably not the way to go for a real application): https://github.com/jersey/jersey/blob/master/examples/helloworld-pure-jax-rs/src/main/java/org/glassfish/jersey/examples/helloworld/jaxrs/App.java
Have you checked out http://www.sparkjava.com/?
It's very light-weight and concise.
Building a server into code is nothing. See "Embedding Jetty", for one. There are plenty of other options with varying degrees of difficulty and capabilities, like the Simple Framework, Tomcat, Grizzly, Netty, and Vert.x, to name a few. Then, if you're not stuck with Java, the language, there's Ratpack for a lightweight REST server. Otherwise, running something like Jersey in an embedded server is quite simple. I do it every day in tests.
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
We have a java server application which runs certain batch jobs. It's core function is not as a web application and there's no reason for it to be that. But we would like to add an option to check what the app is doing from a web page. And we thought this could be nicely done with the Google Web Toolkit.
In any previous experiences we have with GWT we have deployed it on Tomcat. But in this case it seems like overkill. The web part is more of a side function to what the application is actually doing.
I'm thinking of a solution where the web server is integrated into the jar file - perhaps Jetty? So that the full java application can be deployed to a single jar file together with the web/GWT part.
There may be performance aspects to this but the web side of things will have very few users. Are there any other reasons not to do it this way?
And, can you give some advice on how to configure Eclipse / Ant / Jetty / GWT for this?
we had the similar experience at our previous project. There was an eclipse-rcp application, with embedded Jetty server (it was started programmatically when application was starting). GWT application was deployed into the Jetty as usually. Also there was a OSGI-service as a controller to provide communication between GWT-server and other parts of application. GWT server was usual RCP server, which is described in the most of examples. It had a reference to the controller. Moreover, it was an event listener, to support bot-side communication.
The main problem for us I think, was synchronization problem. Since there were a lot of messages between eclipse-rcp application an GWT-part (every let say 100 ms the message was received) and GWT had an asynchronous way of communication between client part and its server part, then some mechanism had to be created to synchronize those messages. Otherwise there were no performance problems (except IE 6. which had to be supported:S :D).
Hope this will somehow help.
Upd: As far as I remember, the controller was registered as OSGI service only to be able to communicate with other services of Eclipse-RCP part. In order to communicate with GWT controller was implementing special interface, which was known to the GWT-server (Controller was registered as an implementer through instantiation and the server was regsitered in the controller as IMessageListener). This interface was lying in separate project, which could was also built into the .war file. This project also contained number of event to support backward communication from controller to GWT-server through IMessageListener interface.
It's kind of confusing probably, sorry. May be I should draw a diagram..