Maven, Eclipse and Tomcat

Following up on my previous post, I went through another frustrating experience trying to develop a webapp that was built using Maven and deployed into Tomcat through Eclipse.

The challenges I ran into were as follows:

1. Tomcat 6.0 supports only Java 1.5 and Servlet 2.5. But, the Java and Dynmaic Web Module facets in Eclipse pick Java 1.6 and Servlet 3.0 by default.
   
2. The Dynamic Web Module facet in Eclipse looks in a folder called WebContent for the web content whereas Maven maintains the web content in src/main/webapp.
   
3. The Dynamic Web Module facet once applied to a project cannot be modified i.e, you cannot change from 3.0 to 2.5 after you discover that your Tomcat will not support Servlet 3.0.
   
4. Eclipse does not provide a way to remove the Dynamic Web Module facet from your project.
   

Before I go into the steps for integrating a Maven webapp with Eclipse and Tomcat, let me first address the challenges of modifying or removing incorrect web facets.

How do I modify the Dynamic Web Module facet for my project ?

In Eclipse, if you try to remove the Dynamic Web Module facet, you will get an error saying "Dynamic Web Module 2.5 cannot be uninstalled". The only way to modify the facet is to first remove it and then reapply it. To learn how to remove it, read the next section.

How do I remove the Dynamic Web Module facet from my project ?

Step 1. Right-click on your project in Eclipse Package Explorer and select Close Project.
Step 2. Open a command-line terminal and go to your project folder.
Step 3. Open the .project file in a text editor and remove the following lines:

Step 4. Open the .classpath file and remove the following lines:

Step 5. Go into the .settings folder and delete the following files:

Step 6. Go back into Eclipse, right-click on your project and select Open Project Your project should now have all facets removed and should appear like a regular project.

What are the steps to integrate a Maven web archetype into Eclipse Tomcat ?

Step 1. I assume you already have a Maven web app in your Eclipse workspace. If not, here are some quick steps.

(i) In a command-line terminal, enter the following command:

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp

You can find out more about this command at Maven - Guide to Webapps

(ii) In Eclipse, select File -> Import ... -> Existing Maven Projects. You will be prompted to select the directory the project located on your filesystem. This should complete the Maven webapp creation in Eclipse.

Step 2. Select your project in Eclipse Package Explorer and select Properties.

Step 3. Select Project Facets in the Properties window and click on the "Convert to faceted form ..." link

Step 4. Select Java 1.5 from the list of facets.

Step 5. Select Dynamic Web Module 2.5 from the list of facets.

Step 6. Click on "Further configuration available..." link below the list of facets.

Step 7. In the Modify Faceted Project window that opens, change the value in the "Content directory" field to reflect maven's target folder.

Step 8. Click OK and OK.

Your project is now both a Maven project as well as an Eclipse Dynamic Web Module project.

If you want to deploy to the Tomcat instance that you setup in Eclipse, just right-click your project in Package Explorer and select Run -> Run on Server. You will be prompted to select your Tomcat instance and the application will be deployed.

If you need instructions on how to setup a Tomcat instance in Eclipse, refer my earlier post at Tomcat from within Eclipse.

If you want to deploy to an external Tomcat instance running outside of Eclipse, you can follow the instructions at How to create a Maven web app and deploy to Tomcat - fast

If you have any other questions, just drop a comment and I will get back to you.

Ciao!

Tomcat from within Eclipse

I just went through a very frustrating time trying to get a Tomcat instance configurable and usable from within Eclipse. As you will realize after going through this article, the Eclipse integration for Tomcat is a very confusing integration. The problem is that Eclipse has no single wizard or form to configure a Tomcat instance.

After an hour, I got my Eclipse and Tomcat integrated the way I wanted them to be. I am sharing some of the initial steps that I had to go through so that you can get a head-start with your Eclipse Tomcat integration.

Step 1. Download the binary distribution of tomcat from Tomcat 6.0.29

Step 2. Just unpack your download and you should be ready to go with Tomcat from the command-line.

Step 3. Launch Eclipse. ( I assume you are already using Eclipse. )

Step 4. Add the Tomcat server runtime environment to your Eclipse workbench.

(i) Click on Window -> Preferences

(ii) Select Server -> Runtime Environments from the preferences pane.

(iii) Click Add and select Apache Tomcat v6.0 from the list.

(iv) Click Next.

(v) Set the Tomcat installation path to the location in Step 2 above.

(vi) Click Finish.

Step 5. Create server instance.

(i) Click on Window -> Show View -> Other

(ii) Select Servers from the list of Views.

(iii) Click OK.

(iv) In the Server view, right-click and select New -> Server.

(v) Select Tomcat v6.0 Server from the list. Provide a name and select the runtime environment created in Step 4 above.

(vi) Click Finish

Step 6. Test your Tomcat instance.

(i) In the Server view, right-click the server that you just created in Step 5 above. Select Start.

