velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Sidler <>
Subject Re: Experiences made by porting a JSP based application to Velocity (with Struts and Tomcat)
Date Thu, 05 Sep 2002 15:04:56 GMT
Hi Tom,
This really great feedback. Thanks a lot for your detailed report.


Tom Bednarz wrote:

> 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
> like
> 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
> the
> beginning.
> Conclusion:
> ========
> 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
> Tom
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland

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

View raw message