Java EE on tomcat?

[nroberts]

If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

 

[Lew]

If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Some of the management console stuff goes away, queues go away, EJBs by default go away but you can add them back with Apache OpenEJB. Why you'd wantto, though, that's another question.

Who are these "higher ups" and what makes them think they're qualified to make technology decisions?

That said, most systems run better on Tomcat, or better yet on Apache Web Server + Tomcat, anyway. EJBs are a pain in the butt most of the time, and queues have specialized use cases you might not even have. For the stuff you most likely care about, namely web pages, Expression Language (EL) the Java Persistence API (JPA), and JSF/XHTML, Tomcat is eminently suitable.

Configuration differs. Most application servers like JBoss and Glassfish work through their own management consoles (web apps in their own right). With Tomcat you configure your DBMS connections through the server.xml and web.xml files. The Tomcat docs explain it well.

Have you studied the Tomcat docs yet? You should.

What are the decision factors in the choice between Tomcat and a more robust app server? Even if you aren't the decision maker you should have insight into the balance sheet in that choice. If they make a bad decision and you haven't done your fiduciary duty, then it's *your* fault.

Whichever way you go, push for the latest stable version of the app server or Tomcat, and for Java 6 or 7 as the base language. Push hard. There's no valid reason to go with Java 5 or J2EE in the platform, given backward compatibility and the absence of license fees. Only development and maintenance costs should weigh into that decision, and use of outdated and obsoletetools affects those rather severely.

 

[nroberts]

Some of the management console stuff goes away, queues go away, EJBs by default go away but you can add them back with Apache OpenEJB.  Why you'd want to, though, that's another question.

Who are these "higher ups" and what makes them think they're qualified tomake technology decisions?

Dunno. People with more seniority, experience and authority than I
have at the moment. I'm just trying to gage how much I should fight
this or whether using Tomcat would be quite reasonable. Right now I'm
thinking that most of the complexity of the current code base is
caused by J2EE requiring a lot of "upkeep" crap and that simply
migrating to the current EE standards, along with some fairly straight
forward refactors, would mitigate most architectural "issues".

That said, most systems run better on Tomcat, or better yet on Apache WebServer + Tomcat, anyway.  EJBs are a pain in the butt most of the time, and queues have specialized use cases you might not even have.  For the stuff you most likely care about, namely web pages, Expression Language (EL)the Java Persistence API (JPA), and JSF/XHTML, Tomcat is eminently suitable.

I'm completely new to Java but in reading tutorials and such I'd
imagine writing Java web applications without EJB, especially the
current standard, would just add a bunch of work. What about EJB
makes it a pita?

What are the decision factors in the choice between Tomcat and a more robust app server?  Even if you aren't the decision maker you should have insight into the balance sheet in that choice.  If they make a bad decisionand you haven't done your fiduciary duty, then it's *your* fault.

Yeah, I'm trying to look into that. As the new guy and one who has 0
experience with Java technologies less than a decade old, it's going
to be hard to get input I think. I've asked what the guiding concerns
are though.

What could those concerns be? The program I'll be writing is
basically this thing that imports data into a database, does some
manipulations and comparisons, and outputs a "report" in a particular
command language. Various aspects of its use need to be limited by
access, pay-grade, responsibility...etc... Based on my limited
understanding, what exists now doesn't need to be THAT secure, but
what they may want to do later would need a great deal of security.
Is it reasonable to write such a thing with the parts of EE possible
to use with tomcat?

Whichever way you go, push for the latest stable version of the app server or Tomcat, and for Java 6 or 7 as the base language.  Push hard.  There's no valid reason to go with Java 5 or J2EE in the platform, given backward compatibility and the absence of license fees.  Only development and maintenance costs should weigh into that decision, and use of outdated and obsolete tools affects those rather severely.

