Re: [veltools] status of 2.x branch
Ok, the problem with init() not being called is fixed. also, i changed VelocityView to not load the default tool configs when an old toolbox.xml is in use. this means that people using the old toolbox.xml can drop in the full jar (including VelocityStruts) and not have configuration exceptions thrown at them. as things stand, however, once they move to a tools.xml or tools.properties configuration and/or add the org.apache.velocity.tools.loadDefaults=true property to their web.xml init params, they will get a exception on startup if they are using the full VelocityStruts jar but do not have the Struts dependencies on the classpath. i did this for now, because it's easier. simply logging an error message when dependencies are missing (as opposed to throwing an exception) will actually be pretty difficult to pull off as things are currently organized. i'll continue to think about ways to do that or make it optional, but it's looking like quite the challenge at the moment. On 5/16/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: On 5/16/07, Claude Brisson <[EMAIL PROTECTED]> wrote: > Le mercredi 16 mai 2007 à 19:50 -0700, Nathan Bubna a écrit : > > > On the next test I made, I ran into the first real problem, I think: the > > > init(Object) method seems to not be called at all on an old request > > > tool. If you've got an idea about this symptome, well "tant > > > mieux" (don't know the english equivalent...), otherwise I'll > > > investigate - it will make me more familiar with the new codebase :-) > > > > does the log description of the toolboxes say whether the tool in > > question is "Old" or not? > > Yes, "old" (which -just guessing, correct me if I'm wrong- is synonym to > the fact that it has a "void init(Object data)" method, the one we'd > like to see called). yeah, it means that we need to support init(Object). tools should be treated as "old" if they have an init(Object) method that is NOT deprecated. i'm glad it at least identified the tool as "old" correctly. now to make sure that init() gets called... > > i thought i had this case supported, but i could be wrong. i haven't > > tested it much yet. > > Somehow reassuring to see you leave a few bugs sometimes... heh. > Claude > > > - > 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]
Re: [veltools] status of 2.x branch
On 5/16/07, Claude Brisson <[EMAIL PROTECTED]> wrote: Le mercredi 16 mai 2007 à 19:50 -0700, Nathan Bubna a écrit : > > On the next test I made, I ran into the first real problem, I think: the > > init(Object) method seems to not be called at all on an old request > > tool. If you've got an idea about this symptome, well "tant > > mieux" (don't know the english equivalent...), otherwise I'll > > investigate - it will make me more familiar with the new codebase :-) > > does the log description of the toolboxes say whether the tool in > question is "Old" or not? Yes, "old" (which -just guessing, correct me if I'm wrong- is synonym to the fact that it has a "void init(Object data)" method, the one we'd like to see called). yeah, it means that we need to support init(Object). tools should be treated as "old" if they have an init(Object) method that is NOT deprecated. i'm glad it at least identified the tool as "old" correctly. now to make sure that init() gets called... > i thought i had this case supported, but i could be wrong. i haven't > tested it much yet. Somehow reassuring to see you leave a few bugs sometimes... heh. Claude - 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]
Re: [veltools] status of 2.x branch
Le mercredi 16 mai 2007 à 19:50 -0700, Nathan Bubna a écrit : > > On the next test I made, I ran into the first real problem, I think: the > > init(Object) method seems to not be called at all on an old request > > tool. If you've got an idea about this symptome, well "tant > > mieux" (don't know the english equivalent...), otherwise I'll > > investigate - it will make me more familiar with the new codebase :-) > > does the log description of the toolboxes say whether the tool in > question is "Old" or not? Yes, "old" (which -just guessing, correct me if I'm wrong- is synonym to the fact that it has a "void init(Object data)" method, the one we'd like to see called). > i thought i had this case supported, but i could be wrong. i haven't > tested it much yet. Somehow reassuring to see you leave a few bugs sometimes... Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [veltools] status of 2.x branch
On 5/16/07, Claude Brisson <[EMAIL PROTECTED]> wrote: Le mercredi 16 mai 2007 à 17:24 -0700, Nathan Bubna a écrit : > > I just tried a drop-in replacement, just to see what would happen. It > > failed in my case due to the fact that the ViewTool interface > > disappeared - after all the efforts you made to reach BC we should > > probably put it back, as deprecated... > > hmm. it's already deprecated and useless as of the 1.3 release. it > should be trivial to remove reference to it. that's all you need to > do... Yes - and I knew it... some old tool lying around... > > (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?) > > no. newer should override older. since a tools.xml should always be > the newest configuration file, it should have the opportunity to > override any tool/toolbox/data definitions configured in the old > toolbox.xml. Ah. If overriding comes into play, it is of course the right order... > > [01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm > > > > (I don't use any struts, only jar.view... where does this reference to struts come from?) > > ah, this is interesting. i'm guessing you were actually using the > full velocity-tools jar, not just the velocity-tools-view jar. if > you are sure you were using the velocity-tools-view jar, then i'll > have to try it myself. this shouldn't have happened for that. Your guess was correct. I used 'jar' instead of 'jar.view' by inadvertence, and since jar == jar.struts... thought so. > anyway, assuming my guess is correct, here's the explanation: since > VelocityView will now load all available tools by default, it is > trying to load the VelocityStruts tools. during the load process, we > still create an instance to be sure (as early as possible) that we are > able to do so. so, when it tries to create a struts tool instance, > the VM is trying to load all the classes that tool needs. since you > don't have the struts dependencies on the classpath, that fails. this isn't quite right. i didn't look closely at the stack trace you sent. turns out, this is happening when just trying to look for an init() method in the tool. no new instance is being created yet. worse still, the error happens during a call to ToolConfiguration.toString(). that's definitely not ok. first i'm going to clean that up... > i'll have to think of a way to fail more gracefully (or perhaps just > log an error) when this happens. Yes, logging an error with its stacktrace looks enough to me. then i'll look into ways to shush errors when loading default tools... > in the meantime, you can add an init param to your VVS declaration in > your web.xml with the name: > > org.apache.velocity.tools.suppressDefaults > > and the value of: > > true > > that will let you get past this error and continue testing... or using the right jar... I really like the trace of the scoped tools in the log, BTW. On the next test I made, I ran into the first real problem, I think: the init(Object) method seems to not be called at all on an old request tool. If you've got an idea about this symptome, well "tant mieux" (don't know the english equivalent...), otherwise I'll investigate - it will make me more familiar with the new codebase :-) does the log description of the toolboxes say whether the tool in question is "Old" or not? i thought i had this case supported, but i could be wrong. i haven't tested it much yet. Claude - 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]
Re: [veltools] status of 2.x branch
Le mercredi 16 mai 2007 à 17:24 -0700, Nathan Bubna a écrit : > > I just tried a drop-in replacement, just to see what would happen. It > > failed in my case due to the fact that the ViewTool interface > > disappeared - after all the efforts you made to reach BC we should > > probably put it back, as deprecated... > > hmm. it's already deprecated and useless as of the 1.3 release. it > should be trivial to remove reference to it. that's all you need to > do... Yes - and I knew it... some old tool lying around... > > (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if > > tools.xml wasn't found?) > > no. newer should override older. since a tools.xml should always be > the newest configuration file, it should have the opportunity to > override any tool/toolbox/data definitions configured in the old > toolbox.xml. Ah. If overriding comes into play, it is of course the right order... > > [01:42:42.498] java.lang.NoClassDefFoundError: > > org/apache/struts/action/ActionForm > > > > (I don't use any struts, only jar.view... where does this reference to > > struts come from?) > > ah, this is interesting. i'm guessing you were actually using the > full velocity-tools jar, not just the velocity-tools-view jar. if > you are sure you were using the velocity-tools-view jar, then i'll > have to try it myself. this shouldn't have happened for that. Your guess was correct. I used 'jar' instead of 'jar.view' by inadvertence, and since jar == jar.struts... > anyway, assuming my guess is correct, here's the explanation: since > VelocityView will now load all available tools by default, it is > trying to load the VelocityStruts tools. during the load process, we > still create an instance to be sure (as early as possible) that we are > able to do so. so, when it tries to create a struts tool instance, > the VM is trying to load all the classes that tool needs. since you > don't have the struts dependencies on the classpath, that fails. > > i'll have to think of a way to fail more gracefully (or perhaps just > log an error) when this happens. Yes, logging an error with its stacktrace looks enough to me. > in the meantime, you can add an init param to your VVS declaration in > your web.xml with the name: > > org.apache.velocity.tools.suppressDefaults > > and the value of: > > true > > that will let you get past this error and continue testing... or using the right jar... I really like the trace of the scoped tools in the log, BTW. On the next test I made, I ran into the first real problem, I think: the init(Object) method seems to not be called at all on an old request tool. If you've got an idea about this symptome, well "tant mieux" (don't know the english equivalent...), otherwise I'll investigate - it will make me more familiar with the new codebase :-) Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [veltools] status of 2.x branch
On 5/16/07, Claude Brisson <[EMAIL PROTECTED]> wrote: Le mercredi 16 mai 2007 à 15:41 -0700, Nathan Bubna a écrit : > i don't know if anyone else has taken the time to try out Tools 2.x or > cares about it yet, but i thought i'd give an update anyway... For now I just followed your updates. I'll try them soon (as soon as I'll end up fighting with maven 2...). I am positively impressed by your work, btw. thanks :) > [...] > As this is a significant milestone, i thought i'd ask if anyone is > interested in having an alpha release or milestone build. I'd love to > get some feedback on the progress so far, as well as the backwards > compatibility of things. Would that help lower the barrier for some > of you to try it out? I just tried a drop-in replacement, just to see what would happen. It failed in my case due to the fact that the ViewTool interface disappeared - after all the efforts you made to reach BC we should probably put it back, as deprecated... hmm. it's already deprecated and useless as of the 1.3 release. it should be trivial to remove reference to it. that's all you need to do... I'm too drunk tonight (an official site release at work...) to commit anything but after having added it back, I got : [01:42:42.321] Velocity [debug] Loading configuration from: /WEB-INF/toolbox.xml [01:42:42.364] Velocity [trace] Searching for configuration at: /WEB-INF/tools.xml [01:42:42.366] Velocity [debug] Could not find file at: /WEB-INF/tools.xml (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?) no. newer should override older. since a tools.xml should always be the newest configuration file, it should have the opportunity to override any tool/toolbox/data definitions configured in the old toolbox.xml. [01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm (I don't use any struts, only jar.view... where does this reference to struts come from?) ah, this is interesting. i'm guessing you were actually using the full velocity-tools jar, not just the velocity-tools-view jar. if you are sure you were using the velocity-tools-view jar, then i'll have to try it myself. this shouldn't have happened for that. anyway, assuming my guess is correct, here's the explanation: since VelocityView will now load all available tools by default, it is trying to load the VelocityStruts tools. during the load process, we still create an instance to be sure (as early as possible) that we are able to do so. so, when it tries to create a struts tool instance, the VM is trying to load all the classes that tool needs. since you don't have the struts dependencies on the classpath, that fails. i'll have to think of a way to fail more gracefully (or perhaps just log an error) when this happens. in the meantime, you can add an init param to your VVS declaration in your web.xml with the name: org.apache.velocity.tools.suppressDefaults and the value of: true that will let you get past this error and continue testing... [01:42:42.498] at java.lang.Class.getDeclaredMethods0(Native Method) [01:42:42.498] at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [01:42:42.498] at java.lang.Class.getMethod0(Class.java:2670) [01:42:42.498] at java.lang.Class.getMethod(Class.java:1603) [01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.isOldTool(ToolConfiguration.java:134) [01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.toString(ToolConfiguration.java:205) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106) [01:42:42.498] at org.apache.velocity.tools.config.ToolboxConfiguration.toString(ToolboxConfiguration.java:154) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106) [01:42:42.498] at org.apache.velocity.tools.config.FactoryConfiguration.toString(FactoryConfiguration.java:130) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.configure(VelocityView.java:496) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:356) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:291) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.(VelocityView.java:189) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.(VelocityView.java:181) [01:42:42.498] at org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils.java:80) [01:
Re: [veltools] status of 2.x branch
Le mercredi 16 mai 2007 à 15:41 -0700, Nathan Bubna a écrit : > i don't know if anyone else has taken the time to try out Tools 2.x or > cares about it yet, but i thought i'd give an update anyway... For now I just followed your updates. I'll try them soon (as soon as I'll end up fighting with maven 2...). I am positively impressed by your work, btw. > [...] > As this is a significant milestone, i thought i'd ask if anyone is > interested in having an alpha release or milestone build. I'd love to > get some feedback on the progress so far, as well as the backwards > compatibility of things. Would that help lower the barrier for some > of you to try it out? I just tried a drop-in replacement, just to see what would happen. It failed in my case due to the fact that the ViewTool interface disappeared - after all the efforts you made to reach BC we should probably put it back, as deprecated... I'm too drunk tonight (an official site release at work...) to commit anything but after having added it back, I got : [01:42:42.321] Velocity [debug] Loading configuration from: /WEB-INF/toolbox.xml [01:42:42.364] Velocity [trace] Searching for configuration at: /WEB-INF/tools.xml [01:42:42.366] Velocity [debug] Could not find file at: /WEB-INF/tools.xml (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?) [01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm (I don't use any struts, only jar.view... where does this reference to struts come from?) [01:42:42.498] at java.lang.Class.getDeclaredMethods0(Native Method) [01:42:42.498] at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [01:42:42.498] at java.lang.Class.getMethod0(Class.java:2670) [01:42:42.498] at java.lang.Class.getMethod(Class.java:1603) [01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.isOldTool(ToolConfiguration.java:134) [01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.toString(ToolConfiguration.java:205) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106) [01:42:42.498] at org.apache.velocity.tools.config.ToolboxConfiguration.toString(ToolboxConfiguration.java:154) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106) [01:42:42.498] at org.apache.velocity.tools.config.FactoryConfiguration.toString(FactoryConfiguration.java:130) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.configure(VelocityView.java:496) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:356) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:291) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.(VelocityView.java:189) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.(VelocityView.java:181) [01:42:42.498] at org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils.java:80) [01:42:42.498] at org.apache.velocity.tools.view.VelocityViewServlet.init(VelocityViewServlet.java:102) If you need any custom debug log to investigate this, just ask! Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [veltools] status of 2.x branch
i don't know if anyone else has taken the time to try out Tools 2.x or cares about it yet, but i thought i'd give an update anyway... - The minor issues with the IteratorTool and RenderTool demos have been resolved. - The VelocityStruts tools are fully up to date with the new infrastructure. - All the tools have been massaged so they should work with either the deprecated XMLToolboxManager and ServletToolboxManager or the new ToolManager and VelocityView infrastructure. Almost everything listed on the wiki planning page has been accomplished. Overall, i think things are about as backwards compatible as they are going to get. The current examples run on the new tool management infrastructure without any modification or problems. The only people likely to be bitten in an upgrade (not counting the many, many deprecation notices) are those implementing their own ViewContext or otherwise extending/overriding much of the ToolboxManager cruft. If the user and dev lists are any indication, such people are few and far between. As this is a significant milestone, i thought i'd ask if anyone is interested in having an alpha release or milestone build. I'd love to get some feedback on the progress so far, as well as the backwards compatibility of things. Would that help lower the barrier for some of you to try it out? As far as further development goes, these are what's next on my mind: - the drudgery of adding the great amounts of missing javadoc and updating the old stuff - creating more parity (perhaps even inheritance) between ToolManager (for non-webapp use) and VelocityView (for webapps). this idea is the largest threat to the stability of the new tool management API. - the possibility of more package shifting, specifically of the actual tool classes - updating and integrating Veltag (soon to be known as VelocityViewTag). this is greatly hampered by the static repo issues in Engine 1.5's StringResourceLoader, but i still want to move ahead on it now, without waiting on Engine 1.6. I'm still debating whether to forget about caching (leading to lousy performance) or include a light StringResourceLoader impl specifically for Veltag's use. - updating the example applications to be examples of the new management API (rather than demonstrations of the new APIs backwards compatibility) - updating/adding website docs for the new stuff and the many changes if anyone is interested in joining these efforts, that'd be swell. :) otherwise, i'll continue to plug along and look forward to your bug reports and patches once we actually get a release out. On 4/27/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: hey folks, so, i thought i'd give a heads up that VelocityTools 2.x has come along quickly. at this point, the new code can be used to build apps with much less configuration and much greater flexibility and power than the previous version. it is also almost completely backwards compatible. if you checkout and build the 2.x branch, you can run the simple and showcase examples with no changes and only two minor problems (having an issue with the IteratorTool and RenderTool demos). The VelocityStruts tools are not updated to work with the new system yet, but i should get to those soon. please feel free to check it out and give feedback. once i get 100% (or maybe 99.5%) backwards compatibility with the examples as they are, i will convert them to get rid of the deprecated config and such, in order to demonstrate the new configuration method(s). then we (probably i) can move on to bringing Veltag in (as VelocityViewTag) and perhaps creating a VelocityViewFilter and other such new possibilities. cheers, nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Velocity Wiki] Trivial Update of "VelocityTools2Planning" by NathanBubna
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Velocity Wiki" for change notification. The following page has been changed by NathanBubna: http://wiki.apache.org/velocity/VelocityTools2Planning The comment on the change is: status update -- 2. EasierToolAccessOutsideTemplates: Other objects in my webapp are often jealous of the VelocityViewServlet. They also would like to use some of the tools. Session scoped tools can be reached via the session, but it's not the case for application or request scoped tools. To achieve this, there would be a few things to do: * create a separate Toolbox for each scope and store it in the attributes of the corresponding servlet API object (request->!ServletRequest, session->!HttpSession, application->!ServletContext). (STATUS: done) * the !ViewToolContext (successor of !ChainedContext) will search the attributes for these Toolboxes and pass requests for the tools on to them. (STATUS: done) - * We could create a simple utility to help other classes retrieve tools, so they needn't all duplicate the code for finding the toolbox in the attributes and then requesting the tool from the toolbox... (STATUS: not done) + * We could create a simple utility to help other classes retrieve tools, so they needn't all duplicate the code for finding the toolbox in the attributes and then requesting the tool from the toolbox... (STATUS: done) 3. SimplifiedToolboxXML: In line with the ideas above, we could cut out some repetition in toolbox.xml by better organizing it and using XML more appropriately. For instance, the [http://svn.apache.org/viewvc/velocity/tools/trunk/examples/simple/WEB-INF/toolbox.xml?revision=487337&view=markup toolbox.xml for the "simple" example] could be simplified further to something like: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: projects vs components in JIRA
The DVSL project is now set up in JIRA. Claude Le mercredi 16 mai 2007 à 07:00 +, Henning P. Schmiedehausen a écrit : > "Will Glass-Husain" <[EMAIL PROTECTED]> writes: > > We already have TEXEN, ANAKIA and DBF projects. I did this a while ago. > > Best regards > Henning > > > >--=_Part_159196_5394995.1179036155720 > >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Content-Transfer-Encoding: 7bit > >Content-Disposition: inline > > >Anakia and Texen have separate projects. We just need to move the issues > >over. > > >I just gave you jira-administrator karma. > > >WILL > > >On 5/12/07, Claude Brisson <[EMAIL PROTECTED]> wrote: > >> > >> Anakia, Texen and DVSL are still declared as components of the Velocity > >> project in JIRA. IMO we need separate projects. If no-one disagree soon > >> (and if I've enough JIRA karma to do so) I'll create three new JIRA > >> projects. > >> > >> Claude > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > >-- > >Forio Business Simulations > > >Will Glass-Husain > >[EMAIL PROTECTED] > >www.forio.com > > >--=_Part_159196_5394995.1179036155720-- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-550) Velocimacros defined in a page are also access by other pages
Velocimacros defined in a page are also access by other pages - Key: VELOCITY-550 URL: https://issues.apache.org/jira/browse/VELOCITY-550 Project: Velocity Issue Type: Bug Components: Website Reporter: Chon-Ji Priority: Minor Hi, I have this weird problem in my velocity pages. I have two different modules on my website, both have a macro (with the same name) defined. For example, I have a macro #settable on module 1 and another #settable on module 2. They have the same name but the content differs slightly from each other. My problem is that soemtimes module1 access the #settable2 or vice versa. It never crossed my mind that having the same name would be a problem since they are on different pages. I thought that macro definition should only be local and not global. I was only able to solve it by using this configuration velocimacro.permissions.allow.inline.local.scope = true However this may affect other pages, is there another way to address this problem? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]