You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Dan Finkelstein <da...@emind.com> on 2001/05/25 22:06:01 UTC
Multiple velocity engines in same JVM
Hi --
Our application uses Velocity in two (and maybe more) distinct ways, each
of which we want to initialize and run separately than the other. For
example, the resource path needs to be different between the two. Also,
other property settings differ.
The Velocity class, being a singleton, is limiting because it means that
whichever of our two systems is "run first", that one will perform the
initialization and the other one's initialization is effectively ignored.
I've seen the emails on this list and work-arounds where velocity.jar can
be put in different classpaths, but what if this isn't an option? Wouldn't
it make sense to move towards having a "velocity factory" so that we can
have as many velocity engines running as we like?
Thanks in advance,
Dan
P.S. By the way, we're live with Velocity on parts of our site -- it has
been a big win for us !!
Dan Finkelstein, Senior Architect, Instructional Tools & Technology
eMind, 1250 Addison St, Suite #210, Berkeley,CA,94702-1700
510/486-2740, dan.finkelstein@eMind.com
"Changing the face of the on-line medium" (again!)
Negative String evaluations
Posted by Kelvin Tan <ke...@myangel.com>.
Hi,
Does Velocity allow Negative String evaluations?
I understand you can evaluate positive : #if ($foo == "evaluation") ...
Can I do this : #if ($foo != "evaluation")?
I've tried doing this with out success.
Thanks
Re: Multiple velocity engines in same JVM
Posted by Dan Finkelstein <da...@emind.com>.
Hi Geir,
Thanks for your well-thought through reply -- I think you're on the money.
Let me explain our crazy design, that is, how using package names for revisions came about. When this application was first architected, we were back in the days of Java Web Server and Apache/JServ -- 2 1/2 years ago, which implemented the Servlet 2.0 spec. Thus, we needed a solution for handling multiple active revisions simultaneously and this package name-based design was selected. Given the Servlet 2.0 limitations, it seemed like a reasonable approach at the time and had, since then, been quite seamless from a developer standpoint.
I like your proposed Servlet 2.2 solution using webapps to encapsalate the various revisions. We are using cvs and ant, and I'd love to move to this sort of structure/process over time. Right now, we're still running Apache/JServ (Yeah!). Moving to Tomcat, and reworking our code to use webapps, probably won't happen until the fall or so -- other pressing priorities?!# After the transistion to webapps, I think we'll have a stronger application, particularly since classpaths can be specified on a per-webapp basis, and as you point out, our release process will be streamlined.
That said, I was suggesting the multiple simultaneous Velocity engine support as something that would be of great help to us in the short-term. It just seems like having a singleton-based engine is an unneccessary limitation in this object-oriented world.
Now, do you understand the web I live in? Hey, it's the _real_ world!
Dan
*********** REPLY SEPARATOR ***********
On 5/31/01 at 6:49 AM Geir Magnusson Jr. wrote:
>Dan Finkelstein 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.
>
>I understand the need for tight configuration control. However, using
>something like CVS, a predictable build system like ant, etc, etc, etc I
>would think this is manageable.
>
>With near-certain confidence, I can tell you that I can go at anytime
>and rebuild the original Velocity 1.0 release from the CVS repository,
>and it will be functionally identical to what we originally issued. It
>may be different bit for bit (suppose I upgraded my javac...) but I can
>control that too if I really want to.
>
>> 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.
>
>Ok - I see that indeed this must be a webapp, unless you are doing
>something spooky with servlets on the desktop :)
>
>You can run multiple webapps in the same JVM by simply using the
>features built into a Servlet Spec 2.2 compliant servlet runner (say,
>Tomcat 3.2), and just dividing up into webapps. Please don't be
>insulted if you know this already and I am simply missing some obvious
>and basic point (as usual), but I am fascinated by this and want to get
>to the bottom of it.
>
>(Note, I do this myself, so I can run two versions of Velocity at the
>same time for comparison purposes, or test beta versions of code while
>the production site continues to run...)
>
>Here's how I would approach the problem as I understand it, and I assume
>that you don't mix things - that a b1 class won't call a b2_3 class :
>
>I would have a source code repository with different versions of the
>codebase tagged and branched (tagged for minor updates - say beta1,
>beta2, etc and branches for the biggies...).
>
>Then, I would build an ant script to fetch from CVS a specific version,
>build the classes, jar them, and name the jar something sensible (like
>foo-b1_1.jar).
>
>then, I would make a different webapp for each of these
>
>webapps/
> b1_1
> b1_2
> etc
>
>then you put the appropriate foo-<ver>.jar in the WEB-APP/lib of each
>webapp, add the supporting jars (like Velocity, the templates, jdbc
>drivers, whatever...) into the WEB-APP/lib and then now you are
>completely clean and partitioned. Each webapp will have a separate
>instance of the Velocity runtime, and won't interfere with each other.
>
>Am I off in the trees here?
>
>geir
>
>
>--
>Geir Magnusson Jr. geirm@optonline.net
>System and Software Consulting
>Developing for the web? See http://jakarta.apache.org/velocity/
>"still climbing up to the shoulders..."
Re: Multiple velocity engines in same JVM
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Dan Finkelstein 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.
I understand the need for tight configuration control. However, using
something like CVS, a predictable build system like ant, etc, etc, etc I
would think this is manageable.
With near-certain confidence, I can tell you that I can go at anytime
and rebuild the original Velocity 1.0 release from the CVS repository,
and it will be functionally identical to what we originally issued. It
may be different bit for bit (suppose I upgraded my javac...) but I can
control that too if I really want to.
> 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.
Ok - I see that indeed this must be a webapp, unless you are doing
something spooky with servlets on the desktop :)
You can run multiple webapps in the same JVM by simply using the
features built into a Servlet Spec 2.2 compliant servlet runner (say,
Tomcat 3.2), and just dividing up into webapps. Please don't be
insulted if you know this already and I am simply missing some obvious
and basic point (as usual), but I am fascinated by this and want to get
to the bottom of it.
(Note, I do this myself, so I can run two versions of Velocity at the
same time for comparison purposes, or test beta versions of code while
the production site continues to run...)
Here's how I would approach the problem as I understand it, and I assume
that you don't mix things - that a b1 class won't call a b2_3 class :
I would have a source code repository with different versions of the
codebase tagged and branched (tagged for minor updates - say beta1,
beta2, etc and branches for the biggies...).
Then, I would build an ant script to fetch from CVS a specific version,
build the classes, jar them, and name the jar something sensible (like
foo-b1_1.jar).
then, I would make a different webapp for each of these
webapps/
b1_1
b1_2
etc
then you put the appropriate foo-<ver>.jar in the WEB-APP/lib of each
webapp, add the supporting jars (like Velocity, the templates, jdbc
drivers, whatever...) into the WEB-APP/lib and then now you are
completely clean and partitioned. Each webapp will have a separate
instance of the Velocity runtime, and won't interfere with each other.
Am I off in the trees here?
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."
Re: Multiple velocity engines in same JVM
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ewan Makepeace wrote:
>
> 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).
>
How would you use it? I mean, you wouldn't want to *code* to a specific
package :
import org.apache.velocity10.app.Velocity;
or something like that. Then instead of simply regression testing
against a new Velocity release (say 1.1), you have to go diddle with
every piece of code also that uses it. Scary.
I understand the problem of wanting to have a repeatable configuration,
but you can do that with reasonable configuration management and decent
source repository, right?
I mean, for a web-based application, I can bundle up a code .jar, a
template .jar, a db configuration, etc into a war in an automatic,
repeatable manner, and then I am guaranteed that I have control.
The only way this wouldn't work is if you had either a webapp that
required different versions of the webapp to be running concurrently
*in* *the* *same* webapp, rather than simply having several in
parallel.
I have to admit I don't get it.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."
RE: Multiple velocity engines in same JVM
Posted by Ewan Makepeace <ew...@yahoo.com>.
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" <da...@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
Re: Multiple velocity engines in same JVM
Posted by Jon Stevens <jo...@latchkey.com>.
on 5/30/01 10:39 AM, "Dan Finkelstein" <da...@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>
Re: Multiple velocity engines in same JVM
Posted by Dan Finkelstein <da...@emind.com>.
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
At 10:45 PM 5/28/01 -0400, you wrote:
>Dan Finkelstein wrote:
> >
> > Yes, both velocity engines are in the same JVM. I was thinking that if
> the api supported something like the following, then multiple engines
> could be supported at one time:
> >
> > Velocity velocity1 = Velocity.newInstance();
> > velocity1.init();
> > velocity1.mergeTemplate();
> > ....
> > Velocity velocity2 = Velocity.newInstance();
> > velocity2.init();
> > velocity2.mergeTemplate();
> >
> > To be more specific as to my unique needs, in our servlet-based
> application, like many people, we use Velocity for the normal html page
> processing. But, in addition, we might invoke it for some
> "preprocessing" of a very different nature. These two uses of the
> velocity templates can each occur at any time, so I'd really like to have
> two already initialized setups of velocity, each ready to run at any time.
>
>Sure. We have ran across this before, and have looked at it. It would
>take a little work to do (not major, I suspect) because up to now, it
>was designed internally with the singleton model in mind. I am
>interested in doing this, and have been playing with how it might be
>done in a transparent way....
>
>Just for grins, whats different about the separate configurations that
>make them incompatible such that you need two?
>
>
>geir
>
>--
>Geir Magnusson Jr. geirm@optonline.net
>System and Software Consulting
>Developing for the web? See http://jakarta.apache.org/velocity/
>"still climbing up to the shoulders..."
Dan Finkelstein, Senior Architect, Instructional Tools & Technology
eMind, 1250 Addison St, Suite #210, Berkeley,CA,94702-1700
510/486-2740, dan.finkelstein@eMind.com
"Changing the face of the on-line medium" (again!)
Re: Multiple velocity engines in same JVM
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Dan Finkelstein wrote:
>
> Yes, both velocity engines are in the same JVM. I was thinking that if the api supported something like the following, then multiple engines could be supported at one time:
>
> Velocity velocity1 = Velocity.newInstance();
> velocity1.init();
> velocity1.mergeTemplate();
> ....
> Velocity velocity2 = Velocity.newInstance();
> velocity2.init();
> velocity2.mergeTemplate();
>
> To be more specific as to my unique needs, in our servlet-based application, like many people, we use Velocity for the normal html page processing. But, in addition, we might invoke it for some "preprocessing" of a very different nature. These two uses of the velocity templates can each occur at any time, so I'd really like to have two already initialized setups of velocity, each ready to run at any time.
Sure. We have ran across this before, and have looked at it. It would
take a little work to do (not major, I suspect) because up to now, it
was designed internally with the singleton model in mind. I am
interested in doing this, and have been playing with how it might be
done in a transparent way....
Just for grins, whats different about the separate configurations that
make them incompatible such that you need two?
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."
Re: Multiple velocity engines in same JVM
Posted by Jon Stevens <jo...@latchkey.com>.
on 5/28/01 5:35 PM, "Dan Finkelstein" <da...@emind.com> wrote:
> Yes, both velocity engines are in the same JVM. I was thinking that if the
> api supported something like the following, then multiple engines could be
> supported at one time:
>
> Velocity velocity1 = Velocity.newInstance();
> velocity1.init();
> velocity1.mergeTemplate();
> ....
> Velocity velocity2 = Velocity.newInstance();
> velocity2.init();
> velocity2.mergeTemplate();
>
> To be more specific as to my unique needs, in our servlet-based application,
> like many people, we use Velocity for the normal html page processing. But,
> in addition, we might invoke it for some "preprocessing" of a very different
> nature. These two uses of the velocity templates can each occur at any time,
> so I'd really like to have two already initialized setups of velocity, each
> ready to run at any time.
>
> Dan
The solution is that you will most likely need to put one instance in one
classloader and another instance in another classloader.
Thanks,
-jon
Re: Multiple velocity engines in same JVM
Posted by Dan Finkelstein <da...@emind.com>.
Yes, both velocity engines are in the same JVM. I was thinking that if the api supported something like the following, then multiple engines could be supported at one time:
Velocity velocity1 = Velocity.newInstance();
velocity1.init();
velocity1.mergeTemplate();
....
Velocity velocity2 = Velocity.newInstance();
velocity2.init();
velocity2.mergeTemplate();
To be more specific as to my unique needs, in our servlet-based application, like many people, we use Velocity for the normal html page processing. But, in addition, we might invoke it for some "preprocessing" of a very different nature. These two uses of the velocity templates can each occur at any time, so I'd really like to have two already initialized setups of velocity, each ready to run at any time.
Dan
*********** REPLY SEPARATOR ***********
On 5/25/01 at 5:35 PM Geir Magnusson Jr. wrote:
>Dan Finkelstein wrote:
>>
>> Hi --
>>
>> Our application uses Velocity in two (and maybe more) distinct ways, each
>> of which we want to initialize and run separately than the other. For
>> example, the resource path needs to be different between the two. Also,
>> other property settings differ.
>>
>> The Velocity class, being a singleton, is limiting because it means that
>> whichever of our two systems is "run first", that one will perform the
>> initialization and the other one's initialization is effectively ignored.
>
>Is it in the same VM?
>
>>
>> I've seen the emails on this list and work-arounds where velocity.jar can
>> be put in different classpaths, but what if this isn't an option?
>Wouldn't
>> it make sense to move towards having a "velocity factory" so that we can
>> have as many velocity engines running as we like?
>>
>> Thanks in advance,
>> Dan
>>
>> P.S. By the way, we're live with Velocity on parts of our site -- it has
>> been a big win for us !!
>>
>> Dan Finkelstein, Senior Architect, Instructional Tools & Technology
>> eMind, 1250 Addison St, Suite #210, Berkeley,CA,94702-1700
>> 510/486-2740, dan.finkelstein@eMind.com
>>
>> "Changing the face of the on-line medium" (again!)
>
>--
>Geir Magnusson Jr. geirm@optonline.net
>System and Software Consulting
>Developing for the web? See http://jakarta.apache.org/velocity/
>"still climbing up to the shoulders..."
Re: Multiple velocity engines in same JVM
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Dan Finkelstein wrote:
>
> Hi --
>
> Our application uses Velocity in two (and maybe more) distinct ways, each
> of which we want to initialize and run separately than the other. For
> example, the resource path needs to be different between the two. Also,
> other property settings differ.
>
> The Velocity class, being a singleton, is limiting because it means that
> whichever of our two systems is "run first", that one will perform the
> initialization and the other one's initialization is effectively ignored.
Is it in the same VM?
>
> I've seen the emails on this list and work-arounds where velocity.jar can
> be put in different classpaths, but what if this isn't an option? Wouldn't
> it make sense to move towards having a "velocity factory" so that we can
> have as many velocity engines running as we like?
>
> Thanks in advance,
> Dan
>
> P.S. By the way, we're live with Velocity on parts of our site -- it has
> been a big win for us !!
>
> Dan Finkelstein, Senior Architect, Instructional Tools & Technology
> eMind, 1250 Addison St, Suite #210, Berkeley,CA,94702-1700
> 510/486-2740, dan.finkelstein@eMind.com
>
> "Changing the face of the on-line medium" (again!)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."