<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1252">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.4417.0">
<TITLE>AW: [opencms-dev] On how to integrate OpenCMS and velocity:</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2><Status Update></FONT>
</P>
<P><FONT SIZE=2>Good news everyone!</FONT>
</P>
<P><FONT SIZE=2>I?ve got the proposed revamp of the glue code working (Now that I had finally time to work on it). I will clean it up tomorrow and rework the readmes and then send it to Alex for posting it on the website. </FONT></P>
<P><FONT SIZE=2>But here is a short explanation what has changed.</FONT>
</P>
<P><FONT SIZE=2>Basically the external interface to OpenCMS itself is the same, the glue class is unaltered except that the synchronized now could be removed, in the hope that Velocity itself is Thread safe, which it looks like.</FONT></P>
<P><FONT SIZE=2>My basic idea was to derive classes from the core Velocity classes and add methods which allow the passing down of parameters into the resource loaders, if they implement a certain interface.</FONT></P>
<P><FONT SIZE=2>Well that didn?t work out as expected since the core classes use extensively privatized instance variables, so a derivation was basically impossible.</FONT></P>
<P><FONT SIZE=2>So I decided something else which might be the better way anyway since the code has to be merged into</FONT>
<BR><FONT SIZE=2>the Velocity codebase ASAP anyway.</FONT>
<BR><FONT SIZE=2>I now simply moved the affected core classes into a opemcms-velocity specific package and added the necessary methods to the classes.</FONT></P>
<P><FONT SIZE=2>Following classes were affected:</FONT>
</P>
<P><FONT SIZE=2>Velocity </FONT>
<BR><FONT SIZE=2>ResourceManager</FONT>
<BR><FONT SIZE=2>RuntimeInstance</FONT>
<BR><FONT SIZE=2>RuntimeSingleton</FONT>
</P>
<P><FONT SIZE=2>They all now have additional methods which blend into the existing interfaces to pass down an additional object into the Resource loaders.</FONT></P>
<P><FONT SIZE=2>This passing down of objects only can be done if the resource loader implements a certain interface (should be worked into the base class in the near future)</FONT></P>
<P><FONT SIZE=2>Now since I made progress very swiftly, I also was able to move the rather basic Velocity caching mechanism of the core classes into a cache factory class, so that it now is possible to replace the basic cache mechanisms (aka hashtables) with better cache implementations. This way a possible hook to add the element cache is provided. The downside however is that I noticed in the code that Velocity doesn?t use a singletoned cache but instanced caches so I?m not sure if a central cache is really possible within Velocity, the developers of Velocity should be contacted in this regard. Anway I provided both mechanisms in my cache factory. All a cache now has to do is to implement a very basic caching interface which easily can be provided by every cache implementation.</FONT></P>
<P><FONT SIZE=2>As I said I will send in the altered classes tomorrow and I hope this is a better base to implement Velocity handling in OpenCMS in the near future. But however what has do be done and what is pretty outside of my scope, since I?m not an OpenCMS core developer, is to send the changes once they are finished back to the Velocity team and convince them to integrate these or similar mechanism into their core code. The problem I see currently is that I have altered several core classes in a minor way, and those basically are a moving target. My code works with the latest official Velocity release but that might change in the near future and thus once a new Velocity release comes out the whole changes in these classes again have to be worked in.</FONT></P>
<P><FONT SIZE=2>Ah, I almost forgot, as for performance, there should be no performance hit compared to the former version, on the contrary I expect it to be a little bit faster and better performing in a multi threaded environment which every web based app basically is, thanks to the now removed synchronized method. And thanks to the well placed caches in the Velocity code the whole thing is blazingly fast.</FONT></P>
<P><FONT SIZE=2>Thats pretty much it</FONT>
</P>
<P><FONT SIZE=2>Happy Sunday</FONT>
</P>
<P><FONT SIZE=2>Werner Punz Labor_C </FONT>
<BR><FONT SIZE=2><A HREF="http://www.labor-c.net">http://www.labor-c.net</A></FONT>
</P>
<P><FONT SIZE=2></Status Update></FONT>
</P>
</BODY>
</HTML>