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"
Related
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.
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.
I'm just trying to get started with Java EE and related concepts. However, I'm having some trouble understanding the relations between some technologies and the roles they play.
As far as I understand, a Java EE Servlet is a Java class that runs inside a server, and generates responses to requests (typically HTML responses to HTTP requests, though Servlets can theoretically serve any protocol).
My questions:
As far as I understand, I can either write a Servlet class directly, or I can use some technology like JSP or JSF, which will then generate/provide a Servlet for me. At any rate, the Java EE web container (e.g. Apache Tomcat) where I ultimately run my app will only see Servlets, and will not care how they were created (so Servlets are kind of a low level plumbing). Is that true?
If Servlets are kind of low-level, is there any reason to actually use Servlets directly? I have seen many tutorials that explain how to write a Servlet, but that seems rather unpractical. Is there any situation where writing a Servlet directly is better/preferred to using JSP or similar?
Finally, Servlets need a server to run in (e.g. Apache Tomcat). When reading about servers in that context, I've seen various names such as (Java EE) web container, or servlet container, or JSP container, or just Java EE server. Do these terms all mean the same, or is there a difference?
Thanks for helping me get started!
When not using a MVC framework like JSF, Spring MVC, Struts, etc, you still need a servlet to do the basic request/response controlling job. The JSPs -while under the covers indeed being compiled to servlets- should be used as view only, not as controller.
I think your confusion is caused by the relatively huge amount of low quality tutorials about servlets where they are been used to print plain HTML by out.print() statements. This is in view of MVC utterly wrong. I'd suggest to start at our wiki page: https://stackoverflow.com/tags/servlets/info
JSP and JSF are presentation-layer technologies. While it is true that JSP's are compiled into servlets, and that you can even write plain Java code inside of a JSP, doing so is extremely bad coding style. In general, your JSP files should not contain any Java code, and should not do things like query your server's database or directly inspect request parameters. All of that should be done in a separate Servlet (or if using a web framework, then your framework's abstraction of a Servlet) prior to hitting the JSP.
In the typical case, coding up a Servlet for every request you want to service is not practical. Most Java web frameworks completely abstract away the Servlet interface so that you can build a complete webapp without ever directly implementing a Servlet. However, there may be occasional unique cases where it is most effective to bypass a web framework and provide a Servlet that provides some special-case functionality.
They're pretty close to the same, really. All of them are servlet containers. Some of them may also include other Java EE features beyond servlet support. Being a servlet container does not guarantee support for additional Java EE features, but being a Java EE container does guarantee support for servlets.
When the container loads the servlet, no, it won't care much where it came from. That said, different containers handle this differently when it comes to things like dynamic loading and stuff like that, but I wouldn't worry much about it.
Servlets are low level. They're the base abstraction upon which all of the other Java EE web frameworks are based. In the "real world", most of the time, people will use some higher level framework rather than a raw Servlet.
That said, Servlets are still useful when you actually want to get to that "bare metal" (well as bare as Servlets get) interface to an HTTP request. For simple things, it's just easier to write a Servlet than stand up a bunch of framework jars and such.
As far as containers, the distinction is basically Java EE server vs Servlet container or server. Tomcat is NOT a Java EE server, it only handles the web portion of the Java EE stack. To confuse things, Java EE 6 now has a "web-profile", which is basically the Servlet stack, but whereas before a Servlet container couldn't be consider a "Java EE Server", now it can be a "Java EE Server - Web Profile".
Yea, I don't know what it means either.
The key difference is that the Servlet containers (Tomcat, Jetty, Resin) don't come bundled with the rest of the Java EE stack (notably EJBs), but have several other components that are part of the overall Java EE stack.
If you're just getting in to Java EE, I would pick a full boat container (like Glassfish) since a) you can, b) it's easy (GF is trivial to setup) and, c) you won't have to second guess what is or isn't included in your container vs whatever you're reading about requires. GF will have "everything" that is Java EE. It won't have Spring, for example, as that's not Java EE, but if it's in your Java EE book or web site article, GF will have it.
Later you can choose when you want the full kit or just want to use something like Tomcat or not.
A lot of frameworks use servlets under the covers, but abstract them away from the end user. The idea is that servlets themselves are very low level, and the frameworks provide useful abstractions that allow the developers to focus on application design and business logic. I tend to agree with that, but there are hardcore developers who like to work at the servlet level.
Knowledge is power, to answer your second question. So its a good idea to know what servlets do; it can only help. If you ever need to augment your underlying framework, you might find yourself working at the Servlet level - you might do this to debug issues as well.
Servlets do run in servlet containers. There are technical distinctions between a servlet container and Java EE containers. You can have the former without the latter, but you can't have the latter without the former (I think). Servlets are one part of the Java EE stack. Other parts are things like JMS (messaging) and JMX (management extensions), among others.
The frameworks like JSF, JSP, Struts etc internally depend on the servlet spec. These frameworks are built on top of servlets only.
Hi
I want to design and develop a big enterprise application using just
GWT in client side.
I want to break this enterprise application into parts and I call each
of them a module (or bundle or portlet or whatever!).
These modules might have relation with each other and might call some services that
exists in other modules (in both client and server side).
The problem is, These modules must be Designed , Developed, Compiled
and Deployed Independently and Dynamically and they will be placed and
shown together in one context on the client and the dependencies
between modules should be manageable (in both client and server side).
What can I do? What kind of technologies I can use to build an enterprise application like this?
When you develop an application that is not divided into parts (In the way that i mentioned) you can easily deploy your application after building your project, but when you change just one form in your application you have to build the entire application again, and deploy the entire application.
In this application I cannot stop the server to deploy the application again, I want to change and deploy that part of application that is needed to be changed not the entire application!!!
Of course I have searched about the way that I can solve my problem!!!
I have found that I can use OSGI on server side because it provides modularity at software construction level and helps me to manage life cycle of modules and many other benefits that you know!
And I have found that I can use Gadgets on client side.
What do you think? Are they good choices?
If they are good choices, how can I start? I know that we have different kinds of implementations of OSGi, like Apache Felix, Eclipse Equinox and Knopflerfish. Which one is good for this choice?
How GWT and OSGi can be integrated? How can they interact with each other?
Unfortunately what you want to do is not fully possible with GWT.
OSGi is a modularity solution for Java, or more accurately the JVM. A GWT client application does not run on the JVM, it runs on the browser in a JavaScript environment. Therefore OSGi cannot be used to create runtime-assembled modular GWT applications.
A GWT application can be modular at the source level, but the modules must be assembled into an application at build time. The resulting runtime is monolithic.
However, it's perfectly possible to use OSGi to host the GWT servlets, and you can use the full power of OSGi runtime modularity on the server side.
As an alternative you may want to look at Vaadin. This is a web framework that uses GWT to provide widgets, but the logic of the application runs on the server. As a result, it does support full runtime modularity through OSGi bundles. There is a cost with this approach though: your web application is quite chatty, with lots more communication going between the browser and the server than in GWT or in a traditional web application. It's possible that this approach will not scale to very large numbers of users.
As for whether to use Equinox, Felix or Knopflerfish... it really doesn't matter. Stick to the specification, and you can easily switch between implementations.
I did just this two years ago: OSGi and GWT for no downtime deployments of project modules.
Verdict: Don't do it unless you really must.
In short, OSGi is a beast and retrofitting an existing application for it is far from trivial. You're no longer making .war files (.ear now) and can't use the standard jars and Maven repositories you used before. Now everything needs to be a bundle. Trouble is, a lot of stuff (GWT, Spring, tons of libs) are not bundles! And you'll need to find them in an enterprise bundle repository or, even more fun, start rebundling 3rd party sources them yourself. Better yet, telling the other devs to rewrite everything that uses their favorite lib because bundling it would be too complex.
The GWT part didn't take that much work. The way contexts for modules were handled in gwt-servlet had to be modified so each module could find it's context on the server. We also had to make a way for most of the GWT services to register/unregister on load and a discovery service so they could know who else was out there.
Now the other pain: project explosion.
Let's say you had 20 modules you wanted to deploy independently. Well, to start with they're probably more coupled than you'd like, so better spent a few weeks breaking them into independent Maven projects and pushing common parts to a lib project. But now, you've got tons of dependencies to keep track of. When someone tweaks your lib project, do you need up upgrade every project or just 7 of them? In the classic stop the world deployment, you only had one version of all your code. Now, you need to decide if that forgot password form being upgrades will require you to also upgrade your index page module. You'll have a ton of version numbers to make up and keep track of. In our case, we quickly had 55 Maven projects building all the time in our CI server. This meant some checkins could trigger 55 builds. Eek.
Finally, JSON interfaces.
We used GWT RPC. It's magical. Write an interface and everything just works. It's also serialized and gzipped over the wire too. Awesome. But, the serialization policies depend on object and string lookup tables that are built at compile time per module. So, project A cannot RPC to project B. Boo. We chose to use JSON due to the graceful degradation, that is not failing when new unrecognized properties were present on objects. This means you'll again need a way to keep all the backend service calls coherent in the versions of the JSON they are expecting and can handle. Better simulate that live upgrade beforehand too.
So, final word: possible, but why? Do you really need OSGi to hot deploy modules because you're running a 1000% uptime business critical application? Or does your boss/architect just refuse to accept that 99.999% is good enough? You probably don't need that uptime and can achieve nearly 100% uptime with a good proxy to let you take instances in/out of the balancer pool. Also, don't forget that even if you can upgrade your projects live on the fly, I hope you've got a way to upgrade your database on the fly without dropping a single transaction.
I think you are setting yourself for more headaches than it is worth.
I would go with deploying the whole thing at a pop. If not you will end up with mismatched pieces of the application that are out of sync with each other. GWT has both Client and Server components and they need to be deployed together. If you have a zero downtime policy then you probably have load balancing in place.
I would use the load balancing software to deploy the new version of the app. Turn off one side (by diverting all traffic to the other side) deploy to it, do a quick smoke test, switch all traffic to the new side and repeat with the old side.
At the moment, I have lot's of Java which does all kind of nifty stuff and I'm happy with it. The code is command line driven which have been great so far, but I recently decided I want to make the functionality available through web-services. Since my is complex and I'm happy with the way it's written , I don't want go through the pain of porting it to other languages. So I set out on a google journey to find out what web servers exist (on a Linux machine, though it's interesting to hear the answer without that limitation).
From what I could find, it seems that there are two viable options: Apache Tomcat and Sun Java Server.
What are the reason to choose one on top of the other? what are the strength of each and what are the weaknesses? Or, perhaps, there is a third one which is much easier, flexible and less cumbersome.
Anyone?
Easy, flexible and not cumbersome, that would be Jetty, but also Simpleweb might be useful. You dont say much about your software so i'm not really sure, but for a command line program, I don't think you need all the JavaEE stuff.
The mainstream servers are these.
I think the Apache Tomcat vs Glassfish (Sun Java Server) discussion is irrelevant for your needs, any would do.
There are many containers for Java web applications, they all have their own strengths and weaknesses. If you're looking for a container to support a business application, you should probably take a look at how they differ and work out which suits your business and IT drivers.
The key thing is that they all support the servlet specification - your webapps can run in any of them - which means you can change your mind easily. Some of them will also support more of the Java Enterprise Edition specs, so may be too heavy for your needs.
If you're just getting started, I'd suggest Tomcat. It's basic, but it's reliable, quick to run and start up, and it's got a really easy web-based webapp deployment interface.
Your question is actually a bit too ambiguous and wide. You can in fact run Java code at any machine you like, regardless of the language you programmed the webbased interface in. You can for example create a PHP based website which interacts with a "backend" Java application (the "command line application" as you call it). The only requirement is to have a JRE at the server machine. Then basically everything as web interface suffices: CGI, PHP, ASP, Python, etcetera, you name it. As long as it has access to the underlying commandline runtime, which is in the PHP example to be done by exec().
But Java, actually Java EE, also provides a web application programming interface: the JSP/Servlet API, the web component of the large Java EE API. This make integration with the "commandline Java application" much more seamless. You can basically just put your application in the classpath and import/access/use it in a Servlet class the real Java way:
YourApplication app = new YourApplication();
Result result = app.doStuff();
// ...
To be able to run JSP/Servlet (JSP is at end actually also a Servlet), you need a concrete implementation of the Servlet API (the whole Java EE is just an abstract specification). Apache Tomcat is good to start with, the other popular alternative being Eclipse Jetty. Those are 'simple' servletcontainers which implements the Servlet API, with Jetty being a more embedded approach of it (you can configure and run it as a "plain vanilla" Java Application). But if you need to support/cover the other aspects of the Java EE API as well, then you need an application server, such as Sun Glassfish or JBoss AS (both which by the way uses Tomcat as the servletcontainer part).
To learn more about JSP/Servlet, I can recommend the Coreservlets.com tutorials.
Apache Tomcat should do good.
The standard concept for running code inside a web server is the "Servlet API" from Sun.
Essentially it provides a few interfaces which the web server uses to invoke your code, and defines how the web server should behave. This allows you to write very generic code that can run in a variety of web containers which implement the Servlet API. See the Wikipedia article for details - http://en.wikipedia.org/wiki/Java_Servlet.
They come in all sizes too, depending on your needs. Some small enough for embedding in your own application, some very big. The servlet API allows you not to care.
For a beginner, the quickest way to get up and running, is to download the full version of Netbeans which includes full support for doing this kind of work, and has a built in servlet container.