You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Alex Fedotov <al...@kayak.com> on 2015/03/04 17:48:08 UTC
Velocity 2.0 (trunk) macro synchronization
Hello Guys,
We use Velocity quite a bit and are considering moving forward and
deploying the trunk build in production even though there never was a 2.0
release. We currently use a custom 1.7 build with a couple of bugs fixed by
us.
One area where we are going to make some changes before it can go in
production is the synchronization in the VelocimacroFactory and
VelicimacroManager classes. It appears to be a mix of ConcurrentHashMaps
and global synchronized blocks. Our code is highly threaded, loads quite a
bit of templates dynamically at run-time and having these global locks
would likely present a synchronization hotspot.
Our plan is to see if we can cleanup the synchronization in this area keep
it robust, but remove the global synchronized blocks.
If you guys have any interest in accepting our contribution back please let
me know what the process should be.
Thank you,
Alex
Re: Velocity 2.0 (trunk) macro synchronization
Posted by Nathan Bubna <nb...@gmail.com>.
I would treat them as local. Global ones should be defined at runtime
initialization.
On Fri, Mar 6, 2015 at 9:14 AM, Alex Fedotov <al...@kayak.com> wrote:
> There are some open questions though:
>
> There is a very useful method Template.merge(Context, Writer, List
> macroLibraries).
> Should these macroLibraries be treated as global or local? I believe they
> are treated as local now.
>
> Alex
>
>
> On Fri, Mar 6, 2015 at 12:08 PM, Alex Fedotov <al...@kayak.com> wrote:
>
> > Sure it can be done.
> >
> > I would still keep the macros in templates, including the global
> templates
> > (i.e. library files). I would maintain the list of global Template
> objects.
> > Depending on the settings, during the macro lookup iterate over the
> global
> > Template objects first, if not found there do the normal lookup in the
> > calling template or in the Template list (macroLibraries).
> >
> > Alex
> >
> >
> > On Fri, Mar 6, 2015 at 11:54 AM, Nathan Bubna <nb...@gmail.com> wrote:
> >
> >> inline...
> >>
> >> On Fri, Mar 6, 2015 at 7:48 AM, Alex Fedotov <al...@kayak.com> wrote:
> >>
> >> > One more question. One of the other areas we making changes is around
> >> how
> >> > macros are called. Right now the lookup process is fairly rigid and
> can
> >> be
> >> > inefficient as well. Consider a couple of examples:
> >> >
> >> > 1. Scenario one - overload macro in the template This works now
> because
> >> the
> >> > lookup checks the namespace where the call is made first.
> >> >
> >> > macros.vtl
> >> > ========
> >> > #macro(B)
> >> > #end
> >> >
> >> > #macro(A)
> >> > #B()
> >> > #end
> >> > ========
> >> >
> >> > template.vtl
> >> > =========
> >> > #parse('macros.vtl')
> >> > #macro(A)
> >> > ## overloaded macro A
> >> > #end
> >> > #A() ## this calls local macro A which is expected.
> >> > =========
> >> >
> >> > 2. Scenario two - overload macro B - this does not work now.
> >> >
> >> > template.vtl
> >> > =========
> >> > #parse('macros.vtl')
> >> > #macro(B)
> >> > ## overloaded macro B
> >> > #end
> >> > #A() ## this calls macro A which is then does NOT call overloaded B,
> >> since
> >> > the look-up would prefer the B from the same module where A is.
> >> > =========
> >> >
> >> > We have created a custom directive #call which is similar to the
> >> > RuntimeMacro, but allows more control over the lookup process. This
> also
> >> > allows stuff like:
> >> > #call('self::macroName')
> >> > #call('nameSpace::macroName')
> >> >
> >> > The way every #parse(d) template is appended to the list of the
> >> > "macroLibraries" can be very bad for macro look-up speed:
> >> > #foreach( $item in $items )
> >> > #parse('item.vtl')
> >> > #end
> >> >
> >> > You end-up with a lot of "item.vtl" references added to the list which
> >> then
> >> > cause a lot of duplicate macro lookups in namespaces.
> >> > We have fixes that avoid adding duplicate sequences of template names
> to
> >> > the macroLibraries list.
> >> >
> >> > Do you guys have any plans to address this area?
> >> >
> >>
> >> So far as i know, no one has plans to work on these things.
> >>
> >>
> >> > We are also inclined to always use namespaces for macros, always allow
> >> > local macros to replace globals and keep the macros as
> >> ConcurrentHashMap in
> >> > the Template object.
> >> >
> >>
> >> Keeping macros in the Template would be good, but i'd be hesitant to
> >> accept
> >> a patch that permanently allows local macros to replace global macros.
> >> There are a LOT of Velocity users out there who use it to allow
> >> third-parties to write templates. Those Velocity users tend to like the
> >> ability to limit what their untrusted users can do with templates.
> >>
> >>
> >> > This way VelocimacroManager can be dropped all together, there is no
> >> issue
> >> > with reloading templates while maintaining the VelocimacroManager in
> >> sync,
> >> > less synchronization problems, etc.
> >> > The flag "isFromLib" for macros would also not be needed, so all the
> >> hair
> >> > around maintaining it during the "init" phase could be removed as
> well.
> >> >
> >>
> >> That sounds good. Can you do that while keeping the option to block
> local
> >> macros from overriding global ones?
> >>
> >>
> >>
> >> >
> >> > Alex
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Mar 6, 2015 at 2:48 AM, Claude Brisson <cl...@renegat.net>
> >> wrote:
> >> >
> >> > > Hi.
> >> > >
> >> > > We'll publish the 2.0 one day, it's slowly moving...
> >> > >
> >> > > Thank you for your proposal. Of course, it is interesting for the
> >> project
> >> > > if you can share your 1.7 bugfixes as long as your synchronization
> >> work
> >> > on
> >> > > the 2.0 branch.
> >> > >
> >> > > The process is rather easy: patches are to be submitted on JIRA :
> >> > > https://issues.apache.org/jira/browse/VELOCITY/
> >> > >
> >> > > Very small patches (too small to be considered intellectual
> property)
> >> > > don't need anything else. For more consequent patches, some people
> say
> >> > you
> >> > > should at least add a sentence like "feel free to use this patch
> under
> >> > the
> >> > > Apache License" in the issue.
> >> > >
> >> > >
> >> > > Claude
> >> > >
> >> > >
> >> > >
> >> > > On 04/03/2015 17:48, Alex Fedotov wrote:
> >> > >
> >> > >> Hello Guys,
> >> > >>
> >> > >> We use Velocity quite a bit and are considering moving forward and
> >> > >> deploying the trunk build in production even though there never
> was a
> >> > 2.0
> >> > >> release. We currently use a custom 1.7 build with a couple of bugs
> >> fixed
> >> > >> by
> >> > >> us.
> >> > >>
> >> > >> One area where we are going to make some changes before it can go
> in
> >> > >> production is the synchronization in the VelocimacroFactory and
> >> > >> VelicimacroManager classes. It appears to be a mix of
> >> ConcurrentHashMaps
> >> > >> and global synchronized blocks. Our code is highly threaded, loads
> >> > quite a
> >> > >> bit of templates dynamically at run-time and having these global
> >> locks
> >> > >> would likely present a synchronization hotspot.
> >> > >>
> >> > >> Our plan is to see if we can cleanup the synchronization in this
> area
> >> > keep
> >> > >> it robust, but remove the global synchronized blocks.
> >> > >>
> >> > >> If you guys have any interest in accepting our contribution back
> >> please
> >> > >> let
> >> > >> me know what the process should be.
> >> > >>
> >> > >> Thank you,
> >> > >> Alex
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >
> >
>
Re: Velocity 2.0 (trunk) macro synchronization
Posted by Alex Fedotov <al...@kayak.com>.
There are some open questions though:
There is a very useful method Template.merge(Context, Writer, List
macroLibraries).
Should these macroLibraries be treated as global or local? I believe they
are treated as local now.
Alex
On Fri, Mar 6, 2015 at 12:08 PM, Alex Fedotov <al...@kayak.com> wrote:
> Sure it can be done.
>
> I would still keep the macros in templates, including the global templates
> (i.e. library files). I would maintain the list of global Template objects.
> Depending on the settings, during the macro lookup iterate over the global
> Template objects first, if not found there do the normal lookup in the
> calling template or in the Template list (macroLibraries).
>
> Alex
>
>
> On Fri, Mar 6, 2015 at 11:54 AM, Nathan Bubna <nb...@gmail.com> wrote:
>
>> inline...
>>
>> On Fri, Mar 6, 2015 at 7:48 AM, Alex Fedotov <al...@kayak.com> wrote:
>>
>> > One more question. One of the other areas we making changes is around
>> how
>> > macros are called. Right now the lookup process is fairly rigid and can
>> be
>> > inefficient as well. Consider a couple of examples:
>> >
>> > 1. Scenario one - overload macro in the template This works now because
>> the
>> > lookup checks the namespace where the call is made first.
>> >
>> > macros.vtl
>> > ========
>> > #macro(B)
>> > #end
>> >
>> > #macro(A)
>> > #B()
>> > #end
>> > ========
>> >
>> > template.vtl
>> > =========
>> > #parse('macros.vtl')
>> > #macro(A)
>> > ## overloaded macro A
>> > #end
>> > #A() ## this calls local macro A which is expected.
>> > =========
>> >
>> > 2. Scenario two - overload macro B - this does not work now.
>> >
>> > template.vtl
>> > =========
>> > #parse('macros.vtl')
>> > #macro(B)
>> > ## overloaded macro B
>> > #end
>> > #A() ## this calls macro A which is then does NOT call overloaded B,
>> since
>> > the look-up would prefer the B from the same module where A is.
>> > =========
>> >
>> > We have created a custom directive #call which is similar to the
>> > RuntimeMacro, but allows more control over the lookup process. This also
>> > allows stuff like:
>> > #call('self::macroName')
>> > #call('nameSpace::macroName')
>> >
>> > The way every #parse(d) template is appended to the list of the
>> > "macroLibraries" can be very bad for macro look-up speed:
>> > #foreach( $item in $items )
>> > #parse('item.vtl')
>> > #end
>> >
>> > You end-up with a lot of "item.vtl" references added to the list which
>> then
>> > cause a lot of duplicate macro lookups in namespaces.
>> > We have fixes that avoid adding duplicate sequences of template names to
>> > the macroLibraries list.
>> >
>> > Do you guys have any plans to address this area?
>> >
>>
>> So far as i know, no one has plans to work on these things.
>>
>>
>> > We are also inclined to always use namespaces for macros, always allow
>> > local macros to replace globals and keep the macros as
>> ConcurrentHashMap in
>> > the Template object.
>> >
>>
>> Keeping macros in the Template would be good, but i'd be hesitant to
>> accept
>> a patch that permanently allows local macros to replace global macros.
>> There are a LOT of Velocity users out there who use it to allow
>> third-parties to write templates. Those Velocity users tend to like the
>> ability to limit what their untrusted users can do with templates.
>>
>>
>> > This way VelocimacroManager can be dropped all together, there is no
>> issue
>> > with reloading templates while maintaining the VelocimacroManager in
>> sync,
>> > less synchronization problems, etc.
>> > The flag "isFromLib" for macros would also not be needed, so all the
>> hair
>> > around maintaining it during the "init" phase could be removed as well.
>> >
>>
>> That sounds good. Can you do that while keeping the option to block local
>> macros from overriding global ones?
>>
>>
>>
>> >
>> > Alex
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Mar 6, 2015 at 2:48 AM, Claude Brisson <cl...@renegat.net>
>> wrote:
>> >
>> > > Hi.
>> > >
>> > > We'll publish the 2.0 one day, it's slowly moving...
>> > >
>> > > Thank you for your proposal. Of course, it is interesting for the
>> project
>> > > if you can share your 1.7 bugfixes as long as your synchronization
>> work
>> > on
>> > > the 2.0 branch.
>> > >
>> > > The process is rather easy: patches are to be submitted on JIRA :
>> > > https://issues.apache.org/jira/browse/VELOCITY/
>> > >
>> > > Very small patches (too small to be considered intellectual property)
>> > > don't need anything else. For more consequent patches, some people say
>> > you
>> > > should at least add a sentence like "feel free to use this patch under
>> > the
>> > > Apache License" in the issue.
>> > >
>> > >
>> > > Claude
>> > >
>> > >
>> > >
>> > > On 04/03/2015 17:48, Alex Fedotov wrote:
>> > >
>> > >> Hello Guys,
>> > >>
>> > >> We use Velocity quite a bit and are considering moving forward and
>> > >> deploying the trunk build in production even though there never was a
>> > 2.0
>> > >> release. We currently use a custom 1.7 build with a couple of bugs
>> fixed
>> > >> by
>> > >> us.
>> > >>
>> > >> One area where we are going to make some changes before it can go in
>> > >> production is the synchronization in the VelocimacroFactory and
>> > >> VelicimacroManager classes. It appears to be a mix of
>> ConcurrentHashMaps
>> > >> and global synchronized blocks. Our code is highly threaded, loads
>> > quite a
>> > >> bit of templates dynamically at run-time and having these global
>> locks
>> > >> would likely present a synchronization hotspot.
>> > >>
>> > >> Our plan is to see if we can cleanup the synchronization in this area
>> > keep
>> > >> it robust, but remove the global synchronized blocks.
>> > >>
>> > >> If you guys have any interest in accepting our contribution back
>> please
>> > >> let
>> > >> me know what the process should be.
>> > >>
>> > >> Thank you,
>> > >> Alex
>> > >>
>> > >>
>> > >
>> >
>>
>
>
Re: Velocity 2.0 (trunk) macro synchronization
Posted by Alex Fedotov <al...@kayak.com>.
Sure it can be done.
I would still keep the macros in templates, including the global templates
(i.e. library files). I would maintain the list of global Template objects.
Depending on the settings, during the macro lookup iterate over the global
Template objects first, if not found there do the normal lookup in the
calling template or in the Template list (macroLibraries).
Alex
On Fri, Mar 6, 2015 at 11:54 AM, Nathan Bubna <nb...@gmail.com> wrote:
> inline...
>
> On Fri, Mar 6, 2015 at 7:48 AM, Alex Fedotov <al...@kayak.com> wrote:
>
> > One more question. One of the other areas we making changes is around how
> > macros are called. Right now the lookup process is fairly rigid and can
> be
> > inefficient as well. Consider a couple of examples:
> >
> > 1. Scenario one - overload macro in the template This works now because
> the
> > lookup checks the namespace where the call is made first.
> >
> > macros.vtl
> > ========
> > #macro(B)
> > #end
> >
> > #macro(A)
> > #B()
> > #end
> > ========
> >
> > template.vtl
> > =========
> > #parse('macros.vtl')
> > #macro(A)
> > ## overloaded macro A
> > #end
> > #A() ## this calls local macro A which is expected.
> > =========
> >
> > 2. Scenario two - overload macro B - this does not work now.
> >
> > template.vtl
> > =========
> > #parse('macros.vtl')
> > #macro(B)
> > ## overloaded macro B
> > #end
> > #A() ## this calls macro A which is then does NOT call overloaded B,
> since
> > the look-up would prefer the B from the same module where A is.
> > =========
> >
> > We have created a custom directive #call which is similar to the
> > RuntimeMacro, but allows more control over the lookup process. This also
> > allows stuff like:
> > #call('self::macroName')
> > #call('nameSpace::macroName')
> >
> > The way every #parse(d) template is appended to the list of the
> > "macroLibraries" can be very bad for macro look-up speed:
> > #foreach( $item in $items )
> > #parse('item.vtl')
> > #end
> >
> > You end-up with a lot of "item.vtl" references added to the list which
> then
> > cause a lot of duplicate macro lookups in namespaces.
> > We have fixes that avoid adding duplicate sequences of template names to
> > the macroLibraries list.
> >
> > Do you guys have any plans to address this area?
> >
>
> So far as i know, no one has plans to work on these things.
>
>
> > We are also inclined to always use namespaces for macros, always allow
> > local macros to replace globals and keep the macros as ConcurrentHashMap
> in
> > the Template object.
> >
>
> Keeping macros in the Template would be good, but i'd be hesitant to accept
> a patch that permanently allows local macros to replace global macros.
> There are a LOT of Velocity users out there who use it to allow
> third-parties to write templates. Those Velocity users tend to like the
> ability to limit what their untrusted users can do with templates.
>
>
> > This way VelocimacroManager can be dropped all together, there is no
> issue
> > with reloading templates while maintaining the VelocimacroManager in
> sync,
> > less synchronization problems, etc.
> > The flag "isFromLib" for macros would also not be needed, so all the hair
> > around maintaining it during the "init" phase could be removed as well.
> >
>
> That sounds good. Can you do that while keeping the option to block local
> macros from overriding global ones?
>
>
>
> >
> > Alex
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Mar 6, 2015 at 2:48 AM, Claude Brisson <cl...@renegat.net>
> wrote:
> >
> > > Hi.
> > >
> > > We'll publish the 2.0 one day, it's slowly moving...
> > >
> > > Thank you for your proposal. Of course, it is interesting for the
> project
> > > if you can share your 1.7 bugfixes as long as your synchronization work
> > on
> > > the 2.0 branch.
> > >
> > > The process is rather easy: patches are to be submitted on JIRA :
> > > https://issues.apache.org/jira/browse/VELOCITY/
> > >
> > > Very small patches (too small to be considered intellectual property)
> > > don't need anything else. For more consequent patches, some people say
> > you
> > > should at least add a sentence like "feel free to use this patch under
> > the
> > > Apache License" in the issue.
> > >
> > >
> > > Claude
> > >
> > >
> > >
> > > On 04/03/2015 17:48, Alex Fedotov wrote:
> > >
> > >> Hello Guys,
> > >>
> > >> We use Velocity quite a bit and are considering moving forward and
> > >> deploying the trunk build in production even though there never was a
> > 2.0
> > >> release. We currently use a custom 1.7 build with a couple of bugs
> fixed
> > >> by
> > >> us.
> > >>
> > >> One area where we are going to make some changes before it can go in
> > >> production is the synchronization in the VelocimacroFactory and
> > >> VelicimacroManager classes. It appears to be a mix of
> ConcurrentHashMaps
> > >> and global synchronized blocks. Our code is highly threaded, loads
> > quite a
> > >> bit of templates dynamically at run-time and having these global locks
> > >> would likely present a synchronization hotspot.
> > >>
> > >> Our plan is to see if we can cleanup the synchronization in this area
> > keep
> > >> it robust, but remove the global synchronized blocks.
> > >>
> > >> If you guys have any interest in accepting our contribution back
> please
> > >> let
> > >> me know what the process should be.
> > >>
> > >> Thank you,
> > >> Alex
> > >>
> > >>
> > >
> >
>
Re: Velocity 2.0 (trunk) macro synchronization
Posted by Nathan Bubna <nb...@gmail.com>.
inline...
On Fri, Mar 6, 2015 at 7:48 AM, Alex Fedotov <al...@kayak.com> wrote:
> One more question. One of the other areas we making changes is around how
> macros are called. Right now the lookup process is fairly rigid and can be
> inefficient as well. Consider a couple of examples:
>
> 1. Scenario one - overload macro in the template This works now because the
> lookup checks the namespace where the call is made first.
>
> macros.vtl
> ========
> #macro(B)
> #end
>
> #macro(A)
> #B()
> #end
> ========
>
> template.vtl
> =========
> #parse('macros.vtl')
> #macro(A)
> ## overloaded macro A
> #end
> #A() ## this calls local macro A which is expected.
> =========
>
> 2. Scenario two - overload macro B - this does not work now.
>
> template.vtl
> =========
> #parse('macros.vtl')
> #macro(B)
> ## overloaded macro B
> #end
> #A() ## this calls macro A which is then does NOT call overloaded B, since
> the look-up would prefer the B from the same module where A is.
> =========
>
> We have created a custom directive #call which is similar to the
> RuntimeMacro, but allows more control over the lookup process. This also
> allows stuff like:
> #call('self::macroName')
> #call('nameSpace::macroName')
>
> The way every #parse(d) template is appended to the list of the
> "macroLibraries" can be very bad for macro look-up speed:
> #foreach( $item in $items )
> #parse('item.vtl')
> #end
>
> You end-up with a lot of "item.vtl" references added to the list which then
> cause a lot of duplicate macro lookups in namespaces.
> We have fixes that avoid adding duplicate sequences of template names to
> the macroLibraries list.
>
> Do you guys have any plans to address this area?
>
So far as i know, no one has plans to work on these things.
> We are also inclined to always use namespaces for macros, always allow
> local macros to replace globals and keep the macros as ConcurrentHashMap in
> the Template object.
>
Keeping macros in the Template would be good, but i'd be hesitant to accept
a patch that permanently allows local macros to replace global macros.
There are a LOT of Velocity users out there who use it to allow
third-parties to write templates. Those Velocity users tend to like the
ability to limit what their untrusted users can do with templates.
> This way VelocimacroManager can be dropped all together, there is no issue
> with reloading templates while maintaining the VelocimacroManager in sync,
> less synchronization problems, etc.
> The flag "isFromLib" for macros would also not be needed, so all the hair
> around maintaining it during the "init" phase could be removed as well.
>
That sounds good. Can you do that while keeping the option to block local
macros from overriding global ones?
>
> Alex
>
>
>
>
>
>
>
>
>
> On Fri, Mar 6, 2015 at 2:48 AM, Claude Brisson <cl...@renegat.net> wrote:
>
> > Hi.
> >
> > We'll publish the 2.0 one day, it's slowly moving...
> >
> > Thank you for your proposal. Of course, it is interesting for the project
> > if you can share your 1.7 bugfixes as long as your synchronization work
> on
> > the 2.0 branch.
> >
> > The process is rather easy: patches are to be submitted on JIRA :
> > https://issues.apache.org/jira/browse/VELOCITY/
> >
> > Very small patches (too small to be considered intellectual property)
> > don't need anything else. For more consequent patches, some people say
> you
> > should at least add a sentence like "feel free to use this patch under
> the
> > Apache License" in the issue.
> >
> >
> > Claude
> >
> >
> >
> > On 04/03/2015 17:48, Alex Fedotov wrote:
> >
> >> Hello Guys,
> >>
> >> We use Velocity quite a bit and are considering moving forward and
> >> deploying the trunk build in production even though there never was a
> 2.0
> >> release. We currently use a custom 1.7 build with a couple of bugs fixed
> >> by
> >> us.
> >>
> >> One area where we are going to make some changes before it can go in
> >> production is the synchronization in the VelocimacroFactory and
> >> VelicimacroManager classes. It appears to be a mix of ConcurrentHashMaps
> >> and global synchronized blocks. Our code is highly threaded, loads
> quite a
> >> bit of templates dynamically at run-time and having these global locks
> >> would likely present a synchronization hotspot.
> >>
> >> Our plan is to see if we can cleanup the synchronization in this area
> keep
> >> it robust, but remove the global synchronized blocks.
> >>
> >> If you guys have any interest in accepting our contribution back please
> >> let
> >> me know what the process should be.
> >>
> >> Thank you,
> >> Alex
> >>
> >>
> >
>
Re: Velocity 2.0 (trunk) macro synchronization
Posted by Alex Fedotov <al...@kayak.com>.
One more question. One of the other areas we making changes is around how
macros are called. Right now the lookup process is fairly rigid and can be
inefficient as well. Consider a couple of examples:
1. Scenario one - overload macro in the template This works now because the
lookup checks the namespace where the call is made first.
macros.vtl
========
#macro(B)
#end
#macro(A)
#B()
#end
========
template.vtl
=========
#parse('macros.vtl')
#macro(A)
## overloaded macro A
#end
#A() ## this calls local macro A which is expected.
=========
2. Scenario two - overload macro B - this does not work now.
template.vtl
=========
#parse('macros.vtl')
#macro(B)
## overloaded macro B
#end
#A() ## this calls macro A which is then does NOT call overloaded B, since
the look-up would prefer the B from the same module where A is.
=========
We have created a custom directive #call which is similar to the
RuntimeMacro, but allows more control over the lookup process. This also
allows stuff like:
#call('self::macroName')
#call('nameSpace::macroName')
The way every #parse(d) template is appended to the list of the
"macroLibraries" can be very bad for macro look-up speed:
#foreach( $item in $items )
#parse('item.vtl')
#end
You end-up with a lot of "item.vtl" references added to the list which then
cause a lot of duplicate macro lookups in namespaces.
We have fixes that avoid adding duplicate sequences of template names to
the macroLibraries list.
Do you guys have any plans to address this area?
We are also inclined to always use namespaces for macros, always allow
local macros to replace globals and keep the macros as ConcurrentHashMap in
the Template object.
This way VelocimacroManager can be dropped all together, there is no issue
with reloading templates while maintaining the VelocimacroManager in sync,
less synchronization problems, etc.
The flag "isFromLib" for macros would also not be needed, so all the hair
around maintaining it during the "init" phase could be removed as well.
Alex
On Fri, Mar 6, 2015 at 2:48 AM, Claude Brisson <cl...@renegat.net> wrote:
> Hi.
>
> We'll publish the 2.0 one day, it's slowly moving...
>
> Thank you for your proposal. Of course, it is interesting for the project
> if you can share your 1.7 bugfixes as long as your synchronization work on
> the 2.0 branch.
>
> The process is rather easy: patches are to be submitted on JIRA :
> https://issues.apache.org/jira/browse/VELOCITY/
>
> Very small patches (too small to be considered intellectual property)
> don't need anything else. For more consequent patches, some people say you
> should at least add a sentence like "feel free to use this patch under the
> Apache License" in the issue.
>
>
> Claude
>
>
>
> On 04/03/2015 17:48, Alex Fedotov wrote:
>
>> Hello Guys,
>>
>> We use Velocity quite a bit and are considering moving forward and
>> deploying the trunk build in production even though there never was a 2.0
>> release. We currently use a custom 1.7 build with a couple of bugs fixed
>> by
>> us.
>>
>> One area where we are going to make some changes before it can go in
>> production is the synchronization in the VelocimacroFactory and
>> VelicimacroManager classes. It appears to be a mix of ConcurrentHashMaps
>> and global synchronized blocks. Our code is highly threaded, loads quite a
>> bit of templates dynamically at run-time and having these global locks
>> would likely present a synchronization hotspot.
>>
>> Our plan is to see if we can cleanup the synchronization in this area keep
>> it robust, but remove the global synchronized blocks.
>>
>> If you guys have any interest in accepting our contribution back please
>> let
>> me know what the process should be.
>>
>> Thank you,
>> Alex
>>
>>
>
Re: Velocity 2.0 (trunk) macro synchronization
Posted by Claude Brisson <cl...@renegat.net>.
Hi.
We'll publish the 2.0 one day, it's slowly moving...
Thank you for your proposal. Of course, it is interesting for the
project if you can share your 1.7 bugfixes as long as your
synchronization work on the 2.0 branch.
The process is rather easy: patches are to be submitted on JIRA :
https://issues.apache.org/jira/browse/VELOCITY/
Very small patches (too small to be considered intellectual property)
don't need anything else. For more consequent patches, some people say
you should at least add a sentence like "feel free to use this patch
under the Apache License" in the issue.
Claude
On 04/03/2015 17:48, Alex Fedotov wrote:
> Hello Guys,
>
> We use Velocity quite a bit and are considering moving forward and
> deploying the trunk build in production even though there never was a 2.0
> release. We currently use a custom 1.7 build with a couple of bugs fixed by
> us.
>
> One area where we are going to make some changes before it can go in
> production is the synchronization in the VelocimacroFactory and
> VelicimacroManager classes. It appears to be a mix of ConcurrentHashMaps
> and global synchronized blocks. Our code is highly threaded, loads quite a
> bit of templates dynamically at run-time and having these global locks
> would likely present a synchronization hotspot.
>
> Our plan is to see if we can cleanup the synchronization in this area keep
> it robust, but remove the global synchronized blocks.
>
> If you guys have any interest in accepting our contribution back please let
> me know what the process should be.
>
> Thank you,
> Alex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org