I would like to take a doubt about the container to run a "Spring Application", in my opinion one of many features who Spring Framework offer is a possibility to create application without container EE. Is right use this type of container ("WildFly", "GlassFish") with a spring project ? In my option is wrong but i'm open to listening more people.
i saw a article where the author are showing the features of Spring 4 with the WildFly, but i didn't agree, so i would like to take more opinions about this topic here.
Considering Spring Web and Web MVC you will typically use a lightweight container like Tomcat, Jetty or any other servlet container - maybe embedded like Spring Boot does.
Spring Web is designed to work without a full JEE container but will also work deployed inside one.
With Spring without JEE you have much more control about the features you use. A full appserver has a bundled feature list, you get all or none. Spring offers you to pick what you need resulting in a more slim application.
Well, first of all it is a little tricky to say that "something" is wrong or right in software development, mainly in this type of subjective question. As always, that really depends on what you need and on the EE Container that that you are using.
Let's get Widlfly as example. Since JBoss 7 (and now Wildfly) I do not think we can say that JBoss is a "heavy" Server, as it starts in just a few seconds, much faster than in the earlier versions. While it is true that Wildfly comes with a lot of services that you may not use, it is not correct to say that you get "all or none", for at least 2 reasons:
You can disable the services you do not need.
Wildfly works with the concept of lazy-loading for its services, which means that it will only load the services that are required to run a given application.
Having said that, we can not forget that Spring also uses some EE services, if you want to. So, if you need to use Spring with JMS, for example, you still need a JMS container. In this case, you can use an EE Server without needing to install additional services or you can start a JMS container in your Tomcat.
Besides the EE features, there is also the question of features related to the server, such as configurability/manageability (Web interface, CLI), HA, scalability... that really varies from server to server and I think Jboss 7/Widfly does a good work on these points.
Related
Servlet container implements web component contract of Java EE specification, specifying a runtime environment for web components that includes security, concurrency, lifecycle management, transaction, deployment, and other services.
Apache tomcat is one open source example.
Object satisfying the contract given by javax.servlet.ServletContext, is used per each web application
Spring IOC container also implement web component contract of Java EE specification.
Object satisfying the contract given by org.springframework.context.ApplicationContext, is used per each web application
Why Spring IOC container is preferred over servlet container?
There are many problematic statements in this question, I'll try to do my best to clarify few things by adding some "list" of facts that hopefully will help:
Tomcat does not implement JEE specification, in fact, its famous only for implementing small (although important and widely-used) specification under the umbrella of JEE: servlets (and JSPs which a technically a servlet but in a more HTML like form).
That's true that tomcat also follows a deployment model of WARs described in JEE, but in JEE there are much more types of archives that tomcat has nothing to do with. In addition, recent versions of tomcat allow "embedded mode", where you don't have to work with WARs at all.
Spring, in a nutshell, is an IOC container, something that tomcat doesn't cover at all. I assume you know what is IOC, so I won't dig into IOC in this question.
In addition to IOC, spring provides a fairly good integration with many different technologies (think about it as yet another thing that Spring can do). Now among these technologies, you can find Web Framework (called spring MVC), various templating engines (just like JSP), REST, working with database (Spring Data), Security model (Spring security) and many other things.
All this makes spring a competitor of any implementation of JEE specification. Spring conceptually makes everything that JEE does (and arguably even more) but doesn't follow the standards established by JEE. Having said that, in modern versions, the difference becomes less and less significant, in many cases, Spring does honor interfaces and annotations offered by JEE, in addition to its own way to do stuff.
So, now it's obvious that Spring and Tomcat don't really compete with each other. In fact, they can work together and its a really wide-spread tandem:
One can use a spring framework to develop an application that will run on tomcat.
Another successful model is to use spring boot that allows embedding the tomcat into the spring boot application and use it under the hood to server web (HTTP/Rest) requests.
Hope this sheds some light and helps to understand the differences between Spring and Tomcat
I have Websphere 7 server, and it don't support JPA 2.0. So I can't run on WAS 7 JPA 2.0 applications.
But I'm wondering how Spring users run Hibernate on Tomcat or Jetty? This servlet-containers also (as WAS 7) doesn't support Java EE 6.
So it's mean that I can run Hibernate on WAS 7 with the same results as on the Tomcat or Jetty?.
If yes, what are benefits of using app-servers for JPA? Why all developers don't use servlet-containers instead app-servers?
Also I heard about "container-managed" stuff, that allows some additional features and functionality. So it's mean that many developers (who uses Spring on Jetty and Tomcat) don't get benefits of using container-managed features of app-servers?
P.S. I know about available Feature Pack patch for WAS 7 for JPA 2.0 support, but question not about it.
You can bring in a lot of functionality by including the appropriate jars in your WEB-INF/lib folder, but then the servlet container cannot help you in any way with the functionality, and it will most likely not be well integrated with the functionalty actually provided by the container. A typical example is bringing your own JSF 2.0 libraries.
The real advantages of using implementations in the container, is that the container can then help with clustering across multiple hosts, providing JDBC connection pools, etc.
So, you need to be more careful when including e.g. Hibernate yourself, and do all the configuration inside your own deployment, but it can be done.
You could just as well ask an exactly opposite question: "why use bare servlet containers with JPA 2 since it is included in all the Java EE 6 servers?".
Basically it boils down to either:
having a light-weight container and then a heavy application (the Spring way),
having a light-weight application and then a heavy container (the Java EE 6 way).
After years of evolution, the models of building the applications with Spring and Java EE 6 have converged to the point where sometimes you cannot really tell just by looking at a class, whether it's a Spring or a CDI bean. So the real difference is mostly in configuration.
Application servers offer a set of services "out of the box", so they are easier to use if the offered services are the ones you need. You just package and deploy your application and the thing works. Furthermore, most of the technologies are instantiated by the application server, so you avoid a lot of classloader issues.
The problem with application servers is that sometimes (quite often, actually), you need to pick and choose particular versions of particular frameworks, services, etc that are incompatible with those which the application server offers. In those cases, you usually need to fiddle with the application server, and in some cases, what you would like to do might not even be possible with your application server.
For example, Weblogic 10.x is a Java EE 5 application server and so it will offer by default JSF 1.2 and JPA 1. If you want to use something newer, you need to manually deploy some additional libraries (JSF 2.0), or patch the server (JPA 2.0).
Another example: with Glassfish 3.1 I have not been able to use Tomcat EL intead of Glassfish EL. Tomcat EL supports varargs method call while Glassfish EL does not.
That rigidness of Java EE application servers makes a lot of people prefer developing for a standalone servlet container such as Tomcat or Jetty, where you have nothing out of the box but the Servlet and JSP APIs, but you can manually put everything inside. You can also package it with your application, which is more comfortable when you are developing, but can give you problems if you deploy more than one application per container (waste of resources, classloading issues, classloader leaks, ...)
UPDATE:
There are some differences in using JPA in a SE environment (such as Tomcat) when compared to using JPA inside a Java EE container. Basically:
You have to manually manage EntityManagerFactory and EntityManager instances.
Tomcat does not do injection so #PersistenceContext annotation and similar ones do not work.
Note that some containers (such as Spring) can be configured to hide these details, so you can work exactly as if you were inside a Java EE container.
Read the JPA spec for details on running in SE environments instead of EE environments.
Regarding another libraries, in general you will find some minor differences. For example, JAX-WS requires registering a servlet and a listener for your webapp, but anything else should be identical. Usually you can search the documentation for instructions on how to run the thing inside a standalone servlet container.
There is a JPA 2.0 feature pack for WAS 7.0, which may help you.
I've started looking at osgi with the main purpose to achieve the task ahead of me. Basically i would be able to distribute an web based application and build specific features of the whole web app separately in such a way that i can deploy at A my web app with features a,b,c and deploy at B with features a,c,d.
A little like how one can install plugin in joomla. So for example when i want to add a different aspect of the web application, i would build a small war with all the html and its admin section and have this feature admin section available in the main admin panel.
Second question is about Spring DM. most likely i will be using Spring and it seem logical i see what Spring DM has to offer.After downloading Spring DM .1.2.1 i found out that its lib folder contains spring jars for version 2.5.6.SEC01 but i planned on using 3.1.2 so am a little confuse as how everything will play nice together.
Thanks for reading
I've just been doing such an exercise so I can shed some light how you do it without the overhead of Spring. I've made a clear division: all application code is in the browser, all data handling is in the server. With HTML5 the browser has grown up to an impressive, portable, and powerful application environment. One has multiprocessing, messaging, modularity, and amazing visuals. I am using angularjs as the framework in the browser.
Angular works with a central routing table mapping the hash part of the page url to "modules" in Javascript. This makes it very easy to define what modules are part of the application. The server can easily control this part.
On the server side I have bundles that carry the Javascript code, the html fragments and the data handling. I based this on the OSGi Http Server model since it is more flexible. However, I added proper support for static resources in bundles: caching, streaming, ranges, etc.
In the server I used DS and bndtools to develop the bundles. This is an impressive development experience since it works like Smalltalk. You change and it is immediately reflected in the server. Adding bundles, removing bundles, the server keeps on running. Server restarts are rare during development.
The disadvantage is that there are unfortunately very few components that leverage OSGi. Most components, with Spring being the archetypical example, rely heavily on class loading hacks to wire applications from a central point. This is fundamentally not modular. For this reason I had to develop many highly cohesive and uncoupled components that leverage the OSGi service model. Once I get time I will donate them to an open source project.
I'm not sure you need to be considering OSGi, at least not directly, to achieve your state requirements. You said:
Basically i would be able to distribute an web based application and
build specific features of the whole web app separately in such a way
that i can deploy at A my web app with features a,b,c and deploy at B
with features a,c,d.
If these are youre requirements, then you don't actually need to concern yourself with OSGi directly, but rather find a web app framework that supports modular extensions. Which most likely means that the framework itself uses OSGi. I'm not familiar with Spring, but I do know that Struts 2 ( a comparable web app framework ) has an OSGi based plugin meant to achieve your use case.
On the other hand, if your idea is to play with OSGi, then I suggest you pick a lower level task, such as writing a web application framework, rather than a web app itself.
What are the advantages of building a small Java web app to run in a Servlet container (like Tomcat) vs. building a standalone Java app with a built-in web server and running it behind a reverse proxy?
I've been playing with Java for about a year. I've noticed that to launch Tomcat takes time, and it's not always possible to do a hot-redeploy due to class loader issues. The Servlet API seems somewhat convoluted to me, especially from the perspective of configuration and of RESTful design (which it doesn't really fully support).
On the other hand, I've noticed that my IDE can compile and run a standalone app at lightning speed. Configuring Apache for reverse-proxying is a piece of cake, and embedded Jetty seems to handle whatever I can throw at it. I don't need Servlets when I can use Restlet, Wicket, etc. Being able to know better how my app works (because it's not integrated with a huge app server) feels empowering. The stack traces are shorter. Download size is smaller. End-user configuration is easier. I'm guessing performance is likely to be better because there are fewer software layers involved.
However, I am reminded of the saying that what sounds too good to be true usually is. So my question is, why would I not want to make my web apps standalone? What does a Servlet container give me and/or my end users that we really need but don't know about?
There are 2 separate questions in here:
Should I be using an embedded
server, or deploy into a container?
I don't think you should be seeing a
big difference one way or the other.
There's slightly more code to
startup a Jetty server
programmatically, and configuration
is easier to do programmatically.
Even though IDE support for web app
configuration and deployment is
getting better, it's still worse
than for standalone applications
(this is kinda by definitions, since
there's a superset of things to
support).
On the other hand, app servers give
you some nice benefits like built-in
management, built-in ability to run
as a service, etc.
You could even use a hybrid
approach: use an embedded server to
develop locally, then deploy into a
container in production. But that's
a bit weird: if you go through the
trouble of making a proper WAR file,
IDEs should really be able to handle
deployment into a container
adequately.
BTW, it's weird that you have issues
with hot-redeploy; Tomcat shouldn't
be having issues with it unless
you're running into some strange
corner case...
Should I be using Servlet API?
This is orthogonal from #1. You
could very well embed Jetty and
implement Servlets. You could also
use Restlet API inside Tomcat
through a ServerServlet
http://www.restlet.org/documentation/1.0/faq#02.
I personally find the Servlet API to
be pretty straight-forward.You get
nice things like concurrency and
state management. I don't quite know
what that means that RESTful design
is not supported, but if Restlets
address your requirements better,
then use that...
Embedded Jetty can be a good choice if you don't need the full Servlet stack. Unlike Tomcat, Jetty makes it easy to get rid of the parts you're not using (JSP, JNDI, whatever).
Writing your own HTTP server, on the other hand, is a terrible idea. Sure, it's easy to write something that handles basic requests. But soon you'll find that some clients are having trouble with it because it doesn't support the full protocol specs; or that it crashes when there's more than a few hundred users; or that there's a vulnerability that allows some kid in Malaysia to blow up your printer. So don't re-invent the wheel.
As for your complaint that the Servlet API doesn't support RESTful design - you're missing the point, it was never intended to do that. But there are plenty of REST libraries that run on top of the Servlet API.
An embedded Jetty is also a servlet container. I assume your application includes a web.xml where you define a wicket filter / servlet, the RESTlet servlet and their mappings (at least). So you cannot get rid of the Servlet API (or of a servlet container, even if you embed it), but you can hide it as well as possible underneath your frameworks and into some main() method of your own. RESTlet (or Jersey or any JAX-RS implementation) as well as Spring MVC are all based on servlets, so the Servlet API does support REST pretty well, i'd say.
P.S.
The two approaches do not exclude each other. You can very well work with Jetty during development and then deploy your war into some (non-embeded) container for QA / production. Or... stick with Jetty for production, if that really suits your needs.
Servlet containers often provide a bunch of useful stuff like automatic session management, hot-deploying, frameworks for failover and clustering and so on. It depends on the container, of course, but sometimes these are very useful tools. Sometimes they are not.
EDIT: Just noticed your comment about hot-redeploy. Yes, sometimes the containers are buggy and a pain to work with, and they all tend to have their own quirks. Nevertheless, sometimes they do provide some really good stuff.
The in-process Servlet containers are the containers which work inside the JVM of Web server, these provides good performance but poor in scalibility.
The out-of-process containers are the containers which work in the JVM outside the web server. poor in performance but better in scalibility
In the case of out-of-process containers, web server and container talks with each other by using the some standard mechanism like IPC.
In addition to these types of containers, there is 3rd type which is stand-alone servlet containers. These are an integral part of the web server.
if you are having issues with your hot deploy, most likely you aren't cleaning up your external connections or other resources. To handle this, usually you want to implement a listener that will let you know when something is started or stopped.
you should probably in your wars implement something like this (tomcat 6):
public class MyTomcatInitCleanupListener implements ServletContextListener
{
#Override
public void contextInitialized(ServletContextEvent arg0)
{
super.contextInitialized(arg0);
}
#Override
public void contextDestroyed(ServletContextEvent arg0)
{
super.contextDestroyed(arg0);
}
}
for tomcat 7+, you can google "tomcat lifecycle listener"
I am facing the decision to abandon Java EE 5 container to use web container instead (with Spring). According to Interface21 Spring Pitchfork allows elements of the Java EE programming model to be used in Spring. Thus, I get a subset of Java EE annotations inside of Spring container. Since I prefer to maintain compatibility with Java EE this looks as attractive option to me. What is your experience with Pitchfork and what did you accomplish by using it?
No experience with Pitchfork, but lots with Spring. Foregoing EJBs hasn't been a problem. POJOs have been more than adequate.
Two other alternatives to consider:
You can use OpenEJB with Tomcat if you need EJBs, want to stick with Tomcat, and don't want to switch to a purchased or open source Java EE app server.
You can try Spring dm Server with OSGi. Eat the shell and the egg - go all the way.
I use pitchfork for unit testing EJB3 and JPA components outside of the container and it works really well. I can wire up everything I need including a transaction manager, a 2nd level caching provider, etc.