Re: Multiple velocity engines in same JVM

[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..."

Negative String evaluations

[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