"Nathan Bubna (JIRA)" <[EMAIL PROTECTED]> writes:
> i don't understand either the need for or accomplishment of your
> changes to the DataInfo class. from glancing over the patch, it
> looks like just another way to skin the same cat. can you explain
> that better?
[ I'll keep that discussion here on the mailing list ]
The problem with the current DataInfo is, that it gets created by the
Digester in uninitialized state and then relies on being set up
correctly. If it does not happen because the users does a mistake in
configuring the object, then a DataInfo in an instable state is given
to the toolbox manager.
Right after creation, the key is empty, the type_id is unset (which
makes it 0, which is TYPE_ID_STRING probaby) and data is null.
Now if you call "getClassname()", which will happen if you add
<data>
<key>foo</key>
</data>
to your toolbox, you get a NPE in addTool(). And you've just added a
null value to the data map which will probably bite the user later on
the template.
My variant BTW contains a bug because getClassname() should read
public String getClassname()
{
return dataClass;
}
I wanted to make sure that DataInfo and ToolInfo are stable in any
state. Especially with the Digester not enforcing the keys and the
setting of Type and Value, IMHO is must be assured that never a
non-valid DataInfo object is added to the Toolbox. Going with the
class objects seemed the easiest way to me (however, I was sitting
with my notebook on a train and I had two crying children next to me,
so I couldn't think too clearly. :-)
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
