Archive

Posts Tagged ‘Tomcat’

Creating an online service – getting started

November 5, 2012 4 comments

In the previous post of this series, I talked about the different technologies we’ll be using and the sample project which is freely available, in this post we’ll cover the basics of setting up a functional development environment, one which will allow you to develop and instantly deploy your code to production so it is available to the rest of the world.

I think that the hardest thing about starting a new service for the first time is, well, getting started.  If you’re a seasoned developer, you’ve done a couple of things in your life, maybe even led some projects, you feel you can do anything.  But when starting out on your own, you are faced with a challenge you haven’t faced before.  In most cases, even as a fifth or sixth developer at a startup, there’s a skeleton on which you work.  Somebody already setup the framework, built the necessary scripts, setup the build/deploy process, created the minimal classes.  Your job is now to add the functionality, possibly adding new infrastructure that was never there, but most times there’s something to work on top of.

For a completely new service there’s nothing.  You need to download the IDE, set it up, configure your application from scratch, deploy it somewhere (locally or all the way to production), and make it work.

You can check out my post on some of the tools we’ll use just to get a general idea of the different stuff you might need to install at different stages of your project.  One thing to notice, all of the tools I’m going to use in this series of posts are free, open source tools, or those that are free for use by small startups which are just getting started.  You might need to pay for it at some point when your project grows, but not right now.

You’ll need to do the basic stuff of getting an OS (virtual or real, preferably Unix based, I use Mac OSX, but Ubunto is a good choice for development as well), installing JAVA, a basic text editor, and some kind of image editing software (you can get adobe photoshop for a free one month trial, more than you’ll ever need for starting out).  I use Chrome for all my browsing, if you’re on Windows you might still be using IE, but as it is no longer the most popular browser, I suggest switching to Chrome for the initial testing stages of your work.

So once you have all those setup, you’ll need an IDE.   You can checkout my short post on choosing an IDE, I personally believe that for a startup Eclipse is more than enough.  I use “Eclipse Java EE IDE for Web Developers.”, you should get some plugins installed, at least EGit (git support) and m2e (maven support).

Next step is to get source control software, I use GIT and the Basic Service project is hosted in a GIT repository on Google code, but Subversion is a decent choice as well.  After that, install Maven, you’ll use it extensively.  Last thing you will need to go through this tutorial is SSH, this will be used for deploying your work to production (cloudbees uses SSH for its repository communication).  Note that I’m using Cloudbees as the git repository, it’s also possible to use GitHub and run from there but we won’t cover that right now.

So now you can checkout stuff, and open it in your IDE, that’s cool.  You might be tempted to install an application server like Tomcat, and that’s ok, but it’s not really needed.  Jetty is a very good application server which you can use directly from your IDE and it will automatically update your project as the source changes, and you can run it using project configuration only (maven FTW).  We’ll get to that later, for now, let’s leave Tomcat out of the equation.

At this point, the best thing for you to do, is watch a video!  Not just any video, you should watch this one.  This is one of the most useful tutorials I’ve ever watched, it will take you from (almost) zero (where you are at right now or at least where I was when I started) to 100 (a fully operational, continuously deployed project) in 30 minutes (actually 26).

Come back when you’re done (meaning you followed the instructions, setup everything, built and deployed it to production, and it works for you).

So now you’re a couple of steps further than you’ve been when you started reading.  You already have your work environment setup, you’re compiling and deploying an app to production, you even have it saving stuff to a production repository.

Next you’ll want to setup your local environment so you can test stuff locally.  You’re almost ready, just need to install MongoDB so you can point your application to your local DB instance (it will also work against the instance on Cloudbees if you prefer, but I’d rather have my local instance which I can play with and explore).  So once that’s installed, try to get it running and point your app to use the local instance.  When that’s done, if you’re on a laptop like me, it means you can work from your favorite spot (on the beach?) and not require an internet connection to develop stuff.

Great, we’re ready to move on.  The next post will talk about getting the Basic Service project over to your development environment, and setting it up so you play around with it and learn the technology involved, or even start developing your own online service.

Using REST in cloudbees – not so simple

September 13, 2012 2 comments

