Aaron Evans wrote: > > My goodness, I certainly seem to have hit a nerve with regards to Velocity > (there were a few posts by people who apparently loathe JSPs). ;-) > > Granted I am new to both Velocity and portlet development and I certainly did > not want to start a religious war here. I think we can save that for the M$ > and PHP developers. >
Don't worry, we're not religious here (the proof being that both Velocity and JSP *are* supported by the engine :). This is mostly personal prefrences of different developers that have evolved based on experience. But I think it's interesting to discuss the pro and cons of the different technologies that are used in Jetspeed. > But I can tell you that having worked with java web apps over the past 10 > years I haven't really run into any frustrations from app server to app server > using JSPs (since the emergence of J2EE) and the frustrations you list > above (eg. classloading, structure of WAR files, etc) I have not found to be > a problem. I have found that if I keep my applications to spec, they will run > in any J2EE environment without a problem. > All the things I've listed have bitten us in Jetspeed 1 over the last 5 years ever since we've decided to support JSP for views (in the very first releases only Velocity was available). Also, note that portals and especially JSR168 portals are tricky applications when it comes to classloading and in general we're stretching the servlet API to its limit (for example: parallel rendering of portlets with JSP views is not possible according to servlet spec 2.3 (haven't checked 2.4 yet) because you'd have to invoke your JSP servlet on a different thread that the main request thread). > With regards to dynamic profiling and personalization of content, I have been > doing this for many years using JSP for the presentation layer in combination > with other technologies and again, I haven't run into any problems there > either. > I agree there are many ways to handle this requirement with JSPs but you can't use JSPs as a script snippet as you can with Velocity. > You say the compelling reason to use velocity over JSP for core components is > because they are text resources instead of compiled servlets. I would think > it would be the opposite. I would think that you would want the components > that are called most frequently to be compiled resources already loaded in > memory thereby avoiding disk contention and reducing processing time. But > then again, I am new to velocity and so perhaps I am ignorant to it's caching > capabilities. > You have some caching capabilities but you are right that there's a performance cost to using velocity compared to JSP. Whatever our personal preferences are, we're going to support both technologies: Velocity because we like it and think it's the right technology for the problem we're trying to solve and JSP because there's a user demand for it. Since it's incredibly cumbersome to implement everything twice, we would need someone comfortable with JSPs to reimplement the Velocity view components and tools as JSP pages/tag libraries and willing to maintain them other time. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