(ii) Open the following URL in your browser: http://localhost:8080/.

(iii) You will get a "HTTP Status 404" error message and the title of the page will indicate the version of Tomcat. This should confirm that Tomcat has launched correctly.

Step 7. Configure the deploy path and ports for Tomcat.

(i) In the Server view, right-click the server that you just created in Step 5 above. Select Open.

(ii) In the server configuration view, you can modify the configuration as you wish.

HELP !!! 404 error when accessing http://localhost:8080/

The tomcat instance that we created in the steps above comes with a ROOT webapp that has no content. You may want to deploy a proper ROOT app with the default Tomcat welcome page that we are all familiar with. I like the welcome page because it gives me quick access to the release notes and Apache's online pages for Tomcat.

To get the welcome page, you must do the following :

(i) Click on the "Open launch configuration" link in the server configuration view (see Step 7 above). In the Edit Configuration window that appears, switch to the Arguments tab and view the location by examining the setting for catalina.base and wtp.deploy in the "VM arguments" field.

(ii) Start and stop your tomcat instance. Note: It is important that you do this step before proceeding to the next step because the wtp.deploy directory does not get created until you have started tomcat at least once.

(iii) From the command-line, you can copy the ROOT application from the tomcat installation (see Step 1 above) to the eclipse tomcat server instance (see Step 5 above).

$ cp -R ~/Apps/apache-tomcat-6.0.26/webapps/ROOT ~/workspace/personal_workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/

(iv) You should now be able to access the root app from http://localhost:8080/

HELP !!! How do I configure tomcat-users.xml ?

In the Package Explorer view of Eclipse, you will find a new project called "Servers". Expand the project and you will see the tomcat-users.xml file.

I hope you have saved yourself some time with the help of the above article. Happy coding!

Ciao

Julian Assange interview with David Frost

Don't be evil!

I am not a fan of large multi-billion dollar tech corporations but I am a fan of Google. Here's why:

1. Google tries to balance openness with business goals. While companies like Oracle, Facebook and @9913 control every bit (pun intended) of their ecosystem, Google is still a big proponent of open standards and open source technologies, and Android is probably the best example of this.

2. Google is driven by geeks and not marketing or business minded employees. There is no better example of a geeky employee than Andy Rubin who co-founded Android. Take a look at this tweet from Andy. Which VP of a tech company tweets a unix command ? Isn't that awesome ?

3. Google invests heavily in research both internally and externally and, research is very important for the betterment of humanity. While most tech companies focus on making pretty products for the middle class in the developed world, Google continues to focus on advancements in engineering. Google's self-driving car, research group, labs, scholar and green all drive towards the goal of moving the human race forward.

4. Google has the guts and the conviction to stop doing business in China, a country that doesn't give a hoot about human rights. While other tech companies like Microsoft, Facebook and @9913 continue to court China with the intention of expanding their business empires to its 1 billion population, Google has decided to stick to principles and pull out of China.

Don't be evil
Ciao

'Wikileaks: The Game'

Game courtesy of jeuxjeuxjeux.fr



Via JeuxJeuxJeux.fr

What happened to 'J2EE Application Servers on Desktops' ?

Here is an article I wrote a long time ago (11/2004 to be precise) about J2EE Application Servers on Desktops. It is 2010 and obviously my prediction hasn't come true. While I analyze what might have gone wrong with my prediction, here is the article for your perusal.

---

Nov, 2004
Summary
This article looks at several reasons that make it feasible and often desirable to use server-based software on desktops.

J2EE Application Servers on Desktops - Vijay Mariadassou

Last week, I was overjoyed to read about IBM's plans for Web-based desktop software. The software is part of IBM's Lotus Workplace strategy and is designed to be distributed and accessed through a Web server. The news reaffirmed my long-held belief that desktop applications will, in the not so distant future, be replaced by application server-based software. Server-based software has traditionally been confined to deployments on large enterprise servers. But, as I discuss below, there are several reasons that make it feasible and often desirable to use server-based software on desktops also.

Application Servers are feasible on Desktops

The primary reason for the absence of server-based software on desktops is the resource-intensive nature of server software, also known as middleware. Traditionally, middleware were designed and built to handle large numbers of transactions typical of large organizations with huge IT infrastructures. But, as Information Technology has permeated organizations of all sizes, middleware has evolved to fit into smaller infrastructure. Middleware based on J2EE and .Net are notable in this respect.

The latest breed of J2EE-based application servers like JBoss and Geronimo have highly modularized architectures based on the Java Management Extension (JMX) API that allow them to be deployed with variable sets of modules. Consequently, these servers may be deployed in resource-friendly configurations with minimal number of modules. For example, modules such as messaging (JMS) and transactions (JTS) may be removed without any adverse effects on the normal functioning of the application server. Such configurations make it possible for these servers to overcome any resource constraints.

Also, most modern application servers make use of some sort of resource caching to further optimize resource usage and performance.

