Help! .vm file not communicating with .class file

[Gurumurthy R <gu...@rediffmail.com>]

Hi Randy,

Good morning.  I am new to Velocity/Turbine.  I went through the Velocity document.  I created HelloWorld.java and HelloWorld.vm files.

I downloaded ant, then first step I did was:

I created a directory Hello under %TDK_HOME% Then I executed "ant" which takes build.xml file and it created %TDK_HOME%/webapps/Hello.... etc.

Then I compiled the HelloWorld.java into %TDK_HOME%/webapps/Hello/WEB-INF/classes directory as directed.

Then I saved the file HelloWorld.vm in templates/app/screens directory under the same %TDK_HOME%/webapps/Hello....

Then, I went to the directory %TDK_HOME%/webapps/Hello/WEB-INF/build and executed "ant init".

Then I started "startup.bat" from the %TDK_HOME%/bin.  

Now, I went to the browser and typed:
http://localhost:8080/Hello/servlet/Hello/Turbine/template/HelloWorld.vm

I got the result:

$hello something,

the problem here is that $hello is not being replaced with the text which was written in HelloWorld.class file.

Pl. Help me,
thanks,
guru

On Fri, 28 Sep 2001 Bojan Smojver wrote :
> Randy Speh wrote:
> > 
> > Could someone explain what the PumpServlet is that was
> > mentioned in the following message yesterday.
> 
> First off, PumpServlet is not part of Velocity 
> distribution, so if it
> blows your machine up, please don't blame Velocity 
> developers :-)
> 
> PumpServlet is my own entry point for all Velocity 
> applications. It is
> just a single servlet (poorly written and probably full 
> of bugs), but if
> correctly mapped in web.xml, it can handle all Velocity 
> pages (for
> instance *.vm).
> 
> The servlet itself is very application centric:
> 
> - uses Velocity 1.2 non-singleton (or instance) model 
> to create a
> VelocityEngine per application (stored in 
> ServletContext); it will init
> the engine from velocity.properties file
> 
> - it will load and initialise beans (if the bean 
> implements
> InitProperties interface, code supplied with the 
> servlet) of
> application, session and request scope that you give it 
> in
> beans.properties; properties read from 
> application.properties will be
> passed to beans at init time
> 
> - application beans are available to all pages in an 
> app (just like JSP)
> and are stored in the ServletContext
> 
> - session beans are available to the pages within that 
> session (just
> like JSP) and are stored in HttpSession
> 
> - request beans are loaded and initialised every time 
> the correct page
> is hit; for instance, this in beans.properties file:
> 
> --------------------------------------------
> request.lottery=com.lottery.beans.Win,
> /lottery/bigwin.vm,/lottery/smallwin.vm
> --------------------------------------------
> 
> would make sure that every time pages 
> /lottery/bigwin.vm or
> /lottery/smallwin.vm are hit, there is a new instance 
> of the lottery
> bean
> 
> --------------------------------------------
> request.lottery=com.lottery.beans.Win
> --------------------------------------------
> 
> would make lottery bean available to all pages
> 
> - there are no page beans (ie. this is not like JSP ;-)
> 
> - all beans are stored into Velocity reference $beans 
> (which is a
> HashMap) by their names (the part after the scope and 
> before the = sign)
> specified in beans.properties; there is also the 
> standard $req and $res
> (for Model 1 architectures as well as URL encoding etc.)
> 
> - if there is a context-param 'controller' which 
> implements Controller
> (code supplied) interface (and optionally 
> InitProperties interface), it
> will be loaded and initialised and then used as 
> (surprise) MVC
> controller class for the application; its single method 
> (service) is
> called with request, response and Velocity context as 
> parameters; this
> is where some real magic is happening since this guy is 
> also permitted
> to switch the page that is going to be loaded because 
> it returns the new
> template name; you write your own class that does 
> whatever custom
> request processing you have for the app
> 
> - if you don't use MVC (or Model 2), Model 1 is assumed,
>  which means
> that .vm pages themselves will be steering the 
> application and calling
> business logic bean calls - just in case you find MVC 
> too complicated
> for some things; note that if you have the controller, 
> you can still
> have some pages on Model 1 by just passing back the 
> same template that
> went into the controller (this is getServletPath() from 
> the request)
> 
> - .vm page (template) is then merged, but the result 
> will not go to
> response until we're sure that everything was cool - 
> therefore the
> ByteArrayOutputStream buffer
> 
> - if there were problems, servlet will pick up the 
> error page you supply
> or failing that its own little piece of XHTML
> 
> - this servlet also makes coffee, cleans the house - oh,
>  sorry, no,
> wrong servlet ;-)
> 
> The thing is currently licensed GPL for one reason 
> alone - it probably
> has a lot of bugs, so feedback is welcome. But it can 
> also be licensed
> BSD-ish for more freedom in the future.
> 
> Bojan