Develop Reference

How to deploy and distribute a new Java Application Software - Starting from Simple yet Effective techniques to a Detailed & Professional ways

I have developed my first version of Java Desktop Application Software for an 'electrical device' of my company and got to plan proper deployment and distribution of our Application. Right now it has 8 class files in one package and is dependent on 2 external libraries.
I have been through a lot of information available in many websites and blogs including Oracle, StackOverflow, wikipedia, workaround.org, excelsior-usa.com, particular software's home-site and many more and found the following steps to build, deploy and distribute my app:
Create a simple executable jar
Add signing configuration and verify
Add Versions and verify for backward compatibility
add time-stamp and verify
add certificates (either self signed or from a CA) and verify
use a build tool like gradle or maven to achieve the above to some extent
Or use launchers and wrappers like java-packager or install anywhere or install shield etc...
use AOT compilers like GCJ or Excelsior JET
Password protect the app and distribute passwords securely
distribute app on our own website or some standard ones
But I am really confused with overwhelming knowledge, too many options available and whether am in the right direction regarding these steps. I want to cross check the info and knowledge I have gained - with the same from experts like you...
Also as its the 1st version of app, I am bothered about how efficient it works & gets reviews from users, than about deployment. Right now, I think, its okey to deploy with minimum security and standards required and slowly invest more knowledge, money and time on deployment...
So please do guide me with
Simple, Effective and Free techniques to Deploy and Distribute Java Desktop Application Software(if possible, along-with codes I have to include in my manifest and app's main class)
Then later, how to Step by Step improve the app more secured and standardised with consecutive release of versions...
At last arrive to a state where the app becomes perfect and complete by all means and becomes a real professional software.(By that time, may be in next 9-12 months, my app will be in its last stage, which would be large and complex enough)

I think I have found what I needed... A real big Index of Everything about Java where the index itself gives a broader perspective of where I am now in the Ocean and which way to go...
http://docs.oracle.com/javase/tutorial/reallybigindex.html
I believe, if I go through "Trail: Deployment" & "Trail: Security Features in Java SE" along with some other concepts like "RMI" I think I get a real complete idea of Deployment. Then I can decide on everything based on my app and needs...
Whenever I searched for "how to deploy and distribute Java desktop application", I have got either
a part of this index
or extended thoughts based on these concepts
or third party tools working around these basic ideas.
These random pages and more restricted discussions created a lot of ambiguity in understanding the concept. Even while learning I was dependent on books & never bothered of even knowing about ReallyBigIndex... I hope, now I am on the right track..

Which server framework (or even platform) do I need for a small dev team?

I want to develop an server/client software of which the clients will be in different Os's.
(Think Mobile phones, tablets, desktop pc's, I even consider this service to connect with asterisk and work with a phone call center).
I'm really searching amongst all the available server frameworks and cannot decide what is the best for my case or whether I even NEED for my specific problem.
Things to consider:
I need it to be scalable: Initially that server will be accessed through a website but later it will expand and allow people to access it through mobile apps, desktop applications, phone call/sms service, etc..
Low cost hosting and open source
Thousands of users to be using that service in the future. (So it must be able to handle this)
Small dev team (1-3 ppl)
I've done past projects in C/C++, actionscript, a bit java and a bit php.
I don't know much about server programming yet (but I'm ok with learning).
So:
it must have an active community and not have died yet.
Be as easy as possible to learn.
it must already solve the problems of security, packet asynchronism, concatenation
for me etc.
Is there such a thing, should I even bother to mess with a framework? What options do I have considering the tools available? What does the industry use? A list of possible options would be greatly appreciated!

A common technology stack which is open source, scales well and has a very active community is:
Java
Tomcat Servlet Container
Spring Framework (with Spring Security)
Either Spring Web-services or Apache CXF for web service (mobile connections for example)
JPA (Hibernate) ORM on top of MySQL
There are numerous other projects that sit around these technologies that fulfill various requirements. I would certainly recommend this as a starting point to your investigation.

Tomcat on Windows - Free profiling and metrics gathering tools?

We're using Windows 2008 and we are thinking of switching application servers from Adobe ColdFusion 9 to Railo 3.1. This would mean using a new Java servlet container, so instead of Adobe JRun 4, we're looking at Apache Tomcat.
Adobe have a helpful perfmon plugin for CF9. We can gather most stats with that. The problem is, as far as I understand, there is no perfmon plugin for Tomcat.
I wanted to know if there are any kind of free profiling tools we can use to get metrics and performance data on Tomcat, for example requests/sec, memory usage etc.
I don't mind if they are just written to logs so long as we can read them in some format. Also, it doesn't have to be a stand-alone product.
Any and all help appreciated!

Just curious - which application server are you using now? Which one uses perfmon now?
Because you've got to run Tomcat on an operating system - Windows, Linux, etc. You seem to imply that perfmon is useless to you now. I don't believe that's the case.
If you need to embellish info from perfmon, you can certainly buy something. But the cheapest solution for you would be filters that would intercept every incoming request and outgoing response to calculate request counts, response time, etc. You'd write these classes once and declare them in your web.xml. They could write to logs using log4j.
Or maybe Hyperic's solution is what you have in mind. It used to be open source, but Spring bought them a few years back. Then VMWare bought Spring. It's all part of a grander solution.

LambdaProbe will give you monitoring for sessions, memory used, web app sessions and servlets, connections etc.
Take a look at the demo site http://demo.lambdaprobe.org/ for more.
Site login: demo/demo

Which Java EE server should I use?

OK, this is a little unusual, because ANY Java EE container can do the simple things I want to do (XML processing, JPA, Hibernate, SOAP/REST web services, etc). This is for personal use, more to gain skills than to accomplish essential functionality. I have my own Linux server (Ubuntu Jaunty x86_64) with business class internet, so I can install pretty much anything.
I use Tomcat a lot now, however, I ran into a few situations lately job hunting where they were looking for experience in a specific Java EE container (which defeats the whole purpose of having a standard), and of course not the same one each time.
So what I'm looking for is a Java EE server that:
Is in demand in the marketplace right now
Is free (or
Is not too horrendous (disk space, time) to install and to deploy applications on
Runs on Ubuntu x86_64
I've been able to glean some information via Indeed's keyword search, and that tells me to stay away from Jetty/Glassfish, even though they fit "lightweight" and "free". I also see from this SO post that WebSphere is a steaming pantload of bloatware that's hard to deploy/configure, but I don't know if that's accurate or current. I like Tomcat (completely FOSS, smallish, easy to deploy, plenty of docs/users), but it's less in demand than some of the bigger boys.
So what would you recommend I install? Thanks in advance.

My personal recommendation is JBoss. Not only is this a solid server, but there are other JBoss Platforms and Frameworks that easily integrate into JBoss. One example is JBoss ESB.

Far too often, I've seen servers like JBoss and WebSphere (I've worked with them for the last 5 years now) rush to market with broken implementations. Unfortunantely, the part that is broken might be very small, but it will be just what you will be breaking your head on.
Oracle Weblogic just kicked the hell out of me with a broken implementation of MDBs (annotations).
If you want a server that is the most Java EE 5 compliant, will give you the least heartache and pretty much production-worthy, go for Glassfish and yes... use Netbeans as your dev IDE.

+1 on JBoss, that is mainly what I use for personal use and work. I have also used OC4J, and find that it is harder to use, and more finicky with it's class loading mechanism, maybe I'm just used to JBoss. But there is definitely more and easier to find community support for JBoss. So that is reason enough if you are doing this for personal use and are not going to get a support license, there will be many more users willing to help out if/when you encounter issues.

I've only used Tomcat myself, professionally. I've been using it for the better part of my (so far) three year career and I havn't experienced many problems with configuring or deploying applications to it. I use Eclipse WTP for Java EE developers 3.4 (Europa) at work, and mostly develop JSF applications utilizing ICEFaces. We deploy using the Tomcat web manager for most of our smaller projects, and through Hudson for some of our broader applications.
Please bear in mind some caveats, however:
We host about 20 seperate web applications, mostly JSF with a few older JSP apps.
The web applications served by my office have a very, very narrow scale. Our department currently supports about 20 unique users, so most of our applications do not receive a lot of heavy traffic.
Most of our web applications are very processor intensive (i.e. here's a 2GB CSV file...write a program to calculate the total number of people that reside within homes that have 3 or more children...) that only usually perform one-off runs either weekly or daily (or even yearly...). In other words, "Give me all your resources for 2 hours...then I'm going to lunch".
Our primary web server is a Solaris 10 box with a Dual core sparc processor (I believe clocked at 1.8 GHz if memory serves correctly), with 2GB of RAM (don't recall if it is DDR or DDR2).
That being said, I've definitely noticed performance problems over time with regards to our application environment that probably have more to do with our application code as opposed to Tomcat itself. I'm willing to bet that the problems have to do with poor memory management within our processing logic and data allocation than anything. The reason I believe this is because on a fresh restart of Tomcat our applications usually execute in an incredibly responsive fashion, yet over the course of even just one or two days the user experience is degraded.
Take it for what you will. We've probably got some problems to deal with on our end, but Tomcat itself seems to be pretty performant in a localized environment.

I ran into a few situations lately job
hunting where they were looking for
experience in a specific J2EE
container (which defeats the whole
purpose of having a standard), and of
course not the same one each time.
Well, I think you have (half) answered the question yourself! If your primary aim is to help you find a job, you need to look at what Java EE container the recruiters in your geographical area are asking for. Go to your favourite recruiting websites, pull up the Java / Java EE jobs for your area for the last couple of months, and count for each kind of web container. (And also count the jobs that don't specify a particular web container.)
If the results of your research say that you need to learn WebSphere, you have my sympathy :-)
Don't forget that a "mandatory" requirement may not actually be mandatory if you are you are good enough in other areas. It all depends on what other candidates the recruiter can find. Don't be afraid to say "you asked for X, but I have Y and Z which demonstrates that I have broader experience with this technology".

Oracle officially ceased to support Glassfish. All bugs found there (and there are quite a lot of them) will never be fixed.
Payara is now the best option, as this is a clone of Glassfish, but is continued to be developed by the Java community.

Proposing Glassfish to customers

With Sun being taken over by Oracle, Oracle will arguably gain control of Glassfish.
I do understand that Glassfish is community driven but most of the contributions do come out of Sun at this time.
Its a great App Server and perfect for many cost-sensitive customers. However, if Oracle decides to pull the rug from under our feet on this, we could be in serious trouble with our customers.
For solutions (applications) with a life time of around 5 years would it still make sense to suggest Glassfish as the application server?

It depends:
Who are your customers?
Are you deploying to customer sites?
Does the customer even let you choose the Java EE container?
Does the Customer buy the application or a service?
Does it really matter which Java EE server your application is deployed to?
Does it even need to be a Java EE container, could you use Tomcat instead?
Can you easily test/support multiple containers?
The spectrum runs from the customer couldn't care if your application is powered by 2 hamsters in a wheel up to specifying you must work in WebSphere 5.1.2.3.4.5.
Hedge your bets. Continue to recommend GlassFish if you think that's most appropriate, but have a fall-back solution.

Oracle can't really "pull the rug out" as such, realistically the worst they could do is to not allow any of their staff who are contributors, contribute as part of their role at Oracle. I personally don't think this will cause all that much disruption on the project even if they did that.