I have a J2EE-based system which is running currently on Apache Tomcat. We are in discussions to move our production servers to the Glassfish server.
Can someone share their experiences with either of them?
They are not really comparable.
Apache Tomcat is not a J2EE Server. It's merely a Servlet Container for Web-Applications. Nothing more. If you need J2EE API implementations, you have to take those from elsewhere. For example by using the Apache Geronimo Server which uses Tomcat as its container, or by taking the JAR files from Glassfish.
Glassfish is a complete Java Application Server with implementation for APIs like JPA, EJBs and more. Glassfish contains a Servlet Engine initially used by Tomcat, but they improved it (don't know what exactly). More recent glassfish servers use another container using grizzly which uses the NIO API for input/output and scales quite well. As far as i know, the Glassfish Servlet Engine is more performant. Here i've found a nice benchmark (it's a bit old though):
http://weblogs.java.net/blog/sdo/archive/2007/05/how_to_test_con.html
Here's quite an old comparison. As such, the capabilities of each server have doubtless improved.
Edit: Here is a current comparison.
Both are more than stable enough for production use though. It's really going to come down to features.
Big question is: why? What do you think you need that Glassfish will provide you over Tomcat or Jetty? Management utilities perhaps?
Most things you want beyond basic servlet container are easily pluggable.
So while Glassfish is fine as is, there is no point in moving "just because". Most production services I have built are on plain old servlet containers, using none of implementation-specific features.
This may be a little dated and maybe even a little biased, but it's from Oracle. You can skip down to the section for comparing Glass Fish to Tom Cat
http://java.sun.com/developer/technicalArticles/glassfish/GFandMySQL_Part1.html
Related
I am learning Erlang and found out it contains httpd which I managed to configure and make serve to my needs for creating an API service.
I know there are other solutions like mochiweb and Cowboy which must be undoubtedly great choice but I want to begin lean and bare bones.
When I decide to release my project, will it be a good plan to use Erlang's httpd regarding performance and HTTP features like HTTPS, HTTP/2, performance, or should I choose another server?
httpd is powerful webserver and a perfectly valid choice for production, as long as it fits your needs. I think the main reason to go for other alternative webservers is that you find that some functionality is missing in httpd that you find somewhere else. For example, I don't think httpd supports websockets, however websockets are supported by for instance cowboy and yaws.
When I decide to release my project, will it be a good plan to use
Erlang's httpd regarding performance and HTTP features like HTTPS,
HTTP/2, performance, or should I choose another server?
I can't find any benchmarks comparing httpd with the other solutions that you mention, like cowboy and mochiweb, but I've not heard any complaints about the peformance of httpd and I would guess that it's as good as cowboy and mochiweb for production. The fact that it's shipped with the erlang language is a good reason for assuming that the code is performant and battle-tested, if you want to go in depth you can always:
look at the source: https://github.com/erlang/otp.
Make your own benchmarks.
LDAP authentication in different J2EE servers is different, unfortunately.
Eg. If I develop a code in JBoss for LDAP authentication with LDAP login module of JBoss, 99% chances are that it will not run in WebSphere or any other J2EE containers. Maybe if I import that library jar files, it might work. I’m looking at just porting the application and not having to worry about library files, unless we have written the libraries. Libraries of J2EE servers must not be copied from one server to the other. I don’t know if that could be called code ethics!!
Is there a J2EE server independent module for LDAP or way of programming for doing this?
Is the solution – code from scratch using JNDI the only method? Please advice.
I'd suspect that most J2EE container already have an LDAP module for the authentication, in which case the problem you're having isn't really about programming, but about adapting the configuration from one container to another. Little to no actual code should be required for this. It's not clear why you would develop your own code for LDAP authentication then.
If you really want this configuration to be container independent, you'll certainly need to embed the authentication within the webapp itself.
The Restlet framework, for example, can do that, but it's part of a wider architectural choice, which may or may not be what you're after.
Even if you program your own LDAP code via JNDI or JAAS for example, you're likely to have to tweak the configuration of the container, perhaps for its security manager to let the connections to your LDAP server through (if enabled) or at least to configure which LDAP server to use when deploying the application.
I think in the general case, it's probably wiser to use the container's module (which will vary depending on the container). It ultimately depends on how you configure your webapps when deploying them.
Which one of these two is most commonly used scenario? I want to use the same scenario in my learning process. thanks.
Don't know about the rest of the industry, but where I work we have Apache HTTPD front-ending for Tomcat.
Any static content is directly provided by HTTPD for performance. Pain in the neck to separate every app out, but there is a noticeable payoff.
Also, HTTPD has some nice code for cookie handling, URL rewriting, clustering and so on.
Only if we determine that there's dynamic, database-bound data to show do we forward to Tomcat, which does an admirable job there.
Has been working well for us for almost a decade. Others too, I would wager.
I've been trying to mug up on Glassfish and one thing that keeps coming up is the "how-to" on fronting Glassfish with Apache. Unfortunately, I have yet to find a description of why you would want to do this!
From my experimentation, Glassfish seems like a pretty fully featured web server-type service; but I might be missing a lot. So, is the notion of front-ending Glassfish more of a solution to integrate it with an existing architecture, or does front-ending (in a pure Java environment) provide extra benefits?
There's also another valid use case as to why we front Glassfish with Apache. Apache in this instance would function as a reverse proxy for increased security of your Glassfish. The RP is configured to allow only certain URLs to be passed through to the application server. For e.g., you may have app contexts /myApp and /myPrivApp deployed in Glassfish. In the RP server, you only configure /myApp to be passed to Glassfish. Anybody requesting for /myPrivApp would see a 404 'cos the request stops right at the RP level.
In one of my deployments, I have a bunch of WARs deployed, some for users coming from the internet, some for intranet only. I have 2 RPs running, one for internet users and the other for intranet. I configure the internet RP to only allow URLs for approved internet applications to pass through while intranet users get to see everything.
Hope that helps.
It is usually used to speed things up. Since apache is a very fast web server it is used to deliver static content. Like images, CSS files and so on. Glassfish serves the dynamic content (servlets, JSPs) in this scenario.
Another reason for using Apache as a frontend to Glassfish is the possibility to provide load balancing across a Glassfish cluster. See http://tiainen.sertik.net/2011/03/load-balancing-with-glassfish-31-and.html for details.
A other reason is that glassfish cannot run (easily) on port 80, without giving it root rights of course.
So, for most users it's easer to run a proxy (apache, nginx, varnish) some sort in front of apache and have both servers run under a normal user.
Then you have a other advantage of some configurations options of your front end. Like others mentioned, caching for example.
I have been looking around to figure out how to configure Glassfish front ended with Apache. And most of the tutorials using the load balancing plug in is making me enable SSL on Apache. I am trying to understand the connection. I should be able to do non SSL communications when I dont have a need for SSL.
There are several blog posts showing how you can use Apache in front of Glassfish. There are several options and depending on your needs, different strategies might be the most appropriate.
I've used Apache with mod_jk which forwards requests to Glassfish - both https and regular http. Lots of good references here.
It's possible to use other modules in Apache also like mod_proxy, but again the requirements you have will flesh out the most appropriate.
Glassfish also have pretty good http engine inside of it where you can configure virtual hosts like in apache. If the load on the Glassfish server isn't to big, you might consider just using Glassfish without anything in front of it.
You can also use the Sun Java System Web Server SJSWS instead of Apache. Despite it's atrocious name, it is just Sun's web server (free to use). It can be used as a reverse proxy (PDF). The SJWS/Glassfish combination is presumably tested really well by Sun.