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]
