velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ewan Makepeace" <ewan_makepe...@yahoo.com>
Subject RE: Multiple velocity engines in same JVM
Date Thu, 31 May 2001 06:56:32 GMT
I think that makes perfect sense - I nearly went down that route for one of
my own applications. I have a commercial system generating month end reports
for each of the 70 worldwide offices of a major multinational corporation.
Unfortunately I get requested to tinker with the format and add new data
sections on a monthly basis. There is a requirement to be able to go back
and look at the archive reports/data but every time I modify the data tables
and accompanying software it ceases to be compatible with the older data.
The cleanest/easiest solution I could think of was to maintain separate
databases for each month together with that month's code version to be used
as required. [So far I just backup everything, and store the HTML in the
database instead.]
If Velocity had it's version number as part of the package, wouldn't it
allow multiple installed versions (ie last stable release plus latest
development version) to be both installed and running at once? Wouldn't this
be an advantage?
I am starting to think that all Java software should do this to allow easy
rollback to last known stable version in case of an unexpected problem with
a new version.
Now before you flame me Jon, if this is a really backwards way of
maintaining versions, what is the best way? (Genuine question here, not
being sarcastic).

rgds
Ewan

-----Original Message-----
From: Jon Stevens [mailto:jon@latchkey.com]
Sent: Thursday, May 31, 2001 1:46 AM
To: velocity-user
Subject: Re: Multiple velocity engines in same JVM


on 5/30/01 10:39 AM, "Dan Finkelstein" <dan.finkelstein@emind.com> wrote:

> Just for grins... here's something like what we do:
>
> When we rev our application, we do it in a way that allows us to maintain
> multiple running applications at the same time -- we do this because we're
> in the course delivery business and we want to maintain the exact same
> course experience as what was originally qa'ed, released and certified.
>
> We maintain our revision state as a package name, say something like
> .b1_1,.b1_2, b2, etc, So, we might have package names like
> com.whatever.b2_1.servlets.StartLesson.  This allows us to run multiple
> applications in the same JVM -- it works out very smoothly.  Anyway, the
> singleton design of Velocity interferes with this, since we have separate
> template dirs for each rev -- since we keep not only the class files
> separate but also any required resources.
>
> Does this make sense?
> Dan

In that case, create a classloader and then load Velocity into that specific
classloader. Then have a controller that brokers requests for specific
velocity instances to the right classloader.

Also, I seriously doubt that packages were ever intended for that usage. It
may work for you, but that seems like a really backwards way of maintaining
versions.

-jon

--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Mime
View raw message