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]