One thing I've pushed on is trying to upgrade our JBOSS server to the
current version (we're currently stuck on 4.0). I don't really know
what's going to be required to do this, how much work, etc...but I
felt it worth looking into. Just got a push-back hard, from multiple
directions, saying that we're rewriting the whole thing to only use
tomcat anyway.

 

[markspace]

If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

You might want to ask "What parts of JEE do the powers-that-be want?" I
might interpret a requirement to use Tomcat as a demand to just use the
servlet spec and drop the rest of it.

Best to ask and be sure.

 

[Arne Vajhøj]

If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology).

That means that you have servlet, JSP, JSTL, EL, JSF etc.
to work with.

You don't have EJB, JCA, JTA, JMS etc..

You can also use all the third party web frameworks (Struts 1,
Wicket, Spring MVC etc.).

Most likely you will be fine, but obvious you should narrow
what you study to match what you have.

Arne

 

[Arne Vajhøj]

I'm completely new to Java but in reading tutorials and such I'd
imagine writing Java web applications without EJB, especially the
current standard, would just add a bunch of work.

If the app you will be developing does not require any of the stuff
you are missing, then it will not have any impact at all.

That is not an unlikely scenario.

What could those concerns be? The program I'll be writing is
basically this thing that imports data into a database, does some
manipulations and comparisons, and outputs a "report" in a particular
command language. Various aspects of its use need to be limited by
access, pay-grade, responsibility...etc... Based on my limited
understanding, what exists now doesn't need to be THAT secure, but
what they may want to do later would need a great deal of security.
Is it reasonable to write such a thing with the parts of EE possible
to use with tomcat?
Yes.

One thing I've pushed on is trying to upgrade our JBOSS server to the
current version (we're currently stuck on 4.0). I don't really know
what's going to be required to do this, how much work, etc...but I
felt it worth looking into. Just got a push-back hard, from multiple
directions, saying that we're rewriting the whole thing to only use
tomcat anyway.

It seems as if it has already been evaluated and a decision has
been made.

Arne

 

[Arne Vajhøj]

Who are these "higher ups" and what makes them think they're
qualified to make technology decisions?

Most likely more qualified than OP.

That said, most systems run better on Tomcat, or better yet on Apache
Web Server + Tomcat, anyway. EJBs are a pain in the butt most of the
time, and queues have specialized use cases you might not even have.

Unless one is allergic to XML config files and/or annotations, then
EJB's should not really bother anyone.

Configuration differs. Most application servers like JBoss and
Glassfish work through their own management consoles (web apps in
their own right). With Tomcat you configure your DBMS connections
through the server.xml and web.xml files. The Tomcat docs explain it
well.

JBoss connection pools are defined in deployable files.

What are the decision factors in the choice between Tomcat and a more
robust app server? Even if you aren't the decision maker you should
have insight into the balance sheet in that choice. If they make a
bad decision and you haven't done your fiduciary duty, then it's
*your* fault.

Whichever way you go, push for the latest stable version of the app
server or Tomcat, and for Java 6 or 7 as the base language. Push
hard. There's no valid reason to go with Java 5 or J2EE in the
platform, given backward compatibility and the absence of license
fees. Only development and maintenance costs should weigh into that
decision, and use of outdated and obsolete tools affects those rather
severely.

In this case where thy have decided to switch from JBoss to Tomcat
the only sensible thing is to pick a new Tomcat and a new Java.

But there are good reasons why stuff sometimes stay on old stuff - it
can be very costly to lift the app and do a full retest.

Future decreases in development cost is a soft argument. It sounds good,
but I doubt that many teams would commit to a significant reduction in
hours/task-size due to a platform lift.

Arne

 

[Torsten Kirschner]

Den 08.09.2011 23:41, skrev Arne Vajhøj:

If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology). [...]
You don't have EJB, JCA, JTA, JMS etc..

[...]

Using the Spring Framework ( http://www.springsource.org/ ), one gets
most of the above, except EJB, I guess. Add Hybernate and you're set.

 

[Arved Sandstrom]

Den 08.09.2011 23:41, skrev Arne Vajhøj:

If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology). [...]
You don't have EJB, JCA, JTA, JMS etc..

[...]

