I have written a little netty server application, packed in a jar file that I want to deploy on a linux server.
Since I have no professional experience with deploying java applications, I was wondering if it is enough to start the netty server by doing:
java -jar NettyServer.jar NettyServer &
Obviously a script could be created to ensure the correct user starts the process etc., but is this the way (stand-alone) java services is being deployed?
It seems almost too easy, considering every other question/answer seems to mention some big hunky container-bean-glassfish-tomcat-whatnot (which I might consider later on if/when issues arise)
yes thats the way - no container needed!! I built a middleware (http://sourceforge.net/projects/serviceconnecto/) using netty as underlaying framework. It's the way i start my server as well! Just verify the classpath is set correctly - meaning libraries are in correct place and the jar archive is correctly built.
I personally prefer Upstart to start services on linux. http://upstart.ubuntu.com/
It is very easy to use, and can also restart your application on crash.
I hope it helps.
Related
I have a Java Spring Boot Application, and I build it with Maven. With
spring-boot-maven-plugin,
I can create fat, executable jar file.
Then I copy it to the remote server and run. But sometimes,
I change only one line or event one word in my code and I had to do whole build/copy step again. I'm sure that I'm doing it wrong, but I couldn't find another way that more efficient (Like capistrano in Rails).
At this point, I'm planning to clone source code to server, push from local, pull from remote, build and run approach. What is the correct (or elegant) way of doing this deployment?
For automatic build and deployment process (continuous integration), you can use Jenkins. Refer this documentation for more details: https://jenkins.io/doc/
I would say it depends where are you trying to do it.
The best and the most agile way to do it for a controlled environment is surely a CI-CD (Continuous Integration and Continuous Deployment) pipelines, which complies-builds-tests-deploys your code against every commit made to the source code BUT it may be too slow to use CI-CD for a development environment where you had like to have a shorter feedback cycle and faster feedback to see how the code is progressing.
However, if you are talking about development environment, I will hit another chord and ask you why to deploy to the external server AT ALL while developing. When you use Spring Boot, which helps you develop a self-contained application, you get the Tomcat Server embedded with it for free. That gives you the choice to run the code anywhere you develop and test to move forward.
A simple maven goal - mvn spring-boot:run can make the code run anywhere you had like.
There is another magical library available in Spring-Boot, known as Devtools, which is meant to support agile developers. The library once in the app classpath, performs hot-swapping of byte-code to auto reload of code into the running application (running locally with embedded Tomcat) as soon there is a saved change. This is one of the coolest gadget that a developer can have.
Use of Spring-Loaded (or JRebel for non spring-boot apps) libraries can also help a developer do hot-swapping of byte code to load changes in running application as soon saved.
I hope it helps.
I need to decide between various Java technologies to install on a Linux server.
My back end (biz logic) is a Java program that must communicate with C functions using JNI. This Java program also must communicate with Oracle database (11G) using JDBC on one side, and BlazeDS residing in a Java-based Application Server on the other side (to communicate with Flash plug-in on client side). I also need an HTTP web server.
Not knowing much about Java, I wonder what the highest performance (e.g. fastest) and/or cleanest solution might be.
For example, should I install JDK on the server to provide JNI functionality, then then use Tomcat for everything else? Or, does Tomcat also include JNI? Or would something like JBoss which includes J2EE and serveletts capability be better, since it does everything in one package?
Just trying to learn any conventional wisdom about possible solutions, and pros and cons about going one way versus another.
Any Java runtime environment can do JNI - so by implication if you have any application server (e.g. Tomcat or JBoss) running then you should be able to do JNI just fine.
Tomcat would be perfectly fine for what you are describing.
It's a popular lightweight application server
It supports servlets and JSPs so works well for serving HTML
It's probably a bit simpler to get started with than a full JBoss setup
On the other hand JBoss is great as well.
More of an "Enterprisey" focus - you can optionally get excellent commercial support from Red Hat
Might make sense if you wanted to leverage some of the other products in the JBoss ecosystem
I basically think both would serve your needs. I'd probably suggest writing a simple servlet-based application and try deploying it to both Tomcat and JBoss to see which one you prefer. If you stick to standard servlet features then your app should run on both Tomcat and JBoss so you can keep your options open.
The other thing to consider early is tool support - make sure you get comfortable and happy with your Java IDE tooling for your app development. My personal choice is Eclipse, which has great support via plugins for both JBoss and Tomcat. But most of the other major Java IDEs like IntelliJ IDEA or Netbeans should serve your purposes as well.
G-WAN is an HTTP server (critera #3) which executes Java scripts that can use Jar and other Java classes (criteria #2) while at the same time run C/C++ scripts (criteria #1).
The advantage of this solution is that you will have only one program running (no intermediate layers, no wrappers).
Disclamer: I am involved in the development of this project.
What are the implications of building a java program against the jars of one web container (say Jetty) and running it in another (say Tomcat)?
I have an application which I run in Jetty durring development but which is deployed into a tomcat server for production (Why? because it seems easier to develop without having to run a whole tomcat server.)
You should compile against only the official Java EE API's for the level you target, for any non-developer builds. Preferably by a build engine. Preferably on a different operating system than you develop on.
For a web application this mean the appropriate servlet API as downloaded from Oracle. Similar for an enterprise application.
In my experience this is the best way to keep it straight.
Edit: Java EE SDK is available from http://www.oracle.com/technetwork/java/javaee/downloads/index.html. If you need an older version than Java EE 6, then follow the "Previous Releases" link.
You can get issues such as MethodNotFoundError. You can usually resolve these by making sure versions of jars installed on the servers match.
you typically want to develop where you deploy. It might be slightly harder to develop with tomcat vs jetty, but you have identified a potential mess of a problem with jar conflicts, so doesn't it seem worth it to develop with tomcat, since you deploy to tomcat?
Also, typically the pain of developing against tomcat/your container of choice is mitigated by putting in the time to write a ant (or other) task that will deploy your code to your development container. The work cycle bemoes
1) Write new code
2) make sure tests pass
3) run your 'redeploy' script
4) poke around in the running instance
You probably want to do that.
Finally, in the spirit of loose coupling, you probably do not want to depend on a container-specific libraries if you can avoid it; only do that as an absolute last resort.
I have a project which is going to use Ruby on the front end, and have JRuby call some needed Java libraries on the back-end.
If this was just a Java application, I would set up an ant script that would make a .war file and be done with it.
Since I am using Ruby, JRuby and Java, what is a good way of setting up the build and deploy process that would ultimately live on Tomcat?
Will the SQLLite db work well on Tomcat? Do I need to do anything extra so that the Ruby code lives on localhost:8080 instead of rails server which is localhost:3000 ?
And will I be able to run the rails framework on Tomcat?
Thanks,
Alex
The Trinidad Gem is basically to tomcat what the Glassfish gem was to the Glassfish java container. It is based on tomcat and sounds like it might suit your purposes. As far as deployment you can also use the warbler gem to create war files to deploy your code as well.
I believe that netbeans had support to deploy rails apps on Java EE app servers... Maybe that's a starting point.
I am deploying new versions of java servlets with JRun as the host. I am having difficulty finding good sources for information about JRun and tutorials about how to configure and manage it.
After installing JRun and opening the launcher it can't start the admin server that it creates by default...so obviously I'm running into some issues just getting started.
edit for clarity: I'm not looking for an answer or help with a specific error but if anyone knows of good sources for information about JRun and how to work with it so I can quickly bring myself up to speed on it.
Jrun development has pretty much stopped. You should look into running another application server. Jboss or Glassfish are good alternatives.
This is probably going to be difficult to resolve unless you post either the error message from the log file or the list of steps that you took so far.
I have JRun 3.1 configured on my machine so maybe I can duplicate your issue if you give us more information.
I didn't know JRun was even still in existence since 1999 or something like that. Anyway, Tomcat or Jetty would be my easy replacements. Tomcat for its scriptability from ANT etc and Jetty for its pure simplicity (start an instance in 5 lines of code!).
Glassfish is a huge system with many components, if you just want to host vanilla servlets and JSPs etc. then I would go for one of the above.