I was wondering if could help me. Please could someone address the below points?
1) My understanding is that J2EE contains additional classes to J2SE that can be used for server side applications
2) These additional classes will all be put in j2ee.jar
3) A web server like Tomcat only uses part of these additional classes. So it will not contain a j2ee.jar, but would only contain a subset of the classes from j2ee.jar
4) Would Tomcat have additional classes defined that are not part of J2EE?
A server is something which gives you some kind of "service". Tomcat being a webserver, will give you the http service, and the associated sub-services
which you can relate to http [ssl, session maintenance etc]. An application server is a superset, in the sense that it can provide you additional services like RMI, IIOP,
database connection pooling, thread pooling, enterprise level security [to name a few], which are way beyond the scope of a webserver. So just adding a j2ee.jar to tomcat will not solve your purpose.
Dawn, I'm not sure that's really the answer to the question he actually asked...
J2EE is an umbrella for many, many different APIs. Remember that an API is just a specification for some code; it's not the code itself. In Java, the specification takes the form of a set of interfaces, and some instructions for using them. Most of what's in j2ee.jar is exactly those interfaces, and nothing more. The J2EE spec by itself doesn't do anything. To actually run, you need an implementation of some parts of those specs.
Then there's the J2EE (or JEE, as it's really called these days) reference implementation, which includes an implementation of every one of the J2EE APIs. That makes it an application server. They're not necessarily the best implementations -- they're just something to test against, maybe run small deployments. For industrial-strength deployments, you need a more substantial implementation like JBoss, Websphere, etc.
Tomcat is a web container; it implements only parts of J2EE, notably the servlet and JSP specs. It provides some tools for using the JDBC spec. It provides a security infrastructure. Plus, you can use other J2EE APIs like JavaMail by plugging in an implementation obtained from any other source.
In general, if you need to use Enterprise Java Beans, you need an application server. If you're only going to use servlets and JSPs, then you just need a web container. You can, generally, run your servlets and JSPs in a full-on application server -- but it's overkill.
Thanks for the answers. Ernest, that was an excellent response, it has certainly made things a lot clearer. However, I still have some loose ends I would like to tie up, so if anyone can help, it would be nice.
If I go to the documentation for J2EE, I can see a lot of abstract classes, interfaces, and classes. Let us consider
Now there must be byte code for this that was created by Sun, yes? I would assume this would be in a OpenMBeanOperationInfo.class. Where would this .class be? Will it be in the j2ee.jar? Are all the .class files that are part of the J2EE specification bundled into the j2ee.jar? Or are some of them bundled into other jars?
My next question is regarding Tomcat. You have said that Tomcat implements only part of the J2EE specification, and that makes sense to me. So, the GenericServlet.class will be part of Tomcat, as it is obviously needed. But because Tomcat is a webserver, and it does not need OpenMBeanOperationInfo, this means that the OpenMBeanOperationInfo.class will not be part of the Tomcat software. Is this correct? In other words, only those .class files that are needed will be part of Tomcat.
Joined: Apr 26, 2007
The OpenMBean....class you mentioned is a part of another specification called JMX [another spec like the servlet spec], and hence will have a different package structure.
j2ee.jar, being a superset of almost all j2ee implementations from sun, would have this class as a member of it, but you can always obtain a jar which contains, say, servlet spec implementation, or a JMX implementation alone.