You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Steve Cohen <sc...@javactivity.org> on 2008/12/29 14:30:24 UTC
To Singleton Or Not To Singleton...
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: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: To Singleton Or Not To Singleton...
Posted by Steve Cohen <sc...@javactivity.org>.
Nathan Bubna wrote:
> On Mon, Dec 29, 2008 at 10:21 AM, Steve Cohen <sc...@javactivity.org> wrote:
>
> ...
>
>
>> 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
No, I made my singleton out of my wrapper class, whose single instance
wraps one VelocityEngine, not Velocity. Any other future wrappers would
follow the same pattern, so we should be okay in that event too.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: To Singleton Or Not To Singleton...
Posted by Nathan Bubna <nb...@gmail.com>.
On Mon, Dec 29, 2008 at 10:21 AM, Steve Cohen <sc...@javactivity.org> 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 <sc...@javactivity.org>
>> 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: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: To Singleton Or Not To Singleton...
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@javactivity.org> 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: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: To Singleton Or Not To Singleton...
Posted by Nathan Bubna <nb...@gmail.com>.
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 <sc...@javactivity.org> 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: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org