Finally, the processing capacity of desktops has been steadily increasing. Thanks to Moore's Law, yesterday's servers are today's desktops. Modern desktops are now capable of handling the many CPU-intensive operations normally associated with application servers. And, the imminent arrival of 64-bit processors in the desktop market will go a long way in guaranteeing this capability.

Thus, it is my belief that application servers are feasible on desktops and concerns about their consumption of resources are unnecessary.

Application Servers are desirable on Desktops

Application server-based software is desirable for several reasons, which let us discuss below.But, before we go into the discussion, I wish to make a disclaimer. There will always be certain applications like games, music editing and animation software that are very sensitive to response times and will remain the domain of Desktop software. For such applications, Desktop software is preferable to middleware-based software because they are optimized for the operating system and the hardware hosting the software. For most other applications that are not as sensitive to response time, middleware-based software is desirable.

An important advantage of using middleware-based software on the desktop will be the reduced impact of viruses in the event of an attack. The devastation caused by the current wave of virus attacks and Internet worms is attributed primarily to the monoculture (read Windows) that exists on the desktop. The choices that both commercial as well as free J2EE application server vendors provide will bring diversity to the desktop and rid it of this monoculture.

In addition, middleware-based software are inherently more robust and secure than traditional Desktop software. Middleware vendors have invested millions of dollars in ensuring their middleware are scalable, reliable and secure for highly sensitive industries like the financial industry. And, software that operate within the secure environment of a middleware are likely to be less vulnerable to security attacks than those that operate out of this secure environment.

Another advantage of middleware based-software is the cost advantage it offers to the vendor and, consequently, to the user. Since there is no difference between a middleware platform deployed on a desktop and that deployed on a large Enterprise Server, vendors can move their existing Enterprise applications to the desktop at no extra cost. Vendors can also leverage the huge talent pool of J2EEdevelopers available in the Enterprise Application industry to build applications for the desktop. These developers do not have to be trained on the myriad Operating System APIs.

Finally, as users spend more time online, they will find it Web-based interfaces more natural to use than traditional desktop interfaces. A case in point is the growing popularity of services like Ofoto and Yahoo! Photos that are replacing the traditional photo albums on the desktop.

Over The Horizon

I see IBM’s recently announced plans as foreshadowing where we can expect to see the first breed of middleware-based desktop software emerging – the workplace. Workplace software is expected to benefit the most from the security and cost advantages of middleware-based software.

---

Ciao

Boycott Amazon and PayPal

You probably have heard about WikiLeaks and the cowardice of Amazon and PayPal. If not, go to this link for details on the appalling cowardice of these corporations.

I am appalled at Amazon's lack of character. They succumbed to pressure from the political class and decided to drop WikiLeaks. I have been using Amazon for a long time now for buying everything from books to diapers and toys. But, after this latest incident, I have decided that it is not worth doing business with a company that cannot stand for freedom of speech.

I am going to boycott Amazon starting today. I have just removed all Amazon Associates widgets from my blog. I will be shopping for diapers at Costco or Walmart. I will be shopping for toys at Target or Toys R Us. I will be shopping for books at Borders and Barnes & Noble. I will be shopping for a Nook or Sony e-Reader. I will be switching to Google App Engine.

Also, starting today I have decided to stop using PayPal. I have just initiated the transfer of all my money out of my PayPal account and will be removing my bank account from PayPal once the transfer is complete.

Shame on you Amazon ! Shame on you PayPal !

P.S.: I am very proud of Google for standing up for freedom and pulling out of China. Go Google ! Go Android !

Write and read locks in Java

Here's a crude but very transparent way of doing the locking. Note the below code assumes that the implementer will ensure by design that there are NO concurrent writers but concurrent readers i.e., only a single thread will write but multiple threads could read.

int _readers = 0;
boolean _writeWaiting = false;

writeMethod() {

_writeWaiting = true;
boolean canWrite = false;

while (!canWrite) {

synchronized (lock) {

canWrite = _readers > 0 ? false : true;
if (canWrite) {
_writeWaiting = false;
writeToFile;
}
}
}
}

readMethod() {

while (_writeWaiting) {
sleep;
}

synchronized (lock) {
_readers++;
}

readFile;

synchronized (lock) {
_readers--;
}
}

The following code uses Java 1.5 APIs and is a lot more efficient than the above pseudocode. But, it is very opaque. If your JVM implementation has a bug ( and JVMs do have bugs ), the below code could be very tricky to validate and debug.

static ReentrantReadWriteLock _rwl = new ReentrantReadWriteLock();

writeMethod() {

rwl.writeLock().lock();
writeToFile();
rwl.writeLock().unlock();

}

readMethod() {

rwl.readLock().lock();
readFromFile();
rwl.readLock().unlock();

}

Update to post: Edit made on Jan 1, 2011 to clarify the beginning paragraph of this article.