RE: Bug in Classes.java

I have applied this patch. Shawn also noticed that I never did apply his
previously submitted patch from June 13...so I've done that as well.
Complete comments follow.
-------------------------------
<b>csc_082603_3</b> -  I also made a very minor update to the
/WEB-INF/bin/*.bat files so
that when running them, Ant will do logging via Log4J. Involved adding a
log4j.xml file to
the src directory that redirects output both to console and to
../WEB-INF/bin/ant.log.

<b>csc_082603_2</b> - I realized that I had never applied Shawn's patch from
June 13,
regarding enhancements to the Form mapping stuff. That is applied here as
well. Details
follow:

Christian and I have been talking about the addition of a new FormType
for TIME and also some modifications to the existing DATE and TIMESTAMP
type. I have attached to this email a patch that includes everything we
have discussed if anyone else would like to provide some input. You can
search for saw_061203_2 to see everything that has changed.

New FormType: TIME - This is a new type that allows parsing of time values
without
any date component. This will return a java.sql.Time object since that is
the
only representation in the core Java packages for a type that is
strictly time.

The parsing process will first try to parse as a long value
(representing the time in milliseconds)... this makes it convenient to
embed the time in a URL, for example. It will then try each of the 4
time formats (SHORT, MEDIUM, LONG, FULL) and finally will try to parse
from the SQL time format.

Changes to TIMESTAMP - Timestamp has been modified to do exactly the same
parsing
steps as TIME except it will obviously be using the datetime parser
(DateFormat.getDateTimeInstance) instead of the time parser. It will
return an instance of java.sql.Timestamp (as it did before).

Changes to DATE - I modified date so that it will also try the two new
parsing steps
referenced above (first try to parse a long; lastly try to parse from
SQL date format). In any case it will still always return strictly a
java.util.Date object.

Note that I also fixed the nagging test case problem we've been having with
data validation in
the THAI locale. Basically, I just modified the test case to skip the thai
locale until we have
someone who knows enough about it to be able to say what are valid dates and
what aren't. Thai
uses a solar calendar, which means what we consider to be leap years aren't.
This was causing
test cases to fail, and since I don't know enough about thai to know what's
actually correct,
for now I am just removing this from the test case. The upshot of all this
is that unit tests
are now 100% clean (for the first time in a long time)

<b>csc_082603_1</b> - Apply a new patch submitted by Shawn Wilson that fixes
a bug in
Classes.getAllInterfaces() that was causing problems with loading an XML
DOM. Basically,
when getting a list of interfaces, we need to explicitly check the parent
objects for
interfaces as well (they don't automatically get returned in the list, as
originally
supposed). This was causing serious problems in that BTemplate was not able
to find the
proper XML renderer because the DOM implementation did not _directly_
implement Node (its
parent class did). Search for saw_082603_1 for details.

----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Shawn Wilson
> Sent: Tuesday, August 26, 2003 8:30 AM
> To: [email protected]
> Subject: [Barracuda] Bug in Classes.java
>
>
> Last night I discovered a potentially fatal bug in
> org.enhydra.barracuda.plankton.Classes that can prevent a document from
> rendering properly depending on the structure of the DOM implementation
> classes.
>
> Basically the Classes.getAllInterfaces() method was only searching the
> interface hierarchy of the given class but not searching the interface
> hierarchies of the class's parent classes. This causes problems when
> AbstractBComponent tries to determine the renderer for a given
> DOM element.
>
> Depending on the DOM implementation used, when AbstractBComponent would
> look for a renderer for the current DOM element it could potentially not
> find a renderer even though the element implements the Node interface.
> Apparently DOM elements in the lazydom implementation implement the Node
> interface directly (because Christian noted the HelloWorld3 example
> worked), however when I compiled without using lazydom the implementing
> class apparently extended another class that implemented Node so
> Barracuda wasn't able to find any renderer for it (because it didn't
> search the interfaces of the parent classes).
>
> I have attached a patched version of Classes.java so that Barracuda will
> now properly locate the renderer for any XML Node element independent of
> the specific DOM implementation. Search for saw_082603_1 to see what I
> changed (+2 lines).
>
> -shawn
>