Java EE on tomcat?

[Arne Vajhøj]

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.

Session and message driven beans are useful for the exact same
thing that they have always been useful for.

Note that you may not need them. Many solutions lives just
fine with a web container only.

I can
replace standard Java EE JPA with Hibernate

But why would you tie your app to a specific lib instead
of using a standard?

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

JSF in Tomcat works great.

Unfortunately, if I use OpenEJB I'm stuck with an older Tomcat as it
doesn't work with 7.0 yet.

You should do:

requirements => technologies => infrastructure

not the other way around.

Start by finding out whether you need EJB or not.

Then start looking at how you can get it.

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.

I would consider:
- session beans and CDI orthogonal
- session beans and managed beans different

Arne

 

[Arne Vajhøj]

I don't have a choice in what to write.

If management have dictated Tomcat as server and EJB as technology,
then you should probably start looking at job ads. That project
will end in disaster.

Tomcat is great.

EJB is great.

But EJB in Tomcat is not great.

Tomcat's place in the Java eco system is to be a container for those
that do not need EJB's.

Arne

 

[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.

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
[/QUOTE]
Arne, I certainly agree with your comment in general. Personally I like Java
and many parts of JEE, but I'm not sure how "standard" Oracle solutions are.
There are several JEE servers so there are a few options - Websphere,
Weblogic, JBoss, Glassfish, ... I must be missing 1 or 2. But have you ever
ported an EJB from 1 to the other? I have. Standard solutions just aren't that
standard anymore.

The LAMP stack, JEE, Spring are all different ways to do similar things.
Options are nice.

Eric

 

[Arved Sandstrom]

[ SNIP ]

Arne, I certainly agree with your comment in general. Personally I like Java
and many parts of JEE, but I'm not sure how "standard" Oracle solutions are.

Pretty standard now. They own Glassfish, for example.

Seriously, Oracle's been as standard as anyone else in the J2EE/Java EE
world, in my experience, for quite some time.

There are several JEE servers so there are a few options - Websphere,
Weblogic, JBoss, Glassfish, ... I must be missing 1 or 2. But have you ever
ported an EJB from 1 to the other? I have. Standard solutions just aren't that
standard anymore.

But with Java EE the progression has absolutely been from less
standardization to more standardization. This has gone hand in hand with
the rationalization/simplification of specifications.

It's not been that long since EJBs meant ejb-jar.xml, and the server's
own ejb-jar.xml companion configuration file, and doing explicit JNDI
lookup. All of that - especially the JNDI - is what was exposing
non-standardization. Not only are less things non-standard now, but the
beauty of API specifications movement in the Java EE space has been that
a lot of the non-standard bits have been hidden. Dependency injection
has a lot to do with that.

The LAMP stack, JEE, Spring are all different ways to do similar things.
Options are nice.

Eric

LAMP absolutely. Or write an HTTP server using node.js. Or operate in
the ASP.NET MVC ecosystem. Options are essential.

But Spring was only an option - a credible, useful option - for a brief
window back when, during some period of J2EE 1.2-1.4. Recall that Spring
emerged during J2EE 1.3, and really only matured during J2EE 1.4. *All*
Spring 2.x releases happened after Java EE 5 was released. Basically
Java EE 5 closed the lid on Spring, and Java EE 6 has hammered in the nails.

My argument now is, if you're using Spring, most of the time there is a
standard non-Spring way to do the same thing.

AHS

 

[Lew]

Arne, I certainly agree with your comment in general. Personally I like Java
and many parts of JEE, but I'm not sure how "standard" Oracle solutions are.
There are several JEE servers so there are a few options - Websphere,
Weblogic, JBoss, Glassfish, ... I must be missing 1 or 2. But have you ever
ported an EJB from 1 to the other? I have. Standard solutions just aren't that
standard anymore.

The LAMP stack, JEE, Spring are all different ways to do similar things.
Options are nice.

But Spring is not a nice option.

MySQL is all right, I guess, but there are better solutions out there.

 

[nroberts]

On 9/21/2011 11:45 AM, nroberts wrote:

You should do:

requirements => technologies => infrastructure

not the other way around.
Yes.


Start by finding out whether you need EJB or not.

Which is impossible if you don't know what EJB does and what it
provides extra to additional or alternative technologies.

I would consider:
- session beans and CDI orthogonal
- session beans and managed beans different

In what way though?

 

[nroberts]

See also:
<http://lmgtfy.com/?q=what+is+the+difference+between+JSF+managed+beans....>

People who give links to google should check those links first. None
of those pages explain what the essential difference between CDI,
ManagedBean, and EJB is. Most are out of date, which is pretty much
exactly the results I got when I tried for a week before coming
here...hm-k?

 

[Lew]

People who give links to google should check those links first. None
of those pages explain what the essential difference between CDI,
ManagedBean, and EJB is. Most are out of date, which is pretty much
exactly the results I got when I tried for a week before coming
here...hm-k?

Y'know, it's funny, but I did look over those links and they all looked pretty relevant from here. Regardless, the point is to continue to work on your Google-fu since you seem so irritated with the answers you've gotten here.

Hm-k?

 

[Lew]

Which is impossible if you don't know what EJB does and what it
provides extra to additional or alternative technologies.

As I explained upthread, EJB (Enterprise Java Beans) are middleware components that implement business logic, typically to be shared as services by multiple applications.

In what way though?

Session beans are orthogonal to CDI in that you can use session beans with or without dependency injection, and dependency injection with or without session beans.

Session beans and managed beans differ, once again as already answered upthread (perhaps you missed that post?), in that session beans are a business logic, middleware component that serves the "Model" part of the MVC architecture, and JSF managed beans are front-end components that serve the "Controller" part of the MVC architecture.

 

[Robert Klemme]

But Spring is not a nice option.

MySQL is all right, I guess, but there are better solutions out there.

That depends on the nature of the application and the load it will have
to cope with. I can't see any information about that in this thread but
maybe I just missed it.

Kind regards

robert

 

[Arne Vajhøj]

On 9/18/2011 6: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 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, I certainly agree with your comment in general. Personally I like Java
and many parts of JEE, but I'm not sure how "standard" Oracle solutions are.
There are several JEE servers so there are a few options - Websphere,
Weblogic, JBoss, Glassfish, ... I must be missing 1 or 2. But have you ever
ported an EJB from 1 to the other? I have. Standard solutions just aren't that
standard anymore.

Java EE is a standard. WAS, WL, JBoss etc. implements that standard.
Spring is a product that does not implement a standard.

If you have had to change anything other than server specific deployment
descriptors when moving between servers I will suspect the problem
is not in the standard but in the people in front of the keyboard.

Arne

 

[Arne Vajhøj]

Which is impossible if you don't know what EJB does and what it
provides extra to additional or alternative technologies.


In what way though?

Like Ford and Red being ortogonal and car and airplane
being different.

Arne

 

[Arne Vajhøj]

On 9/21/2011 12:38 AM, EricF wrote:
[ SNIP ]

Arne, I certainly agree with your comment in general. Personally I like Java
and many parts of JEE, but I'm not sure how "standard" Oracle solutions are.

Pretty standard now. They own Glassfish, for example.

Seriously, Oracle's been as standard as anyone else in the J2EE/Java EE
world, in my experience, for quite some time.

There are several JEE servers so there are a few options - Websphere,
Weblogic, JBoss, Glassfish, ... I must be missing 1 or 2. But have you ever
ported an EJB from 1 to the other? I have. Standard solutions just aren't that
standard anymore.

But with Java EE the progression has absolutely been from less
standardization to more standardization. This has gone hand in hand with
the rationalization/simplification of specifications.

It's not been that long since EJBs meant ejb-jar.xml, and the server's
own ejb-jar.xml companion configuration file, and doing explicit JNDI
lookup. All of that - especially the JNDI - is what was exposing
non-standardization. Not only are less things non-standard now, but the
beauty of API specifications movement in the Java EE space has been that
a lot of the non-standard bits have been hidden. Dependency injection
has a lot to do with that.

The LAMP stack, JEE, Spring are all different ways to do similar things.
Options are nice.

LAMP absolutely. Or write an HTTP server using node.js. Or operate in
the ASP.NET MVC ecosystem. Options are essential.

But Spring was only an option - a credible, useful option - for a brief
window back when, during some period of J2EE 1.2-1.4. Recall that Spring
emerged during J2EE 1.3, and really only matured during J2EE 1.4. *All*
Spring 2.x releases happened after Java EE 5 was released. Basically
Java EE 5 closed the lid on Spring, and Java EE 6 has hammered in the nails.

My argument now is, if you're using Spring, most of the time there is a
standard non-Spring way to do the same thing.

If Spring is only used for its original purpose DI and that feature
is used moderatly then it is not so bad.

But using everything Spring and use it all over a project usually
turns pretty ugly.

Arne

 

[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.

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, I certainly agree with your comment in general. Personally I like Java
and many parts of JEE, but I'm not sure how "standard" Oracle solutions are.
There are several JEE servers so there are a few options - Websphere,
Weblogic, JBoss, Glassfish, ... I must be missing 1 or 2. But have you ever
ported an EJB from 1 to the other? I have. Standard solutions just aren't that
standard anymore.

Java EE is a standard. WAS, WL, JBoss etc. implements that standard.
Spring is a product that does not implement a standard.

If you have had to change anything other than server specific deployment
descriptors when moving between servers I will suspect the problem
is not in the standard but in the people in front of the keyboard.

Arne
[/QUOTE]

I was the people in front of the keyboard. The differences were mostly JNDI
related, specifying the datasource, etc. Not rocket science but painful if you
have to support an application on several app servers. There were some subtle
differences between Weblogic's JPA and Hibernate in JBoss. I wish I could
remember what they were. Injection made the process much easier, but it can't
be used everywhere.

Eric