Java EE on tomcat?

Discussion in 'Java' started by nroberts, Sep 8, 2011.

  1. nroberts

    nroberts Guest

    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?
    nroberts, Sep 8, 2011
    #1
    1. Advertising

  2. nroberts

    Lew Guest

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

    --
    Lew
    Lew, Sep 8, 2011
    #2
    1. Advertising

  3. nroberts

    nroberts Guest

    On Sep 8, 11:22 am, 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?

    >
    > 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.
    nroberts, Sep 8, 2011
    #3
  4. nroberts

    markspace Guest

    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.
    markspace, Sep 8, 2011
    #4
  5. nroberts

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Sep 8, 2011
    #5
  6. nroberts

    Arne Vajhøj Guest

    On 9/8/2011 3:08 PM, nroberts wrote:
    > On Sep 8, 11:22 am, Lew<> 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
    Arne Vajhøj, Sep 8, 2011
    #6
  7. nroberts

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Sep 8, 2011
    #7
  8. 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.
    Torsten Kirschner, Sep 18, 2011
    #8
  9. 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
    Arved Sandstrom, Sep 19, 2011
    #9
  10. 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.
    Torsten Kirschner, Sep 19, 2011
    #10
  11. nroberts

    Arne Vajhøj Guest

    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.

    Arne
    Arne Vajhøj, Sep 20, 2011
    #11
  12. 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
    Arved Sandstrom, Sep 20, 2011
    #12
  13. nroberts

    EricF Guest

    In article <4e77f29e$0$311$>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <> wrote:
    >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.
    >
    >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
    EricF, Sep 21, 2011
    #13
  14. nroberts

    nroberts Guest

    On Sep 20, 1:50 am, Arved Sandstrom <>
    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.
    nroberts, Sep 21, 2011
    #14
  15. nroberts

    Lew Guest

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

    --
    Lew
    Lew, Sep 21, 2011
    #15
  16. nroberts

    nroberts Guest

    On Sep 21, 11:19 am, Lew <> 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 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, Sep 21, 2011
    #16
  17. nroberts

    nroberts Guest

    On Sep 21, 11:19 am, Lew <> 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.
    nroberts, Sep 21, 2011
    #17
  18. On 11-09-21 03:31 PM, nroberts wrote:
    > On Sep 21, 11:19 am, Lew <> 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
    Arved Sandstrom, Sep 21, 2011
    #18
  19. nroberts

    Lew Guest

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


    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:
    <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
    Lew, Sep 21, 2011
    #19
  20. nroberts

    Arne Vajhøj Guest

    On 9/21/2011 12:38 AM, EricF wrote:
    > In article<4e77f29e$0$311$>, =?ISO-8859-1?Q?Arne_Vajh=F8j?=<> wrote:
    >> 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
    Arne Vajhøj, Sep 22, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. %=zerointeractive.it%

    [TOMCAT] Tomcat crashes

    %=zerointeractive.it%, Jan 22, 2004, in forum: Java
    Replies:
    1
    Views:
    409
    Erwin Moller
    Jan 22, 2004
  2. Christos Gravvanis
    Replies:
    0
    Views:
    2,035
    Christos Gravvanis
    Jul 7, 2004
  3. Joe
    Replies:
    0
    Views:
    1,666
  4. Martin Eberle
    Replies:
    2
    Views:
    815
  5. Katerina McLean
    Replies:
    1
    Views:
    3,067
    Juha Laiho
    Dec 10, 2004
Loading...

Share This Page