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.init(VelocityView.java:189) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:181) [01:42:42.498] at org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils.java:80)
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 à 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 à 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
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]
[veltools] status of 2.x branch
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]