Well, this one is going into “things that can drive you mad” for sure, as it took me a couple of days to reach the inevitable conclusion that I have to give up 😦

So here’s the thing:  you created a RESTful application, using the proper GET/PUT/POST/DELETE headers where appropriate, it works great on your local Jetty/Tomcat deployment, but when you try to run it on the cloud, it fails.  After much testing and debug prints, you find that when using PUT & DELETE the request gets there BUT the body embedded  parameters do not.

If this sounds familiar, you’ve got a problem.  As it is right now (Sep. 2012), app servers are not obligated to parse parameters delivered with PUT/DELETE requests if they are sent in the body (like in POST), because the standards to do not define that behavior.  Some will do it, some won’t, and there’s no one to complain to!

You can, of course, do all kinds of work arounds like setup a filter to parse the request on your own, or even do it in the methods, but I hate work arounds, they have a tendency to fail at some point when things change.

In the end, my solution to cloudbees deployment was to get rid of PUT altogether, and use DELETE only in requests which do not need anything in the body.  While this will work, I am unhappy with this solution, to the point of thinking about going to EC2 and not working with Cloudbees!  My applications should work as required, and should not depend on the hosting platform’s limitations!!

UPDATE!

Following Michael’s comment (see below), I gave this item some more attention, and finally got it to work!

As it turns out, it IS possible to use PUT and DELETE in cloudbees, you just need to know how to make it work.  Since PUT requests are not parsed like POST, there is a trick to make the application side parse it correctly.

The way I did it, is by using @RequestBody to pass the data to my dto on the server side, setting my content type to application/json;charset=UTF-8 on the jQuery side, and using JSON.stringify to set the content correctly so it can be parsed by my JSON converter.

So, my method looked like so:

@RequestMapping(value=”{id}/status/read/}”, method=RequestMethod.PUT)
public ResponseEntity<String> markRead(
@CookieValue(value=Constants.AUTHENTICATED_USER_ID_COOKIE, required=false) UUIDValidatedString userIdCookie, 
@PathVariable UUIDValidatedString id,
@RequestBody TestDto test
) {

}
 
and my ajax side looked like so:
 
function internalMarkMessageReadStatus(messageId) {
var obj = new Object();
obj.test = “true”;
$.ajax({
url: ‘/api/messages/’ + messageId + ‘/status/read/’ ,
type: ‘PUT’,
dataType: ‘json’,
contentType: “application/json;charset=UTF-8”,
data: JSON.stringify(obj),
success: function(response) { 
}
});
}
 
The DTO is just a simple POJO:
 
package com.tipabout.dto;
import org.codehaus.jackson.annotate.JsonAutoDetect;
@Document
@JsonAutoDetect()
public class TestDto {
public String test;
 
public TestDto() {
}
 
public String getTest() {
return test;
}
 
public void setTest(String test) {
this.test = test;
}
}
 

Post 5 – The basics – Software for SAAS development

August 20, 2012 1 comment

The following is a list of programs I’ve played with.  It is by no means a complete list of the software you’ll need, simply describes some of the stuff I’ve looked at.

 

