Also see the XMLC 2.2 Release Note, XMLC 2.2.1 Release Note, XMLC 2.2.2 Release Note, XMLC 2.2.3 Release Note, XMLC 2.2.4 Release Note, XMLC 2.2.5 Release Note, and XMLC 2.2.6 Release Note.
XMLC-2.2.7 was initially released, but pulled because of a fundamental issue with the enhancement "Allow for the supression of getElementXXX() methods" that was missed before release. The 2.2.7.1 release is essentially identical but takes care of the problem along with a new command line option and a slight change in semantics. See description of said enhancement for more information.
SSIReader was using straight File IO to resolve SSI's at runtime. This seems not to be working on Windows. Now using File IO at first to create a URL string (mostly for compile-time processing) and falling back to using URL's directly. The result in both cases is a URL string which gets fed into an InputSource and seems to work properly on all platforms.
Did exactly what had been done to XHTMLDocumentBase and copied getElementById(String) functionality from the Xerces HTMLDocumentImpl.
The implementation of getElementsByTagName(String) in XHTML had been generally copied from the HTML implementation without getting rid of the tagName.toUpperCase() that it was doing. Since XHTML requires lowercase, nothing ever matched so it always returned an empty NodeList. It now returns elements properly.
Boolean attribute methods in the XHTML DOM were returning false for anything but values of "y", "yes", and "true", which is totally wrong since the mere existence of a boolean attribute should trigger "true" and absence "false". That is now how it is implemented.
It is now possible to use ASM2 rather than BCEL for deferred parsing/dynamic loading. In fact, other bytecode modifiers could be implemented as well, as DynamicMLCreator has been changed to an interface. The nice thing about using ASM2 rather than BCEL is that ASM2 is 33k (and, theoretically, faster) while BCEL is 504k. Plus, ASM2 is in active development. BCEL has been pretty stagnant for quite a while, but it can be useful in cases where other code requires ASM1 and would conflict with XMLC's dependency on ASM2. If ASM2 exists in the classpath, it will be used in preference to BCEL even if both are in the classpath. BCEL will only be used if ASM2 is non-existent in the classpath.
Previously, URL rewriting was performed on attributes defined (and hardcoded) by each respective XMLCDomFactory implementation. This still happens by default, but it is now possible to override the defaults using OutputOptions.setURLRewriteAttributes(Set) or OutputOptions.setURLRewriteAttributes(String[]). This solves recently reported issues with URL rewriting breaking javascript code in event handler attributes such as "onclick". Further customization can be added by creating ones own URLRewriter implementation. However, that should be much less necessary with this change in place.
XMLCContext.getContext() was doing multiple lookups of the servlet-context-stored XMLCContext object. It now does it only once.
Spelled out the useage of xmlcReparseResourceDirs, xmlcReparsePackagePrefixes, and xmlcReparseDefaultMetaDataPath so one doesn't have to guess what the values need to look like, especially since they are different in different environments (Unix and Windows).
We only had the WML1.1 DTD in XMLC. In order to build against the newer DTD's, offline, I added the new ones. Updated XCatalog as well, of course. Applied a fix to both the 1.2 and 1.3 DTD's. The declaration of xml:space was invalid and caused a validation error. I updated XMLC's copies to comply with the XML spec. See http://www.w3.org/TR/2000/REC-xml-20001006#sec-white-space
It was requested that the getElementXXX() methods allow for configurable generic return types. This would allow for interfaces that don't change at the whim of an Id being moved to a differently named markup tag. As it turns out, optional getTagXXX() method generation was already implemented for this purpose. However, there still was no way to suppress getElementXXX() generation, partially defeating the purpose of the generic getTagXXX() methods. It is now possible to supress getElementXXX() method generation while enabling getTagXXX() generation using <documentClass suppressGetElementMethods="true" createGetTagMethods="true"/> or "-suppress-get-element-methods" and "-create-get-tag-methods". Note that the new "suppressGetElementMethods" attribute is optional and defaults to "false". Also note that any time getElementXXX() method generation is enabled, they will always use return types matching the most specific interface corresponding with the respective element being represented. Those desiring generic return types only should suppress getElementXXX() methods and enable getTagXXX() methods. Also note that if neither getElementXXX() or getTagXXX() methods are enabled, neither will setTextXXX() methods be enabled. If either one of the getXXX() methods are enabled, the setTextXXX() methods will be enabled.
Updated Eclipse .classpath file to account for the new ASM2 dependency along with version updates to various other jar dependencies.
Got rid of many warnings reported by Eclipse 3.1
Not sure exactly why XHTMLDocumentBase was implementing DocumentInfo, but it didn't need to. Made consistent with other DOMs which have their *DocumentImpl implement XMLObjectLink (including XHTMLDocumentImpl). XMLObject/XMLObjectImpl should be the only concrete class to implement DocumentInfo.
Got rid of usage of org.jaxen.dom.html.HTMLXPath. It has been removed from Jaxen's codebase for various technical reasons. DOMXPath is now used. All XPath queries on HTML elements must, again, be in upper case, as elements in the HTML DOM are stored.
For instance, it was like: expected one of "lazydom" or "xerces. Now it is: expected one of "lazydom" or "xerces".