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.
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? If not, then what are the purposes of having different engines?
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? 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. Or am I still missing something?
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]
