Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #7704 > unrolled thread

Java EE on tomcat?

Back to article view | Back to comp.lang.java.programmer

Contents

  Java EE on tomcat? nroberts <roberts.noah@gmail.com> - 2011-09-08 10:53 -0700
    Re: Java EE on tomcat? Lew <lewbloch@gmail.com> - 2011-09-08 11:22 -0700
      Re: Java EE on tomcat? nroberts <roberts.noah@gmail.com> - 2011-09-08 12:08 -0700
        Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-08 17:48 -0400
      Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-08 17:56 -0400
    Re: Java EE on tomcat? markspace <-@.> - 2011-09-08 12:36 -0700
    Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-08 17:41 -0400
      Re: Java EE on tomcat? Torsten Kirschner <torsten.kirschner@gmail.com> - 2011-09-19 00:30 +0200
        Re: Java EE on tomcat? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-18 20:44 -0300
          Re: Java EE on tomcat? Torsten Kirschner <torsten.kirschner@gmail.com> - 2011-09-20 00:20 +0200
            Re: Java EE on tomcat? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-20 05:50 -0300
              Re: Java EE on tomcat? nroberts <roberts.noah@gmail.com> - 2011-09-21 08:45 -0700
                Re: Java EE on tomcat? Lew <lewbloch@gmail.com> - 2011-09-21 11:19 -0700
                  Re: Java EE on tomcat? nroberts <roberts.noah@gmail.com> - 2011-09-21 11:31 -0700
                    Re: Java EE on tomcat? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-21 17:37 -0300
                  Re: Java EE on tomcat? nroberts <roberts.noah@gmail.com> - 2011-09-21 11:29 -0700
                    Re: Java EE on tomcat? Lew <lewbloch@gmail.com> - 2011-09-21 14:26 -0700
                      Re: Java EE on tomcat? nroberts <roberts.noah@gmail.com> - 2011-09-22 10:27 -0700
                        Re: Java EE on tomcat? Lew <lewbloch@gmail.com> - 2011-09-22 13:30 -0700
                    Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-21 20:40 -0400
                Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-21 20:35 -0400
                  Re: Java EE on tomcat? nroberts <roberts.noah@gmail.com> - 2011-09-22 10:23 -0700
                    Re: Java EE on tomcat? Lew <lewbloch@gmail.com> - 2011-09-22 13:38 -0700
                    Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-22 21:15 -0400
        Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-19 21:55 -0400
          Re: Java EE on tomcat? eric@invalid.com (EricF) - 2011-09-21 04:38 +0000
            Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-21 20:29 -0400
              Re: Java EE on tomcat? eric@invalid.com (EricF) - 2011-09-22 02:41 +0000
                Re: Java EE on tomcat? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-22 06:08 -0300
                  Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-22 21:18 -0400
                Re: Java EE on tomcat? Lew <lewbloch@gmail.com> - 2011-09-22 08:39 -0700
                  Re: Java EE on tomcat? Robert Klemme <shortcutter@googlemail.com> - 2011-09-22 22:58 +0200
                Re: Java EE on tomcat? Arne Vajhøj <arne@vajhoej.dk> - 2011-09-22 18:47 -0400
                  Re: Java EE on tomcat? eric@invalid.com (EricF) - 2011-09-24 04:45 +0000

Page 1 of 2  [1] 2  Next page →

#7704 — Java EE on tomcat?

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?

[toc] | [next] | [standalone]

#7706

On Thursday, September 8, 2011 10:53:18 AM UTC-7, 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?

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 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 obsolete tools affects those rather severely.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#7713

On Sep 8, 11:22 am, Lew <lewbl...@gmail.com> wrote:
> On Thursday, September 8, 2011 10:53:18 AM UTC-7, 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?
>
> 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 to make 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 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.

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 decision and 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.

[toc] | [prev] | [next] | [standalone]

#7724

On 9/8/2011 3:08 PM, nroberts wrote:
> On Sep 8, 11:22 am, Lew<lewbl...@gmail.com>  wrote:

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

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

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

Arne

[toc] | [prev] | [next] | [standalone]

#7726

On 9/8/2011 2:22 PM, Lew wrote:
> On Thursday, September 8, 2011 10:53:18 AM UTC-7, 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?

> 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

[toc] | [prev] | [next] | [standalone]

#7716

On 9/8/2011 10:53 AM, 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?


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.

[toc] | [prev] | [next] | [standalone]

#7723

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

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

[toc] | [prev] | [next] | [standalone]

#8145

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.

[toc] | [prev] | [next] | [standalone]

#8147

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 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
-- 
job creator: US Republican term for a wealthy party contributor

[toc] | [prev] | [next] | [standalone]

#8160

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.

[toc] | [prev] | [next] | [standalone]

#8170

On 11-09-19 07:20 PM, Torsten Kirschner wrote:
> 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.

AHS

-- 
job creator: US Republican term for a wealthy party contributor

[toc] | [prev] | [next] | [standalone]

#8178

On Sep 20, 1:50 am, Arved Sandstrom <asandstrom3min...@eastlink.ca>
wrote:
> On 11-09-19 07:20 PM, Torsten Kirschner wrote:
>
>
>
>
>
>
>
>
>
> > 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.

[toc] | [prev] | [next] | [standalone]

#8179

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 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 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' objects, 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 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#8180

On Sep 21, 11:19 am, Lew <lewbl...@gmail.com> wrote:
> 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 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 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.

[toc] | [prev] | [next] | [standalone]

#8182

On 11-09-21 03:31 PM, nroberts wrote:
> On Sep 21, 11:19 am, Lew <lewbl...@gmail.com> wrote:
>> 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 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 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.

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

[toc] | [prev] | [next] | [standalone]

#8181

On Sep 21, 11:19 am, Lew <lewbl...@gmail.com> wrote:

> 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 a while 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.

[toc] | [prev] | [next] | [standalone]

#8183

nroberts wrote:
> Lew wrote:
> > ManagedBean and SessionBean are not the same thing.
> 
> Which would be why I was asking the diff.

Here is part of that answer as already given:
>> 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.

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 they forward 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:
<http://lmgtfy.com/?q=what+is+the+difference+between+JSF+managed+beans+and+enterprise+Java+beans+EJBs>

>> That said, you should avoid EJBs at first anyway.  Write web apps for a while 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

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?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#8212

On Sep 21, 2:26 pm, Lew <lewbl...@gmail.com> wrote:

> 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?

[toc] | [prev] | [next] | [standalone]

#8215

On Thursday, September 22, 2011 10:27:29 AM UTC-7, nroberts wrote:
> On Sep 21, 2:26 pm, Lew <lewb...@gmail.com> wrote:
> 
> > 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?

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

[toc] | [prev] | [next] | [standalone]

#8190

On 9/21/2011 2:29 PM, nroberts wrote:
> On Sep 21, 11:19 am, Lew<lewbl...@gmail.com>  wrote:
>> That said, you should avoid EJBs at first anyway.  Write web apps for a while until you know what you are doing.
>
> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web