Spring as standalone or on Tomcat?

Question

I am seeking for the advantages of having Spring deployed on Tomcat rather then have it out side of any application server container.

My project doesn't require any web support. It does requires technologies like transactions management, DB pool, JMX, low latency and more common java-ee technology.

So why would I use tomcat anyway? if it's just because of the reason of having DB POOL, I could implement it myself. I am looking for low latency solution.

Again, my project is a total backend no need of any web support.

So what do I miss here?

Solution 1

What do you actually mean by "more common Java EE technology"?

If it's "just a back end", what is the front end? How will applications talk to the back end?

If there's no need for a web interface, there's no advantage to using a web container.

If you have complex transaction management needs, need message queues, etc. that may be easier to set up under an application server (as opposed to a web container) because there are existing admin/management interfaces. All those may also be set up on their own, but can be more of a pain--using Spring may mitigate that pain somewhat.

The need for "more common Java EE technology", however, makes me a little nervous about implementing a standalone app, though. App containers have all that "common Java EE technology" built-in, tested, and functional. If you're bolting a variety of packages together to give you "common Java EE technology", without using a common Java EE app container, it's likely easier to just use an app container, which also gives you the benefit of providing normalized access to your services from a variety of sources.

Solution 2

If you don't need web support, you don't have to use tomcat or any other app server. Spring will provide you with most of the features you need. For connection pool, there are many options available such as c3p0 & apache dbcp. You can use one of them.

The only thing you have to worry about is a clean shutdown of your process. You can do that by implementing your own shutdown hook.

Solution 3

If your app is not a web app, you can use any of the non-web specific application contexts listed under All Known Implementing Classes here. You can then init the context from a main method in a runnable jar.

Comments

[nos]

Tomcat only does management of http connections and threads related to servlet/web/http processing. But the OP doesn't have a http interface

[rayman]

I am using app container today. but we want to move into Spring. so Why would I need Spring inside app container if all I need is the app container services?

[rayman]

This is kind of answer I was looking for. so why many people using Spring inside jboss/tomcat although they dont need any web interface. What advantage does it give to them? why not to run the spring as stand alone.

[rayman]

I am not asking what is the purpose of app container or it's benefits. I do ask why do I need spring on it if Spring already implemented all those technologies

[Dave Newton]

@rayman Because Spring doesn't implement all those technologies--Spring wraps those technologies in a unified way. It doesn't implement JPA, it has Hibernate and JPA helpers. You still need a JMS implementation, caching, whatever.

[rayman]

Yes.I understand that Spring doesnt have the implementations but only those templates. But so is Tomcat. if for example I chose HornetQ as jms implementation I will need to add it's jars to tomcat. so why couldnt I just add it's jars to standalone and achieve the same result? Still cant find the benefit of Tomcat except it's HTTP technologies.

[Samarth Bhargava]

Apart from web app & web services, app servers provide support for EJB/MDB's. That could be a very valid reason to use them. Also, if you already have an app server running, you may choose to deploy scheduled jobs etc on the same server to have a simple deployment architecture

[Dave Newton]

@rayman As I said, of course you could build a complete stack of the technologies you need-but then you're building a complete stack of technologies you need. If you have the time and desire to do so, go right ahead (and test it, etc). I rarely have that luxury, and the system admins rarely have the time to learn a bunch of disparate admin tools (compared to having them in a single unified interface).

[rayman]

But I have kind of "MDB" implementations within Spring. so why would I need the app container's MDB?

[rayman]

ofcourse I dont have the time to build stack of existence technologies. but this is all about. those technologies which I need already builed inside the Spring. so why would I need to have my Spring inside tomcat if that "stack" can be used also in Spring standalone?

[Dave Newton]

@rayman I already told you the most typical reasons, and specifically said if there's no need for any web interaction, there isn't any reason--although a web interface is the easiest way to get system visibility. I don't know what else you want me to say, so I'm going to stop talking.

[rayman]

What about resources cleaning? Does Spring responsible for cleaning it's resources itself? Since I always used application servers I never had to pay attention for cleaning resources everything was pooled.

[magulla]

Same there. Depends on what kind of resource do you use. As example if you use JMS, u can use spring impl of jms Connection factory and it will provide you with pool. Same regarding jdbc or anything else. Spring much more light weight comparing to app.server since you don't need to turn on support of everything. However on other hand you need to configure everything manually.