A_Changes_History


1   /*
2    * Copyright (C) 2003  Christian Cryder [christianc@granitepeaks.com]
3    *
4    * This library is free software; you can redistribute it and/or
5    * modify it under the terms of the GNU Lesser General Public
6    * License as published by the Free Software Foundation; either
7    * version 2.1 of the License, or (at your option) any later version.
8    *
9    * This library is distributed in the hope that it will be useful,
10   * but WITHOUT ANY WARRANTY; without even the implied warranty of
11   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
12   * Lesser General Public License for more details.
13   *
14   * You should have received a copy of the GNU Lesser General Public
15   * License along with this library; if not, write to the Free Software
16   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
17   *
18   * $Id: A_Changes_History.java,v 1.209 2004/02/03 02:55:25 christianc Exp $
19   */
20  package org.enhydra.barracuda;
21  
22  /**
23   * <p>The purpose of this class is to track all major changes made to
24   * the Barracuda framework. If you check changes into cvs, you must
25   * document those changes here. The list should be sorted in reverse
26   * chronological order (newer at the top).</p>
27   *
28   * <li>
29   *   <p>--------------- RELEASED 1.2.6 ---------------------</p>
30   * </li>
31   * <ul>
32   *   <p><b>saw_020204_1</b> - Updated BlockIterateHandler and DefaultDOMWriter to fix a problem
33   *      where the DOCTYPE would not get rendered to the final HTML document.
34   * </ul>
35   * <ul>
36   *   <p><b>csc_013104_2</b> - Changed all the license verbiage to LGPL. Rebuilt all the jars.
37   *      Got BarracudaDiscRack upgraded to the latest version. Started working on updating all the docs
38   *      for the new 1.2.6 release. At this point, we are very close to being ready to roll a build (still
39   *      waiting for a new Jivan binary licensed under LGPL).
40   * </ul>
41   * <ul>
42   *   <p><b>csc_013104_1</b> - Minor mod to HttpConverter to ensure that if you pass in a map
43   *      to convert it to a URL string it will automatically create that string in sorted order
44   * </ul>
45   * <ul>
46   *   <p><b>csc_013004_1</b> - Added a very important (but hacky) patch to the BlockIterateHandler to 
47   *      work correctly with the CommaSeparatedDOMWriter. This needs to make it into the 1.2.6 build
48   *      (I will retag as soon as Jivan is ready)
49   * </ul>
50   * <ul>
51   *   <p><b>csc_012904_1</b> - Added the CommaSeparatedDOMWriter (courtesy Shawn Wilson [shawnw@atmreports.com]).
52   *      This class makes it very easy to render your DOMs to a comma separated format (ie. download in browser,
53   *      or to excel). Also upgraded to XMLC 2.2.4 and verified that it seems to work fine.
54   * </ul>
55   * <ul>
56   *   <p><b>csc_012804_1a</b> - Additional work to the DOMWriter interface to add the following methods:
57   *          void prepareResponse(HttpServletResponse resp)
58   *          void setLeaveWriterOpen(boolean val)
59   *          boolean getLeaveWriterOpen()
60   *      This was necessary so that BlockIterateHandler could use whatever DOMWriter you provide (ie. if
61   *      you want to plug in a custom DOMWriter with BlockIterator, now you can.
62   * </ul>
63   * <ul>
64   *   <p><b>csc_012804_1</b> - Minor tweak to GenerateSSIs taskdef, so that it doesn't include the ssi comment
65   *      tags in the generated file. In other words, this taskdef creates ssis by looking for comment tags
66   *      of the format:
67   * 
68   *          <!-- start foo.ssi -->
69   *          <!-- end foo.ssi -->
70   *
71   *      What was happening was these tags themselves were being included in the generated ssi, and this caused
72   *      problems in the case of custom renderers where the destination file formats doesn't allow for comments
73   * </ul>
74   * <ul>
75   *   <p><b>csc_012704_1</b> - Minor tweak to BlockIterateHandler to correctly write out the document type
76   *      if encountered
77   * </ul>
78   * <ul>
79   *   <p><b>csc_011904_2</b> - Minor change to HttpSessionStateMap - when removing an attribute from the session,
80   *      occasionally getting a Null Pointer Exception when you try to remove an attribute from the session but
81   *      its expired already. Just consume the error and return null.
82   * </ul>
83   * <ul>
84   *   <p><b>csc_011904_1</b> - Minor change - when invalidating state and removing the session repository,
85   *      clear out the map/registered values in that SessionRepository before actually removing it from the session
86   * </ul>
87   * <ul>
88   *   <p><b>csc_011704_2</b> - Minor change - previously we were storing a reference to the session in the 
89   *      Session OR, which really wasn't a very good idea because it was a circular reference. Now there is a
90   *      static getRawSession() method that returns the underlying session object (and creates it if it doesn't
91   *      already exist). You should only use this if you need to work with the session in some way other than 
92   *      simply to put data in and get it back out.
93   * </ul>
94   *   <p><b>csc_011704_1</b> - More work on ObjectRepository, to make it work better at cleaning up sessions stuff.
95   *      there is now a convenience class called SessionManager to make it easier to work with the session (and invalidate
96   *      it). As of this change, invalidating a session should cause the OR to be properly cleaned up (previously this
97   *      was something of a problem).
98   * </ul>
99   * <ul>
100  *   <p><b>csc_011604_1</b> - Minor change to ObjectRepository making it possible now to get all of the underlying
101  *      servlet sessions. This is primarily intended for debugging purposes.
102  * </ul>
103  * <ul>
104  *   <p><b>csc_011504_1</b> - Very minor tweak to the DispatchQueue interface, adding setRequiresResponse() and
105  *      setResponseHandled() to the interface so that we can programatically manipulate this. Shouldn't break
106  *      any existing code unless someone has their own implementation of DispatchQueue. Also remove a couple
107  *      of System.printlns that should have been removed previously
108  * </ul>
109  * <ul>
110  *   <p><b>csc_010504_3</b> - Minor fix to ApplicationGateway to make it correctly catch any exceptions or errors
111  *      thrown during long running process and cache them in session so the redirect can display them
112  * </ul>
113  * <ul>
114  *   <p><b>csc_010504_2</b> - Minor patch to CollectionsUtil to handle a null pinter exception when printing
115  *      stack trace info on a state map
116  * </ul>
117  * <ul>
118  *   <p><b>csc_010504_1</b> - Very minor change to ApplicationGateway to make it easier to debug the LongRunning stuff
119  * </ul>
120  * <ul>
121  *   <p><b>csc_010404_1</b> - Lots of changes...
122  *   <p>Added support for LongRunning events (described in /Barracuda/docs/events/long_running.html)
123  *   <p>Added support for setting Class objects in ObjectRepositoryAssembler
124  *   <p>Changed the BaseEvent interface - added new method getEventURL() and deprecated getEventIDWithExtension(). 
125  *      getEventURL() will return any params associated with the event as part of the url string
126  *   <p>other misc changes
127  * </ul>
128  * <ul>
129  *   <p><b>csc_112203_1</b> - Missed a spot in ListValidator. Thanks for catching this, Thorsten.
130  * </ul>
131  * <ul>
132  * <li>
133  *   <p><b>jrk_20031202.1</b> - Applied fix for HTMLComponentRenderer, courtesy of David R Robison [drrobison@openroadsconsulting.com].
134  *      Empty Text nodes were being seen as invalid children for certain tags, so HTMLComponentRenderer was adding new &quot;valid&quot;
135  *      children, which were actually invalid since they already existed.</p>
136  *   <p>Added JivanDOMWriter suppplied by Arno Schatz [gare@gmx.net] to allow for serialization by Jivan where we only had XMLC
137  *      serialization available before.  This matches up nicely with the JivanDOMFactory.</p>
138  *   <p>Updated Ant tasks to not reference the protected &quot;project&quot; attribute of the org.apache.tools.ant.ProjectComponent class
139  *      since this usage is now deprecated in Ant-1.6.  Using getProject() and setProject(Project) instead.</p>
140  * </li>
141  * <li>
142  *   <p><b>csc_112103_1</b> - Minor (but important) fix to TemplateHelper to make it possible for multiple
143  *      Set_Attr directives to be embedded in a single node without stomping on one another. Also applied a
144  *      couple of small patches to DefaultEventPool (giving the cleanup thread a name) and to ListValidator
145  *      (making it work on List, not just ArrayList). Thanks to Thorsten M�ller [ThorstenMoeller@web.de]
146  *      for providing the patches...
147  * </li>
148  * <li>
149  *   <p><b>csc_111703_1</b> - Add a method getSession() to SessionObjectRepository. There are 2 ways to
150  *      access the session information now from the OR.
151  *      1) HttpSession session = ((ObjectRepository.SessionRepository) ObjectRepository.getSessionRepository()).getSession();
152  *      2) HttpSession session = (HttpSession) ObjectRepository.getSessionRepository().getState(ObjectRepostiory.HTTP_SESSION);
153  * </li>
154  * <li>
155  *   <p><b>csc_111203_1</b> - Fixed a bug in ObjectRepositoryAssembler, where if you had a <method> tag
156  *      following a <prop> tag, it was not clearing the argList after the <prop> tag was finished, and
157  *      so you would end up with an extra argument when trying to invoke the <method>
158  * </li>
159  * <li>
160  *   <p><b>csc_111103_1</b> - Added the ability to easily configure doc type settings in
161  *      DefaultDOMWriter for all the OutputOptions created by getDefaultOutputOptions()...all you
162  *      have to do is set DefaultDOMWriter.DEFAULT_OO_PUBLIC_ID and DefaultDOMWriter.DEFAULT_OO_SYSTEM_ID
163  *      via obj repository assembler.
164  * </li>
165  * <li>
166  *   <p><b>csc_111003_1</b> - Added pre/post iterate methods to the BlockIterator interface
167  * </li>
168  * <li>
169  *   <p><b>csc_101803_2</b> - Fixed 3 additional problems. First, I noticed that sometimes when trying
170  *      to compile or build jars I was getting a null pointer exception in Localize - it was returning
171  *      a null ResourceBundle. I have no idea why this is, so I just added a check for that case. When
172  *      was doing a clean/compile it was working (so it was only on subsequent builds). Go figure.
173  *      Localization still seems to be working just fine apart from that.
174  *   </p><p>
175  *      Second, added the ability to remove keys by wildcard to DefaultStateMap. Previously, this
176  *      was implemented only in HttpSessionStateMap.
177  *   </p><p>
178  *      Finally, note that I modified the SoftHashMap implementation so that it will return
179  *      an entry set, making it possible to iterate through the keys (meaning you can get a list
180  *      of keys in the object repository even when its backed by SoftHashMap).
181  * </li>
182  * <li>
183  *   <p><b>csc_101303_1</b> - Minor tweak to previous change on csc_100603_1...changed the logging
184  *      level to warn, rather than error
185  * </li>
186  * <li>
187  *   <p><b>jrk_20031010.1</b> - Cleaned up DOMFactory and DOMLoader interfaces to make them more flexible
188  *      and easier to implement.  Got rid of all non-getDOM() methods from DOMLoader, since they seemed to
189  *      be more implementation specific, and removed all cases of ViewCapabilities from the interface.  The
190  *      latter change required changes to a good number of files in the Barracuda source including examples
191  *      and such, but all it was being used for is extracting the locale, so this change shouldn't be a big
192  *      deal for users.  Modified javadoc for both DOLoader and DOMFactory to be more clear.  Updated DefaultDOMLoader
193  *      register/deregisterDOMFactory() to take a String argument instead of a class.  This makes it more
194  *      flexible in dealing with non object-wrapped dom loaders such as Jivan.</p>
195  *   <p>Speaking of Jivan, I implemented a new JivanDOMFactory.  This also required adding the Jivan jar to
196  *      WEB-INF/jars in order to build.</p>
197  *   <p>Note that as a result of the interface changes to DOMLoader, the DefaultApplicationAssembler no longer
198  *      supports the &lt;dom-loader&gt; and &lt;dom-loader-register&gt; elements.  However, this functionality
199  *      was considered deprecated anyway since the ObjectRepositoryAssembler is able to script this in a much
200  *      cleaner way.</p>
201  * </li>
202  * <li>
203  *   <p><b>csc_100603_1</b> - Modified ApplicationGateway so that there is a new RESPOND_WITH_404
204  *      constant which defaults to false but can be overriden to true. If true, rather than create
205  *      a generic HttpRequestEvent when a bad event is specified, simply return a 404 error.
206  *      Thanks to Thorsten M�ller [ThorstenMoeller@web.de] for making this suggestion.
207  * </li>
208  * <li>
209  *   <p><b>jrk_20031002.1</b> - Cleaned up mainly ResourceGateway.  Calling resp.flushBuffer() instead of
210  *      out.flush(), got rid of outdated comments and commented code, only override doGet() and doPost()
211  *      rather than all the do*() methods because the others don't apply to the ResourceGateway functionality,
212  *      removed unnecessary imports, change public static vars to be non-final as they should have been left,
213  *      and tightened some code up.</p>
214  *   <p>Also modified ParamGateway and ScriptDetector to remove the out.close() calls.  resp.flushBuffer()
215  *      commits the response and that is all that is needed.  Also added init() method to ParamGateway and
216  *      got rid of spurious do*() methods just like in ResourceGateway.</p>
217  * </li>
218  * <li>
219  *   <p><b>saw_092603_1</b> - Recoded most of the classes within ObjectRepository to fix a current
220  *      bug but more importantly to prevent the same type of bug in the future. Specifically the
221  *      clearState() method was not being overridden. The way the classes were coded, they extended
222  *      from ObjectRepository (and therefore DefaultStateMap) but in fact was not utilizing anything
223  *      provided from those classes.
224  * </li>
225  * <li>
226  *   <p><b>jrk_20030916.1</b> - Applied patch to the the EventBuilder taskdef provided by
227  *      Thorsten M�ller [ThorstenMoeller@web.de].  It adds (optionally) the ability to specify one's own
228  *      template file for templating generated event classes.  This was done by adding
229  *      an optional attribute to the taskdef called "template" where one can provide a fully qualified file
230  *      path to the template file.</p>
231  *   <p>The algorithm to choose the template is as follows:
232  *     <ol>
233  *       <li>Choose the 'template' attribute inside the Ant task. If the attribute is absent...</li>
234  *       <li>Choose the 'template' attribute inside the <build-events> tag. If the attribute is absent...</li>
235  *       <li>Fallback and choose "EventBuilder.template".</li>
236  *     </ol></p>
237  * </li>
238  * <li>
239  *   <p><b>jrk_20030909.1</b> - updated the EventBuilder taskdef in the same way that Shawn updated
240  *      the Localize taskdef.  That is, so that it no longer compiles the
241  *      resulting .java files into .class files. This step is now left for the developer to add to
242  *      their build.xml using the standard &lt;javac&gt; taskdef which provides more options.</p>
243  *   <p>Note that event task syntax changed a bit.  There are now no 'srcdir' or 'destdir' attributes,
244  *      there is a new 'sourceout' attribute (which replaces whatever you had in 'srcdir'), and there
245  *      is no nested classpath element support (nor is it necessary any longer). Updated the main
246  *      build.xml file and those of the contrib projects to support the modified functionality</p>
247  * </li>
248  * <li>
249  *   <p><b>saw_090803_1</b> - updated the Localize taskdef so that it no longer compiles the
250  *      resulting .java files into .class files. This step is now left for the developer to add to
251  *      their build.xml using the standard &lt;javac&gt; taskdef which provides more options.
252  * </li>
253  * <li>
254  *   <p><b>csc_090303_1</b> - modify the BScript renderer so that it can create a default node
255  *      (allowing us to easily pass a BScript component back from the model)
256  * </li>
257  * <li>
258  *   <p><b>csc_090103_1</b> - added support for <control-events> section in the EventBuilder
259  *      taskdef and events.xml file (see src/org/enhydra/barracuda/examples/ex1/events.xml for
260  *      an example). A control event can be fired programatically, but will NOT be dispatched
261  *      through the ApplicationGateway (meaning a user can not manually fire the event by
262  *      specifying it in the URL). Prior to this, you had to manually define control events
263  *      in code.
264  * </li>
265  * <li>
266  *   <p><b>jrk_20030828.2</b> - update log4j-sandbox library.  Now only one jar is required and no more worrying
267  *      about where to put the selectors -vs- servlets when using log4j.jar in a parent class loader
268  *      (and not WEB-INF/lib).  All that needs to be remembered now is to keep the single sandbox jar
269  *      together with log4j.jar.  If you remove one from WEB-INF/lib, remove the other as well
270  *      (and make sure to have them together in a parent classloader).</p>
271  *   <p>Also added new appender which allows for logging to the servlet context log provided by the
272  *      server.  This was just added to the log4j-sandbox for version 0.2alpha.  Made it the root
273  *      appender.  For now, we will not log to main.log by default.</p>
274  * </li>
275  * <li>
276  *   <p><b>jrk_20030828.1</b> - Applied patch from Jancsi A. Farkas [csaken@fx.ro] to fix an issue in
277  *      the {@link org.enhydra.barracuda.core.helper.servlet.HttpServletRequestWrapper HttpServletRequestWrapper}
278  *      where <code>getParameter(String)</code> was not making a distinction between parameter &quot;id&quot;
279  *      and &quot;aaa_id&quot;.</p>
280  * </li>
281  * <li>
282  *   <p><b>csc_082603_4</b> - Another patch, this time to BAction, adding a new setDisableFormLocking(),
283  *      which makes it possible to keep the component from using the doSubmitAndLock() call (it will use the
284  *      doSubmitAndNoLock() call instead). This is needed when the target action for the form is showing
285  *      up in another window and not writing over existing window's contents. Previously, this scenario was
286  *      leaving the submit button locked. THanks to Shawn Wilson [shawn@lannocc.com] for this patch.
287  * </li>
288  * <li>
289  *   <p><b>csc_082603_3</b> -  I also made a very minor update to the /WEB-INF/bin/*.bat files so
290  *      that when running them, Ant will do logging via Log4J. Involved adding a log4j.xml file to
291  *      the src directory that redirects output both to console and to ../WEB-INF/bin/ant.log.
292  * </li>
293  * <li>
294  *   <p><b>csc_082603_2</b> - I realized that I had never applied Shawn's patch from June 13,
295  *      regarding enhancements to the Form mapping stuff. That is applied here as well. Details
296  *      follow:
297  *
298  *   <p>Christian and I have been talking about the addition of a new FormType
299  *      for TIME and also some modifications to the existing DATE and TIMESTAMP
300  *      type. I have attached to this email a patch that includes everything we
301  *      have discussed if anyone else would like to provide some input. You can
302  *      search for saw_061203_2 to see everything that has changed.
303  *
304  *   <p>New FormType: TIME - This is a new type that allows parsing of time values without
305  *      any date component. This will return a java.sql.Time object since that is the
306  *      only representation in the core Java packages for a type that is
307  *      strictly time.
308  *
309  *   <p>The parsing process will first try to parse as a long value
310  *      (representing the time in milliseconds)... this makes it convenient to
311  *      embed the time in a URL, for example. It will then try each of the 4
312  *      time formats (SHORT, MEDIUM, LONG, FULL) and finally will try to parse
313  *      from the SQL time format.
314  *
315  *   <p>Changes to TIMESTAMP - Timestamp has been modified to do exactly the same parsing
316  *      steps as TIME except it will obviously be using the datetime parser
317  *      (DateFormat.getDateTimeInstance) instead of the time parser. It will
318  *      return an instance of java.sql.Timestamp (as it did before).
319  *
320  *   <p>Changes to DATE - I modified date so that it will also try the two new parsing steps
321  *      referenced above (first try to parse a long; lastly try to parse from
322  *      SQL date format). In any case it will still always return strictly a
323  *      java.util.Date object.
324  *
325  *   <p>Note that I also fixed the nagging test case problem we've been having with data validation in
326  *      the THAI locale. Basically, I just modified the test case to skip the thai locale until we have
327  *      someone who knows enough about it to be able to say what are valid dates and what aren't. Thai
328  *      uses a solar calendar, which means what we consider to be leap years aren't. This was causing
329  *      test cases to fail, and since I don't know enough about thai to know what's actually correct,
330  *      for now I am just removing this from the test case. The upshot of all this is that unit tests
331  *      are now 100% clean (for the first time in a long time)
332  * </li>
333  * <li>
334  *   <p><b>csc_082603_1</b> - Apply a new patch submitted by Shawn Wilson that fixes a bug in
335  *      Classes.getAllInterfaces() that was causing problems with loading an XML DOM. Basically,
336  *      when getting a list of interfaces, we need to explicitly check the parent objects for
337  *      interfaces as well (they don't automatically get returned in the list, as originally
338  *      supposed). This was causing serious problems in that BTemplate was not able to find the
339  *      proper XML renderer because the DOM implementation did not _directly_ implement Node (its
340  *      parent class did). Search for saw_082603_1 for details.
341  * <li>
342  * </li>
343  *   <p><b>csc_082103_1</b> - Expanded the functionality of HttpSessionStateMap's removeState()
344  *      method to support the notion of wildcarding, allowing you to remove multiple keys in one fell
345  *      swoop. Basically, if the key is a String, which ends with an '*', then any keys that
346  *      start with that string will be removed (and in this case, the method returns a Map of
347  *      key/val pairs that got removed, rather than a single object that got removed). This
348  *      approach is not quite as flexible as using regular expressions, but that would make us
349  *      dependent on jdk1.4 (so we won't go there for now). Note that this class backs the
350  *      ObjectRepository data structures, so this functionality applies there as well.
351  * </li>
352  * <li>
353  *   <p>--------------- RELEASED 1.2.5 ---------------------</p>
354  * </li>
355  * <li>
356  *   <p><b>jrk_20030815.2</b> - Updated .xmlc files for corresponding XML templates in the
357  *       tutorials to use an absolute &quot;file:/&quot; path to the tutorials.xcat file.
358  *       Also updated the path to the dtd within the .xcat file to use an absolute path
359  *       to the dtds existing in the &quot;xlib/dtds&quot; directory.  Updated the build.xml
360  *       file to copy dtds from Barracuda/dtds to src/xlib/dtds. These are, later, copied to
361  *       WEB-INF/classes/xlib/dtds in the compile.post.process target.  This allows for
362  *       relolving the dtd not only at compile time, but also at runtime by deferred parsing.
363  *       Updated the tutorials options.xmlc to use the -for-deferred-parsing option. With this change,
364  *       every example and tutorial in Barraucda is now compiled for deferred parsing!</p>
365  * </li>
366  * <li>
367  *   <p><b>jrk_20030815.1</b> - updates for deferred parsing.  updated options.xmlc files to use
368  *       -for-deferred-parsing, updated the build.xml to copy generated .xmlc files and *.*ml files
369  *       to the classes dir so they are available for deferred parsing to load at runtime.
370  *       Also updated everything to use the DefaultDOMLoader rather than the XMLCStdFactory to load
371  *       XMLC classes.</p>
372  *   <p>Note that this provides a huge reduction in jar size for the BConfig app.  In fact,
373  *       barracuda-config.jar went from 960k to 289k.  That's a reduction of 671k, or 70%,
374  *       in jar file size!!!  The other jars show reduction in file size as well, but the
375  *       BConfig app with its many large templates really shows off what deferred parsing can do.</p>
376  *   <p>Note that the Deferred parsing dom factory (which DefaultDOMLoader uses by default) is backward compatible
377  *       with classes not compiled for deferred parsing.  The converse is not true, though, so it is wise
378  *       to use the DefaultDOMLoader and never ever use the XMLCStdFactory to load classes.</p>
379  *   <p>One caveat I found with deferred parsing is that if one uses the &quot;-dom xerces&quot; option
380  *      when compiling XML files, the templates are rendered unmodified. BTemplate directives are left
381  *      in rather than being replaced by data from the model.  Everything works fine when using
382  *      &quot;-dom lazydom&quot; or not specifying the -dom option at all. Not clear on why this is, but
383  *      since the simple workaround is to not use the xerces dom, this won't hold up the XMLC or Barracuda
384  *      releases.  Hopefully the problem will be found and fixed post XMLC-2.2.</p>
385  * </li>
386  * <li>
387  *   <p><b>jrk_20030814.1</b> - Update ScriptDetector in the same way I updated ParamGateway to make
388  *       things more efficient.  Also updated sample.event-gateway.xml with a commented out way to
389  *       turn script detection on.</p>
390  * </li>
391  * <li>
392  *   <p><b>jrk_20030814.1</b> - Applied patch from Stefan Armbruster to make the CopyAndReplace task
393  *      compatible with both Ant-1.5.x and Ant-1.6.x.  A change to the Copy task interface, which
394  *      CopyAndReplace extends, caused errors in both building and running the task under Ant-1.6.x.</p>
395  * </li>
396  * <li>
397  *   <p><b>jrk_20030812.1</b> - Fixed BAction#hasAction() to take into account not only
398  *      actions specifically set via BAction#setAction(), but also those set via
399  *      BAction#addEventListener().  Without this, the HTMLActionRenderer won't render
400  *      BAction or BLink components bound to HTMLActionElement's with actions set by
401  *      adding an event listener because it checks if the component has an action before
402  *      attempting to manipulate the element.  If an &amp;action&amp; is not defined to
403  *      include event listeners, then hasAction() returns false and no manipulation is performed</p>
404  *   <p>Also updated the CompEx4 .java and .html example files to clean them up and make
405  *      them more clear about what the purpose(s) of their examples are. Note that this was
406  *      where I discovered the bug in BAction#hasAction().</p>
407  * </li>
408  * <li>
409  *   <p><b>jrk_20030808.1</b> - Added write(Node, OutputStream) to the DOMWriter interface.</p>
410  * </li>
411  * <li>
412  *   <p><b>jrk_20030731.1</b> - Lots of scripting updates and a couple other things.
413  *      Updated ParamGateway.java and ClientServerHTTPLib.js to be more efficient.
414  *      Also modified the .js library to match up as closely as possible with the original
415  *      jsrsClient.js file to make it easier to see how the two files differ.</p>
416  *   <p>Also updated RenderStrategy and HTMLActionRenderer to allow for a CUSTOM_SCRIPT render
417  *      strategy.  CUSTOM_SCRIPT is exactly like NEVER_SCRIPT, except that it alerts the Barracuda
418  *      renderers not to throw exceptions in cases where actions being rendered wouldn't work properly
419  *      without Javascript.  Essentially, it says "don't script for me because I want to do my own
420  *      client-side scripting and I don't want Barracuda interfering with that".</p>
421  *   <p>And finally, updated HttpServletRequestWrapper.java to catch exceptions when attempting to
422  *      decode a query string.  It seems that runtime exceptions are being thrown.  Kirk Daries says
423  *      that catching the exception and ignoring it makes things work fine, so that is what has now
424  *      been done.</p>
425  * </li>
426  * <li>
427  *   <p><b>jrk_20030624.1</b> - Update HTMLActionRenderer to behave better with input elements
428  *      or button elements of type &quot;button&quot; when javascript isn't allowed (eg... the client
429  *      is not registered with Barracuda as supporting javascript, javascript is disabled on a
430  *      client that normally supports javascript, or the render strategy has been intentionally set
431  *      to not allow scripting). Instead of throwing an exception, modify these elements by setting
432  *      their &quot;type&quot; attribute to &quot;submit&quot;. However, if the pre-existing type
433  *      is something other than &quot;submit&quot; or &quot;button&quot;, then throw the exception,
434  *      otherwise we'd be overstepping our bounds.</p>
435  *   <p>Also updated BScriptResource to contain static constants for references to existing Barracuda
436  *      scripts so we don't have to write the full path to those scripts all the time. Besides being
437  *      cleaner, this is less error prone. Modified HTMLActionRenderer to use these constants.</p>
438  *   <p>Also cleaned up HTMLActionRenderer and consolidated some common code.  Added new
439  *      private static utility method clientScriptingAllowed() to encapsulate logic for determining
440  *      if scripting is enabled/allowed. Updated some of the Javadoc comments as well. Still more to
441  *      do such as fix it so that if scripting is disabled on the client, we actually see that and
442  *      modify the render strategy to that of flagging scripting not allowed. Also, may need to figure
443  *      out how to deal with null form elements.</p>
444  * </li>
445  * <li>
446  *   <p><b>jrk_20030623.1</b> - Updating Barracuda to finally get rid of the concept of dom-based
447  *      caching marker which was part of the components.  This is now entirely localized to
448  *      DefaultDOMWriter so if you need to control caching behavior, return your own customized
449  *      instance of DefaultDOMWriter after setting the applicable properties to your needs.  This
450  *      change affects AbstractBComponent, BComponent, and DefaultDOMWriter.  Also updated Javadoc
451  *      for DefaultDOMWriter to make its use more understandable.</p>
452  * </li>
453  * <li>
454  *   <p><b>csc_062003.1</b> - Pretty significant upgrade of ObjectRepositoryAssembler, per extensive
455  *      discussion on the email list. <object> tag now supprts name='$this'; <method> tags can now
456  *      return values, using the return="" attribute; and static methods on classes with no public
457  *      constructors can now be invoked. In short, I think everything you want can now be done Jake :-)
458  *      Note that I also upgraded the way we obtain an instance of the parser to follow the Sun convention
459  *      (per Sun's JDK 1.4 and discussion with Shawn). Also note that the javadocs and comments in
460  *      ObjectRepositoryAssembler are all up-to-date, and I have expanded the object-repository.xml to
461  *      better illustrate all the various possibilities. Finally, please notice that the test case
462  *      (TestObjectRepositoryAssembler) has been improved to verify all the new funcitonality works.
463  *      Woo hoo! Way cool! :-)
464  * </li>
465  * <li>
466  *   <p><b>csc_061803.1</b> - Modified ObjectRepositoryAssembler to support the setting of
467  *      Shorts, Longs, Doubles and Floats in addition to the String, Boolean, and Integer
468  *      support that was already there. While I was at it I discovered that the previous
469  *      implementation only supported the setting of primitives, so I modified things so that
470  *      you can set both primitives and their first class counterparts.
471  * </li>
472  * <li>
473  *   <p><b>csc_060903.3</b> - Preliminary work for Jake's review on a new way to configure
474  *      pluggable classes. Basically, I modified org.enhydra.barracuda.plankton.Classes to offer
475  *      a couple of new methods for getting a Class or an instance of a Class (using some simple
476  *      caching for efficiency sake). Then I created a new org.enhydra.barracuda.core.event.A_Classes.
477  *      This class defines constants that refer to default class names...they can be overridden
478  *      via the Object Repository scripting approach. The basic idea here is that when a class needs
479  *      to instantiate something that implements the interface, it uses Classes.newInstance(String clName),
480  *      where clName is the value defined in A_Classes. I have currently implemented this in
481  *      ApplicationGateway, for both DefaultEventGateway and DefaultEventPool. This is to provide
482  *      an example of the approach I have in mind. Jake and others...your comments and feedback would
483  *      be appreciated.
484  * </li>
485  * <li>
486  *   <p><b>csc_060903.2</b> - Move the instantiation of the EventPool down beneath the application
487  *      gateway assembly, allowing application gateway to override the EventPool constants if
488  *      necessary. Note that the reason ApplicationGateway instantiates event pool and event
489  *      broker here is to ensure that the classes provided can be instantiated - we want to verify
490  *      this at startup, rather than at actual event dispatch time.
491  * </li>
492  * <li>
493  *   <p><b>csc_060903.1</b> - Make the default constructor of DefaultEventPool use static constants
494  *      that can be overridden from object-repository.xml
495  * </li>
496  * <li>
497  *   <p><b>jrk_20030602.1</b> - Added a couple items to the interfaces of DOMLoader and DOMFactory.
498  *      <p>1. DOMFactory now has getInstance(String docPath) which is meant to load the dom directly from
499  *      a file rather than a pre-compiled class. This was done to support XMLC's deferred parsing, but
500  *      is also generic so any other DOM implementation that supports loading directly from file could
501  *      be used as well. XMLCDeferredParsingDOMFactory was updated to support this. See the javadoc
502  *      for details.</p>
503  *      <p>2. DOMLoader was modified to support the addition to DOMFactory by adding getDOMFromFile()
504  *      methods analogous to the existing getDOM() methods.  Also added convenience getDOM(className)
505  *      methods so that you can pass a fully qualified class name rather than having to pass a JVM
506  *      loaded class. DefaultDOMLoader was updated to support this. See the javadoc for details.</p>
507  *   <p>These changes shouldn't adversely effect anyone since it is doubtful that anyone has, so far,
508  *      created their own DOMFactory or DOMLoader implementation. So, these changes should be transparent
509  *      for most people and provide cool new functionality!</p>
510  * </li>
511  * <li>
512  *   <p><b>jrk_20030531.1</b> - Backed out changes to DefaultDOMLoader where no default was provided
513  *      for the domFactory so things would blow up as soon as getDOM() was called since, if not set,
514  *      no dom factory would exist. This had been done to solve a dom-implementation dependency issue
515  *      with anything that referenced the DefaultDOMLoader; especially the DefaultApplicationAssembler.
516  *      I have now solved this in an alternative way. The application assembler no longer directly refers
517  *      to DefaultDOMLoader. It is loaded via runtime reflection. Also, added support for defining a dom
518  *      loader other than the default DefaultDOMLoader in assembly configuration. See the javadoc for
519  *      DefaultApplicationAssembler, DefaultDOMLoader, and Barracuda's event-gateway.xml file for more details</p>
520  * </li>
521  * <li>
522  *   <p><b>jrk_20030530.1</b> - Renamed DefaultDOMFactory to XMLCStdDOMFactory to make it more clear
523  *      what DOM implementation it backs.  Also updated the EventGateway interface to include more
524  *      of the methods that the DefaultEventGateway supports so that no implementation-specific
525  *      check needs to be done in the DefaultApplicationAssembler.  This makes the DefaultApplicationAssembler
526  *      much more generic and able to work with implementations of the EventGateway interface.  Had to
527  *      update ApplicationGateway as well since it implements EventGateway to account for the interface
528  *      method addtions.</p>
529  * </li>
530  * <li>
531  *   <p><b>jrk_20030529.2</b> - Updated component testcases to account for the jrk_20030528.1 change in
532  *      behavior of the DefaultDOMLoader. Basically, since DefaultDOMLoader no longer uses a default
533  *      DOMFactory instance, one must be set before using getDOM(). This is taken care of when running
534  *      via a webapp in the assembly descriptor configuration. However, since the testcases don't run
535  *      within the context of a webapp, they need to have have the DOMFactory programatically set. So,
536  *      for each of the component testcases, I added...
537  *      <pre>
538  *      protected void setUp() {
539  *          //Make sure we specifically define a DOMFactory since the DefaultDOMLoader no longer
540  *          //uses a default to avoid dom implementation-specific compile dependencies.
541  *          //This is taken care of more simply in the assembly descriptor when running
542  *          //via a webapp.
543  *          DefaultDOMLoader.getGlobalInstance().setDefaultDOMFactory(new XMLCDeferredParsingDOMFactory());
544  *      }
545  *      </pre>
546  *      Now all is well!</p>
547  * </li>
548  * <li>
549  *   <p><b>csc_052903.1</b> - review DefaultDOMLoader for threadsafety - I didn't see any glaring
550  *      issues, but Shawn did suggest a couple of improvements that I think were worth making
551  *      just to be safe (safe, get it? _thread_ safe? Ha ha ha ha ha...ok, so it wasn't that funny)
552  *      Note that this fix does break some of the test cases, but that is because of a problem in
553  *      them that results from jrk_20030528.1...Jake will update the test cases tonight or tomorrow.
554  * </li>
555  * <li>
556  *   <p><b>jrk_20030529.1</b> - Updated handling of &lt;set-property&gt; and &lt;constant&gt; in
557  *      DefaultApplicationAssembler to recognize the concept of a &quot;delegate runtime value&quot;.
558  *      What this means is that the value of the parameter to be set is a runtime object rather than
559  *      something that can be provided as a literal value in the configuration file. Currently, the only
560  *      supported delegate runtime value is a ServletContext object. The syntax of this new configuration
561  *      option is...
562  *   <pre>
563  *   &lt;set-property name=&quot;servletContext&quot; delegateRuntimeValue=&quot;true&quot;/&gt;
564  *   </pre></p>
565  *   <p>Obviously this assumes that the class this property is to act upon have either a public
566  *     &quot;setServletContext()&quot; method or a public &quot;servletContext&quot; field.</p>
567  *   <p>Also updated XMLCDeferredParsingDOMFactory to take advantage of this feature, the reason
568  *     being that it needs to read context init parameters to provide extra optional information to
569  *     the DeferredParsingFactory which the DeferredParsingDOMFactory backs. Also modified it to
570  *     create the DeferredParsingFactory once instead of every time DOMFactory#getInstance() is
571  *     called. This should provide a slight performance improvement.</p>
572  * </li>
573  * <li>
574  *   <p><b>jrk_20030528.1</b> - Updated DefaultDOMLoader to not pre-set a default DOMFactory
575  *      implementation.  This should solve the issue reported by James Carnegie where
576  *      the DefaultApplicationAssembler had a compile dependency upon XMLC simply because
577  *      it accessed a DOMLoader via DefaultDOMLoader.getGlobalInstance() and the default dom
578  *      factory that it pre-set used XMLC to load the DOM. Since there is now
579  *      no default dom factory pre-set, one must set themselves it via the application assembler with
580  *      &lt;dom-loader factory=&quot;...&quot;/&gt; or programatically via
581  *      DefaultDOMLoader#setDefaultDOMFactory(DOMFactory) before using any of the
582  *      getDOM() methods. Also updated the javadoc for DefaultDOMLoader to account
583  *      for this change and for some general cleanup and clarity.</p>
584  * </li>
585  * <li>
586  *   <p><b>csc_052803.2</b> - expanded the StateMap interface to support a clearState() method.
587  *      This was necessary because the current implementation of SoftHashMap does not allow you
588  *      to get the entrySet for the map (it throws an UnsupportedOperationException), so by
589  *      adding this method we at least make it possible to clear the cache.
590  * </li>
591  * <li>
592  *   <p><b>csc_052803.1</b> - minor mod to ApplicationGateway so that when debugging is turned
593  *      on it will show the headers as well.
594  * </li>
595  * <li>
596  *   <p><b>csc_052703.1</b> - added a new SoftHashMap class to org.enhydra.barracuda.plankton.data
597  *      and then modified ObjectRepository to provide access to this (both globally, and as based
598  *      on session). The basic reason behind this is that soft references make better caches than
599  *      weak references because weak will be reclaimed as soon as possible, whereas soft will be
600  *      retained as long as possible. This was showing itself in the client side redirects -
601  *      on a fairly regular basis, gc would run between a redirect, and the information in the
602  *      weak session repository would get lost. I modified DefaultEventContext to use the new
603  *      soft session repository, which should allow cached information to survive gcs.
604  * </li>
605  * <li>
606  *   <p>--------------- RELEASED 1.2.0 ---------------------</p>
607  * </li>
608  * <li>
609  *   <p><b>jrk_20030520.1</b> - Further updated XMLC to fix a couple bugs. Completely
610  *      removed endorsed packages (javax.*, org.xml.*, org.w3c.dom.*) from XMLC's xerces
611  *      package. This makes it so XMLC's xerces can exist in WEB-INF/lib. Simplified XMLC
612  *      by moving xmlc jars (xmlc, xerces, xhtml, wireless) into on jar called
613  *      xmlc-all-runtime.jar.  There is no more need to copy the xerces jar to and external
614  *      shared classloader.  Note that all XMLC jars including jtidy, gnu-regexp,
615  *      xmlc-all-runtime, and xmlc-taskdef are based on the XMLC CVS source with the
616  *      tag XMLC_2_2_POST_BETA_1_BARRACUDA_1_2_0.</p>
617  * </li>
618  * <li>
619  *   <p><b>jrk_20030520.1</b> - Updated HTMLSelectRenderer to be in-line with the html
620  *      dom level1 interfaces which don't include a setSelected(boolean) method in
621  *      HTMLOptionElement. My comments in that file go into detail about this, so
622  *      read them if you want more info. No behavioral changes should be seen from
623  *      this change except that Barracuda will compile in the presence of the official
624  *      html dom level1 interfaces provided by Xerces2.</p>
625  * </li>
626  * <li>
627  *   <p><b>csc_051703_1</b> - Very minor changes to the toString() method in ValidationException
628  *      to make it show sub-exceptions as well (makes debugging a little easier)
629  * </li>
630  * <li>
631  *   <p><b>csc_051503_1</b> - Modified FormType to add a new TIMESTAMP data type
632  *      (java.sql.Timestamp)
633  * </li>
634  * <li>
635  *   <p><b>jrk_20030514</b> - updating to XMLC-2.2beta1 release.
636  *      The Xmlc taskdef moved from the org.enhydra.barracuda.taskdefs package
637  *      to org.enhydra.xml.xmlc.taskdef package.  Updated the Localize taskdef
638  *      to account for that.  Also had to modify LocalizeXmlcUtilsImpl to make
639  *      the constructor public.  It had been protected to prevent direct
640  *      instantiation, but since the XmlcUtil class needs to be able to
641  *      instantiate it and it is in a different package, I had to make the
642  *      constructor public.</p>
643  * </li>
644  * <li>
645  *   <p><b>jrk_20030508</b> - Modified the plankton URLRewriter to not attempt to
646  *      override normal servlet spec behavior. The only thing that is still there
647  *      is the ability to turn off url rewriting based on the static REWRITE_URLS
648  *      variable. This variable has been changed from a default of "false" to a
649  *      default of "true".  This makes the normal servlet spec behavior the default.
650  *      For buggy servers such as early Tomcat servers or Enhydra-3.xx servers, one
651  *      may disable URL rewriting by setting REWRITE_URLS to false in the assembly
652  *      descriptor or programatically at runtime.</p>
653  * </li>
654  * <li>
655  *   <p><b>jrk_20030416.1</b> - updated DefaultApplicationAssembler to support
656  *      the loading of one or more application assembler files without using File IO.
657  *      This uses a servlet 2.3 specific method, but I use reflection to fall back to
658  *      only supporting the loading of a single assembler file for servlet 2.2.</p>
659  *   <p>Also added the ability to set the default dom factory for the DefaultDOMLoader
660  *      and/or register specific dom factories with specific dom classes in the
661  *      assembler file.  See sample.event-gateway.xml for more info.</p>
662  *   <p>Updated sample.event-gateway.xml for both Barracuda and Diez contrib app to set
663  *      the xmlc deferred parsing factory as the default factory.  Removed code I had
664  *      added to the DBRApplicationGateway to set the dom factories since this is now
665  *      done in the assembler file.</p>
666  *   <p>Updated xmlc-2.2.jar because Richard Kunze added a fix to make it so the
667  *      deferred parsing factory would load classes not compiled for deferred parsing.
668  *      the opposite is not true, which is why we made the deferred parsing factory the
669  *      default dom factory in the assembly descriptor.</p>
670  * </li>
671  * <li>
672  *   <p><b>csc_041603.2</b> - Added logic to ObjectRepositoryAssembler so that you can
673  *      get it to continue assembling a file even if errors are encountered. This is useful
674  *      because it allows your assembler file to specify things which may not always be there
675  *      (depending on your deploy configuration). Of course, if those things aren't there,
676  *      then subsequent assembly may not work either, so use with caution...
677  *   </p><p>
678  *      To take advantage of this functionality, you can either specify a startup parameter
679  *      in the GlobalRepositoryAssembler section of web.xml, like this:
680  *      <pre>
681  *         &lt;init-param&gt;
682  *           &lt;param-name&gt;LogHeartbeat&lt;/param-name&gt;
683  *           &lt;param-value&gt;true&lt;/param-value&gt;
684  *         &lt;/init-param&gt;
685  *      <pre>
686  *      or, you can specify it within the object-repository.xml file itself, like this:
687  *      <pre>
688  *         &lt;object class="org.enhydra.barracuda.plankton.data.ObjectRepositoryAssembler"&gt;
689  *           &lt;prop name="globalContinueOnErr"&gt;true&lt;/prop&gt;
690  *         &lt;/object&gt;
691  *      </pre>
692  *      or, you can specify it on a per-line item in object-repository.xml, like this:
693  *      <pre>
694  *         &lt;object name="$cts" class="com.atmr.kilimanjaro.CodeTables" continue_on_err="true" /&gt;
695  *      </pre>
696  *      Note that the default remains false, so this should not affect any existing code
697  *      at all...you have to explicitly turn this behavior on if you want it.</p>
698  * </li>
699  * <li>
700  *   <p><b>csc_041603.1</b> - Minor change to HttpConverter to add a couple of extra convenience
701  *      methods.</p>
702  * </li>
703  * <li>
704  *   <p><b>csc_041403.2</b> - Pretty significant set of changes. Updated BSelect to
705  *      remove the setDisableBackButton and getDisableBackButton methods (these weren't)
706  *      used anywhere. Modified BSelect to act like BInput in terms of the addEventListener
707  *      method (you can now specify a disabled prop there). Added new setAction()/getAction()
708  *      methods to both of these classes, which effectively mirror the functionality of
709  *      the addEventListener methods, except you provide the event to be fired, rather than
710  *      the handler to receive it. In retrospect, I think this is the way we should have done
711  *      it in the first place, and I'd like to actually remove the addListener functionality
712  *      from both BSelect and BInput in the fairly near future. I also modified AbstractBComponent
713  *      so that when you add a stepchild, it will automatically inherit the parents views if
714  *      it doesn't have any; also modified the add tempView method so that it will add temp
715  *      views to step children if they exist. This makes it MUCH easier to pass back nested
716  *      components from a template model (where the view may not yet be assigned) - for instance,
717  *      you can now actually do something like this:
718  *      <pre>
719  *          BSelect bselect = new BSelect(dlm);
720  *          ...
721  *          BAction baction = new BAction(new DoSwitchCompany());
722  *          bselect.addStepChild(baction);
723  *          return bselect;
724  *      </pre>
725  *      and it will actually work - both components will be bound to the same view when it
726  *      is actually created by TemplateHelper. Very nice...</p>
727  * </li>
728  * <li>
729  *   <p><b>csc_041403.1</b> - Fixed a minor annoyance in HTMLActionRenderer -
730  *      when binding an Action/Link to an anchor element, only set the url href
731  *      if the component actually has either a url string or an event specified;
732  *      otherwise, just leave what is in the template. This will fix the issue where
733  *      if you are using a BAction but only setting visibility (not the URL), it was
734  *      overriding it with a default ActionEvent.</p>
735  * </li>
736  * <li>
737  *   <p><b>jrk_20030411.3</b> - Fixed NullPointerException bug in
738  *      HTMLListRenderer where the item passed to the list is assumed to be
739  *      non-null.  Put a null check in addItemToList() and added a logging
740  *      warning. I noticed this when I hit the submit button in Diez' File
741  *      Upload example without having chosen a file to upload. I got a nifty
742  *      stack trace!  Won't happen any more, though.</p>
743  * </li>
744  * <li>
745  *   <p><b>jrk_20030411.2</b> - created new XMLCDeferredParsingDOMFactory.java
746  *      class for use in enabling XMLC deferred parsing support with Barracuda
747  *      apps.  I also updated Diez' contrib app to register this custom factory
748  *      to be used with his html classes.  That way, DefaultDOMLoader knows to
749  *      load certain template classes with deferred parsing while using the
750  *      defaut dom loading factory for the rest of the classes.  Note that in
751  *      order to enable deferred parsing, one must add the XMLC compile flag
752  *      "-for-deferred-parsing" to the options.xmlc file.  Also, one must copy
753  *      the .xmlc files generated from compilation (not .xmlc files from
754  *      src_mockup directories) and the .html files to the xmlc class file
755  *      destination.  Diez' build has been updated to do this and has deferred
756  *      parsing enabled!</p>
757  * </li>
758  * <li>
759  *   <p><b>jrk_20030411.1</b> - enhanced HTMLActionRenderer and BAction
760  *      to enable the concept of custom client-side form validation. Added
761  *      addScriptFunction(String) and getScriptFunctions() to BAction and
762  *      modified HTMLActionRenderer to add these function names as a list of
763  *      arguments for a new javascript function called doSubmitAndLock() which
764  *      takes a form object as its first argument and then an infinite number
765  *      of function names as arguments after that.  This can be found in
766  *      a new file called FormControl.js.  If provided, each added function
767  *      will be called in the order added.  The only constraints are that they
768  *      take a form object as an argument (or no arguments) and return a
769  *      boolean.  If any function returns false, the submit will be canceled.
770  *      Custom functions are added before any Barracuda specific functions such
771  *      as "cshl_SubmitAndReplace" for disabling the back button.  Custom
772  *      functions may submit the form via a javascript submit, but this is
773  *      unnecessary as doSubmitAndRelace() will submit the form via a
774  *      javascript submit if nothing else does and no function returned false.
775  *      Functions are named without parenthasis such as...
776  *      addScriptFunction("checkValue")</p>
777  * </li>
778  * <li>
779  *   <p><b>dbr_20030408.1</b> - fixed a problem in DefaultFormMap that
780  *      was detected by Shawn Wilson. It prevents empty strings from beeing
781  *      parsed. This ensures correct behaviour for the ValidTypeValidator.
782  * </li>
783  * <li>
784  *   <p><b>jrk_20030407.1</b> - fixed a problem with the HTMLActionRenderer
785  *      setting any and all input elements, with an action listener, disabled
786  *      before submitting form. This caused data-critical input elements
787  *      such as radio buttons and checkboxes to not send their data to the
788  *      server. Now only input elements of type "submit", "button", and "image"
789  *      are set as disabled.  At the same time I did this, I did some major
790  *      cleanup and reorganization of HTMLActionRenderer.  Behavior shouldn't
791  *      really have changed (besides the mentioned bug fix) except that it
792  *      should be easier to read and more efficient than before.</p>
793  * </li>
794  * <li>
795  *   <p><b>csc_040203.2</b> - fix a mapping problem in FormType - wrapped the logic
796  *      in a block to catch NumberFormatExceptions...not sure why this hadn't been
797  *      done originally!
798  * </li>
799  * <li>
800  *   <p><b>csc_040203.1</b> - fix a bug in HttpSessionStateMap - null pointer exception when
801  *      trying to remove a key from the session who's value is null. This had already been
802  *      fixed for the call to getState().
803  * </li>
804  * <li>
805  *   <p><b>jrk_20030318</b> - Introduction of XMLC-2.2 along with a number of other
806  *     changes, such as...</p>
807  *   <p>1.  Verified that xmlc-2.2 (current cvs) is not only compatible with Barracuda,
808  *     it solves all the gotchas that we had before.  You can now have a stock install
809  *     of Ant with Xerces2 and xml-apis.jar in ANT_HOME/lib and successfully build
810  *     Barracuda at the same time.  You can have Xerces2 and xmlParserAPIs.jar in
811  *     CATALNIA_HOME/common/endorsed and xmlc's xerces in CATALNIA_HOME/shared/lib or
812  *     WEB-INF/lib and xmlc classes based upon xml files will work (remember under
813  *     xmlc-2.1, these bombed out because there was a clash between xerces1 and
814  *     xerces2).  So, basically, we don't have to expound on any caveats to using xmlc
815  *     anymore.  Things just work with default installs!!!!  Note that I still am not
816  *     copying xerces to WEB-INF/lib because even though xerces is wrapped
817  *     (org.enhydra.apache.xerces), it still
818  *     contains org.w3c.dom, javax.xml, and org.xml packages.  David Li is working on
819  *     getting rid of those and once that happens we can put it back in WEB-INF/lib.</p>
820  *
821  *   <p>1b.  Note I have removed the Xmlc taskdef from Barracuda's source
822  *     now that it exists over at the XMLC project CVS.  Also note that it has already
823  *     been enhanced by David Li to notice not only changes to *ML files but also
824  *     corresponding *.xmlc files.  And I applied a patch from Stefan Armbruster which
825  *     allows the task to recursively look in parent directories for options.xmlc so
826  *     that one can have nested subdirectories containing *ML templates all using a
827  *     single options.xmlc file.  The xmlc-taskdef.jar is now incldued in WEB-INF/jars.
828  *     I also applied another patch from Stefan to fix some logging
829  *     issues in the Localize task.  I also fixed the EventBuilder task to use whatever
830  *     XMLReader is available rather than failing if it can't find the Xerces parser.
831  *     This should probably be used elsewhere where SAX2 parsers are utilized.</p>
832  *
833  *   <p>2.  Modified DefaultDOMWriter and in the process, removed printPretty,
834  *     preventCaching, and maxAge from DefaultViewHandler and ComponentGateway.
835  *     Dealing with these values is now entirely localized to DefaultDOMWriter.  If you
836  *     want to override defaults, then override getDOMWriter() or just create a
837  *     DefaultDOMWriter and set the properties. before calling the write() method.</p>
838  *
839  *   <p>3.  Updated Diez' page model to conform to the new stuff and am now successfully
840  *     overriding getDOMWriter() and being able to set OutputOptions so that the
841  *     doctype will be written for his example pages.  cool!</p>
842  *
843  *   <p>4.  Updated build.xml and version.properties to account for the new xmlc
844  *     jars.</p>
845  *
846  *   <p>5.  Removed the core.util.dom.io package.  All classes (very few) referencing
847  *     that package now reference org.enhydra.xml.io.*.  I believe that all needed
848  *     custom modifications have already been moved into XMLC's source.  They must have
849  *     because everything seems to work perfectly.</p>
850  * </li>
851  * <li>
852  *   <p><b>csc_031103.2</b> - added Cloneable, Serializable support for DefaultListModel
853  *      (it was already implemented previously for DefaulListSelectionModel)
854  * </li>
855  * <li>
856  *   <p><b>csc_031103.1</b> - updated ExceptionUtil so that when printing stacktraces to
857  *      HTML, it wraps the trace in &lt;pre&gt; tags for better readability
858  * </li>
859  * <li>
860  *   <p><b>csc_031003.1</b> - added a convenience method setValue(Object) to BInput.
861  * </li>
862  * <li>
863  *   <p><b>csc_030703.1</b> - realized that my changes from yesterday actually broke stuff
864  *      in the contrib directory, so I fixed it there as well. Thanks to Jake for pointing
865  *      this out. Verified that everything compiles now, and unit tests run. Rebuilt the jars.
866  * </li>
867  * <li>
868  *   <p><b>csc_030603.2</b> - changed the signature of the getItem() method in the
869  *      TemplateModel interface from:
870  *          getItem(String key)
871  *      to:
872  *          getItem(TemplateDirective td)
873  *      This gives the model implementation access to the full TemplateDirective, and opens
874  *      up some interesting pattern opportunities based on the key data portion of directives
875  *      (rather than on a naming convention applied to key name, which was the only option
876  *      available before). While changing the signature might seem like it will have a big impact
877  *      on existing code, I don't think it will do so because AbstractTemplateModel implements
878  *      this method and simply calls the old getItem(String key) method. So old code should
879  *      continue to work, but it you want to implement something under the new signature, you
880  *      certainly can. The only caveat is that if you implement this new method directly, you
881  *      should make sure you call super.getItem() for TemplateDirectives that go unhandled
882  *      or are still handled in the old getItem(String key) method.
883  *   </p>
884  *   <p><b>csc_030603.1</b> - removed the ViewContext param from DefaultViewHandler's
885  *      handleViewEvent, preCompRender and postCompRender as everyone pretty much agreed
886  *      that these methods are not widely used. If you do have code that uses these methods
887  *      you can now get the context within these methods simply by calling getViewContext()
888  *      (which was added yesterday).
889  *   </p>
890  * </li>
891  * <li>
892  *   <p><b>csc_030503.1</b> - added a getViewContext() method to DefaultViewHandler so that
893  *      the getTemplateClass() method has some means to get the ViewContext, so it can work its
894  *      way back to the EventContext and thus to the source event (to return different template
895  *      classes for that if necessary). Note that this actually renders the ViewContext
896  *      parameter in handleViewEvent, preCompRender, and postCompRender obsolete, but for
897  *      now we'll just leave them in there (so we don't break existing code)
898  * </li>
899  * <li>
900  *   <p><b>jrk_20030217.1</b> - Updated build to use log4j-sandbox jars for log4j initialization.
901  *      These include log4j-sandbox-selector-[version].jar and log4j-sandbox-servlet-[version].jar.
902  *      These replace barracuda-log4j.jar and barracuda-webapp.jar.  Since I am now a committer on
903  *      the log4j-sandbox project after contributing the custom selector and initialization stuff
904  *      that had been homed in Barracuda's source, I felt it made sense to remove the duplicates in
905  *      Barracuda's source.  The same concepts hold.  The selector jar must exist alongside log4j.jar
906  *      and the servlet jar must exist in any webapp's WEB-INF/lib which is using the sandbox servlet
907  *      initialization.  In web.xml, you should now use org.apache.log4j.servlet.InitContextListener
908  *      instead of the old Log4jApplicationWatch</p>
909  * </li>
910  * <li>
911  *   <p><b>dbr_070203.1</b> - reworked shawn's patch from 121102 to work with jdk1.3
912  * </li>
913  * <li>
914  *   <p><b>csc_012003.1</b> - Improved the parental functionality in the PArrayList and PHashMap
915  *      plankton code - basically, when setting parent, only do so if isInheritParents() = true
916  *      AND the parent is not already set to something. Also, when removing items from data sets,
917  *      only clear the parent if the parent of the object being removed matches the current container
918  *      from which it is being removed.</p>
919  * </li>
920  * <li>
921  *   <p><b>csc_121302.1</b> - Added support for case insensitive event mapping; what
922  *      this means is that getlogin.event maps to the same class as GetLogin.event.
923  *      Also added a test case to verify this behavior. This should not have ANY
924  *      impact on existing applications. Thanks to Jacob Kjome [hoju@visi.com] for
925  *      suggesting the idea.
926  *   </p>
927  * </li>
928  * <li>
929  *   <p><b>csc_121202.1</b> - Fixed a minor problem in BAction where the sep variable
930  *      was not getting changed to '&' soon enough while processing an array of items.
931  *   </p>
932  * </li>
933  * <li>
934  *   <p><b>saw_121102.2</b> - Added in Cookie support to the HttpRequester class in
935  *      Plankton. This effectively lets you connect to a URL that returns a cookie,
936  *      and then you can reuse the requester for other URLs that are going to require
937  *      that cookie. Thanks to Shawn Wilson [shawnw@atmreports.com] for implementing this.
938  *   </p>
939  *   <p><b>saw_121102.1</b> - Updated BTemplate and TemplateHelper to properly release
940  *      references between the component and the models. Basically, whenever you use a
941  *      BTemplate the destroyCycle() method MUST be called when you're done with it, or
942  *      the template models will retain a reference to the BTemplate, and the objects
943  *      will never get cleaned up. This was a problem in TemplateHelper where we create
944  *      temporary BTemplate components and then discard them. We also had to modify BTemplate
945  *      itself so that a) if you add a model it first tries to deregister the model (ie. in
946  *      case you are overwriting an existing model, which BlockIterator does) and b) when
947  *      destroy cycle is called we need to run through and deregister all the models before
948  *      nulling out the model list. This effectively fixes the only known memory leak in
949  *      Barracuda, so its a very important patch. Thanks to Shawn Wilson [shawnw@atmreports.com]
950  *      for contributing</p>
951  * </li>
952  * <li>
953  *   <p><b>jrk_20021207.1</b> - Updated ObjectRepositoryAssembler to load assembler
954  *      files the same way that DefaultApplicationAssembler does.  Moved things around
955  *      a good deal to make it work just like DefaultApplicationAssembler.  Modified
956  *      the inner class to be the same name as in DefaultApplicationAssembler
957  *      (AssemblerXMLReader).</p>
958  * </li>
959  *   <p><b>csc_120602.2</b> - Bunch of minor formatting changes (ie. remove tabs that
960  *      crept into the code, etc
961  *   </p>
962  *   <p><b>csc_120602.1</b> - Change HttpServletRequestWrapper so that getParameterMap
963  *      returns map values as String[], like its supposed to according to the spec. Also
964  *      make it handle multiple values (previously it didn't). Thanks to Udovenko Sergey
965  *      [Sergey.Udovenko@swx.com] for bringing this to my attention.
966  *   </p>
967  *   <p><b>csc_120502.1</b> - Added support to BaseEvent class to support the notion of
968  *      params. This means adding the following methods:
969  *      - void setParam(String key, String val)
970  *      - void setParam(String key, String[] vals)
971  *      - Map getParams()
972  *      You can use these events to "add" parameters to a URL request. Basically, if you
973  *      shove any values in here, then when this event is dispatched (by adding it to
974  *      the event queue) then the param values will get pulled out and appended into the
975  *      underlying Http req object. Thus to the code that handles this event, it will look
976  *      like the parameters where there all along. Pretty slick! Thanks to Jack Hodges
977  *      [Jack.Hodges@efi.com] for submitting this patch
978  * </li>
979  * <li>
980  *   <p><b>jrk_120302_1</b> - Change DefaultApplicationAssembler so that single
981  *      file reading does not use File IO.  I also got rid of unnecessary commented
982  *      out stuff and rearranged things quite a bit.  I plan to add non File IO
983  *      reading of multiple files as well, but I'd like to get this in quickly
984  *      because single file configuration is what most people use.</p>
985  * </li>
986  * <li>
987  *   <p><b>csc_120202_1</b> - Change all references to 'protected static Logger' to be
988  *      'protected static final Logger' per discussion with Jake</p>
989  * </li>
990  * <li>
991  *   <p><b>jrk_2002-12-02</b> - I reversed all changes Christian made previously to
992  *      ResouceGateway.  Using the Thread context classloader, we can load resources
993  *      from the WebappClassloader just fine even if ResourceGateway is in a parent
994  *      classloader.  So, ResourceGateway is now back to
995  *      core.helper.servlet.ResourceGateway.</p>
996  * </li>
997  * <li>
998  *   <p><b>jrk_2002-12-01.1 and .2</b> - removed references to java.sql and javax.sql in
999  *      src_tests/org/enhydra/barracuda/plankton/TestStringUtil.java since nothing was
1000 *      actually using those packages except possibly some commented out stuff.  Franck
1001 *      Routier reported this when running under IBM's jdk1.3.1 which, apparently doesn't
1002 *      include the javax.sql package where Sun's j2sdk1.4.1 does.  We'll have to include
1003 *      that jar file in WEB_INF/jars if we want to use javax.sql in the future.</p>
1004 * </li>
1005 * <li>
1006 *   <p><b>csc_122702.3</b> - minor fixes to the previous checkin
1007 * </li>
1008 * <li>
1009 *   <p><b>csc_122702.2</b> - moved core.helper.servlet.ResourceGateway -->
1010 *      core.webapp.servlet.ResourceGatewaychanged as this file needs to be included in
1011 *      the barracuda-webapp.jar in order to correctly load resources
1012 * </li>
1013 * <li>
1014 *   <p><b>csc_122202.2</b> - changed the forms package to use getVal()/getVals() instead
1015 *      of the longer getSingleValue()/getMultipleValue(); added back in the old convenience
1016 *      methods and made them part of the interface; also removed the deprecated classes from
1017 *      org.enhydra.barracuda.core.util, recompiled everything and verified the test cases
1018 *      work properly
1019 * </li>
1020 * <li>
1021 *   <p><b>csc_122202.1</b> - Fix a bug in DefaultApplicationAssembler. Patch provided by
1022 *      Srinivas Yermal [syermal@encover.com]. Here is his description:
1023 *      In the startElement method, listenerFactories dont get added to the objStack
1024 *      (object stack) when the factory attribute is a field. But the endElement seems
1025 *      to be popping them out at all times. And I get a EmptyStackException. So I
1026 *      suggested that we add the listenerFactory to the object stack at all times. The
1027 *      fix therefore is to move the "objStack.push(lf);" statement out of the if block
1028 *      it is currently under.
1029 * </li>
1030 * <li>
1031 *   <p><b>csc_112102.1</b> - finish fixing the nested directives problem that
1032 *      I rolled back out in csc_111902.1. Basically, the csc_100802.1 change
1033 *      was very close to being correct, BUT, it was skipping directives in nodes
1034 *      immediately below the node with a directive (and then correctly processing
1035 *      everything further down the DOM). The solution then, is that when we get
1036 *      a component or a node back from the model, we need to find the chunk of DOM
1037 *      to which it is bound, to run through all the child elements, and if any of them
1038 *      actually implement Element, then create one BTemplate and bind it to newNode.
1039 *      Test cases work correctly now.
1040 *   </p><p>
1041 *      Note that during the process of rebuilding jars, I discovered that changes to
1042 *      build.xml to restructure the location of the Barracuda jars from lib-ext to lib
1043 *      require you to delete the existing build.properties and version.properties in
1044 *      the src directory. Subsequent compiles will copy the new files into place and
1045 *      all will be well. Just thought I'd mention that.
1046 * <li>
1047 *   <p><b>csc_111902.1</b> - roll back changes in TemplateHelper that got added in
1048 *      csc_100802.1 - these changes where not processing nested directives correctly
1049 *      (the test case was failing too...not sure how I missed that originally). What this
1050 *      means is that nested directives in an iterative loop may not got processed correctly
1051 *      again (that was what 100802.1 was orginally supposed to fix); I'm working on a
1052 *      solution for that.
1053 * </li>
1054 * <li>
1055 *   <p><b>csc_111302.1</b> - Minor enhancements to CollectionsUtil (add support for
1056 *      Object arrays)
1057 * </li>
1058 * <li>
1059 *   <p><b>csc_110402.1</b> - Revert back changes to URLEncoder and URLDecoder calls; the
1060 *      deprecated methods which I replaced used calls that are only available in JDK 1.4
1061 *      causing problems for folks using JDK 1.3 still)
1062 * </li>
1063 * <li>
1064 *   <p><b>csc_110102.1</b> - Major refactoring changes on the plankton stuff. Moved
1065 *      everything out of core.util.* into barracuda.plankton, barracuda.webapp, and
1066 *      barracuda.log4j. Note that at this point there are a couple of classes that
1067 *      will need to stay under core.util. Specifically, these include core.util.dom,
1068 *      core.util.http.ContextServices and SessionServices, core.util.l10n.Locales,
1069 *      and core.util.srv.SimpleServiceFinder. Now, these simple classes have been
1070 *      modified to extend from their counterparts in the new plankton packages, so
1071 *      in general you should switch everything in your code from core.util to
1072 *      plankton, unless it still needs one of the methods in the classes that remain
1073 *      under core.util. For now, everything else in core.util has been deprecated,
1074 *      so what you can do is recompile your app with the deprecation option turned
1075 *      on, and you will see everyplace that needs to be changed. Once I am sure
1076 *      everything is working, I will actually remove the deprecated classes just so
1077 *      everything is clearer (even though it will require more work on the part of the
1078 *      developer). Jake tagged the tree prior to this commit with BARRACUDA_PRE_REFACTORING,
1079 *      so if you want to see what was there before hand you can easily do so.
1080 * </li>
1081 * <li>
1082 *   <p><b>jrk_102602.1</b> - Added
1083 *      <code>org.enhydra.barracuda.core.util.logging.Log4jCRS</code> which is a
1084 *      <code>LoggerRepositorySelector</code>. Log4j uses a default one, but we
1085 *      can make it use our own and then have more control over the
1086 *      LoggerRepository (Hierarchy) being used.  This allows us to put Log4j in
1087 *      a parent classloader and allow all applications to use that instance of
1088 *      Log4j without stomping on each others logger configuration.  For those who
1089 *      still want to use Log4j from within each webapp, that is still completely
1090 *      supported.  There isn't anything different that a user will have to do in
1091 *      configuring Log4j or using Loggers.  Everything will work as it always has
1092 *      transparently.  The one thing that needs to be remembered, however, is that
1093 *      log4j needs to live wherever you move the logger repository selector or,
1094 *      in our case, wherever you put plankton.jar.  So, if plankton.jar gets moved
1095 *      to a parent classloader such as Tomcat's shared/lib, you need to make double
1096 *      sure that you remove the log4j jar file from your webapp's WEB-INF/lib folder.
1097 *      Otherwise, you will get mysterious
1098 *      <code>java.lang.IncompatibleClassChangeError</code> messages at application
1099 *      startup and your logging won't work; neither will your application.
1100 *      So, you are *always* safe if you put keep plankton in WEB-INF/lib, but if you
1101 *      move plankton to a parent classloader, Log4j must move to that parent classloader
1102 *      as well and be removed from WEB-INF/lib.</p>
1103 *   <p><code>Log4jInit</code> and <code>Log4jApplicationWatch</code> have been modified
1104 *      to make use of <code>Log4jCRS</code>.  Other than that, no changes were
1105 *      necessary to enable this functionality.  See the javadoc of <code>Log4jCRS</code>
1106 *      for more information on what it is and does</p>
1107 * </li>
1108 * <li>
1109 *   <p><b>ndc_101202.1</b> - Applied patch from Denny Chambers [dchambers@snapserver.com]
1110 *      to add caption support to BTable
1111 *   </p>
1112 * </li>
1113 * <li>
1114 *   <p><b>csc_100802.1</b> - Applied patch from Rajesh Poddar [Rajesh.Poddar@efi.com]
1115 *      to TemplateHelper, which causes BTemplate delegate components to be rendered
1116 *      immediately, rather than waiting for the iteration to finish. This effectively
1117 *      fixes the nested directives bug that so many people have run into - you can now
1118 *      use nested directives inside of an iterative model, and all the nested directives
1119 *      will get processed before the next iteration occurs. Cool.
1120 *   </p>
1121 * </li>
1122 * <li>
1123 *   <p><b>jrk_092102.1</b> - Added
1124 *      org.enhydra.barracuda.core.util.logging.Log4jApplicationWatch which is a
1125 *      ServletContextListener. Application servers supporting Servlet 2.3 will use
1126 *      run this class just before application shutdown.  We use this to call
1127 *      LogManager.shutdown(). This releases handles to log files, thereby unlocking
1128 *      them. This has been a problem up until now. Unfortunately, it doesn't seem
1129 *      to unlock the Log4j jar itself. Still searching for answers to that.
1130 *      <p>In order to use this functionality, a $lt;listener$gt; must be set up in
1131 *         the web.xml. For those using servlet 2.2, this can be safely commented
1132 *         out, but the log files will be locked until full server shutdown.</p>
1133 *   </p>
1134 * </li>
1135 * <li>
1136 *   <p><b>dbr_083102.1</b> - Added the getSingleValue/getMultipleValues methods
1137 *      to FormElement, DefaultFormElement, FormMap and DefaultFormMap.
1138 *      The old getVal method now is deprecated.</p>
1139 *      <p>A new Validator, CardinalityValidator has been created. It purpose is to control
1140 *      the number of elements returned from a FormElement.</p>
1141 * </li>
1142 * <li>
1143 *   <p><b>csc_082802.1</b> - CopyAndReplace - moved the ssi processing code up in front
1144 *      of the mapping code.  This was done in response to a patch submitted by Stefan
1145 *      Armbruster [sarmbruster@web.de] which allows CopyAndReplace to work if you only
1146 *      want to do SSI processing, and don't need to do any mapping. This change means
1147 *      that you no longer have to supply an empty mappings file.
1148 *   </p>
1149 * </li>
1150 * <li>
1151 *   <p><b>csc_082602.1</b> - Added a minor modification to the ObjectRepositoryAssembler
1152 *      which makes it possible to see what file the assembler is configuring from without
1153 *      actually having to turn on logging. This makes it very easy to see what apps a particular
1154 *      instance of Tomcat is running when it fires up, as well as making it possible to see
1155 *      when an individual app was successfully reloaded. To turn on the logging, search the
1156 *      Barracuda web.xml for 'LogHeartbeat'
1157 *   </p>
1158 * </li>
1159 * <li>
1160 *   <p><b>csc_082302.2</b> - Modify the ClientSideRedirect logic so that when it persists
1161 *      state across multiple requests, it does so without placing information in the
1162 *      session. Previously, the event dispatcher was the code invoking the call to persist
1163 *      the context; now it happens in ApplicationGateway, allowing us to remove the
1164 *      persistContext() funtion from the EventContext interface (developers shouldn't be calling
1165 *      this method anyway). Now, when it comes time to persist, we store the event context
1166 *      statemap and local object repository info in a newly created WeakGlobalRepository. We
1167 *      use a weak structure to ensure that we don't get stale objects accumulating in memory
1168 *      (previously, by storing in the session this was taken care of for us). In order to store
1169 *      the info in this weak global repository, we need a key unique to the jvm, and we have to
1170 *      append this onto the outging url (ie. that the client side redirect is pointing to). This
1171 *      has the side effect of changing the url in the browser to include something like this
1172 *      onto the end of it: $ctxid=_1030135624563. I also modified the Simple Login app to
1173 *      test this code change out (we now store the login flag in the local repository, instead of
1174 *      the session, so the client side redirect that happens when you're already logged in
1175 *      should cause the auto-login flag to be propogated throughout the course of the redirect.
1176 *      Run the simple login app, login, and then click to return to the login screen--you'll see
1177 *      the redirect happen and should observe the browser url changing too.
1178 *   </p>
1179 * </li>
1180 * <li>
1181 *   <p><b>csc_082302.1</b> - Added a Barracuda Workbench gui app to
1182 *      the testbe package (the classes are included in barracuda_testbed.jar),
1183 *      and added a Barracuda_WorkBench.bat to lib-ext which demonstrates how to
1184 *      launch the app. The purpose of this app is to provide a place to add
1185 *      gui testing utilities that we write for the purpose of working with
1186 *      Barracuda or Barracuda based webapps. Right now there are 2 components:
1187 *      a URLStressTester (which allows you to stress test a simple URL) and a
1188 *      JDBC SQL utility (that allows you to connect to a DB via JDBC and execute
1189 *      SQL commands against it; you will need to make sure that the appropriate
1190 *      JDBC drivers are available on your classpath in order to actually use this).
1191 *      The purpose of these utilities is not to be exhaustively robust, but rather
1192 *      simply to make available some simple utilities that I use frequently and
1193 *      find quite helpful for debugging.
1194 *   </p>
1195 * </li>
1196 * <li>
1197 *   <p>--------------- RELEASED 1.1.1 ---------------------</p>
1198 * </li>
1199 * <li>
1200 *   <p><strong>csc_072202.1</strong> - modify ObjectRepositoryAssembler so that it tries
1201 *      to use the javax.xml.parsers.SAXParser class first, then it looks for the
1202 *      org.apache.xerces.parsers.SAXParser if it can't find the javax class.
1203 *   </p>
1204 * </li>
1205 * <li>
1206 *   <p><strong>ndc_073002.1</strong> - I noticed a problem where I was getting two
1207 *      attribute of the same name in my html output. In my template html
1208 *      lets say I had something like this:
1209 *      <pre>
1210 *        &lt;img SRC="foo.png" alt="foo image"&gt;
1211 *      </pre>
1212 *      In my model I had some code like this:
1213 *      <pre>
1214 *        BComponent img = new BComponent();
1215 *        img.setAttr(" alt", "foobar");
1216 *        return img;
1217 *      </pre>
1218 *      The resulting html would look like this:
1219 *      <pre>
1220 *        &lt;img SRC="foo.png" alt="foo image" alt="foobar"&gt;
1221 *      </pre>
1222 *   </p><p>Because of the extra space in " alt" it does not match this
1223 *      attribute with the attribute in the html template. So instead of
1224 *      overwriting the attribute, it adds the attribute. I am adding a
1225 *      trim() to the key.toString().
1226 *   </p>
1227 * </li>
1228 * <li>
1229 *   <p><strong>dbr_072302.1</strong> - FormType now uses the provided locale when reporting a ParseException in the DATE FormType.
1230 *   </p>
1231 * </li>
1232 * <li>
1233 *   <p><strong>csc_071602.1</strong> - modify DefaultItemMap's toString() method so that if
1234 *      there is a null value in the item map we don't get a null pointer exception here
1235 *   </p>
1236 * </li>
1237 * <li>
1238 *   <p><strong>csc_062102.1</strong> - minor changes to the Barracuda Admin app (moved the
1239 *      default Admin.properties and renamed it to AdminDefs.properties; added additional
1240 *      logging to the BarracudaAdmin class.
1241 *   </p>
1242 * </li>
1243 * <li>
1244 *   <p><strong>csc_061902.1</strong> - somewhere along the way FormType lost earlier changes that
1245 *      I applied to allow it to map 'Y' and 'N' values to Boolean types
1246 *   </p>
1247 * </li>
1248 * <li>
1249 *   <p>--------------- RELEASED 1.1.0 ---------------------</p>
1250 * </li>
1251 * <li>
1252 *   <p><strong>csc_061702.1</strong> - applied the same changes identified in sam_061602.1
1253 *      to BlockIterateHandler, BTemplateGateway, and BrowserCheck.
1254 *   </p>
1255 * </li>
1256 * <li>
1257 *   <p><strong>sam_061602.1</strong> - small change to BTemplateViewHandler contributed by
1258 *      Stefan Armbruster <sarmbruster@web.de>.  He noticed that the BTemplateViewHandler wasn't
1259 *      loading the dom taking the locale into account.  We now pass the ViewCapabilities object
1260 *      in addition to the DOM class so that the proper localized DOM class can be loaded.
1261 *   </p>
1262 * </li>
1263 * <li>
1264 *   <p><strong>csc_061402.1</strong> - Research various issues associated with EventConnectorFactory.
1265 *      Turns out that if you want to use it with inner class event handlers, those handlers MUST
1266 *      be declared as public static or you will get an instantiation exception at runtime (even though
1267 *      everything will compile fine at compile time). I did modify the factory to at least try getting
1268 *      an instance of the class when its instantiated--that way, if there are errors, they'll be caught
1269 *      when the servlet starts up, rather than waiting for a user to stumble into that section of code.
1270 *   </p>
1271 * </li>
1272 * <li>
1273 *   <p><strong>csc_061302.1</strong> - Very minor tweak to DefaultViewHandler...changed the scope
1274 *      of the class variables from public to protected (I had opverlooked this yesterday)
1275 *   </p>
1276 * </li>
1277 * <li>
1278 *   <p><strong>jrk_061302.1</strong> - Added support for using FileAppender's in the Log4jInit
1279 *      servlet which is loaded at application startup. If no custom path is provided, a default
1280 *      path set to WEB-INF/logs is used. A system property is set up to reference this path
1281 *      which is named based on the following scheme: [webapp name].log.home. So, in Baracuda's
1282 *      case, it would be Barracuda.log.home. This is referenced in the xml file as ${Barracuda.log.home}.
1283 *      More details are in the Javadoc for org.enhydra.barracuda.core.util.logging.Log4jInit.java
1284 *      and Barracuda's web.xml.
1285 *   </p>
1286 *   <p>I also added some other Appenders that might be useful to people such as the
1287 *      DailyRollingFileAppenderExt and the SMTPAppender. They are not used by default, but
1288 *      are available. The current default appender is the FileAppender and will, by default,
1289 *      log to WEB-INF/logs at application startup.
1290 *   </p>
1291 *   <p>Now I just have to figure out why I am getting duplicat logging statements from Log4j? I have
1292 *      a question out on the log4j-user email list which will, hopefully, be answered in short order.
1293 *   </p>
1294 * </li>
1295 * <li>
1296 *   <p><strong>csc_061202.1</strong> - More work to fix the previous change. Basically, I had
1297 *      been setting the Cache-Control header to "public", and this was not correct. It needs to
1298 *      be set to "max-age=0"; this will cause IE to NOT reload the page if you go back in the
1299 *      browser history, but if you re-visit the URL the page will be reloaded. This is now the
1300 *      default behaviour in DefaultDOMWriter if you do not specify the prevent caching flag.
1301 *   </p>
1302 *   <p>Now, there will be cases where we want to set max-age to a non-zero value; I modified
1303 *      DefaultDOMWriter to allow for this. Then, I also realized that DefaultViewHandler needs to
1304 *      make it easy to set this value, so I created a protected variable called maxAge which your
1305 *      event handler code can modify if you want to specify the number of seconds before the page
1306 *      is considered stale. Also, I realized that the printPretty and preventCaching vars in
1307 *      DefaultViewHandler should NOT be static, as we probably don't want these values to apply
1308 *      system wide. So I changed their scope accordingly. After testing, things seem to work better
1309 *      all-around now.
1310 *   </p>
1311 * </li>
1312 * <li>
1313 *   <p><strong>csc_061202.1</strong> - Added logic to explicitly set the response headers
1314 *      so as to allow the browsers to cache pages (previously, we were only setting the hdrs
1315 *      when we DIDN'T want the browser to cache). There's a couple of resources on which this
1316 *      change was based:
1317 *      <ul>
1318 *         <li><a HREF="http://www.web-caching.com/mnot_tutorial/">Caching Tutorial</a></li>
1319 *         <li><a HREF="http://www.web-caching.com/cacheability.html">Cacheability Query Engine</a></li>
1320 *      </ul>
1321 *   </p>
1322 * </li>
1323 * <li>
1324 *   <p><strong>csc_061102.1</strong> - Updated DefaultDOMWriter to add some logging stmts
1325 *   </p>
1326 * </li>
1327 * <li>
1328 *   <p><strong>csc_060702.1</strong> - I changed FormType's BigDecimal stuff to
1329 *      use the String constructor since the javadocs say that using the Double
1330 *      constructor is unpredicatable. Also modified to stripping out the dollar sign
1331 *      if its there. Added a StringUtil class (and test case) to
1332 *      org.enhydra.barracuda.core.util. Renamed DateUtils to DateUtil for consistency.
1333 *   </p>
1334 * </li>
1335 * <li>
1336 *   <p><strong>dbr_060702.1</strong> - added support for BigDecimal in
1337 *      org.enhydra.barracuda.core.forms.FormType.java.  Code was submitted by
1338 *      Diez Roggisch <diez.roggisch@artnology.com>.  Also added contributors and
1339 *      author tags to that file...especially to recognize the work of
1340 *      Chris Webb <chris.webb@voxsurf.com> in rewriting that file so nicely.
1341 *   </p>
1342 * </li>
1343 * <li>
1344 *   <p><strong>jdv_060602</strong> - apply Jason Vincents patch to Localize
1345 *      <blockquote>
1346 *          We decided to modify our clean target in our build.xml file to remove
1347 *          all *.xmlc and all localized html files from our xmlc/resources
1348 *          directory.  In doing so, i noticed that localized html files are created
1349 *          if the timestamp of them is equal to the xmlc files timestamp.  They
1350 *          were created initially in the same second as the xmlc files, so they
1351 *          would be compiled again on the next build, even though neither had
1352 *          changed.  I tweaked Localize.java to fix this (search for jdv_060602, in
1353 *          two locations).
1354 *      </blockquote>
1355 *      Jake then updated the build.xml to add new targets to cleanup localization
1356 *      generated .xmlc and .*ml files.  Look for the "source.xmlc.clean" target.
1357 *   </p>
1358 * </li>
1359 * <li>
1360 *   <p><strong>csc_060502.1</strong> - removed an unnecessary import stmt from
1361 *      org.enhydra.barracuda.core.util.dom.io.DOMFormatter. This import stmt was
1362 *      causing jikes compiler to fail - thanks to Franck Routier [Franck.Routier@hospvd.ch]
1363 *      for finding/fixing this
1364 * </li>
1365 * <li>
1366 *   <p><strong>jdv_053102.1</strong> - apply Jason Vincents patch to Localize2 and
1367 *      rename taskdef to Localize.java. Removed Localize2.java from cvs. Updated build.xml
1368 *      to reference Localize instead of Localize2. Verified that the newly regenerated
1369 *      Locaization examples still work as expected.
1370 * </li>
1371 * <li>
1372 *   <p><strong>csc_053102.2</strong> - improved the logging in ObjectRepositoryAssembler,
1373 *      added a simple test case, and moved log4j.properties to the /WEB-INF directory
1374 *      (previously the build was copying it to WEB-INF/classes). Q: Do we still need
1375 *      log4j_localize.properties and log4j_testing.properties?
1376 * </li>
1377 * <li>
1378 *   <p><strong>csc_053102.1</strong> - changed the logger variable in some classes back to
1379 *      localLogger; this prevents variable conflicts when you extend these classes (ie. in
1380 *      inner classes)
1381 * </li>
1382 * <li>
1383 *   <p><strong>csc_052902.1</strong> - added support to ObjectRepositoryAssembler for a
1384 *      property tag. This makes it easy to set variables (espec. static constants) at
1385 *      assembly time. See the object-repository.xml for an example. Right now Strings,
1386 *      Integers, and Booleans are supported.
1387 * </li>
1388 * <li>
1389 *   <p><strong>csc_051302.1</strong> - modified BlockIterateHandler so that when it renders
1390 *      DOM nodes it does not render closing tags for HTML elements for which closing tags
1391 *      are forbidden. Also added an initHandler() method.
1392 * </li>
1393 * <li>
1394 *   <p><strong>jrk_051002.1</strong> - I am removing the regular xmlc-2.0.1 and replacing it with xmlc-2.1-preview.
1395 *      This new xmlc is independent of xerces, jtidy, and gnu-regexp.  Of course, those other libraries are still
1396 *      needed and are included here as jtidy-r7-patched and gnu-regexp-1.1.4.  They are based on the newest versions
1397 *      of the libraries currently available (with some patches added to jtidy to make it dom3 compatible).</p>
1398 *   <p>xmlc-2.1-preview still requires Xerces-1.x.x and I suggest using the latest Xerces-1.4.4.
1399 *      Xerces-2.x.x support willl come in a while, but there are too many dependencies at this time.</p>
1400 *   <p>The one <strong>caveat</strong> with using this new version of xmlc with Xerces is that Xerces needs to have
1401 *      org.apache.xerces.dom.DocumentTypeImpl.java patched so that the following method:
1402 *      <blockquote><pre>
1403 *        void setOwnerDocument(CoreDocumentImpl doc)
1404 *
1405 *        is changed to:
1406 *
1407 *        protected void setOwnerDocument(CoreDocumentImpl doc)
1408 *      </pre></blockquote></p>
1409 *   <p>xmlc-2.1-preview has one or more classes that subclass DocumentTypeImpl, override the setOwnerDocument,
1410 *      and make calls to super(doc).  If the method is not visible to the subclass (which it isn't unless it is
1411 *      specifically marked as public or protected), then the JVM denies access to the method and the code bombs.</p>
1412 *   <p>I will, temporarily, provide the modified source and binary forms of DocumentTypeImpl at
1413 *      ftp.visi.com/users/hoju/pub.  All you need to do is drop in the new compile class into the
1414 *      org.apache.xerces.dom package in the Xerces jar file.  Then you are set to go.</p>
1415 *   <p>BTW, if you are using j2sdk1.4, make sure you put the Xerces jar file in the $JAVA_HOME/jre/lib/endorsed
1416 *      directory.  Do *not* assume that the $JAVA_HOME/jre/lib/ext directory is the equivalent of this.
1417 *      It absolutely needs to be in the endorsed directory or you will run into some very strange behavior.
1418 *      Otherwise, with JDK's previous to 1.4.0, you can put the xerces jar file anywhere in your classpath for
1419 *      compilation and in Tomcat's $TOMCAT_HOME/common/lib directory if you are using Tomcat4.x.x.</p>
1420 *   <p>That should be everything.  This should be easier to use and more efficient than xmlc-2.0.1.
1421 *      More updates will continue on xmlc-2.1, but this should work great in the meantime.</p>
1422 *   <p>Please report any bugs you find to the list promptly!</p>
1423 * </li>
1424 * <li>
1425 *   <p><strong>jrk_051002.1</strong> - modified ScriptDetector... made it so
1426 *      prepareClientResponse(Document, ViewContext) checks the DETECT_CLIENT_SCRIPTING_ENABLED
1427 *      before anything and then just ignore documents that we don't yet support in actually preparing the response
1428 *      instead of throwing a DOMException.  Probably want to re-visit this if we ever turn this back on by default to
1429 *      cover XHTMLDocument, WMLDocuemnt, and any other type of document that we wish to support in finding whether the
1430 *      browser supports scripting for that document.</p>
1431 *   <p>Specifically, this fixes cases where an XMLDocument is passed in like in the "Hello XML World" example
1432 *      in the component tutorial and we were throwing an exception because we don't explicitly support any other
1433 *      document than HTMLDocument.</p>
1434 * </li>
1435 * <li>
1436 *   <p><strong>jrk_050802.1</strong> - applying modifications to FormType.java submitted by
1437 *      Chris Webb <chris.webb@voxsurf.com> and reviewed by  myself, Iman Crawford <icrawford@greatnation.com>,
1438 *      and Diez B. Roggisch <deets@web.de>.  Here are Chris' comments:
1439 *      <blockquote>
1440 *      <p>I've reorgainsed the class org.enhydra.barracuda.core.forms.FormType to be a bit more OO.
1441 *         This is a drop in replacement with no side effects on any other classes. It should be a bit
1442 *         more efficient as well as the nested if statement has been replaced by sub-class method calls
1443 *         and there is no need to store any state about the return class type.</p>
1444 *      <p>The main benefit for this change I believe is maintainability. It should also be possible
1445 *         now to add new types without changing the FormType class by sub-classing FormType and adding
1446 *         new static definitions. This means that only real generic types are defined in FormType and
1447 *         extensions defined somewhere else.</p>
1448 *      </blockquote>
1449 * </li>
1450 * <li>
1451 *   <p><strong>csc_050702.1</strong> - modified TemplateHelper so that it will support nested
1452 *      iteration directives embedded within the same nodes. Cool. This was actually pretty tricky
1453 *      to implement, since it requires that when we hit an ITERATE_END, we not only loop back
1454 *      up to the starting node, but we skip all directives contained in that node until we get
1455 *      to nodes that pertain to the current iteration loop. Also required that when we hit an
1456 *      ITERATE_END, we ignore it unless it matches the current iteration context. RE-ran the test
1457 *      suite and everything passed muster, so I think this change is good to go (ie. I'm pretty sure
1458 *      it doesn't break anything).
1459 * </li>
1460 * <li>
1461 *   <p><strong>csc_041802.1</strong> - technically the tree is frozen, but since its not actually
1462 *      getting pulled until tonight, I'm checking this minor change in now. Added a getRootSource
1463 *      method to BaseEvent/DefaultBaseEvent...if the source is an instance of BaseEvent, it'll
1464 *      chain as deeply as possible to find the base event. Useful for handling hierarchical events
1465 *      where you want to know what the actual event fired by the client was.
1466 * </li>
1467 * <li>
1468 *   <p><strong>csc_041702.1</strong> - Emergency source check in to prepare for move to
1469 *      SourceForge. I've added some minor (but important) fixes to the component classes,
1470 *      mostly relating to making sure references get freed up so that objects can garbage
1471 *      collect properly. I've also patched the FormMap class (see previous entry below),
1472 *      plus I've added 3 new classes to the core.event.helper package BlockIterator,
1473 *      AbstractBlockIterator, and BlockIterateHandler. These are used to handle very large
1474 *      DOM templates; I'll have to document them in detail later.
1475 * </li>
1476 * <li>
1477 *   <p><strong>csc_041602.1</strong> - readded a getVals() method whioch seems to have gotten
1478 *      deleted from the previous revision of DefaultFormMap
1479 * </li>
1480 * <li>
1481 *   <p><strong>jrk_041602.1</strong> - committing patch submitted by Jefferson K. French <jeff@frenches.org>
1482 *      back in February to make the BTemplateViewHandler allow nulls like it used to.</p>
1483 * </li>
1484 * <li>
1485 *   <p><strong>jrk_041502.1</strong> - Ok, this is the update that everyone has been waiting for!
1486 *      The Form Mapping overhaul.  Very special thanks go to Iman Crawford <icrawford@greatnation.com>
1487 *      and Diez B. Roggisch <deets@web.de> for working on this.  It took a lot of time and effort, but
1488 *      we now have a consistent form mapping framework!!!  Diez also provided an update to BComponent,
1489 *      adding a little more bulletproofing to what I added over the weekend to avoid some possible
1490 *      NullPointerExceptions.
1491 *      Thanks again Iman, Diez, and anyone else who helped out on these modifications.</p>
1492 *   <h3>Here is a list of the files that changed:</h3>
1493 *   <div>
1494 *     <pre>
1495 *      Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/forms/:
1496 *           AbstractFormValidator.java
1497 *           And.java
1498 *           DefaultFormMap.java
1499 *           DefaultFormValidator.java
1500 *           FormType.java
1501 *           FormValidator.java
1502 *           Or.java
1503 *      Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/forms/validators/:
1504 *           DateRangeValidator.java
1505 *           DateValidator.java
1506 *           DigitValidator.java
1507 *           EqualsValidator.java
1508 *           MaxLengthValidator.java
1509 *           MinLengthValidator.java
1510 *           NotNullValidator.java
1511 *           RangeValidator.java
1512 *           ValidTypeValidator.java
1513 *      </pre>
1514 *   </div>
1515 *   <h3>Here are comments from Diez</h3>
1516 *   <p>Its more consistent now. All FormValidators are supposed to validate, if the
1517 *      entered value is null. This wasn't the case, so e.g. the MinLengthValidator
1518 *      forced the user to enter something. The solution had been monsters like this:
1519 *      <code>new Or(new Not(new NotNullValidator()), new MinLengthValidator(10))</code>.</p>
1520 *   <p>Now, every mandatory form field needs a NotNullValidator attached to it.  What value is
1521 *      interpreted as null is also more consistent: the AbstractFormValidator now has a isNull-method.</p>
1522 *   <h3>Here are comments from Iman</h3>
1523 *   <p><h4>Synopsis:</h4>
1524 *      Handling of nulls was inconsistant.  We made sure the only way to fail because of a null value was
1525 *      to explicitly use a validator that checks for nullness.  In the normal case this would be the
1526 *      NotNullValidator.</p>
1527 *   <p>Also, we made sure all validators validated the element.origVal.  In some cases the validator would
1528 *      validate element.val and would cause inconsistancies when element.defaultVal was not null, but parseexceptions
1529 *      had occurred.</p>
1530 *   <h4>The following details are for changes to the src directory</h4>
1531 *      <dl>
1532 *        <dt>AbstractFormValidator<dt>
1533 *        <dd>added the method <code>public boolean isNull(Object val, FormElement element)</code>
1534 *            <p>Checks the nullness of the element parameter.  This was to insure all validator derived from
1535 *               AbstractFormValidators had the same concept of nullness.</p>
1536 *        </dd>
1537 *        <dt>DefaultFormMap<dt>
1538 *        <dd>modified method <code>private Object mapElement(FormElement element, Object origVal, Locale loc)</code>
1539 *            <p>Checked the type of origVal and not parse it if it is the expected type of the element parameter.<p>
1540 *        </dd>
1541 *        <dt>DefaultFormValidator</dt>
1542 *        <dd>modified method <code>public void validate(FormElement element, FormMap map, boolean deferExceptions) throws ValidationException</code>
1543 *            <p>Changed validation to take place on the <code>element.origVal</code> instead of
1544 *               <cdoe>element.getVal</code></p>
1545 *        </dd>
1546 *        <dt>FormType<dt>
1547 *        <dd>modified method <code>public Object parse(String origVal) throws ParseException</code>
1548 *            <p>Make sure FormType.SHORT and FormType.LONG parses values that have zeros following
1549 *               the decimal place.</p>
1550 *        </dd>
1551 *        <dt>FormValidator</dt>
1552 *        <dd>added new method to interface <code>public boolean isNull(Object val, FormElement element)</code>
1553 *            <p>This is to encourage checking for nullness in a consistant way.</p>
1554 *        </dd>
1555 *        <dt>DateRangeValidator</dt>
1556 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1557 *            <p>Check for and allow null values first thing by calling the ancestor method isNull, and remove
1558 *               any other null checks.  Moved a call to <code>element.getType</code> to happen after a null
1559 *               check on the element parameter...  Restructered code to check the range calling
1560 *               <code>element.getVal</code> if no parseexception had been raised.  Also validate against val
1561 *               parameter if it is of type Date.</p>
1562 *        </dd>
1563 *        <dt>DateValidator</dt>
1564 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1565 *            <p>Check for and allow null values first thing by calling the ancestor method isNull, and remove any
1566 *               other null checks.  Removed code to get and parse <code>element.origVal</code>, the parameter val
1567 *               is the origVal Restructered code to check the range calling element.getVal if no parseexception
1568 *               had been raised.  Also validate against val parameter if it is of type Date.</p>
1569 *        </dd>
1570 *        <dt>DigitValidator</dt>
1571 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1572 *            <p>Check for and allow null values first thing by calling the ancestor method isNull, and remove any
1573 *               other null checks.  Removed code to get and parse <code>element.origVal</code>, the parameter val
1574 *               is the origVal</p>
1575 *        </dd>
1576 *        <dt>EqualsValidator</dt>
1577 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1578 *            <p>Check for and allow null values first thing by calling the ancestor method isNull, and remove
1579 *               any other null checks.  Check for any parseexceptions being raise, fail if there was one.</p>
1580 *        </dd>
1581 *        <dt>ListValidator (new class)</dt>
1582 *        <dd>Validates multiple values if the element has <code>allowMultiples = true</code>.  Needs some unit
1583 *            testing code and some real testing not ready for use.  Also contains a method to make a copy of an
1584 *            element for the purpose of deferring exceptions.</p>
1585 *        </dd>
1586 *        <dt>MaxLengthValidator</dt>
1587 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1588 *            <p>Check for and allow null values first thing by calling the ancestor method isNull, and remove
1589 *               any other null checks.</p>
1590 *        </dd>
1591 *        <dt>MinLengthValidator</dt>
1592 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1593 *            <p>Check for and allow null values first thing by calling the ancestor method isNull, and remove
1594 *               any other null checks.</p>
1595 *        </dd>
1596 *        <dt>NotNullValidator</dt>
1597 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1598 *            <p>make sure to call the ancestor's isNull method to check nullness.  Removed any other null checks.</p>
1599 *        </dd>
1600 *        <dt>RangeValidator</dt>
1601 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1602 *            <p>Check for and allow null values first thing by calling the ancestor method isNull, and remove
1603 *               any other null checks.  Make sure no parseexceptions occurerd for the element parameter.</p>
1604 *        </dd>
1605 *        <dt>ValidTypeValidator</dt>
1606 *        <dd>modified method <code>public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException</code>
1607 *            <p>Check for and allow null values first thing by calling the ancestor method isNull, and remove
1608 *               any other null checks.  Comment out a call to element.getOrigVal as the parameter val is the same.</p>
1609 *        </dd>
1610 *      <dl>
1611 * </li>
1612 * <li>
1613 *   <p><strong>jrk_041402.1</strong> - Somewhat major changes here, although most shouldn't change
1614 *      behavior you are seeing if you are successfully running a Barracuda app currently.  These changes
1615 *      make Barracuda more versatile with Servlet engines using multiple classloaders.   Most these
1616 *      changes have to do with classloading.  The main issue is that when Barracuda libs are put in a
1617 *      servlet container's lib directory so that they can be accesed by all webapps running under that
1618 *      container, any call to Class.forName() will end up causing a ClassNotFoundException.  The reason
1619 *      is that it is looking for resources in the current classloader only and not searching all classloaders
1620 *      it has access to.  The proper way to do this in Java2 is:
1621 *      <code>Thread.currentThread().getContextClassLoader().loadClass(String)</code>
1622 *      After adding that, I was able to run most of the Barracuda apps from the $TOMCAT_HOME/lib directory.
1623 *      I still ran into a couple other errors.  One was a related error in the DefaultPropertiesModel where
1624 *      I was getting a MissingResourceException.  The fix to that is, when calling ResourceBundle.getBundle
1625 *      we need to pass in the classloader.</p>
1626 *   <p>The last nasty error I was getting was a NullPointerException in java.util.ArrayList.  This stemed from
1627 *      the getViews() method in BComponent not checking for null before sending an existing ArrayList into a
1628 *      new ArrayList constructor.</p>
1629 *   <p>I added the null check and just retun null if "views" was null.  Not sure
1630 *      why "views" is null, though.  We will have to look for the root cause later.  It only seems to happen
1631 *      when running Barracuda apps with Barracuda libs in $TOMCAT_HOME/lib.  Never happens when running libs
1632 *      out of WEB-INF/lib of any given webapp???</p>
1633 *   <p>I also updated log4j.properties loading in BCategory.  Not perfect yet, but better.  Still working on
1634 *      this....</p>
1635 *   <p>Look for //jrk_20020414 to find changes...</p>
1636 *   <p><strong>UPDATE:</strong> Those using Enhydra 3.x.x will probably run into problems using
1637 *      Thread.currentThread().... and must revert to using Class.forName().  This was discussed on the
1638 *      list and James Carnegie <kipz@multicom.co.uk> is maintaining a patch to be distributed separately from
1639 *      Barracuda.  Contact him if you are having issues with Barracuda and Enhydra 3.x.x.</p>
1640 * </li>
1641 * <li>
1642 *   <p><strong>jrk_040702.1</strong> - modified TemplateHelper to fix a bug reported by
1643 *      Tim Daly <tim.daly@artnology.com>.  The patch was actually from Christian, but it seems to
1644 *      have been missed so far, so I thought I'd check it in.</p>
1645 *   <p>&gt; in AbstractBComponent L495, hasViews() returns true if there are views
1646 *      &gt; _or_ tempViews:
1647 *      &gt;
1648 *      &gt; public boolean hasViews() {
1649 *      &gt;    return ((views!=null && views.size()>0) ||
1650 *      &gt;            (tempViews!=null && tempViews.size()>0));
1651 *      &gt; }
1652 *      &gt;
1653 *      &gt;
1654 *      &gt; in BComponent L252, getViews() doesn't return any tempViews:
1655 *      &gt;
1656 *      &gt; public List getViews() {
1657 *      &gt;    return new ArrayList(views);
1658 *      &gt; }
1659 *      &gt;
1660 *      &gt; which can lead to an IndexOutOfBoundsException in TemplateHelper L330:
1661 *      &gt;
1662 *      &gt;
1663 *      &gt; if (!bcomp.hasViews()) {
1664 *      &gt;    ...;
1665 *      &gt; } else {
1666 *      &gt;    newNode = ((View) bcomp.getViews().get(0)).getNode();
1667 *      &gt; }</p>
1668 * </li>
1669 * <li>
1670 *   <p><strong>jrk_040702.1</strong> - modified HttpServletRequestWrapper to fix parameter handling
1671 *      for servers like ATG Dynamo which, upon a call to getParameter(), do not always return all
1672 *      parameters if the request was a post with extra parameters on the url string.  Actually, this
1673 *      is just an update to an existing fix to look for parameters by "parameterName=" rather than just
1674 *      "parameterName" (notice the lack of the "=" sign).  This just updates the functionality to match
1675 *      the way servlet engines grab parameters.  Patch suggested by Andras Balogh <java@reea.net> and
1676 *      tested by Merg <merg@merg.be>.</p>
1677 * </li>
1678 * <li>
1679 *   <p><strong>csc_032202.1</strong> - found and fixed a really obscure bug in TemplateHelper,
1680 *      that was causing parts of the template to get processed twice, which not only was extra
1681 *      overhead, but also caused null pointer exceptions in certain cases (ie. when the element
1682 *      the step child was bound too got removed and then the step child was rendered it wouldn't
1683 *      have a parent, thereby causing a null pointer exception when adding teh element back into
1684 *      the template).
1685 *   </p><p>
1686 *      The solution in this particular case was to modify TemplateHelper so that in the main
1687 *      render() method, it only removes child nodes and replaces them from the master template
1688 *      if the component we are rendering is not a step child. I added a test case to TestBTemplateRender
1689 *      and verified that it seems to work. Thanks to Thuong Nguyen [thuong.nguyen@theplatform.com]
1690 *      for coming up with a sample piece of markup that clearly illustrated the problem.
1691 * </li>
1692 * <li>
1693 *   <p><strong>csc_031902.1</strong> - modified HTMLTableRenderer to implement the createDefaultNode
1694 *      routine. This will allow you to return a BTable component from the a template model
1695 *      and have it automatically get associated with the proper node.
1696 * </li>
1697 * <li>
1698 *   <p><strong>csc_031502.2</strong> - modified DefaultViewHandler to rename logger to
1699 *      localLogger; modified BTemplateViewHandler to not even reference a logger (it can
1700 *      always use localLogger if it needs to). This name change is useful since code
1701 *      which uses these classes often defines its own logger classes (calling them logger)
1702 * </li>
1703 * <li>
1704 *   <p><strong>csc_031502.1</strong> - created a FormUtil class which contains some simple
1705 *      utility functions to assist in form validation
1706 * </li>
1707 * <li>
1708 *   <p><strong>csc_031402.2</strong> - updated the FormMap/DefaultFormMap classes
1709 *      with some minor modifications. First, use a static final defaultLoc throughout
1710 *      rather than constantly grabbing a default loc every time we map an item. Second,
1711 *      add 2 mapElement methods that take a key and origVal--look up the form element
1712 *      that matches the key and then set the value accordingly. This makes it possible
1713 *      to map individual elements (rather than mapping the whole shebang all at once from
1714 *      a request or statemap).
1715 * </li>
1716 * <li>
1717 *   <p><strong>csc_031402.1</strong> - very minor change to FormType so that it will
1718 *      correctly map Boolean types from "y" and "n", along with other strings
1719 * </li>
1720 * <li>
1721 *   <p><strong>csc_031202.1</strong> - AbstractBComponent - tweaked destroyCyle so that it checks
1722 *      to make sure children are non-null before trying to iterate through and invoke destroy cycle
1723 *      on them. This should fix a null pointer exception that Peter Mergaerts [PMERGAER@janbe.jnj.com]
1724 *      was getting on occasion
1725 * </li>
1726 * <li>
1727 *   <p><strong>csc_030802.1</strong> - Found and fixed a bug in AbstractBComponent; when
1728 *      removing al step children, need to invoke their destroyCycle() method to ensure that
1729 *      they correctly release references to data, allowing them to be reclaimed by system gc
1730 * </li>
1731 * <li>
1732 *   <p><strong>csc_030602.1</strong> - Added a WeakSession repository to the
1733 *      ObjectREpository class. This basically gives you a place to put things that
1734 *      are scoped to session but can be reclaimed by the garbage collecter as needed.
1735 *      Excellent place to put things like multi-page results sets; if its there, you
1736 *      don't have to re-query the DB, if it's not then you know you need to.
1737 * </li>
1738 * <li>
1739 *   <p><strong>csc_025102.1</strong> - Modified DefaultEventContext so that when
1740 *      persisting/restoring state, it saves Local ObjectRepository state as well
1741 *      across client side redirects)
1742 * </li>
1743 * <li>
1744 *   <p><strong>csc_022102.1</strong> - Removed GlobalRepository, and revamped ObjectRepository (both
1745 *      found in org.enhydra.barracuda.plankton.data). Basically, ObjectRepository now extends StateMap,
1746 *      and can be used to easily access common storage areas, scoped as:
1747 *      <ul><li>
1748 *          Global - 1 per JVM, threadsafe
1749 *      </li><li>
1750 *          Session - Wrapper over HttpSession (or a DefaultStateMap if running in a non-servlet
1751 *          environment...very useful for testing purposes!)
1752 *      </li><li>
1753 *          Local - Lasts for the duration of a req-resp cycle
1754 *      </li><li>
1755 *          Custom - Accessible via NameSpace or String key. If you use these, you are responsible for
1756 *          cleanup.
1757 *      </li></ul>
1758 *   </p>
1759 *   <p>The basic idea here is too make it really easy to access common storage spaces (in particular:
1760 *      Global, Session, and Local). So this class provides static methods for all of these. To make this
1761 *      integrate with Barracuda, I modified ApplicationGateway and ComponentGateway to set up the
1762 *      Session repository (has to pass it a ref to the req obj), and then to clean up these repositories
1763 *      when the request is complete.
1764 *   </p>
1765 *   <p>What this means is that you can easily access session information from anywhere in your code now...
1766 *      simply call ObjectRepository.getSessionRepository() and proceed to put data in or take it out. Same
1767 *      thing for global and local.
1768 *   </p>
1769 * </li>
1770 * <li>
1771 *   <p><strong>jrk_021902.1</strong> - Made change supplied by Stephen Peterson <stephen_peterson@agilent.com>.  I updated
1772 *      Barracuda to work with Log4j1.2.  The current release that Barracuda now uses is Log4j-1.2beta3.  This change requires no
1773 *      changes to developer code referencing BCategory.  The only action required to support the new Log4j is that the Log4j library
1774 *      be updated to Log4j1.2beta2 or later.  Otherwise, this change should be transparent.  See Apache's site for information
1775 *      on what's new in Log4j-1.2:  http://jakarta.apache.org/log4j/docs/download.html
1776 *   </p>
1777 * </li>
1778 * <li>
1779 *   <p><strong>jrk_021802.1</strong> - Made changes supplied by Diez B. Roggisch <diez.roggisch@artnology.com>.  I made
1780 *     a some formatting changes and added contributors where appropriate.
1781 *   </p>
1782 *   <blockquote>
1783 *      The problem is that we (and surely others as well) need support for file
1784 *      uploads. These come as MIME-Requests. The standard HttpServletRequest can't
1785 *      deal with them, so you have to use your own wrapper. Unfortunately BARRACUDA
1786 *      doesn't allow to install yourt own wrapper. So I made some changes to
1787 *      ApplicationGateway. It now doesn't create a HttpServletRequestWrapper by
1788 *      default. Instead a method wrap is called. This method creates either a
1789 *      HttpServletRequestWrapper or it invokes a RequestMapper.wrap method. The
1790 *      RequestMapper is a simple interface, and it can be installed by setting a
1791 *      class variable in ApplicationGateway.
1792 *   </blockquote>
1793 * </li>
1794 * <li>
1795 *
1796 *    <p><strong>jrk_021502.1</strong> - Made changes supplied by Stephen Peterson.  I made
1797 *     a some formatting changes and added contributors where appropriate.
1798 *     <ol>
1799 *       <li>A new event helper: org.enhydra.barracuda.core.event.helper.EventConnectorFactory
1800 *         <p>This class associates a given event with a given event handler.
1801 *           This class reduces the need for the anonymous inner classes typically
1802 *           found in gateways. To associate an event with an event handler reduces
1803 *           to a single line of code:
1804 *           <blockquote>
1805 *             <code>specifyLocalEventInterests(new EventConnectorFactory(Handler.class), Event.class);</code>
1806 *           </blockquote></p>
1807 *       </li>
1808 *       <li>A bug (?) fix to DefaultView.searchForTemplates()
1809 *         <p>in some of my setups I kept getting a NullPointerException
1810 *           in DefaultView.searchForTemplates() ... I never quite found exactly what
1811 *           was wrong with my setup, but adding a null check on curnode at the start
1812 *           of searchForTemplates() took care of it. (jrk - I also added a logger.warn()
1813 *           line if the node is null)</p>
1814 *       </li>
1815 *     </ol>
1816 *   </p>
1817 * </li>
1818 * <li>
1819 *   <p><strong>csc_021502.1</strong> - Modified all the test cases to use assertTrue()
1820 *      instead of assert() (assert is now a keyword in JDK 1.4)
1821 *   </p>
1822 * </li>
1823 * <li>
1824 *   <p><strong>csc_021102.3</strong> - Fixed a bug in BComponent, whereby renderView
1825 *      didn't really do anything. This meant that if you used a plain-jane BComponent
1826 *      (ie. to control enabled/disabled), the custom renderer never got invoked. By
1827 *      adding this functionality into BComponent, you can now use plain BComponents
1828 *      to control both visibility and enabled/disabled rendering, plus, we were able to
1829 *      remove all the duplicated renderView methods from all of the individual components
1830 *      that extend from BComponent. Much much better now...
1831 *   </p>
1832 * </li>
1833 * <li>
1834 *   <p><strong>csc_021102.2</strong> - Modified HTMLComponentRenderer so that is
1835 *      again sets enabled/disabled at the end of the render cycle. This was commented
1836 *      out at some point way back, and I can't figure out why...there's a chance that
1837 *      it might cause a problem if you pass back a disabled BAction component (since
1838 *      the component would be disabled, the HTMLComponentRenderer would remove any
1839 *      references to href and target; perhaps this might cause a problem when the
1840 *      HTMLActionRenderer tries to render next...but I can't see anything obvious in
1841 *      the code, so if you run into anything, let me know). This change is necessary
1842 *      so that you can use a plain-jane BComponent to control simple things like visibility
1843 *      and enabled/disabled status.
1844 *   </p>
1845 * </li>
1846 * <li>
1847 *   <p><strong>csc_021102.1</strong> - Modified the BTemplateViewHandler so as to
1848 *      allow the abstract method to return either a TemplateModel or a List of
1849 *      TemplateModels. Before now, you could only return one. If you are extending
1850 *      from this class anywhere, please note that the method signature changed from
1851 *      singular to plural: getTemplateModels (note the 's'!)
1852 *   </p>
1853 * </li>
1854 * <li>
1855 *   <p><strong>csc_020602.1</strong> - removed all references to log4j stuff in the
1856 *      org.enhydra.barracuda.taskdefs package. Basically, if you need loggin here, use
1857 *      that provided by Ant. This eliminates the need for log4j_localize.properties to
1858 *      be in your classes directory (which was a major pain in the butt for projects
1859 *      that were simply using Barracuda)
1860 *   </p>
1861 * </li>
1862 * <li>
1863 *   <p><strong>csc_020502.1</strong> - added a new GenerateSSIs taskdef. This taskdef
1864 *      is primarily useful if you use ssi based mockups, when you want to edit your
1865 *      mockups in a single HTML file and then have pieces of it automatically written
1866 *      out to .ssi files. The taskdef will parse a given file (or fileset) looking for
1867 *      html comments that look like this (where 'foo' can be the name of any ssi file):
1868 *
1869 *     <pre>
1870 *       &lt;!-- start foo.ssi --&gt;
1871 *       ...
1872 *       &lt;!-- end foo.ssi --&gt;
1873 *     </pre>
1874 *
1875 *   </p><p>When the taskdef sees these tags it will write the contents to the target ssi
1876 *      file IFF the source file is newer than the ssi file or force="true". For complete
1877 *      details, see the source comments.
1878 *   </p>
1879 * </li>
1880 * <li>
1881 *   <p><strong>csc_020202.1</strong> - added a NameSpace, ObjectRepository, and
1882 *      GlobalObjectRepository classes to org.enhydra.barracuda.core.util. These
1883 *      classes are useful for establishing a common storage facility, where
1884 *      commonly used resources (ie. datasource) can be placed. Also created an
1885 *      ObjectRepositoryAssembler which can be used to automatically insert items
1886 *      into the default ObjectRepository at startup (the assembler class implements
1887 *      HttpServlet, and can be pointed at a file like /WEB-INF/object-repository.xml)
1888 *      to automatically set up items in the OR when the servlet starts. Also made a
1889 *      few minor improvements to miscellaneous classes.
1890 *   </p>
1891 * </li>
1892 * <li>
1893 *   <p><strong>csc_013102.1</strong> - added several methods to HttpServletRequestWrapper
1894 *      to comply with Servlet 2.3 spec. Upgraded the servlet.jar included in WEB-INF/ant/lib/
1895 *      to use the new servlet 2.3 jar.
1896 *   </p>
1897 * </li>
1898 * <li>
1899 *   <p><strong>csc_013002.1</strong> - Couple of significant changes.
1900 *     <ul>
1901 *       <li>Changed ScriptDetector.java to set DETECT_CLIENT_SCRIPTING_ENABLED = false;
1902 *          There is a bug in IE 5.5 which causes the URL to be hosed when this is turned
1903 *          on, so I'm turning it off until I can decide what to do. This means that
1904 *          scripting capabilities will once more be assumed strictly on client type, rather
1905 *          than trying to actually determine whether scripting is enabled.</li>
1906 *       <li>Moved the src_test/test package into src/org/enhydra/barracuda/testbed and
1907 *          modified all tests to use this new package. This allows apps using Barracuda
1908 *          to use the testbed classes as well (previously you had to cut and paste)</li>
1909 *       <li>Started working on a BarracudaAdmin example. This is working right now, but I
1910 *          don't have any documentation on it yet (coming soon, hopefully)</li>
1911 *       <li>I also created a BarracudaWarStub which can be used as a starting point for
1912 *          Barracuda apps. This will be checked in separately under its own cvs directory
1913 *          (soon, hopefully...need support to create the directory for me)</li>
1914 *     </ul>
1915 *   </p>
1916 * </li>
1917 * <li>
1918 *   <p><strong>jrk</strong> - Overhauled ScriptDetector.java and ScriptingCheck.js
1919 *      to fix bugs where mailto: and javascript: href values were improperly
1920 *      getting $csjs and $u parameters added to them. Also fixed a bug were
1921 *      hash values on URL's were not working with the scripting check because
1922 *      we were indiscriminately appending the scripting flags where, in order
1923 *      for a hash to work to link to a particular anchor in a document, the hash
1924 *      value needs to be the last item on the URL string.
1925 *   </p>
1926 *   <p>I also enhanced the Javadoc comments in ScriptDetector removed a lot of the
1927 *      old code that didn't make sense anymore.  In addition, I modified
1928 *      prepareClientResp so that it is overloaded rather than using instanceof all
1929 *      the time to check for the type of document we are dealing with. This provides
1930 *      compile-time checking rather than running into errors at runtime. I left in
1931 *      a version of prepareClientResp that takes a generic Document and uses
1932 *      instanceof for backward compatibility but I strongly recommend using the more
1933 *      specific HTMLDocument version and other versions (when they become supported).
1934 *   </p>
1935 *   <p>The next thing to do is to create an "Assume Scripting Enabled" mode where no
1936 *      scripting check is run, but Barracuda will still think the client supports
1937 *      scripting.
1938 *   </p>
1939 * </li>
1940 * <li>
1941 *   <p><strong>dbr_012202.1</strong> - Applied a patch from Diez B. Roggisch
1942 *      [diez.roggisch@artnology.com] that provides BAction setParam with support
1943 *      for String[] so both types of request parameters are supported now.
1944 *   </p>
1945 * </li>
1946 * <li>
1947 *   <p><strong>dbr_122801.1</strong> - Applied patches from Diez B. Roggisch
1948 *      [diez.roggisch@artnology.com] that fixed bugs in both the DigitValidator
1949 *      and the DateValidator where they wouldn't validate if the desired FormType
1950 *      wasn't a String.
1951 *   </p>
1952 * </li>
1953 * <li>
1954 *   <p><strong>csc_011902.1</strong> - Added back in UserReport.properties and
1955 *      UserReport_es.properties...these somehow got removed from cvs. I restored
1956 *      these files from the Barracuda 1.0.1 zip, and tested that the CompTest3
1957 *      example works again now...Thanks to Jacob kjome [apu@mediaone.net] for
1958 *      catching this.
1959 *   </p>
1960 * </li>
1961 * <li>
1962 *   <p><strong>dbr_011602.1</strong> - Applied a patch from Diez B. Roggisch
1963 *      [diez.roggisch@artnology.com] that expands the FormMap interface to
1964 *      optionally take a locale when mapping; if none is passed the default
1965 *      locale will be used.
1966 *   </p>
1967 * </li>
1968 * <li>
1969 *   <p><strong>jdv_121201</strong> - Applied a patch to Localize2 from
1970 *      Jason Vinson [jason.vinson@mindspring.com]. This patch basically
1971 *      adds support for two additional taskdef parameters: masterlocalefile
1972 *      and masterlocaledir. If these parameters are present, Localize2 will
1973 *      perform all localization out of these master files, rather than looking
1974 *      for individual property files on a per-template basis.
1975 *   </p><p>
1976 *      As an example of this, if you wanted to localize an app and store all of
1977 *      text in a common directory (ie. ./Locales), using a file naming convention
1978 *      of MasterProps.properties, MasterProps_en.properties, MasterProps_sa.properties,
1979 *      etc, then you would modify your ant build.xml's invocation of Localize to
1980 *      pass two additional parameters, like this:
1981 *   </p><p>
1982 *      masterlocaledir="./Locales" <br>
1983 *      masterlocalefile="MasterProps"
1984 *   </p>
1985 * </li>
1986 * <li>
1987 *   <p><strong>csc_121201.1</strong> - Fixed a bug in HTMLTextRenderer and
1988 *      XMLTextRenderer...only try and set the text value if text is non-null.
1989 *      Checked the link renderers, and found that this fix had already been
1990 *      applied there.
1991 *   </p>
1992 * </li>
1993 * <li>
1994 *   <p><strong>csc_112901.2</strong> - Fixed a bug in ScriptDetector, where we weren't
1995 *      handling the Area element in the anchors section. Also modified BarracudaConfig
1996 *      to call ScriptDetector, since its not extending DefaultViewHandler.
1997 *   </p>
1998 * </li>
1999 * <li>
2000 *   <p><strong>csc_112901.1</strong> - Fixed a bug in CopyAndReplace. Basically, if
2001 *      you are using it to include ssi's, you _don't_ want to copy those ssi's across
2002 *      too (or they get replace run on them twice, once as their own file, and then
2003 *      again after they've been included...this causes problems. SO...modified the
2004 *      build.xml to not copy across ssi files, and then modified the CopyAndReplace
2005 *      taskdef so that if the include file is not found it'll look in the src dir.
2006 *   </p><p>
2007 *      After updating from cvs, you MUST delete any *.ssi files which are left in
2008 *      src\org\enhydra\barracuda\config\xmlc.
2009 *   </p>
2010 * </li>
2011 * <li>
2012 *   <p><strong>csc_112801.1</strong> - Created a new Localize2 taskdef (which will
2013 *      eventually replace Localize, once we've had a chance to test it further)
2014 *      and updated build.xml to use this. This new taskdef solves the issues
2015 *      described here: <a HREF="http://barracuda.enhydra.org/project/mailingLists/barracuda/msg02207.html">detailed here</a>.
2016 *   </p>
2017 * </li>
2018 * <li>
2019 *   <p><strong>csc_111601.1</strong> - Start reworking the Localize taskdef so as not
2020 *      to need XMLC. This solves a problem which is <a HREF="http://barracuda.enhydra.org/project/mailingLists/barracuda/msg02207.html">detailed here</a>.
2021 *   </p><p>
2022 *      The first step was to modify the CopyAndReplace taskdef so that it can
2023 *      (optionally) resolve SSIs. The default is false; so if you want it to
2024 *      do this you will need to set the parameter accordingly (see Barracuda's
2025 *      build.xml for examples)
2026 *   </p>
2027 * </li>
2028 * <li>
2029 *   <p><strong>csc_110501.1</strong> - Fix a problem that was introduced
2030 *      with the csc_103101.1 fix. Basically, what we were doing is creating
2031 *      a slightly more complex piece of markup (ie. clone the current
2032 *      node, then add an anchor element into it) and then returning that. The
2033 *      problem is that when template helper goes and automatically creates a
2034 *      view, it does it on the outermost node (in the case of CompEx7, this
2035 *      is a <span> element, which is not valid for a link to be bound to).
2036 *      So the problem is that when we create a more complex piece of markup
2037 *      the component sometimes needs to be bound to an element that is buried
2038 *      down inside the node created. TemplateHelper has no idea how to find
2039 *      the right piece to bind it properly.
2040 *   </p><p>
2041 *      The real solution here is to modify createDefaultNode() so as to pass in
2042 *      a reference to the component; this then allows the code that creates the
2043 *      default node to optionally associate the component with the right element
2044 *      in the view then and there (meaning TemplateHelper won't have to do that
2045 *      step). Of course, if the code that creates the default node _doesnt_
2046 *      create a default view, template helper will fall back to the previous
2047 *      approach, which is simply to create a view on the outermost node returned.
2048 *   </p><p>
2049 *      Note that there is a larger issue here which still hasn't been fixed. When
2050 *      the createDefaultNode returns a node with children (HTMLLinkRenderer is an
2051 *      example) wherein it added a view onto the part of that markup, a
2052 *      BTemplate delegate gets created on the nodes _after_ the delegate, but before
2053 *      its rendered. What this means is that even though the delegate component
2054 *      renders properly, the BTemplate render wipes out what was there (since
2055 *      the master template snapshot is taken at the time the view is created, rather
2056 *      than right before the component renders). This whole thing is very complex.
2057 *      The real solution is to revamp the way the views are generated (as described
2058 *      here: http://barracuda.enhydra.org/project/mailingLists/barracuda/msg02326.html)
2059 *      However, I don't have time to implement this right now, so I inserted a temporary
2060 *      fix instead: if the createDefaultNode() method adds a view, the BTemplate
2061 *      delegates will not be created. This isn't ideal, but it works for now.
2062 *   </p>
2063 * </li>
2064 * <li>
2065 *   <p><strong>csc_110201.1</strong> - Added a notion of RenderStrategy, defined
2066 *      in org.enhydra.barracuda.core.comp.renderer.RenderStrategy as either
2067 *      SCRIPT_AS_NEEDED or NEVER_SCRIPT. Strategies can be set on a per-component
2068 *      basis; if the strategy is null, it is obtained from the component's
2069 *      parent; if the root component's strategy is null, it defaults to
2070 *      DEFAULT_RENDER_STRATEGY.
2071 *   </p><p>
2072 *      The basic idea here is that sometimes even though a client may have scripting
2073 *      enabled, a developer may still not want the components to render using
2074 *      scripting. All the developer has to do is set a component's render strategy
2075 *      (either at the individual component level, at the root component level, or
2076 *      at the default setting level in RenderStrategy). When a component renderer
2077 *      wishes to make use of Javascript, it must not only check to see that Javascript
2078 *      is enabled, but also that the component's render strategy allows for it.
2079 *   </p><p>
2080 *      Note that right now the only renderer that really uses scripting is
2081 *      HTMLActionRenderer. Also note that this change does NOT apply to
2082 *      HTMLScriptRenderer or HTMLScriptResourceRenderer...these renderers MUST always
2083 *      render, regardless of whether or not the client supports scripting (see notes
2084 *      therein for details)
2085 *   </p>
2086 * </li>
2087 * <li>
2088 *   <p><strong>csc_103101.1</strong> - Fix a bug in HTMLLinkRenderer; when it was
2089 *      trying to create a default node, if the type was not &lt;a&gt;, &lt;button&gt;, or
2090 *      &lt;input&gt;, it was just creating an &lt;a&gt; element and returning that. This caused
2091 *      whatever the node containing the directive was (ie. a &lt;td&gt;) to get discarded.
2092 *      Now, when the BLink was added back into the DOM, it would eventually create
2093 *      a containing &lt;td&gt; element so as to be valid markup, but all the attributes
2094 *      of the original node are of course missing.
2095 *   </p><p>
2096 *      A much better approach is to clone the current node, and then add a newly
2097 *      created <a> element to that. Thanks to Kirk Daries [Kirk.Daries@sita.co.za]
2098 *      for finding this one.
2099 *   </p>
2100 * </li>
2101 * <li>
2102 *   <p><strong>csc_102601.1</strong> - Fix a minor glitch in the error logging within
2103 *      HTMLListRenderer; a null pointer exception was being generated if logging
2104 *      was enabled and the item being added to the list happens to be a BComponent
2105 *      which is not yet bound to a view. Thanks to Sarens, Filip [FSARENS@janbe.jnj.com]
2106 *      for reporting this problem.
2107 *   </p>
2108 * </li>
2109 * <li>
2110 *   <p><strong>csc_102501.2</strong> - Applied a patch to ensure that when we
2111 *      handle a RedirectException, the resulting redirect url contains the necessary
2112 *      script detector flag (this will prevent another subsequent client side redirection
2113 *      in order to determine it).
2114 *   </p>
2115 * </li>
2116 * <li>
2117 *   <p><strong>bw_102501.1</strong> - Applied a patch submitted by Bill_Wallace@elementk.com.
2118 *      The basic purpose of this change was to make it easier to get info out of the
2119 *      validators about what is being validated.   The changes are quite minor, only
2120 *      adding getX() methods where needed.  Note that none of the information retrieved is
2121 *      muttable, so getting it is purely informational.
2122 *   </p>
2123 * </li>
2124 * <li>
2125 *   <p><strong>csc_102501.1</strong> - Upgraded build system to use final versions of
2126 *      Ant 1.4.
2127 *   </p>
2128 * </li>
2129 * <li>
2130 *   <p><strong>csc_102401.1</strong> - Fixed a major typo in AbstractBComponent;
2131 *      this bug was causing step children not to get removed correctly, which in
2132 *      turn caused all kinds of really subtle problems when you have a component
2133 *      hierarchy that was getting reused. Because the step child was never getting
2134 *      removed, on the second render it would be pointing to a view that no longer
2135 *      existed. Ouch.
2136 *   </p><p>
2137 *      This is a high priority fix--if you have been having problems related to
2138 *      nested components, you should make sure you have a version of the source
2139 *      that includes this patch.
2140 *   </p>
2141 * </li>
2142 * <li>
2143 *   <p><strong>csc_102201.1</strong> - This checking represents some very
2144 *      significant changes that I've been working on over the last several says.
2145 *      The basic thrust behind these changes has been to make Barracuda accurately
2146 *      detect whether or not scripting is actually _enabled_ on the client (not
2147 *      just if its supported, which is what we were doing before). This change is now
2148 *      complete, and the <a HREF="../../../../Barracuda/docs/misc_features.html#Detecting_Client_Side_Scripting">
2149 *      explanation is given here</a>.
2150 *   </p><p>
2151 *      Here is a line item explanation of the specific changes:
2152 *   </p><p>
2153 *      1. Created org.enhydra.barracuda.core.helper.servlet.ScriptDetector. This class
2154 *      basically provides several key helper methods that are used by other classes
2155 *      within Barracuda. These methods included checkClientReq() and prepareClientResp().
2156 *   </p><p>
2157 *      2. Renamed BScript to BScriptResource and then created a new BScript component
2158 *      which actually allows you to attach a client side script to a DOM element. BScripts
2159 *      can take any number of BScriptResources. The way a BScript works is that you specify
2160 *      the script attribute (ie. "onload"), the script command (ie. "sc_CheckPage();"),
2161 *      and then the mode (APPEND, PREPEND, or REPLACE). The mode will determine whether the
2162 *      script command you specify overwrites whatever else is in the template for that
2163 *      element, or whether it simply adds to it (either in front of or after what's there).
2164 *      Note that this change effectively brings full client side scripting capabilities
2165 *      to the Barracuda component model, although we haven't created any library of routines
2166 *      yet. Also note that I moved both of these classes from the main comp directory into
2167 *      a comp.scripting subpackage. Also created renderers for these classes (note that
2168 *      for scripting renderers, they must ALWAYS render, even if the client doesn't support
2169 *      scripting, as they might always enable it later and then it needs to be there).
2170 *   </p><p>
2171 *      3. Created a ScriptingCheck.js file to actually provide the client side check (sets
2172 *      all the $csjs values in the page from false to true)
2173 *   </p><p>
2174 *      4. Modified ViewUtil to actually check for the $csjs value when determining
2175 *      scripting type
2176 *   </p><p>
2177 *      5. Modified ComponentGateway to call ScriptDetector.checkClientReq() prior to
2178 *      processing GET requests; this will ensure that if a request comes in without
2179 *      a $csjs value it will get rerouted immediately so to provide one. Call
2180 *      ScriptDetector.prepareClientResp() after rendering the main component DOM; This
2181 *      will ensure that all the links and forms have the necessary $csjs=false values
2182 *      embedded.
2183 *   </p><p>
2184 *      6. Modified ApplicationGateway to call ScriptDetector.checkClientReq() as
2185 *      described above. Note that app gateway can't make the corresponding
2186 *      prepareClientResp() call because it knows nothing about the DOM (ie. the
2187 *      event model is not tied to any particular rendering mechanism).
2188 *   </p><p>
2189 *      7. Modified DefaultViewHandler to provide the corresponding call to
2190 *      ScriptDetector.prepareClientResp(). Note that if you are using components
2191 *      within the context of the event model, you really should have your view
2192 *      handlers extend from either DefaultViewHandler or BTemplateViewHandler
2193 *      so that you can pick up this functionality for free. If you are building/
2194 *      rendering your own component hierarchy, you will need to add the corresponding
2195 *      prepareClientResp() call to your own code to take advantage of the new
2196 *      scripting detection functionality. Of course, if you don't do this, everything
2197 *      just continues to function as it did before.
2198 *   </p><p>
2199 *      8. Updated the docs describing this (see /docs/misc_features.html); reran the
2200 *      test suite and rebuilt all the jars.
2201 *   </p><p>
2202 *      I think that about covers it. The key point to note here is that this change
2203 *      effectively tells us whether or not the client actually has scripting enabled.
2204 *      While I don't think these changes will break anything, note that you can always
2205 *      turn them off simply by setting ScriptDetector.DETECT_CLIENT_SCRIPTING_ENABLED=false;
2206 *   </p>
2207 * </li>
2208 * <li>
2209 *   <p><strong>csc_101901.1</strong> - Backout out the encoding changes I added
2210 *      to FormGateway under csc_101701.1...turns out they are not needed there
2211 *      since RequestDispatcher.forward() handles this for us.
2212 * </li>
2213 * <li>
2214 *   <p><strong>csc_101701.1</strong> - Diez B. Roggisch [d.roggisch@artnology.com]
2215 *      identified a problem in the HTMLActionRenderer: basically, when we get a
2216 *      components action, the value is encoded for us with a session id if URL rewriting
2217 *      id turned on. This is fine, as long as you don't need to modify the
2218 *      url. Unfortunately, HTMLActionRenderer sometimes needs to do this. So, we
2219 *      created another getAction() method in BAction which allows you to get the
2220 *      action _without_ having it encoded. The HTMLActionRender can then manipulate
2221 *      it as needed and encode it itself.
2222 *   </p><p>
2223 *      In addition, there are several gateway classes (ParamGateway, FormGateway)
2224 *      which effectively do a redirect. These need to use URLRewriter when building
2225 *      the target, so that the session info will get preserved through the redirect.
2226 *   </p>
2227 * </li>
2228 * <li>
2229 *   <p><strong>csc_101201.1</strong> - Modify HTMLActionRenderer: when rendering
2230 *      an &lt;input&gt; element whose type="submit", we need to set the forms' onsubmit
2231 *      handler to simply click the button, thereby running it through the same
2232 *      chunk of Javascript as if the user actually pressed the button. IE seems
2233 *      to do this by fault, but Mozilla does not. This fix will work for both.
2234 *      Thanks to Iman L. Crawford [icrawford@greatnation.com] for finding this.
2235 *   </p>
2236 * </li>
2237 * <li>
2238 *   <p><strong>csc_101101.2</strong> - Minor tweaks to BarracudaEventBuilder.dtd;
2239 *      it need to refer to 'req-events' and 'resp-events' (note the plural) rather
2240 *      than 'req-event' and 'resp-event' (singular). Thanks to Diez B.
2241 *      Roggisch [d.roggisch@artnology.com] for catching this one.
2242 *   </p>
2243 * </li>
2244 * <li>
2245 *   <p><strong>csc_101101.1</strong> - Modified ApplicationGateway so the
2246 *      initializeLocal(ServletConfig iconfig) method is deprecated and final;
2247 *      this will prevent it from compiling, and will force people to
2248 *      correct their code to call the right method. Failure to do this
2249 *      was allowing the system to compile but not run.
2250 *   </p>
2251 * </li>
2252 * <li>
2253 *   <p><strong>csc_101001.2</strong> - previously, the HTMLSelectRender's
2254 *      createDefaultNode() was just always creating a select element from
2255 *      scratch. We really want to try nd use the template node if at all
2256 *      possible, however, so that we can inherit any special property settings
2257 *      it might have (like name)
2258 *   </p>
2259 * </li>
2260 * <li>
2261 *   <p><strong>csc_101001.1</strong> - More constructors work; elementinated
2262 *      references to Views in constructors. This is because in most case
2263 *      people will just be passing components back from a model and allowing
2264 *      the model component to actually create a view for them. This streamlines
2265 *      the APIs significantly, although it will break existing code. Fortunately,
2266 *      the changes you need to make to get it to recompile are straightforward
2267 *      and obvious.
2268 *   </p><p>
2269 *      Fixed a non-related bug in BInput and BSelect that didn't show up until
2270 *      I made the above change. Basically, if you returned one of these components
2271 *      from a model, and that component had listeners attached to it, the preRender
2272 *      method will create a delegate BAction component for all the views. The problem
2273 *      was that it should also be looking at tempViews too (since these will be set
2274 *      when the model creates the view for the component).
2275 *   </p>
2276 * </li>
2277 * <li>
2278 *   <p><strong>csc_100901.5</strong> - Cleaned up constructors on various components.
2279 *      A lot of the components had single arg constructors which took just a view...
2280 *      in reality, this flavor is almost never used, so I removed them.
2281 *   </p>
2282 * </li>
2283 * <li>
2284 *   <p><strong>csc_100901.4</strong> - Fixed a very serious (yet difficult to spot!)
2285 *      bug in HTMLListRenderer and HTMLTableRenderer whereby it was setting the
2286 *      template node to null after render, rather than setting it back to its
2287 *      original value. Fixed now.
2288 *   </p>
2289 * </li>
2290 * <li>
2291 *   <p><strong>csc_100901.3</strong> - DefaultFormElement was incorrectly passing
2292 *      in a 'false' value to the final constructor. Thanks to Diez B. Roggisch
2293 *      [d.roggisch@artnology.com] for catching this.
2294 *   </p>
2295 * </li>
2296 * <li>
2297 *   <p><strong>csc_100901.2</strong> - Modified web.xml to conform to the new 2.3
2298 *      DTD. Thanks to Jacob Kjome [apu@mediaone.net] for this patch.
2299 *   </p>
2300 * </li>
2301 * <li>
2302 *   <p><strong>csc_100901.1</strong> - Reverse yesterdays change...just use the noargs
2303 *      init method and then call getServletConfig() to get the ServletConfig object.
2304 *   </p>
2305 * </li>
2306 * <li>
2307 *   <p><strong>csc_100801.1</strong> - Make sure the ApplicationGateway class
2308 *      invokes super.init() in the init(ServletConfig) method. Also applied this
2309 *      fix to ResourceGateway. Thanks to Diez B. Roggisch [d.roggisch@artnology.com]
2310 *      for catching this.
2311 *   </p>
2312 * </li>
2313 * <li>
2314 *   <p><strong>csc_100501.2</strong> - <strong>1.0 RELEASE (source is tagged in cvs
2315 *      under BARRACUDA_1_0_FINAL</strong>
2316 *   </p>
2317 * </li>
2318 * <li>
2319 *   <p><strong>csc_100501.1</strong> - Modified ApplicationGateway so
2320 *      that it creates the DispatchQueue using a factory method. This
2321 *      makes it possible for someone to provide a different implementation.
2322 *      Thanks to Diez B. Roggisch [d.roggisch@artnology.com] for the suggestion.
2323 *   </p>
2324 * </li>
2325 * <li>
2326 *   <p><strong>csc_100401.1</strong> - Very minor change to remove some
2327 *      vestige code from AbstractTemplateModel: basically it still had
2328 *      a resetModel() method in it, which went away from the interface
2329 *      long ago. I just overlooked it in AbstractTemplateModel.
2330 *   </p>
2331 * </li>
2332 * <li>
2333 *   <p><strong>csc_100301.2</strong> - Several changes.<p>
2334 *      First of all, there was a problem in the jsrsClientServerHTTPLib
2335 *      script. Basically, it was not setting the selected options correctly.
2336 *      In addition, I modified the posted script to not include button, submit
2337 *      and reset elements. Furthermore, I made it so that when you run it
2338 *      with debuggin turned on, you can manually submit the generated script
2339 *      (in IE anyway). This fixes a problem whereby the values of select
2340 *      elements were not getting passed through to the ParamGateway correctly.
2341 *   </p><p>
2342 *      Second, there was a problem in HTMLActionRenderer whereby if the
2343 *      action included url params, when the back button was disabled it
2344 *      would screw up the resulting URL that was created to map the request
2345 *      to the param gateway. There were 2 underlying problems. First of all,
2346 *      the BAction component when constructing an action String needed to be
2347 *      encoding the parameter key/values. Second, when building the disabled
2348 *      action String, the params needed to go outside of the extension. To
2349 *      facilitate this I created a LightweightURL class.
2350 *   </p>
2351 * </li>
2352 * <li>
2353 *   <p><strong>csc_100301.1</strong> - Backed out yesterday's changes
2354 *      for disabling a select element when rendering in HTMLActionRenderer.
2355 *      We can't do this for selects, since it causes the value not to be
2356 *      submitted along with the form if it is disabled. Input and Button
2357 *      elements are still disabled.
2358 *   </p>
2359 * </li>
2360 * <li>
2361 *   <p><strong>csc_100201.2</strong> - Created a NamingHelper class that
2362 *      can be used to retrieve teh name of an HTMLElement. If the element
2363 *      supports the name attribute but the value is not set, a unique
2364 *      name will be automatically created.
2365 *   </p>
2366 * </li>
2367 * <li>
2368 *   <p><strong>merg_100201.1</strong> - Added a close() statement after
2369 *      reading the resource from the inputstream. I noticed that I
2370 *      couldn't redeploy the app when it used the ResourceGateway. This
2371 *      simple .close() fixes it.
2372 *   </p>
2373 * </li>
2374 * <li>
2375 *   <p><strong>csc_100201.1</strong> - When rendering BAction componnents,
2376 *      make sure we disable the element to which they are bound (for input,
2377 *      button, and select elements), thus preventing duplicate submits by
2378 *      double clicking (note that this won't work in NN4)
2379 *   </p>
2380 * </li>
2381 * <li>
2382 *   <p><strong>csc_100101.1</strong> - Modified the
2383 *      DefaultApplicationAssembler so that it can read assembler files
2384 *      from either the /WEB-INF directory OR the /WEB-INF/classes dir;
2385 *      previously, files had to be in /WEB-INF/classes.
2386 *   </p>
2387 * </li>
2388 * <li>
2389 *   <p><strong>merg_092901.1</strong> - HttpServletRequestWrapper:
2390 *      Some servlet containers do not accurately report all parameters
2391 *      submitted with the request. If the request is a post, and there
2392 *      were additional parameters submitted in the url, the additional
2393 *      params are sometimes not returned (ie. on ATG Dynamo). SO...if
2394 *      the value comes back null, then actually check the query string
2395 *      for them.
2396 *   </p>
2397 * </li>
2398 * <li>
2399 *   <p><strong>jk_092801.1</strong> -
2400 *      Supplied a patch for DigitValidator that fixed a logic bug and did
2401 *      general cleanup on the code.
2402 *   </p>
2403 * </li>
2404 * <li>
2405 *   <p><strong>csc_092801.1</strong> -
2406 *      Moved FormGateway from comp.event to comp.helper
2407 *   </p>
2408 * </li>
2409 * <li>
2410 *   <p><strong>csc_092701.1</strong> -
2411 *      We had a problem in BText and BLink, in that the text was always
2412 *      getting placed into the DOM using a CDATASection. This meant that
2413 *      the text was not encoded, so if you returned a String with a markup
2414 *      symbol in it, like '<', it would hose the validity of your DOM.
2415 *   </p><p>
2416 *      Basically, the text component should generally encode text before
2417 *      rendering. There are, however, exceptions to this rule, like when you
2418 *      actually want to embed markup in some text.
2419 *   </p><p>
2420 *      The solution to this was to modify the DOMUtil.setTextInNode() method
2421 *      to take an extra parameter that indicates whether or not to encode.
2422 *      Then, we modified BText and BLink to each have a setAllowMarkupInText()
2423 *      method...if set, then the text will not be encoded. The default,
2424 *      however, is to always encode.
2425 *   </p><p>
2426 *      Finally, built a sample (CompEx7) to test it out, and a test case
2427 *      (TestBTextRender) to validate it.
2428 *   </p>
2429 * </li>
2430 * <li>
2431 *   <p><strong>csc_092501.1</strong> -
2432 *      Minor code cleanup--formatting changes, adding EPL headers, etc.
2433 *   </p>
2434 * </li>
2435 * <li>
2436 *   <p><strong>csc_092101.1</strong> -
2437 *      fixed a problem in TemplateHelper where the BTemplate delegates that get created
2438 *      not only need to inherit the model information from their parent, but also the
2439 *      view settings as well (ie. if the directives are coming from a properties file).
2440 *      The proper way to do this is to make views cloneable (thereby inheriting all their
2441 *      settings)
2442 *   </p>
2443 * </li>
2444 * <li>
2445 *   <p><strong>csc_091801</strong> -
2446 *      fixed EventBuilder so that it would compile under JDK 1.2.2; evidently there
2447 *      is a bug in this version of the JDK which prevents inner classes from accessing
2448 *      protected values in their parent class. Compiled fine in JDK 1.3.
2449 *   </p>
2450 * </li>
2451 * <li>
2452 *   <p><strong>csc_091701</strong> -
2453 *      Created a new BTemplateGateway and BTemplateViewHandler to make it easier to
2454 *      work with template views. BTemplateViewHandler extends DefaultViewHandler,
2455 *      which in turn provides basic component lifecycle functionality (similar to that
2456 *      of ComponentGateway) but for event driven processing. Basically, the idea is
2457 *      that when you need to handle view events (and thus generate a view) this
2458 *      helper class should handle 90% of the use cases. Thanks to
2459 *      Timo Sillanp�� [Timo.Sillanpaa@reach-u.com] for suggesting this idea.
2460 *   </p><p>
2461 *      Reworked the SimpleLogin (examples/ex1) to use this approach (eliminated a
2462 *      ton of code by doing so). Look here for examples.
2463 *   </p><p>
2464 *      Fixed a nasty Javascript bug in HTMLActionRenderer that was causing forms
2465 *      to be submitted twice. Add convenience methods to SessionServices to make
2466 *      it easy to get session info from a ViewContext reference.
2467 *   </p>
2468 * </li>
2469 * <li>
2470 *   <p><strong>csc_091401.1</strong> -
2471 *      the purpose of this mod is to make it possible to process directives in
2472 *      the root node of the template view. We can only do this for BTemplates
2473 *      that are step children because in this case they will only be rendered
2474 *      once and thus its not a big deal to go replacing the root node
2475 *   </p>
2476 * </li>
2477 * <li>
2478 *   <p><strong>csc_091301.2</strong> -
2479 *      Updated TemplateHelper.java to support the notion of recursive template
2480 *      parsing. Basically, there are two known use cases where data coming back
2481 *      from a template model might actually contain additional directives which
2482 *      need to be parsed. In the first case, an anchor element might have a nested
2483 *      image; in the second case, a template model might return a chunk of markup
2484 *      (ie. to insert a header, footer, etc) which in turn might contain directives
2485 *      that need to be parsed.
2486 *   </p><p>
2487 *      In both of these cases now, child BTemplateComponents are created and
2488 *      added to the parent component to ensure that the sub-nodes get processed as
2489 *      well. The second part of /Barracuda/CompTest6 verifies this. Also created
2490 *      a test case (TestBTemplateRender) to validate this.
2491 *   </p>
2492 * </li>
2493 * <li>
2494 *   <p><strong>csc_091301.1</strong> -
2495 *      Updated TemplateHelper.java so that when a TemplateModel's getItem()
2496 *      method returns null it will skip that node entirely. Previously, a
2497 *      default "key not found" type message would be displayed, which is really
2498 *      actually redundant with the default implementation of the
2499 *      AbstractTemplateModel. Created CompEx6.java to visually verify this.
2500 *   </p>
2501 * </li>
2502 * <li>
2503 *   <p><strong>csc_091301.0</strong> -
2504 *      Created this document.
2505 *   </p>
2506 * </li>
2507 * </ul>
2508 */
2509public class A_Changes_History {
2510
2511    private A_Changes_History() {
2512        super();
2513    }
2514
2515    public static void main(String   args[]) {
2516        System.out.println ("This class records the changes history to the Barracuda framework");
2517        System.out.println ("obj 1:"+new Object  ());
2518        System.out.println ("obj 2:"+new Object  ());
2519    }
2520}
2521
A to Z: JavaDoc & Examples Daily Java News & Articles Open Source Projects Open Source Codes Free Computer Books Remove Frame
Popular Tags