Using the Spring Framework ( http://www.springsource.org/ ), one gets
most of the above, except EJB, I guess. Add Hybernate and you're set.

And as Cay Horstmann put it in
http://weblogs.java.net/blog/cayhorstmann/archive/2009/12/29/jsf-20-and-tomcat,
when describing how to set up JSF 2.0 and Java EE 6 EL and CDI and bean
validation and JPA (to some extent):

"But even if you don't, ask yourself what you gain from the Tomcat pain.
GlassFish v3 is very fast, easy to manage, and, due to its modular
nature, you get as much or as little of EE 6 as you want."

Or as Lincoln Baxter put in
http://ocpsoft.com/java/why-doesnt-jpa-jma-jta-ejb-jsf-cdi-work-jee-is-too-complicated/:

"Trust me, the reason people have thought Java EE sucks, is because they
try to do this stuff on Tomcat, and say 'Why doesn’t (JPA, JMS, JTA,
EJB, JSF, CDI) work?'...Tomcat, Jetty, and other 'Servlet Containers'
all have these issues – that’s why they are called Servlet Containers."

Using Spring and a JPA provider and God knows what else with Tomcat,
just so it'll approach the capability provided by a proper Java EE
server, is exactly the same thing that Cay and Lincoln were advising
against. It's unnecessary, wasteful, error-prone, unproductive, and
misguided. Furthermore, the management capabilities provided by all
modern Java EE application servers blow Tomcat completely out of the water.

I use Tomcat myself and have used servlet containers ever since they
appeared. Echoing the comments of the two quoted guys, no disrespect
intended to Tomcat or any other servlet container, use a servlet
container for what they give you out of the box: don't try and make
imitations of Java EE servers out of them.

AHS

 

[Torsten Kirschner]

Den 9/19/11 1:44 AM, skrev Arved Sandstrom:

Den 08.09.2011 23:41, skrev Arne Vajhøj:

On 9/8/2011 1:53 PM, nroberts wrote:
If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology). [...]
You don't have EJB, JCA, JTA, JMS etc..

[...]

Using the Spring Framework ( http://www.springsource.org/ ), one gets
most of the above, except EJB, I guess. Add Hibernate and you're set.

[... spherical cows in an EJB container ...]

AHS

The OP's clearly stated premise was being limited to a given web
container.

 

[Arne Vajhøj]

Den 08.09.2011 23:41, skrev Arne Vajhøj:

If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology). [...]
You don't have EJB, JCA, JTA, JMS etc..

[...]

Using the Spring Framework ( http://www.springsource.org/ ), one gets
most of the above, except EJB, I guess. Add Hybernate and you're set.

I don't think Spring has JCA.

I don't think Spring provides JTA or JMS - it just allows to
interface other providers.

It is Hibernate not Hybernate.

Spring really does not provide much of the standards.

Arne

 

[Arved Sandstrom]

Den 9/19/11 1:44 AM, skrev Arved Sandstrom:

Den 08.09.2011 23:41, skrev Arne Vajhøj:
On 9/8/2011 1:53 PM, nroberts wrote:
If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology).
[...]
You don't have EJB, JCA, JTA, JMS etc..
[...]

Using the Spring Framework ( http://www.springsource.org/ ), one gets
most of the above, except EJB, I guess. Add Hibernate and you're set.

[... spherical cows in an EJB container ...]

AHS

The OP's clearly stated premise was being limited to a given web container.

Yes, and you've supplied a fairly decent chain of quoting. So, given
that he asked what would be unavailable if he was stuck with Tomcat, and
it was made clear that most of Java EE is unavailable (out of the box),
why not leave it at that?

The way I look at it is, if you shoehorn everything possible into
Tomcat, including Spring, just to make it act like a crippled Java EE
server, are you not subverting the point of sticking with Tomcat?
Presumably there is a reason why the OP could be limited to that servlet
container - suggesting ways in which it can be seriously modified (in a
less than optimal fashion) to not be just a servlet container anymore is
changing the premise.

AHS

 

[EricF]

Den 08.09.2011 23:41, skrev Arne Vajhøj:

On 9/8/2011 1:53 PM, nroberts wrote:
If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology). [...]
You don't have EJB, JCA, JTA, JMS etc..

