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.
Related
I'm carrying out a feasibility study on writing, let's say it's a lightweight run-in-browser MMORPG. (It's not exactly an MMORPG, but would take longer to explain, and the requirements are similar.) I'm trying to figure out the required technology stack.
Client side, it runs in the browser, so the client is Javascript. That was nice and easy :-)
Server side, I'm looking at Java. The common Lamp stack was designed for RESTful applications, as I gather were typical Java web frameworks, and this application is different - it needs a continual stream of data going back and forth between the server and all the clients. I think what I need in this case is Java of the non-framework, full no-holds-barred Java EE variety, someone please correct me if my understanding is incorrect or incomplete? I would need something that is commonly available on reasonably cheap hosting, Java EE fits this description, right?
(Figuring on using MySQL for the database, as this is what's most commonly available. Also I might actually write the code in Scala, being a Java-compatible but supposedly slightly nicer language. I assume neither of these makes any difference?)
Supposing I were writing a website in Lamp, doing at least the initial development on Windows, then I'd install Xamp, which gives you a running copy of the entire server stack right there on your desktop, so you can just alt-tab back and forth between your editor/IDE and browser for testing.
Now my question is: What's the best equivalent setup for Java, for developing something like this on Windows?
Right, in a sense it is. What I think I'm really saying is that almost all discussion of server-side Java seems to talk about JSP, EJB, Glassfish, Google app server etc which are frameworks in the sense that they put restrictions on what your code can do, whereas Java EE puts no such restrictions, you can use as much or as little of the standard library as you want, but it doesn't stop you running arbitrary persistent Java code. Is that correct?
You've thrown out a bunch of terms there:
Glassfish is an application server that implements (all of) Java EE.
JSP is a specification that is part of Java EE, and implemented by application servers such as Glassfish as well as web servers such as Tomcat and (I think) Jetty.
EJB is another specifications that are part of Java EE. It is typically implemented by application servers.
"Google app server" is really "Google Application Engine" (GAE), and is really a platform for implementing web servers in a cloud computing environment. If that's not what you want / need to do, GAE is probably a blind alley for you.
Glassfish, JBoss, Tomcat, Jetty and so on are all platforms that implement some or all of Java EE. None of them stop you implementing arbitrary persistent Java code.
GAE on the other hand does restrict what you can run, because the platform only allows you to run standard Java classes in a whitelist. If your "arbitrary" code depends on other standard Java classes, you are out of luck. (And hence my warning about blind alleys.)
And of course, there are various other Java-based frameworks that are targeted at web development in one form or another. Some are compatible with Java EE servlets and other EE technology, and some have gone off in a different direction.
My recommendation would be to start with something straight forward using plain servlets on a stock platform. Only look at the high performance stuff if and when performance looks like it will be a real concern (not just a "nice to have"). It is better to have a simple and non-scalable prototype, than a high performance solution that you don't have the time and skills to get working. And you can treat the prototype as a learning exercise.
A little hard to tell from the requirements given, but I would look at the following based on your description:
http://www.playframework.org/
http://www.zkoss.org/
http://code.google.com/webtoolkit/
Play Framework is a nice web-centric framework that provides a complete stack (you can code in Java or Scala). ZKoss (ZK) and GWT both provide user interface frameworks. ZK, GWT, and Play all run nicely in Tomcat/MySQL and should work just fine in typical Java/MySQL hosting environment.
... not sure what your definition of 'cheap' is but, that and 'no holds barred Java EE' don't exactly go together. Also, 'frameworks' by themselves don't put restrictions on running any arbitrary java on the server side. When I say 'frameworks' I mean Spring, Struts, etc. Servers will be a little different story. If you need EJBs you'll need Glasfish or JBoss or another EJB compliant container. Hosting with these will be more expensive compared to getting by with Tomcat. IMHO easiest and quickest way to get started is with NetBeans. Comes with Tomcat and / or Glassfish out of the box, all you need is a db.
I have a few questions to understand better Java's usage in context of web applications:-
Is Java EE web development suitable for small start-up (with less human resource) looking to develop an web application ?
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ?
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
and Finally, What are some of the most important things to learn before starting web development in Java EE ?
Thank you
Generally the answer to the question of "what technology to use" is "the one which you have most experience with". However, Java EE is huge and clunky, and definitely not good for rapid prototyping, which you will be doing if you're doing a startup.
Personally I would recommend a more modern and dynamic environment. If you're coming from PHP, you should be able to pick up Ruby on Rails or Django (Python) easily. These two choices are in my opinion orders of magnitude better than Java EE. If you want to stick with Java, at least go with the Play framework then.
Is Java EE web development suitable for small start-up (with less human resource) looking to develop an web application ?
Yes, I worked in a startup where I was the only full time programmer.
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
The same as in any other web development shop. Of course, the problems have their Java flavor. For instance, one bug we discovered was caused by different minor version of JDK used on the live system than on our test system.
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ? Do not code the PHP way. Java's strength is OOP and its many libraries/ open source frameworks. Use that.
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
I don't know why you think that, but Java is used everywhere. It is one of the few languages that Google officially uses. They use PHP as well, but it has a "lower" status.
and Finally, What are some of the most important things to learn before starting web development in Java EE ? Use Java's strong points which I mentioned above.
Updated after comment
I cannot make the choice for you. If you are in doubt and in a big hurry you should not go with Java. This is common sense. However, it is an opportunity for your team to learn and grow. Maybe there is a PHP/other client for Cassandra. I knew a former PHP programmer in a startup, who switched to Java. Not saying anything bad about PHP programmers in general, but he did all kinds of strange things, such as not leveraging the power of Java web frameworks and writing lots of procedural code mixed with HTML and SQL. Obviously there are lots of Java programmers who would do the same thing. The point is that your team will probably learn new ways to do things and benefit from it in the future.
Allow me to answer these from the perspectives of a developer/architect in a small start-up, experiencing a bunch of these issues.
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
How do you decide on which toolset/framework to use? Do you need an IDE? Which version control system and why? Do you want to develop at some place and deploy somewhere else, or develop directly on the server? Do you buy a linux box for this, or rent some cloud? How much do they cost, in terms of licenses and training?
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ?
How would your servlet send out an e-mail? It's much simpler in PHP. Need secure transfer of encrypted objects? Java is your friend. What about session tracking? Use cookies, or have a dedicated class do it? How do you access the database? Want to use hibernate? What other tools is hibernate dependent on? What are their costs (license+learning)? Can you use JDBC directly? What are the pros and cons? Which db to use to why.
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
I am not sure if this is the case, but possible reasons could be the availability of .net and integration with C# based systems and Apple ditching Java from its SDK. But that is my speculation, don't quote me on it. I am developing a large scale system myself with Java 6.
and Finally, What are some of the most important things to learn before starting web development in Java EE ?
(This is my opinion) have a test or trial set up of the entire architecture. Is the GUI web-brower based? Is it an applet? Standalone application talking to a server? JNLP system downloading archives and JRE off the net? You will find some stuff do not work on Windows 7, some do not on Vista, W3C have deprecated the applet tag from HTML but Sun/Oracle asks you to use it, different browsers do not support contents of your style sheet, etc.
Firewall set up is another major challenge - you start using thread pooling using Spring libraries and your capabilities to use DBvisualizer to check on DB tables are gone! Now you need a DBA and a sys-admin to fix these who you do not have!
Personally I found the LAMP architecture (Linux-Apache-MySQL-PHP) the fastest way to go for smaller applications, but if you need heavier guns for your app (security, GUI with swing, multithreading, etc), replace the P in LAMP with a tomcat container. The hardest thing I find is to judge the value of a tool in the context of my application - I do not need a tool that generates Java files with getter/setter methods given a list of variables - to me that is yet another level of indirection, but then JUnit in eclipse is helpful for debugging.
Just shared some of my thoughts - hope this helps, - M.S.
For a startup an interesting choice could be the Lift web framework, which is used for developing "Java Web Applications" (although in Scala).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I know this may be a recurring topic, but I have read a lot of articles and I still have doubts. Also, I would like to hear more recent opinions about this.
The main requirements of my application server are: flexible configuration, support for a extremely high number of concurrent users. It will be a system for the mobile communications industry, so it must have high availability as well.
I am going to develop a Java EE application and Open Source Applications Servers are my only option. I have used GlassFish for a very small project and I really liked it.
My current thoughts:
Small, Fast to start and simple: Jetty
Bigger and more robust and very large knowledge base of users: Tomcat
Bigger again, more features, good
enterprise support, slower to start: JBoss
All can support large user bases and all will do 95% of use cases well.
I'd start by default at the top and move down the list as your situation/requirements get more complex e.g. how much Java EE support you need
Also if you are careful on not using any custom features changing at a later point should be relatively simple.
This is purely based on my personal experience and is a bit simplistic - one could write books on this!
If you're looking for a Java EE server, you basically have two options: GlassFish or JBoss (Geronimo or Jonas just have too small communities and I'm not aware of serious references for them - which doesn't mean there aren't any - I wouldn't pick them). Both are serious platforms, support clustering and HA and have been used to build large scale clusters and offer commercial support if this matters.
Now, a quick summary of the various versions:
JBoss AS 5.1: Java EE 5 certified. Supports HA, clustering, comes with an admin console if you're XML averse (but doesn't support cluster setup through console yet)
GlassFish v2.1: Java EE 5 certified. Supports HA, clustering, better admin console than JBoss 5.1 (especially for the cluster setup, if this matters), great CLI tool.
GlassFish v3: Java EE 6 certified. Very new, doesn't support clustering, centralized administration. Version 3.0.1 to be released soon.
JBoss AS 6.0: Java EE 6 certified. Didn't reach General Availability yet. Can't say much about it for now, M2 might not be representative of final version.
GlassFish v3.1: Java EE 6 certified. Will add Centralized Administration / Clusters, High availability / State replication and more. To be released this year. See the official roadmap.
At the end, if you project won't go in production before 2011, I would consider Java EE 6. If not, then go for a Java EE 5 server. In any case, don't base your choice only on opinions of the web. Download both server, setup a clusters of at least four nodes on two machines (that's a minimum, use a bigger cluster if possible), run a benchmark with a representative proof of concept of your application. And don't hesitate to involve folks from JBoss and Oracle, I'm pretty sure they'll be happy to help at proving their solution is the best one :)
References
For JBoss, have a look at Bela Ban's talk Large clusters in JBoss (pdf) at JBoss World 2009. Also check the sessions from JBoss World 2010. For GlassFish, have a look at their stories and more specifically in the Telco. Contact Sun/Oracle and RedHat for more references.
If you really need Java EE (strictly speaking) then JBoss is a good option. If you don't need true Java EE then you would be well served by using Tomcat. SpringSource also provides an enterprise version of Tomcat with support named tc Server that would be a good option if you don't need true Java EE.
I actually recommend to go with GlassFish. Apart from your familiarity, it uses a NIO network infrastructure (Grizzly) which supports very high number of concurrent connections.
We primarily use JBoss, and I can tell you JBoss5 can support a pretty high number of connections, too (as far as I know, it also uses a NIO based connector).
There is also an EJB container called Resin, which is semi-opensource (basically they have open source version and proprietary version). People say it has excellent performance, but I haven't got the chance to investigate further.
My last point is, are you sure you want to go with JavaEE EJB container? We actually started off with JavaEE EJB container, but because of our performance requirement etc. we are now trying to migrate to Tomcat+Spring. EJB has restriction on threading model etc., which can become unwanted restriction if you have clients other than web browsers...
Until JavaEE5, you have only this "TimerService" for executing periodical tasks, and JMS for doing asynchronous stuff, which is very heavy weight and can become very annoying.
If you're talking full boat Java EE, then Glassfish.
GFv2.1 is rock solid, GFv3 is too young to say, but offers new Java EE 6.
Actively developed, free and commercial support, good forums. Oracle has published it roadmap for it.
It's easy to use, easy to configure, well organized. Great console.
Really well documented, vast amounts of supplementary documents and article from folks working different aspects of it (Metro, Grizzly, JAX-RS, NetBeans, etc.)
NetBeans + Glassfish is a painless out of box experience to get started.
Offers clustering and all sorts of management options.
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.
Alright, the question might be broad. We've been looking at Jboss and a few other similar app. servers.
From the feature list it would be perfect for replacing our soon to be outdated homegrown reporting application on the server side. But at this point, for 2 developers, just grasping all the setup, configuration, administration, tuning,testing not to mention the APIs and programming itself just seems way too much, too big, too complex.
What path does people take to become familiar and productive with such application servers ?
Start with a simple one, and only use a more complex one if you really need the features.
For example, Do you really need the full JBoss stack? Would Tomcat not be sufficient? It's much less of a handful.
I would approach this the same way I approach anything new.
Start with the documentation - read the introduction and basic setup/configuration documents. Then move on to tutorials and maybe some simple apps that I find interesting. In your case, maybe port a few features over to the new system. As time goes on, you should get better with the tools at hand.
From my experience using one is the best way to learn what you like/dislike about it. Once you have a project set up for one application server it should not be too much work to migrate it to another. I am currently working on an application that we develop & test daily using a simple Tomcat v6 server, but which runs in production on both Websphere Application Server and JBoss.
As a side note for your development, I strongly recommend looking into integrating your Eclipse development environment with your chosen application server through server adapters - it will greatly speed up development tasks and simplify the debugging process.
I'd say that the minimum features for using Java EE are:
Servlets and JSPs, written using JSTL (no scriptlets)
JDBC
JNDI for pooling database connections (optional but recommended)
Basic authentication for security
You can accomplish a great deal knowing just those. If you want to minimize the learning curve, I'd recommend starting with those and staying away from EJBs, JMS, Struts, JSF, etc.
Another benefit is that this subset of features is common to both servlet/JSP engines, like Tomcat, Jetty, Resin, etc. and full-blown Java EE app servers like WebLogic, JBOSS, WebSphere, etc. An app that runs on one should be portable to any of the others, as long as you stay away from app engine-specific extensions.
You should realize that there's a trade-off here. You'll have to develop pieces that might be easier if you leverage the app server more. But hopefully you'll start with some simpler problems and work your way up once you're comfortable with the basics.
There's another approach: Hire an experienced guide to help you with training and mentoring for the first project. A six-month gig with a reputable consulting firm might get you started.
Last of all, I'd recommend Spring. It would also have a learning curve, but it's a good alternative to Java EE EJB development.