AW: [opencms-dev] On how to integrate OpenCMS and velocity:

[Werner Punz]

<Status Update>

Good news everyone!

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.
But here is a short explanation what has changed.

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.

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.

Well that didn?t work out as expected since the core classes use extensively
privatized instance variables, so a derivation was basically impossible.

So I decided something else which might be the better way anyway since the
code has to be merged into
the Velocity codebase ASAP anyway.
I now simply moved the affected core classes into a opemcms-velocity
specific package and added the necessary methods to the classes.

Following classes were affected:

Velocity
ResourceManager
RuntimeInstance
RuntimeSingleton

They all now have additional methods which blend into the existing
interfaces to pass down an additional object into the Resource loaders.

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)

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.

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.

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.

Thats pretty much it

Happy Sunday

Werner Punz Labor_C
http://www.labor-c.net

</Status Update>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20020407/9e3429b3/attachment.htm>