• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

Spring insinde or outside J2EE containers

 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

As I said in another post today, I'm quite sure I'm missing the point of all the Spring stuff.
Some say it's really cool because does not need a container anymore, but it appears to me that several functionalities can only be done using a container, and so using Spring as a wrapper around Full Old J2EE Objects (new acronym FOJO :-)

Please explain what I'm missing here
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Spring doesn't just wrap J2EE components into "decorated" components. It lets you do that if you need to, but the general approach to a Spring-based architecture is to write your components as plain old Java objects.

The SessionBean in an EJB application is a POJO in a Spring application. The EntityBean in an EJB application is a Hibernate/JDO/OJB/iBatis-backed POJO in a Spring application. And, of course, if you need to integrate with an existing EJB application, for example, you can still do the wrapping thing by writing a POJO Spring bean that delegates to the EJB.

In short, you're not tied to J2EE containers but you're still able to use them if that's what you need.
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Lasse, it helps

So correct me if I'm wrong (sorry, iI'm really a Spring newbie), but Spring is not meant to be used with a J2EE container AT ALL, because it does provide the same functionalities with other technologies

Nevertheless, Spring IS ABLE to integrate with a J2EE server if you really need it, say you have an old (sic) J2EE application you've got to interact with
[ February 23, 2005: Message edited by: JeanLouis Marechaux ]
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by JeanLouis Marechaux:
So correct me if I'm wrong (sorry, iI'm really a Spring newbie), but Spring is not meant to be used with a J2EE container AT ALL, because it does provide the same functionalities with other technologies


Sort of, yes, but there's a catch.

I'd suspect that 99.999(and a lot more 9's)% of Spring projects are actually web applications and are deployed on a J2EE application server or web container. While Spring does provide a set of useful services (mainly AOP and configurable components) for other kinds of applications, the web domain is certainly mainstream.

Originally posted by JeanLouis Marechaux:
Nevertheless, Spring IS ABLE to integrate with a J2EE server if you really need it, say you have an old (sic) J2EE application you've got to interact with


Yes. And in practice, you most often do in fact deploy your Spring application as a J2EE web application.
 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The aim of Spring is to make J2EE easy
One way that it does this is to free you from having to use some 'standard' J2EE container components, e.g. EJBs just because you want transaction management.
Because you are free to use POJOs, and Spring provides an excellent way to wire up the dependencies between objects, you don't have to run the code in a J2EE container (though as Lasse says, almost everyone does in production).

The massive knock on effect of this is that you can easily use something like jUnit to test your code outside the container during development. At a time when Test Driven Development is being pushed as the way to go, being able to easily test your code is vital. Thats where the independance from a J2EE container is most important for me.



Louise
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by louise rochford:
The aim of Spring is to make J2EE easy
One way that it does this is to free you from having to use some 'standard' J2EE container components, e.g. EJBs just because you want transaction management.
Because you are free to use POJOs, and Spring provides an excellent way to wire up the dependencies between objects, you don't have to run the code in a J2EE container (though as Lasse says, almost everyone does in production).

The massive knock on effect of this is that you can easily use something like jUnit to test your code outside the container during development. At a time when Test Driven Development is being pushed as the way to go, being able to easily test your code is vital. Thats where the independance from a J2EE container is most important for me.

Louise



That's what EJB 3.0 is (or will be)
A simplification of J2EE (EBJ 2.x), using POJO and testable outside the EJB container

And I suppose jBoss will still offer it for free, just like Geronimo will probably do.



you don't have to run the code in a J2EE container(though as Lasse says, almost everyone does in production).



Ok. That's why Spring sometimes appears to me juste like Object - Oriented DBMS vs RDBMS. It's cool, and everyone agrees with that, but (almost) nobody uses it in production.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by JeanLouis Marechaux:
It's cool, and everyone agrees with that, but (almost) nobody uses it in production.


If you deploy a Spring application on a J2EE server in your production environment, doesn't that mean you're putting a Spring application to production?

Nowhere it says that Spring would be intended to be a complete middleware platform in itself. It's an application framework that works well inside and outside of a J2EE environment. It's not a replacement for the J2EE application server.
 
Author
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess the easiest way to answer this is that Spring does not mandate a usage pattern at all. You can replace many of the services you get with *EJB* using Spring outside of a container - that is pooling, security and transaction management.

If you need to use other J2EE services like JMS, XA transaction, JNDI or servlets then you are going to need to the appropriate container. Obviously, you don't need a full J2EE container. For instance, I often use just servlets and JMS, which translates to Tomcat and ActiveMQ.

Spring will work happily in both J2EE and J2SE settings.

Rob
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


I'd suspect that 99.999(and a lot more 9's)% of Spring projects are actually web applications and are deployed on a J2EE application server or web container. While Spring does provide a set of useful services (mainly AOP and configurable components) for other kinds of applications, the web domain is certainly mainstream.



Thanks for saying most Spring apps are deployed in 99% of times deployed via j2ee containers, made me look hard and realized it's what my team was doing. For so long was confused how javax validation packages were wired up with Spring so cleanly, it's because spring is running in the environment that javax validation beans are built in.
 
Saloon Keeper
Posts: 24212
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andrew Willette wrote:
Thanks for saying most Spring apps are deployed in 99% of times deployed via j2ee containers, made me look hard and realized it's what my team was doing. For so long was confused how javax validation packages were wired up with Spring so cleanly, it's because spring is running in the environment that javax validation beans are built in.



I think that it's better to say that Spring is designed to play nicely with standards, including java validation. But neither Spring nor JEE are limited to web applications and the like. I've used Spring JPA for offline database maintenance services more than once. I've also used Spring in an OSGi environment.

We don't do much of the traditional "punched card" style batch processing any more, so validation is probably not going to be a big pat of most offline or automated services. But if the environment supports validation, then Spring will do its part.
 
Pay attention! Tiny ad!
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic