If I use Glassfish and only need jersey for jax-rs and grizzly for servlet/jsp, will glassfish load all other Java EE components I don't need and take more up more resources than just running jersey/tomcat or will glassfish just load jersey/grizzly and will use almost the same resources? I have tried running starting default glassfish and default tomcat, glassfish takes much more ram.
Is there any reason not to run jersey with tomcat? maybe because the integration is done better by Glassfish?
There are lots of people who use Jersey with Tomcat. Tomcat is a servlet container only but will not interfere with other Java EE technologies that you choose to support through other means (e.g. Jersey). You may have to manage some of the initialization of the frameworks, etc. that other full-J2EE containers like Glassfish already provide, but it shouldn't be too painful.
You can use the 'web profile' to help minimize the download, initial memory and start-up time.
The most recent web profile is http://dlc.sun.com.edgesuite.net/glassfish/3.1.2.2/release/glassfish-3.1.2.2-web.zip
The start-up time is between Tomcat and the GlassFish 'full' profile.
The web profile includes an integrated implementation of Jersey.
Related
Can I deploy a Spring java application on all (or at least most) of JavaEE servers ? like Weblogic, JBoss, Webshpere, Tomcat, Jettty etc.
And is there is preferred Java EE server for Spring ?
Yes you can. And no - there isn´t. Errata: you can take a look at the SpringSource dm Server. Be aware that spring is not a java EE implementation. Read this post here.
Yes, you can deploy it on any server, and you can use it on standalone applications and even on mobile applications. It is in no way restricted to web deployment. It is not even restricted to java, there is Spring.NET and even a Python version. However, java and web servers are a common if not the most common use for it.
Currently recommended web server by VMWare/Pivotal (current owner of Spring) is VFabric tcServer, which is a Tomcat fork containing some extra tools and functionality. But server in itself does not matter, Spring is container agnostic.
There is no preferred EE server. VFabric tcServer is a servlet container, not an EE server. It contains "enterprise capabilities" instead, but that's not the same thing. As said however, you can use whichever EE server you want.
OpenShift offers the possibility to develop Spring based applications using JBoss EAP6. I am considering migrating a Spring application developed/deployed on Tomcat 7.
I have little experience with JBoss. Am I going to go through many troubles if I migrate my application? If yes which? Are Tomcat 7 and JBoss EAP6 compatible?
It depends entirely on your application.
The servlet container in JBoss 6 is based on Tomcat 6. If you are using any new features in Tomcat 7 (e.g. extensions in the Servlet 3.0 or JSP 2.2 spec), these will not run on JBoss 6.
The general response will be yes, JBoss will provide all the standard elments Tomcat does. But it is always possible to make it not compatible (using directly some tomcat class, JBoss Web use a different name space and there is no 1:1 corespondances).
I most cases you will need to make some litle addaptation (add some configuraiton and properties, change datasource name...).
JBoss AS7 documentation contains some Spring integration elements.
Some elments provided by default in JBoss may give you some trouble (like JPA), but if you have full controle on the application source, you should be able to get it working without lot of efforts.
Without inside on your application it will be difficult to give concreate effort estimate.
Is it possible to deploy ear (Jersey and Metro) archive in embedded Jetty? Google shows articles and manuals only about Jetty + JBoss.
As far as I understand, Jetty shouldn't have such a functionality.
That's because jetty was designed to be a web container only for Servlets and JSPs.
You can see the jetty as an alternative to the Tomcat web server.
So Jetty is able to process only web based stuff (read WARs).
JBoss on the other hand is a full fledged Java EE container, so it can handle ears as well.
What you've seen is probably embedding the jetty inside the jboss.
I know that Jboss has used tomcat for dealing with servlets and jsps internally, so it might be possible to switch the underlying implementation from tomcat to jetty.
Hope this helps
I'll add that many people deploying into things like JBoss or other full Java EE stacks really don't need the full stack and can often get away with a servlet engine plus a handful of components. I know folks that have gone with aggregated solutions of things like jetty + open ejb to achieve a lightweight stack that does what they need without all the added Java EE bells and whistles. For example, if you intend to have an embedded scenario then you don't need to deploy an ear you can deploy the application bit by bit, handling servlets with jetty and ejb's with openejb or whatever *bean solution you like.
If you need the full Java EE container then by all means use one...but if you are using a minor subset of those Java EE features there are other ways to assemble your application.
If I were to deploy an application on Tomcat vs. Websphere, what are things that I need to consider?
Do I have to develop my Java code differently if developing in one app server vs another?
Edit:
I will be funneling people from a website into a web app that does credit card processing and e-signatures (cc processing and e-sigs are through separate services). That is its sole job
You cannot use EJBs on Tomcat (unless you add OpenEJB). If your WebSphere deployment uses EJBs, you'll have to remove them to deploy on Tomcat.
If you use any Java EE features beyond servlet/JSP engine and JNDI naming service you'll have to eliminate them from your app.
Tomcat accepts WAR packages. If you package your app into an EAR on WebSphere, you'll have to change it to WAR for Tomcat.
Both use JNDI for data sources. There might be some nagging differences in naming conventions, but if you stick to the standard they should be portable.
If you use any WebSphere specific code in your app, you'll have to remove it to deploy on Tomcat.
If your app is servlets, JSPs, and JDBC you can deploy on either one without any problems.
You can think as Tomcat as a subset of Websphere, so theoretically everything that works on Tomcat will work in Websphere.
But...Deploying in Websphere, in my humble opinion, is a terrible pain, while deploying in Tomcat just works. (And if fails, just delete temporary folders)
Without knowing the technologies you are using, that's all I can say.
Depends, what are you trying to deploy?
Tomcat isn't a full EE server--are you trying to deploy an EE app?
If you're just deploying a web app, it's more important to consider which version of the servlet spec/etc. each server implements.
I am starting to look into Enterprise Java and the book I am following mentions that it will use JBoss. Netbeans ships with Glassfish. I have used Tomcat in the past.
What are the differences between these three programs?
Tomcat is just a servlet container, i.e. it implements only the servlets and JSP specification. Glassfish and JBoss are full Java EE servers (including stuff like EJB, JMS, ...), with Glassfish being the reference implementation of the latest Java EE 6 stack, but JBoss in 2010 was not fully supporting it yet.
Tomcat is merely an HTTP server and Java servlet container. JBoss and GlassFish are full-blown Java EE application servers, including an EJB container and all the other features of that stack. On the other hand, Tomcat has a lighter memory footprint (~60-70 MB), while those Java EE servers weigh in at hundreds of megs. Tomcat is very popular for simple web applications, or applications using frameworks such as Spring that do not require a full Java EE server. Administration of a Tomcat server is arguably easier, as there are fewer moving parts.
However, for applications that do require a full Java EE stack (or at least more pieces that could easily be bolted-on to Tomcat)... JBoss and GlassFish are two of the most popular open source offerings (the third one is Apache Geronimo, upon which the free version of IBM WebSphere is built). JBoss has a larger and deeper user community, and a more mature codebase. However, JBoss lags significantly behind GlassFish in implementing the current Java EE specs. Also, for those who prefer a GUI-based admin system... GlassFish's admin console is extremely slick, whereas most administration in JBoss is done with a command-line and text editor. GlassFish comes straight from Sun/Oracle, with all the advantages that can offer. JBoss is NOT under the control of Sun/Oracle, with all the advantages THAT can offer.
You should use GlassFish for Java EE enterprise applications.
Some things to consider:
A web Server means: Handling HTTP requests (usually from
browsers).
A Servlet Container (e.g. Tomcat) means: It can handle
servlets & JSP.
An Application Server (e.g. GlassFish) means: *It can manage
Java EE applications (usually both servlet/JSP and EJBs).
Tomcat - is run by Apache community - Open source and has two flavors:
Tomcat - Web profile - lightweight which is only servlet container and does not support Java EE features like EJB, JMS etc.
Tomcat EE - This is a certified Java EE container, this supports all Java EE technologies.
No commercial support available (only community support)
JBoss - Run by RedHat
This is a full-stack support for JavaEE and it is a certified Java EE container.
This includes Tomcat as web container internally.
This also has two flavors:
Community version called Application Server (AS) - this will have only community support.
Enterprise Application Server (EAP) - For this, you can have a subscription-based license (It's based on the number of Cores you have on your servers.)
Glassfish - Run by Oracle
This is also a full stack certified Java EE Container. This has its own web container (not Tomcat).
This comes from Oracle itself, so all new specs will be tested and implemented with Glassfish first. So, always it would support the latest spec. I am not aware of its support models.
jboss and glassfish include a servlet container(like tomcat), however the two application servers (jboss and glassfish) also provide a bean container (and a few other things aswell I imagine)
It seems a bit discouraging to use Tomcat when you read these answers. However what most fail to mention is that you can get to identical or almost identical use cases with tomcat but that requires you to add the libraries needed (through Maven or whatever include system you use).
I have been running tomcat with JPA, EJBs with very small configuration efforts.
JBoss and Glassfish are basically full Java EE Application Server whereas Tomcat is only a Servlet container.
The main difference between JBoss, Glassfish but also WebSphere, WebLogic and so on respect to Tomcat but also Jetty, was in the functionality that an full app server offer. When you had a full stack Java EE app server you can benefit of all the implementation of the vendor of your choice, and you can benefit of EJB, JTA, CDI(JAVA EE 6+), JPA, JSF, JSP/Servlet of course and so on. With Tomcat on the other hands you can benefit only of JSP/Servlet. However to day with advanced Framework such as Spring and Guice, many of the main advantage of using an a full stack application server can be mitigate, and with the assumption of a one of this framework manly with Spring Ecosystem, you can benefit of many sub project that in the my work experience let me to left the use of a full stack app server in favour of lightweight app server like tomcat.
Both JBoss and Tomcat are Java servlet application servers, but JBoss is a whole lot more. The substantial difference between the two is that JBoss provides a full Java Enterprise Edition (Java EE) stack, including Enterprise JavaBeans and many other technologies that are useful for developers working on enterprise Java applications.
Tomcat is much more limited. One way to think of it is that JBoss is a Java EE stack that includes a servlet container and web server, whereas Tomcat, for the most part, is a servlet container and web server.
Apache tomcat is just an only serverlet container it does not support for Enterprise Java application(JEE). JBoss and Glassfish are supporting for JEE application but Glassfish much heavy than JBOSS server : Reference Slide