SVN repository: Subversion source control, used to manage your code versions.  Your life can not be complete without having one of those, be it SVN or Git (see a separate post on the topic)
Tortoise SVN client: A very good and free subversion client, don’t look anywhere else.  I know there’s one for windows, don’t remember seeing one for Unix.
Maven 2: THE right way to manage your java dependencies, run your tests, and even manage the whole product packaging life cycle.  Downloading JAR’s yourself takes time, you need to look for them, and upgrading a version is a pain, not to mention managing the different dependencies.  With maven, you simply say what your project needs, and maven takes care of it.  It’s as simple as that.  If you’re building a product from scratch, don’t even think of working any other way.
Maven Artifactory: used to host maven artifacts.  When maven builds your war, you can host it in your artifactory for easy access by developers, production, or other projects using maven which depend on your project.
Tomcat: one of the best application servers out there.  Very light weight, works on all OS’s, old and mature, and constantly under development.
Jetty: Another very good app server, I use it mainly as a maven plugin because of a very nice feature it has of real time resource reloading, which means I can change a JSP or even a class and it will immediately reload it and reflect my changes. 
Apache web server (httpd): One of the best Web servers out there, I’d say it’s the Tomcat equivalent of a web server (some will say it is the other way around, but w/e).  The question of whether or not to use a web server as an app server front end is too deep for this blog post, but if you do decide to use one, Apache is one of the two top options.
ngineX: The other top web server on the market, said to be x50 faster than Apache.  It is still rather new, but quickly making its way up, with usage levels raising.  I haven’t looked at the statistics but if the trend continues it will eventually take over and become #1.
Teamcity: A Continuous Integration server by Jetbrains (if the name sounds familiar it should, it’s the same guys who made Idea).  Considered to be one of the best of its kind, it is free to use for small startups with limited deployment requirements, and will cost about $8k for standard use.
Jenkins: Built from the ruins of Hudson, the open source Continuous Integration project taken over by Oracle after their Sun acquisition, this is considered the best open source CI project, used widely by many.  A while back I had to choose between Jenkins and Teamcity, we did a wide research  on the subject (also looked at Bamboo, from Atlassian, the guys who also make Jira).  We finally went with Teamcity after realizing that support costs for Jenkins will be around the same price that Teamcity costs, and Teamcity is a little bit better in some ways, with a better interface and smoother integration with Jira.  But honestly, if you don’t need the full support package, Jenkins has all you need to get going, and it’s free.
MySQL DB: well, not much to say here, free, small, easy to use and manage using PhpMyAdmin.  Unless you want to spend millions on Oracle, this is a very good choice for SQL based databases.
PhpMyAdmin for MySQL administration: Used for administrating MySQL.
Eclipse: The best open source IDE out there, with an incredible number of plugins and fully featured to the level that it is a fair competitor to Idea, the #1 IDE on the market made by Jetbrain.  See a separate post on this subject.
Idea, Community Edition: For those of us wanting to save some $$$, this version of Idea has almost all you need, the limited functionality which makes it a little bit of a problem to use for development of certain types of applications is server support (can’t officially run it from Idea, you need to do it on your own, although you can run Tomcat as a standard program (not as a “server”) and so if you use maven or ant to deploy your war and configure it correctly you can have it run within Idea, and even debug.  Haven’t found a way to overcome the JSP limitation, so if you need that one you’ve got a problem.   If you want to buy the full version, they have a “personal” license for 200$, which is more affordable than the 500$ they ask for  in their so called “company” license.
I’m a big fan of Idea, can’t say I’ll spend 200$ on it for now though.  Perhaps when I get some funding 🙂
Puppet Enterprise 2.5: For those of us fortunate enough to need deployment to a large number of servers, PuppetLabs has a fine product for automated deployment.  I know there are open source products out there which are pretty good, haven’t done the research on that one yet.
SpringI’m not going to talk too much about Spring here, there are very good resources out there and springsource have a fine web site you can explore.  
Besides, I have a feeling I’ll be talking about it extensively in future posts.  For now I’ll just say that if you’re building something from scratch, taking Spring as your container will make life simpler and force you to build your code in a way that is organized and supportable in the future.
Tiles 2: Tiles (2) is a framework for building web pages from fragments, so for example you can have a header, a body, and a footer each in their own file, and within each you can inject different content based on what you need.  I have a feeling I’ll post something on this subject later, since I’ve done my research trying to decide between Tiles, Spring MVC, and Struts.  I eventually picked Tiles 2, more on that later.
jQuery: A very popular Javascript library built to make life easier when dealing with the different browsers on the market.  Writing browser compatible javascript code is difficult, and requires extensive testing, if you can limit yourself to a 3rd party library which promises full browser compatibility, you’re set.  It also has a very wide range of plugins to do really cool stuff.
MongoDB: The trend nowadays is moving away from SQL databases into the so called “No-SQL” DB’s.  Mongo is one of those light-weight No-SQL databases which lets you store your data as a “document”, actually in a JSON format.  Compared to its size, this database has really strong capabilities.
Logback: Once upon a time there was log4j, a very popular logging framework for java.  Then the creator of this framework came up with slf4j, an interface for using logging engine in a standard way.  And finally there was Logback, the latest from this very capable developer, and what you should now use to do your logging in java.