[...]

Using the Spring Framework ( http://www.springsource.org/ ), one gets
most of the above, except EJB, I guess. Add Hybernate and you're set.

I don't think Spring has JCA.

I don't think Spring provides JTA or JMS - it just allows to
interface other providers.

It is Hibernate not Hybernate.

Spring really does not provide much of the standards.

Arne

I do think Spring is nice but it doesn't try to provide the standards (JEE).
When it first came out, it was a lot easier to use than much of the JEE stack.
These days JEE has been simplified.

Eric

 

[nroberts]

Den 9/19/11 1:44 AM, skrev Arved Sandstrom:

On 11-09-18 07:30 PM, Torsten Kirschner wrote:
Den 08.09.2011 23:41, skrev Arne Vajhøj:
On 9/8/2011 1:53 PM, nroberts wrote:
If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at?  What parts
of Java EE become unavailable to me?
Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology).
[...]
You don't have EJB, JCA, JTA, JMS etc..
[...]
Using the Spring Framework (http://www.springsource.org/), one gets
most of the above, except EJB, I guess. Add Hibernate and you're set.

[... spherical cows in an EJB container ...]

AHS

The OP's clearly stated premise was being limited to a given web container.

Yes, and you've supplied a fairly decent chain of quoting. So, given
that he asked what would be unavailable if he was stuck with Tomcat, and
it was made clear that most of Java EE is unavailable (out of the box),
why not leave it at that?

The way I look at it is, if you shoehorn everything possible into
Tomcat, including Spring, just to make it act like a crippled Java EE
server, are you not subverting the point of sticking with Tomcat?
Presumably there is a reason why the OP could be limited to that servlet
container - suggesting ways in which it can be seriously modified (in a
less than optimal fashion) to not be just a servlet container anymore is
changing the premise.

Apparently the decision to move to Tomcat was simply one of
standardization. I think perhaps the decision was made a while back.
At any rate it was made without me for reasons I do not know. I was
told though, when I mentioned being worried that such limits could
increase development effort, that I can use whatever libraries or
extensions I need. This includes things like OpenEJB etc...

After learning more about these buzzwords and what they actually
implement though I'm starting to wonder what is left for EJB. I can
replace standard Java EE JPA with Hibernate as it implements it now.
I can pull in JSF with either the standard implementation or MyFaces
(and tobago or whatever looks pretty interesting). I can get
dependency injection with CDI; I'm thinking this gives me all the
advances in unit testing that EJB 3.1 gave us. I can get @WebService
with JAX-WS though I might not even want it.

Unfortunately, if I use OpenEJB I'm stuck with an older Tomcat as it
doesn't work with 7.0 yet. I tried a patched version that someone
released and it kind of worked I thought, but yesterday I found that
webservices were bugging out...either that or need a totally different
way of setting them up that would likely be a nightmare to figure
out. I spent a good day on it yesterday just trying to get the ejb
example webservices to work and the way I fixed it was to stop trying
to use a patched version and just downgrade Tomcat.

I'd rather not base a new project on old technology that's just going
to end up obsolete the next release if I can at all help it.

Another thing about the previous technologies I listed is that I can
put them in my app's WEB-INF folder; I don't have to install them in
Tomcat. Perhaps OpenEJB is the same way but I've not seen clear
documentation on doing so.

What is it that EJB offers me that I don't get with these other
standard technologies? I thought it was things like SessionBeans and
such, but if I use the CDI and JSF bits it seems like I get a lot of
the same behavior because I've got @ManagedBean or @Named. I'm
finding this confusing.

 

[Lew]

Apparently the decision to move to Tomcat was simply one of
standardization. I think perhaps the decision was made a while back.

"Let's standardize on Betamax for our on-demand movie streaming service."

Standardization is good as long as the standard actually applies to the problem domain.

At any rate it was made without me for reasons I do not know. I was
told though, when I mentioned being worried that such limits could
increase development effort, that I can use whatever libraries or
extensions I need. This includes things like OpenEJB etc...

As others pointed out, this is not a good approach. If you need all those things, better to go with Glassfish or Geronimo or JBoss where it's alreadyall there, and just about as lightweight as Tomcat without those things.

After learning more about these buzzwords and what they actually
implement though I'm starting to wonder what is left for EJB. I can
replace standard Java EE JPA with Hibernate as it implements it now.

Wrong direction. Standard JPA replaces the old-style Hibernate way.

Since Hibernate directly supports JPA, why would you even remotely considerdoing that the ass-backwards way?

Use Hibernate, sure, but use it *as a JPA provider*. Using "raw" Hibernateleads to trouble. You wouldn't think so, but it does. Every single time I've seen Hibernate in the wild, it's used wrong. Monolithic 'Session' objects, inappropriate calls across message queues, direct references to tablesurrogate keys (auto-generated integer IDs, if you can believe it!) in theobject code, strange manipulations of under-the-hood SQL - I've seen so many crazy things in Hibernate-based applications.

Using it as a JPA provider (strictly) leads to gentler idioms. Short-lived'EntityManager' instances, dependency injection, objects that reference other objects (or collections thereof), not their keys - the benefits accrue.

Use the JPA mode.

I can pull in JSF with either the standard implementation or MyFaces
(and tobago or whatever looks pretty interesting). I can get

That's not EJB - that is Web. Tomcat supports JSF quite nicely.

dependency injection with CDI; I'm thinking this gives me all the

Some things are just easier in an enterprise application server than a web application server, but you're right, Tomcat suffices for a broad category of needs.

Until it doesn't.

advances in unit testing that EJB 3.1 gave us. I can get @WebService
with JAX-WS though I might not even want it.

Unfortunately, if I use OpenEJB I'm stuck with an older Tomcat as it
doesn't work with 7.0 yet. I tried a patched version that someone
released and it kind of worked I thought, but yesterday I found that
webservices were bugging out...either that or need a totally different
way of setting them up that would likely be a nightmare to figure
out. I spent a good day on it yesterday just trying to get the ejb
example webservices to work and the way I fixed it was to stop trying
to use a patched version and just downgrade Tomcat.

Don't use OpenEJB. Don't use EJBs at all.

I'd rather not base a new project on old technology that's just going
to end up obsolete the next release if I can at all help it.

Another thing about the previous technologies I listed is that I can
put them in my app's WEB-INF folder; I don't have to install them in
Tomcat. Perhaps OpenEJB is the same way but I've not seen clear
documentation on doing so.

Putting "them in [your] app's WEB-INF folder" is not the right way to deploy applications. Oh, wait, you mean "deploy in your application's WAR file".. Okay, that's all right. Your terminology confused me for a second.

What is it that EJB offers me that I don't get with these other
standard technologies? I thought it was things like SessionBeans and
such, but if I use the CDI and JSF bits it seems like I get a lot of
the same behavior because I've got @ManagedBean or @Named. I'm
finding this confusing.

ManagedBean and SessionBean are not the same thing.

JSF is a front-end technology. EJB is a middleware technology. Different layers with different purposes.

That the behaviors are similar is a help to learning them, but do not make the mistake of thinking that that makes them the same thing. They are not.

That said, you should avoid EJBs at first anyway. Write web apps for a while until you know what you are doing.

 

[nroberts]

ManagedBean and SessionBean are not the same thing.

Which would be why I was asking the diff.

JSF is a front-end technology.  EJB is a middleware technology.  Different layers with different purposes.

That the behaviors are similar is a help to learning them, but do not make the mistake of thinking that that makes them the same thing.  They are not.

That said, you should avoid EJBs at first anyway.  Write web apps for awhile until you know what you are doing.

I don't have a choice in what to write. If I did I wouldn't be using
Java anyway; I've never been a fan. What I need to do is find out
what technologies do what so that I can figure out what I need to
learn in order to accomplish the task given.

 

[nroberts]

"Let's standardize on Betamax for our on-demand movie streaming service."

Standardization is good as long as the standard actually applies to the problem domain.


As others pointed out, this is not a good approach.  If you need all those things, better to go with Glassfish or Geronimo or JBoss where it's already all there, and just about as lightweight as Tomcat without those things.

You're preaching to the choir here. Giving me hell for using
something I'm forced to use isn't going to help me. I have a task. I
have constraints. It is what it is. Given the choice I'd be using an
app server instead of trying to figure all this crap out. I wasn't
given one.

 

[Arved Sandstrom]

You're preaching to the choir here. Giving me hell for using
something I'm forced to use isn't going to help me. I have a task. I
have constraints. It is what it is. Given the choice I'd be using an
app server instead of trying to figure all this crap out. I wasn't
given one.

In your shoes I think, at this point, I'd whip up a written technology
assessment that explains exactly what vanilla Tomcat is capable of. If
you've been given to understand that the motivation is standardization,
then explain in that assessment that only certified-compliant Java EE
applications servers are standardized for Java EE.

Also explain in that document what they will not get even with a Tomcat
that you've enhanced.

You clearly already know this, but cobbling together a slice of Java EE
with a dozen or more third-party JARs and jamming them into Tomcat is a
recipe for every kind of maintenance and development nightmare.

Think of this document as not only a good-faith attempt to educate your
people, but also a potential CYA for when things start going south. Add
into the document a clear evaluation of configuration management impact
- how many extra third party JARs are needed, who are these third party
JARs from, what is the choice available for each API/specification, how
much extra work is entailed in including these things, etc.

My hunch is that whoever made this decision is ignorant. I don't mean
stupid; I just mean ignorant. Which means they can be educated. In theory.

AHS

 

[Lew]

Which would be why I was asking the diff.

Here is part of that answer as already given:
Managed beans in JSF are the "Controller" components of the model-view-controller (MVC) pattern that JSF embodies. They are close to the screens, often aware of what is in the view and what model components they should orchestrate. They do not embody deeper logic, if properly designed, rather theyforward the high-level requests from the view to deeper-level components to handle the business logic.

Session beans are such deeper-level components, embodying business (and/or persistence) logic as part of the "Model" component of the MVC pattern.

See also:

I don't have a choice in what to write. If I did I wouldn't be using

So they are mandating that you write EJBs? That was not clear from your other posts.

If they mandate to write EJBs, it's especially strange that they require a platform that doesn't support EJBs, and especially important that you push back on that.

Java anyway; I've never been a fan. What I need to do is find out

Java is perfectly fine for the purpose. Don't let your prejudices interfere with your effectiveness.

what technologies do what so that I can figure out what I need to
learn in order to accomplish the task given.

Well, you certainly have gotten a lot of that information from the folks here.

Don't get edgy with us for trying to help you, hm-k? We know you have a lot of stress at work, but we're the folks helping you, so don't take it out on us. The advice you're getting here is good, so don't shoot the messengers. Hm-k?

 

[Arne Vajhøj]

Den 08.09.2011 23:41, skrev Arne Vajhøj:
On 9/8/2011 1:53 PM, nroberts wrote:
If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?

Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology).
[...]
You don't have EJB, JCA, JTA, JMS etc..
[...]

Using the Spring Framework ( http://www.springsource.org/ ), one gets
most of the above, except EJB, I guess. Add Hybernate and you're set.

I don't think Spring has JCA.

I don't think Spring provides JTA or JMS - it just allows to
interface other providers.

It is Hibernate not Hybernate.

Spring really does not provide much of the standards.

I do think Spring is nice but it doesn't try to provide the standards (JEE).
When it first came out, it was a lot easier to use than much of the JEE stack.
These days JEE has been simplified.

But to me it is difficult to see why go with a non-standard
solution exists when a standard solution exists that does the
same.

Arne