On Mon, Dec 29, 2008 at 10:21 AM, Steve Cohen <[email protected]> wrote: > Thanks, again, Nathan for your generous knowledge sharing. I guess I'm > wrapping so that I can wrap as much as I can centrally, with as little > change as possible in my existing code. My wrapper would be the only thing > that needs to know about Velocity (at least in theory). I pass a Map (not a > VelocityContext) into my initialized wrapper method (of course, it's static) > from which a VelocityContext is built, along with resource path info and > kaboom, there we are. It's ideal for me.
ideal is great! :) > I guess what I am asking and didn't really get an answer for is what the > lifecycle idea is with the VelocityEngine. Surely you're not initializing > an engine each time you want to merge a template - or are you? yikes, no! > If not, then > what are the purposes of having different engines? to have different configurations. > Maybe, as you say, I am > developing an application which doesn't need to play with anyone else and > just can't see the need, therefore, have no such need. Are you saying > that, at some point in the future I may uncover a need for a totally > different use of Velocity within my application, requiring different init > parameters? yep. but most people don't. > At that point, I suppose I could write another wrapper for this > other set of client code (static as well, perhaps) and the two could live in > blissful ignorance of each other. yep, so long as both are not trying to use the singleton under the covers. > Or am I still missing something? i don't think so. > Nathan Bubna wrote: >> >> No, so long as threads aren't sharing the same Context, you shouldn't >> have an thread safety issues. Rather, i am expressing a general >> distaste for the JVM singleton model, since it is a "doesn't play well >> with the other kids" approach. As you are developing an application >> (no other kids will play with it), and not a library (meant to play >> with other kids), this should not be a problem for you (until you >> later need a second Velocity instance with a different configuration). >> >> If you need singleton access enough that you are writing a wrapper >> around VelocityEngine to get it, then you may as well use the Velocity >> singleton. >> >> The VM_global_library.vm message can be ignored. It's just saying >> that it didn't find a global velocimacro library of the default name. >> That only matters if you had one and expected it to be found. >> >> On Mon, Dec 29, 2008 at 5:30 AM, Steve Cohen <[email protected]> >> wrote: >> >>> >>> Well, okay, I am reasonably satisfied. I think Velocity and my app are a >>> damned good fit, as I had hoped. I have a couple of questions before I >>> dive >>> in head first: >>> >>> 1) To singleton or not to singleton: >>> >>> Is this a question of thread safety? The documentation doesn't make it >>> appear so. I had initially gone with the singleton pattern, but a post >>> by >>> Nathan Bubna was more negative toward this than the Velocity site >>> documentation. Even using VelocityEngine, my first move was to put it >>> inside a singleton wrapper, so ingrained was my fear of initialization >>> cost. >>> Which is, of course, stupid. If I am going to put Velocity into a >>> singleton wrapper (which I am tentatively calling VelociWrapper :-)), >>> what >>> is the point of using the engine? If either one is thread-safe does it >>> matter? I guess I'm asking where, along the path, am I going to regret >>> using the singleton if the issue is NOT thread-safety, which is my >>> assumption at this point? >>> >>> 2) What does this mean in my logs? It doesn't appear I need this - yet. >>> But what is it and when might I need it? >>> >>> 2008-12-29 06:07:57,846 [main] DEBUG Velocity - Could not load resource >>> 'VM_global_library.vm' from ResourceLoader >>> org.apache.velocity.tools.view.servlet.WebappLoader: >>> org.apache.velocity.exception.ResourceNotFoundException: WebappLoader : >>> Resource 'VM_global_library.vm' not found. >>> at >>> >>> org.apache.velocity.tools.view.servlet.WebappLoader.getResourceStream(WebappLoader.java:179) >>> at >>> >>> org.apache.velocity.runtime.resource.loader.ResourceLoader.resourceExists(ResourceLoader.java:224) >>> at >>> >>> org.apache.velocity.runtime.resource.ResourceManagerImpl.getLoaderNameForResource(ResourceManagerImpl.java:617) >>> at >>> >>> org.apache.velocity.runtime.RuntimeInstance.getLoaderNameForResource(RuntimeInstance.java:1464) >>> at >>> >>> org.apache.velocity.runtime.VelocimacroFactory.initVelocimacro(VelocimacroFactory.java:159) >>> at >>> >>> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:261) >>> at org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:107) >>> >>> Thanks. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
