Re: Java EE on tomcat?
nroberts wrote:
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 pro=
blem 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 already=
all 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 consider=
doing that the ass-backwards way?
Use Hibernate, sure, but use it *as a JPA provider*. Using "raw" Hibernate=
leads 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' obj=
ects, inappropriate calls across message queues, direct references to table=
surrogate keys (auto-generated integer IDs, if you can believe it!) in the=
object code, strange manipulations of under-the-hood SQL - I've seen so ma=
ny 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 ot=
her 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 deplo=
y 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 whi=
le until you know what you are doing.
--
Lew