Introduction: Let the debates begin…
What type of Java app server should you choose for your next project? Well, that kinda depends on what kind of app you’re building, what your needs are, what type of organization you work in, and lots of other factors too. Hence the debate. So perk up your ears, and get ready for a showdown.
This blog post continues the Great Application Server Debate series, in which we have already covered IBM Liberty Profile as well as Jetty. Today we’re talking about (arguably the most popular application server) Tomcat and also touching on TomEE. As with previous posts, we will be reviewing the application server purely from a developers point of view.
Apache Tomcat is an open source application server that (in version 7.0) implements the Servlet 3.0 and JavaServer Pages 2.2 specifications, and includes many additional features that make it a useful platform for developing and deploying web applications and web services.
This is the first blog post of a series in which we test-drive application servers from a developer’s perspective, giving our opinion on how they perform through our developer-oriented tests. This is more of a ‘how it did’ than a ‘how-to’. We start our series with a new offering from IBM, the Liberty Profile.
The Liberty Profile is both part of the full IBM WebSphere Application Server image and a standalone download. It’s an Application Server that targets developers needs in an environment where the full WebSphere product is not ideal or appropriate. It was first available in WebSphere Application Server v8.5, released in 2012.
The LiveRebel team is proud to present the latest and greatest release of LiveRebel. Prepare to have your socks knocked off :)
With LiveRebel 2.6 you can rollout code, database and configuration changes in sync, onto a blend of environments with no downtime or overhead. The result: you get the latest version in front of users quickly, without compromising on quality or disrupting user experience.
When we released our Developer Productivity Report last year, it was the first time we asked our respondents about Code Quality Tools.
Code quality tools fulfill a growing need, as our code bases become larger and more complex, and it’s important to try to automate your code checks as much as possible. What’s interesting though, the entire code quality tools ecosystem is kind of meant to complement one another, they are not really competing. This is indicated by the fact that there really isn’t a clear leader in the code quality tools space, although Sonar, which combines all three other tools into a single package, seems to be the most well suited for advanced users & enterprise teams…
Presenting is nerve-wracking. There’s no doubt about it. But, don’t panic! There are ways to make it less so. The key is to be adequately prepared and have a goal. If you know what you’re talking about and have a general idea of where this presentation will and should go, then everything else is the balloon-shaped icing on the red velvet & mint chocolate chip ice cream cake your friends always order for your birthday (which you begrudgingly accept and secretly love)…
Over the years we have been working hard the make LiveRebel the most awesome deployment tool for the Java ecosystem; however, during these years, we have constantly been approached by non-Java crowd, inquiring if it will be possible to use LiveRebel with their PHP/Python/RoR/Perl application. LiveRebel 2.6 (coming on March 13) has your answer, and it’s a BIG YES!
For operations and sysadmin folks, server and application monitoring is serious business. Apps that run flawlessly in development environments may not scale once deployed into production. Although poor coding is easy, tackling performance issues is certainly not. This is why we have a variety of tools for monitoring, detecting and analyzing bottlenecks: profilers, memory and GC analyzers, memory leaks detectors and so on. If you are able to catch and eliminate all performance bugs before the release, great! But this is not always the case. Many web apps go live with performance bugs that exist in stealth until they hit hard….and then what do you do?
Three reasons why I came back to Java and the JVM
- The Java community – an awesome and critical driver maintaining the spirit of open development, collaboration and experimentation in software
- Java tools & technologies – the tools used in Java (from IDEs to code analysis to profilers) benefit programmers more than the tools in other languages, such as C++ & Python
- The JVM (and Java) – the best balance productivity, performance, stability and more better than other platforms available to developers today
So if you feel like leaving Java and the JVM behind, I wish you luck. But be aware that you may find yourself right back where you started ;)
When it comes to Java, most developers either use JUnit or TestNG and Mockito for mocking up your unit tests. JUnit is the established de-facto solution, TestNG attempts to offer additional features needed for Enterprise applications, and Mockito comes to the rescue and offers powerful mocking abilities to your unit tests. But is the JUnit/TestNG + Mockito solution the best one?
For this post, I took some time to play around with another testing framework called Spock. Spock is a test framework for Groovy applications, however as a Java developer I wanted to know how well it did at testing Java code as well. So far, I’m impressed….