velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Weinstein <>
Subject Here is a very good velocity documentation tool
Date Thu, 05 Sep 2002 17:18:27 GMT
RE: Experiences made by porting a JSP based application to Velocity (with
Struts and Tomcat)

Here is a very good velocity documentation tool.
It is like javadocs for velocity.

I encountered a bug when using it but perhaps given the interest bugs can be
fixed and features added.

Just download and use is simple

java -jar velocidoc-app.jar -s "source directory" -d "destination directory"

Remember to look at docs as you now must comment your code
(see docs for format)

-----Original Message-----
From: Tom Bednarz [] 
Sent: Thursday, September 05, 2002 7:30 AM
To: Velocity Users List
Subject: Experiences made by porting a JSP based application to Velocity
(with Struts and Tomcat)

I have ported a quite big Web Application from JSP to Velocity and Struts.
Some weeks ago (or even months) I promised to provide some feedback here.
After a successful rollout in production here my feedback.

I started the web application about two years ago and used jRun as servlet
and jsp container. I was porting an application written in C++ (using
Microsofts ISAPI). The goal was to replace Microsoft RPC by CORBA and use
Java technology on the web server instead of C/C++ API's on a web server.
Java Web Applications are much more portable then C/C++ code which is
dependant on the OS of the web server and the web server itself. To reach
more flexibility I was even willing to accept a certain performance penalty.

The specification of JSP at that time was 0.9x and therefore not finally
released. At that time the technology was quite new and nobody was talking
about MVC etc. I had implemented some servlets with 'controllerish'
functionality. However when I was looking at my JSP files they contained a
lot of Java code cluttered with HTML and JavaScript code.
The application was growing constantly over the time and it became more and
more difficult to maintain this 'big beast'.

After almost two years in production, it was again time for a complete
redesign. This was at the beginning of this year. Now it was possible to
implement a proper MVC design quite easily by using libraries such as
STRUTS. I was also looking after a new servlet engine and decided to use
Tomcat 4. The support is much better than the one for the commercial product
jRun. Bugs get usually fixed faster and I had no need for built-in load
balancing and clustering features.

The other important question was: shall I continue using JSP or should I
take something else like e.g. Velocity. After looking at JSP in more details
I recognized, that this would mean the intensive use of tag libraries. But
these libraries are like a different programming language. You can get a lot
different libs and almost every servlet container vendor offers its own tag
library which is very nice to use with a specific container but not very
portable. Also it means, that a Web developer needs to learn this syntax
first. It did not really convince me and I looked for alternatives. APACHE
is always a good source for good, stable and portable code. Thats how I
found Velocity and decided to give it a try.

After all, I must say, it was a good decision. The usage is quite simple and
allows a direct use of Java objects by using public members (or getters and
setters). It is quite safe because a Web Designer (who is usually not a very
experienced C/C++/Java programmer) cannot write code that can crash an
entire server. A good exemple are endless loops that create new objects
until you get an out of memory error. With Velocity you cannot do things
while ()
    BigObject b = new BigObject();
and forget the break condition. With the foreach construct offered by
Velocity you cannot run into this problem. This and other things make the
use of Velocity quite safe.

Additionally it allows a good separation of 'view code' and business logic.
The language itself is simple and every Web Designer who writes JavaScript
code will also be able to write Velocity code very quickly.

One big issue for me was performance. After being in production for more
than two months I got only positive feedback from users. They all said it is
faster then the previous version. There are every day between 300 and 500
users concurrently using the application in a large enterprise network
spread all
over the country. In general I must say that server-side Java applications
perform very well if you spend enough memory to the VM and of course have an
eye on performance when coding. Once the code is running from memory it is
nearly as fast as native code (C/C++).

Another important thing is stability. So far the application seems to be
rock-solid. It has never crashed nor had the application to be restarted. My
tomcat 4.0.3 runs under W2K. The java business logic is quite complex since
it retrieves data from a database server and several CORBA servers. It
generates output in HTML and Excel. For the latter I use POI. It all works
very well.

Issues - things to be improved:

One problem with Velocity is documentation. Of course you can generate
JavaDocs out of your business logic classes. But how can you tell a Web
Designer, which objects are available where (in which context). The only
method I currently know is to write a HTML index page with some explanations
yourself (manually). Some improvment here would be helpful.

An other problem is debugging. I am currently using JBuilder 6 Enterprise to
develop all of my Java code including web apps. There is great support for
debugging JSP's and servlets. It is not possible do get something similar
for Velocity (at least I don't know of any tools). But since Velocity is
really simple to use, a developer can write almost bug free code quite from


Velocity, Struts and Tomcat are very good alternatives to expensive
commercial products. It is sufficient for a majority of situations where you
use web applications, even for commercial products. The source is available
and if you are missing something, it is possible to add it, or fix a bug
yourself or with the help of the community if it is a real show stopper. I
am convinced, that the Jakarta tools and software has the same solidity as
the Apache Web Server, the most used HTTPD in the world. With the experience
I made I would say: for dynamic web content go with Java, go with!


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message