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 "valid" 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 "project" 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 <dom-loader> and <dom-loader-register> 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 <javac> 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 <javac> 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 "id" 279 * and "aaa_id".</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 "file:/" 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 "xlib/dtds" 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 "-dom xerces" 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 * "-dom lazydom" 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 &action& 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 "button" 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 "type" attribute to "submit". However, if the pre-existing type 433 * is something other than "submit" or "button", 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 <set-property> and <constant> in 557 * DefaultApplicationAssembler to recognize the concept of a "delegate runtime value". 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 * <set-property name="servletContext" delegateRuntimeValue="true"/> 564 * </pre></p> 565 * <p>Obviously this assumes that the class this property is to act upon have either a public 566 * "setServletContext()" method or a public "servletContext" 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 * <dom-loader factory="..."/> 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 * <init-param> 682 * <param-name>LogHeartbeat</param-name> 683 * <param-value>true</param-value> 684 * </init-param> 685 * <pre> 686 * or, you can specify it within the object-repository.xml file itself, like this: 687 * <pre> 688 * <object class="org.enhydra.barracuda.plankton.data.ObjectRepositoryAssembler"> 689 * <prop name="globalContinueOnErr">true</prop> 690 * </object> 691 * </pre> 692 * or, you can specify it on a per-line item in object-repository.xml, like this: 693 * <pre> 694 * <object name="$cts" class="com.atmr.kilimanjaro.CodeTables" continue_on_err="true" /> 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 <pre> 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'
Java API By Example, From Geeks To Geeks.