|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Objectorg.enhydra.barracuda.A_Changes_History
The purpose of this class is to track all major changes made to the Barracuda framework. If you check changes into cvs, you must document those changes here. The list should be sorted in reverse chronological order (newer at the top).
--------------- RELEASED 1.2.6 ---------------------
saw_020204_1 - Updated BlockIterateHandler and DefaultDOMWriter to fix a problem where the DOCTYPE would not get rendered to the final HTML document.
csc_013104_2 - Changed all the license verbiage to LGPL. Rebuilt all the jars. Got BarracudaDiscRack upgraded to the latest version. Started working on updating all the docs for the new 1.2.6 release. At this point, we are very close to being ready to roll a build (still waiting for a new Jivan binary licensed under LGPL).
csc_013104_1 - Minor mod to HttpConverter to ensure that if you pass in a map to convert it to a URL string it will automatically create that string in sorted order
csc_013004_1 - Added a very important (but hacky) patch to the BlockIterateHandler to work correctly with the CommaSeparatedDOMWriter. This needs to make it into the 1.2.6 build (I will retag as soon as Jivan is ready)
csc_012904_1 - Added the CommaSeparatedDOMWriter (courtesy Shawn Wilson [shawnw@atmreports.com]). This class makes it very easy to render your DOMs to a comma separated format (ie. download in browser, or to excel). Also upgraded to XMLC 2.2.4 and verified that it seems to work fine.
csc_012804_1a - Additional work to the DOMWriter interface to add the following methods: void prepareResponse(HttpServletResponse resp) void setLeaveWriterOpen(boolean val) boolean getLeaveWriterOpen() This was necessary so that BlockIterateHandler could use whatever DOMWriter you provide (ie. if you want to plug in a custom DOMWriter with BlockIterator, now you can.
csc_012804_1 - Minor tweak to GenerateSSIs taskdef, so that it doesn't include the ssi comment tags in the generated file. In other words, this taskdef creates ssis by looking for comment tags of the format: What was happening was these tags themselves were being included in the generated ssi, and this caused problems in the case of custom renderers where the destination file formats doesn't allow for comments
csc_012704_1 - Minor tweak to BlockIterateHandler to correctly write out the document type if encountered
csc_011904_2 - Minor change to HttpSessionStateMap - when removing an attribute from the session, occasionally getting a Null Pointer Exception when you try to remove an attribute from the session but its expired already. Just consume the error and return null.
csc_011904_1 - Minor change - when invalidating state and removing the session repository, clear out the map/registered values in that SessionRepository before actually removing it from the session
csc_011704_2 - Minor change - previously we were storing a reference to the session in the Session OR, which really wasn't a very good idea because it was a circular reference. Now there is a static getRawSession() method that returns the underlying session object (and creates it if it doesn't already exist). You should only use this if you need to work with the session in some way other than simply to put data in and get it back out.
csc_011704_1 - More work on ObjectRepository, to make it work better at cleaning up sessions stuff. there is now a convenience class called SessionManager to make it easier to work with the session (and invalidate it). As of this change, invalidating a session should cause the OR to be properly cleaned up (previously this was something of a problem).
csc_011604_1 - Minor change to ObjectRepository making it possible now to get all of the underlying servlet sessions. This is primarily intended for debugging purposes.
csc_011504_1 - Very minor tweak to the DispatchQueue interface, adding setRequiresResponse() and setResponseHandled() to the interface so that we can programatically manipulate this. Shouldn't break any existing code unless someone has their own implementation of DispatchQueue. Also remove a couple of System.printlns that should have been removed previously
csc_010504_3 - Minor fix to ApplicationGateway to make it correctly catch any exceptions or errors thrown during long running process and cache them in session so the redirect can display them
csc_010504_2 - Minor patch to CollectionsUtil to handle a null pinter exception when printing stack trace info on a state map
csc_010504_1 - Very minor change to ApplicationGateway to make it easier to debug the LongRunning stuff
csc_010404_1 - Lots of changes...
Added support for LongRunning events (described in /Barracuda/docs/events/long_running.html)
Added support for setting Class objects in ObjectRepositoryAssembler
Changed the BaseEvent interface - added new method getEventURL() and deprecated getEventIDWithExtension(). getEventURL() will return any params associated with the event as part of the url string
other misc changes
csc_112203_1 - Missed a spot in ListValidator. Thanks for catching this, Thorsten.
jrk_20031202.1 - Applied fix for HTMLComponentRenderer, courtesy of David R Robison [drrobison@openroadsconsulting.com]. Empty Text nodes were being seen as invalid children for certain tags, so HTMLComponentRenderer was adding new "valid" children, which were actually invalid since they already existed.
Added JivanDOMWriter suppplied by Arno Schatz [gare@gmx.net] to allow for serialization by Jivan where we only had XMLC serialization available before. This matches up nicely with the JivanDOMFactory.
Updated Ant tasks to not reference the protected "project" attribute of the org.apache.tools.ant.ProjectComponent class since this usage is now deprecated in Ant-1.6. Using getProject() and setProject(Project) instead.
csc_112103_1 - Minor (but important) fix to TemplateHelper to make it possible for multiple Set_Attr directives to be embedded in a single node without stomping on one another. Also applied a couple of small patches to DefaultEventPool (giving the cleanup thread a name) and to ListValidator (making it work on List, not just ArrayList). Thanks to Thorsten Möller [ThorstenMoeller@web.de] for providing the patches...
csc_111703_1 - Add a method getSession() to SessionObjectRepository. There are 2 ways to access the session information now from the OR. 1) HttpSession session = ((ObjectRepository.SessionRepository) ObjectRepository.getSessionRepository()).getSession(); 2) HttpSession session = (HttpSession) ObjectRepository.getSessionRepository().getState(ObjectRepostiory.HTTP_SESSION);
csc_111203_1 - Fixed a bug in ObjectRepositoryAssembler, where if you had a
csc_111103_1 - Added the ability to easily configure doc type settings in DefaultDOMWriter for all the OutputOptions created by getDefaultOutputOptions()...all you have to do is set DefaultDOMWriter.DEFAULT_OO_PUBLIC_ID and DefaultDOMWriter.DEFAULT_OO_SYSTEM_ID via obj repository assembler.
csc_111003_1 - Added pre/post iterate methods to the BlockIterator interface
csc_101803_2 - Fixed 3 additional problems. First, I noticed that sometimes when trying to compile or build jars I was getting a null pointer exception in Localize - it was returning a null ResourceBundle. I have no idea why this is, so I just added a check for that case. When was doing a clean/compile it was working (so it was only on subsequent builds). Go figure. Localization still seems to be working just fine apart from that.
Second, added the ability to remove keys by wildcard to DefaultStateMap. Previously, this was implemented only in HttpSessionStateMap.
Finally, note that I modified the SoftHashMap implementation so that it will return an entry set, making it possible to iterate through the keys (meaning you can get a list of keys in the object repository even when its backed by SoftHashMap).
csc_101303_1 - Minor tweak to previous change on csc_100603_1...changed the logging level to warn, rather than error
jrk_20031010.1 - Cleaned up DOMFactory and DOMLoader interfaces to make them more flexible and easier to implement. Got rid of all non-getDOM() methods from DOMLoader, since they seemed to be more implementation specific, and removed all cases of ViewCapabilities from the interface. The latter change required changes to a good number of files in the Barracuda source including examples and such, but all it was being used for is extracting the locale, so this change shouldn't be a big deal for users. Modified javadoc for both DOLoader and DOMFactory to be more clear. Updated DefaultDOMLoader register/deregisterDOMFactory() to take a String argument instead of a class. This makes it more flexible in dealing with non object-wrapped dom loaders such as Jivan.
Speaking of Jivan, I implemented a new JivanDOMFactory. This also required adding the Jivan jar to WEB-INF/jars in order to build.
Note that as a result of the interface changes to DOMLoader, the DefaultApplicationAssembler no longer supports the <dom-loader> and <dom-loader-register> elements. However, this functionality was considered deprecated anyway since the ObjectRepositoryAssembler is able to script this in a much cleaner way.
csc_100603_1 - Modified ApplicationGateway so that there is a new RESPOND_WITH_404 constant which defaults to false but can be overriden to true. If true, rather than create a generic HttpRequestEvent when a bad event is specified, simply return a 404 error. Thanks to Thorsten Möller [ThorstenMoeller@web.de] for making this suggestion.
jrk_20031002.1 - Cleaned up mainly ResourceGateway. Calling resp.flushBuffer() instead of out.flush(), got rid of outdated comments and commented code, only override doGet() and doPost() rather than all the do*() methods because the others don't apply to the ResourceGateway functionality, removed unnecessary imports, change public static vars to be non-final as they should have been left, and tightened some code up.
Also modified ParamGateway and ScriptDetector to remove the out.close() calls. resp.flushBuffer() commits the response and that is all that is needed. Also added init() method to ParamGateway and got rid of spurious do*() methods just like in ResourceGateway.
saw_092603_1 - Recoded most of the classes within ObjectRepository to fix a current bug but more importantly to prevent the same type of bug in the future. Specifically the clearState() method was not being overridden. The way the classes were coded, they extended from ObjectRepository (and therefore DefaultStateMap) but in fact was not utilizing anything provided from those classes.
jrk_20030916.1 - Applied patch to the the EventBuilder taskdef provided by Thorsten Möller [ThorstenMoeller@web.de]. It adds (optionally) the ability to specify one's own template file for templating generated event classes. This was done by adding an optional attribute to the taskdef called "template" where one can provide a fully qualified file path to the template file.
The algorithm to choose the template is as follows:
jrk_20030909.1 - updated the EventBuilder taskdef in the same way that Shawn updated the Localize taskdef. That is, so that it no longer compiles the resulting .java files into .class files. This step is now left for the developer to add to their build.xml using the standard <javac> taskdef which provides more options.
Note that event task syntax changed a bit. There are now no 'srcdir' or 'destdir' attributes, there is a new 'sourceout' attribute (which replaces whatever you had in 'srcdir'), and there is no nested classpath element support (nor is it necessary any longer). Updated the main build.xml file and those of the contrib projects to support the modified functionality
saw_090803_1 - updated the Localize taskdef so that it no longer compiles the resulting .java files into .class files. This step is now left for the developer to add to their build.xml using the standard <javac> taskdef which provides more options.
csc_090303_1 - modify the BScript renderer so that it can create a default node (allowing us to easily pass a BScript component back from the model)
csc_090103_1 - added support for
jrk_20030828.2 - update log4j-sandbox library. Now only one jar is required and no more worrying about where to put the selectors -vs- servlets when using log4j.jar in a parent class loader (and not WEB-INF/lib). All that needs to be remembered now is to keep the single sandbox jar together with log4j.jar. If you remove one from WEB-INF/lib, remove the other as well (and make sure to have them together in a parent classloader).
Also added new appender which allows for logging to the servlet context log provided by the server. This was just added to the log4j-sandbox for version 0.2alpha. Made it the root appender. For now, we will not log to main.log by default.
jrk_20030828.1 - Applied patch from Jancsi A. Farkas [csaken@fx.ro] to fix an issue in
the HttpServletRequestWrapper
where getParameter(String)
was not making a distinction between parameter "id"
and "aaa_id".
csc_082603_4 - Another patch, this time to BAction, adding a new setDisableFormLocking(), which makes it possible to keep the component from using the doSubmitAndLock() call (it will use the doSubmitAndNoLock() call instead). This is needed when the target action for the form is showing up in another window and not writing over existing window's contents. Previously, this scenario was leaving the submit button locked. THanks to Shawn Wilson [shawn@lannocc.com] for this patch.
csc_082603_3 - I also made a very minor update to the /WEB-INF/bin/*.bat files so that when running them, Ant will do logging via Log4J. Involved adding a log4j.xml file to the src directory that redirects output both to console and to ../WEB-INF/bin/ant.log.
csc_082603_2 - I realized that I had never applied Shawn's patch from June 13, regarding enhancements to the Form mapping stuff. That is applied here as well. Details follow:
Christian and I have been talking about the addition of a new FormType for TIME and also some modifications to the existing DATE and TIMESTAMP type. I have attached to this email a patch that includes everything we have discussed if anyone else would like to provide some input. You can search for saw_061203_2 to see everything that has changed.
New FormType: TIME - This is a new type that allows parsing of time values without any date component. This will return a java.sql.Time object since that is the only representation in the core Java packages for a type that is strictly time.
The parsing process will first try to parse as a long value (representing the time in milliseconds)... this makes it convenient to embed the time in a URL, for example. It will then try each of the 4 time formats (SHORT, MEDIUM, LONG, FULL) and finally will try to parse from the SQL time format.
Changes to TIMESTAMP - Timestamp has been modified to do exactly the same parsing steps as TIME except it will obviously be using the datetime parser (DateFormat.getDateTimeInstance) instead of the time parser. It will return an instance of java.sql.Timestamp (as it did before).
Changes to DATE - I modified date so that it will also try the two new parsing steps referenced above (first try to parse a long; lastly try to parse from SQL date format). In any case it will still always return strictly a java.util.Date object.
Note that I also fixed the nagging test case problem we've been having with data validation in the THAI locale. Basically, I just modified the test case to skip the thai locale until we have someone who knows enough about it to be able to say what are valid dates and what aren't. Thai uses a solar calendar, which means what we consider to be leap years aren't. This was causing test cases to fail, and since I don't know enough about thai to know what's actually correct, for now I am just removing this from the test case. The upshot of all this is that unit tests are now 100% clean (for the first time in a long time)
csc_082603_1 - Apply a new patch submitted by Shawn Wilson that fixes a bug in Classes.getAllInterfaces() that was causing problems with loading an XML DOM. Basically, when getting a list of interfaces, we need to explicitly check the parent objects for interfaces as well (they don't automatically get returned in the list, as originally supposed). This was causing serious problems in that BTemplate was not able to find the proper XML renderer because the DOM implementation did not _directly_ implement Node (its parent class did). Search for saw_082603_1 for details.
csc_082103_1 - Expanded the functionality of HttpSessionStateMap's removeState() method to support the notion of wildcarding, allowing you to remove multiple keys in one fell swoop. Basically, if the key is a String, which ends with an '*', then any keys that start with that string will be removed (and in this case, the method returns a Map of key/val pairs that got removed, rather than a single object that got removed). This approach is not quite as flexible as using regular expressions, but that would make us dependent on jdk1.4 (so we won't go there for now). Note that this class backs the ObjectRepository data structures, so this functionality applies there as well.
--------------- RELEASED 1.2.5 ---------------------
jrk_20030815.2 - Updated .xmlc files for corresponding XML templates in the tutorials to use an absolute "file:/" path to the tutorials.xcat file. Also updated the path to the dtd within the .xcat file to use an absolute path to the dtds existing in the "xlib/dtds" directory. Updated the build.xml file to copy dtds from Barracuda/dtds to src/xlib/dtds. These are, later, copied to WEB-INF/classes/xlib/dtds in the compile.post.process target. This allows for relolving the dtd not only at compile time, but also at runtime by deferred parsing. Updated the tutorials options.xmlc to use the -for-deferred-parsing option. With this change, every example and tutorial in Barraucda is now compiled for deferred parsing!
jrk_20030815.1 - updates for deferred parsing. updated options.xmlc files to use -for-deferred-parsing, updated the build.xml to copy generated .xmlc files and *.*ml files to the classes dir so they are available for deferred parsing to load at runtime. Also updated everything to use the DefaultDOMLoader rather than the XMLCStdFactory to load XMLC classes.
Note that this provides a huge reduction in jar size for the BConfig app. In fact, barracuda-config.jar went from 960k to 289k. That's a reduction of 671k, or 70%, in jar file size!!! The other jars show reduction in file size as well, but the BConfig app with its many large templates really shows off what deferred parsing can do.
Note that the Deferred parsing dom factory (which DefaultDOMLoader uses by default) is backward compatible with classes not compiled for deferred parsing. The converse is not true, though, so it is wise to use the DefaultDOMLoader and never ever use the XMLCStdFactory to load classes.
One caveat I found with deferred parsing is that if one uses the "-dom xerces" option when compiling XML files, the templates are rendered unmodified. BTemplate directives are left in rather than being replaced by data from the model. Everything works fine when using "-dom lazydom" or not specifying the -dom option at all. Not clear on why this is, but since the simple workaround is to not use the xerces dom, this won't hold up the XMLC or Barracuda releases. Hopefully the problem will be found and fixed post XMLC-2.2.
jrk_20030814.1 - Update ScriptDetector in the same way I updated ParamGateway to make things more efficient. Also updated sample.event-gateway.xml with a commented out way to turn script detection on.
jrk_20030814.1 - Applied patch from Stefan Armbruster to make the CopyAndReplace task compatible with both Ant-1.5.x and Ant-1.6.x. A change to the Copy task interface, which CopyAndReplace extends, caused errors in both building and running the task under Ant-1.6.x.
jrk_20030812.1 - Fixed BAction#hasAction() to take into account not only actions specifically set via BAction#setAction(), but also those set via BAction#addEventListener(). Without this, the HTMLActionRenderer won't render BAction or BLink components bound to HTMLActionElement's with actions set by adding an event listener because it checks if the component has an action before attempting to manipulate the element. If an &action& is not defined to include event listeners, then hasAction() returns false and no manipulation is performed
Also updated the CompEx4 .java and .html example files to clean them up and make them more clear about what the purpose(s) of their examples are. Note that this was where I discovered the bug in BAction#hasAction().
jrk_20030808.1 - Added write(Node, OutputStream) to the DOMWriter interface.
jrk_20030731.1 - Lots of scripting updates and a couple other things. Updated ParamGateway.java and ClientServerHTTPLib.js to be more efficient. Also modified the .js library to match up as closely as possible with the original jsrsClient.js file to make it easier to see how the two files differ.
Also updated RenderStrategy and HTMLActionRenderer to allow for a CUSTOM_SCRIPT render strategy. CUSTOM_SCRIPT is exactly like NEVER_SCRIPT, except that it alerts the Barracuda renderers not to throw exceptions in cases where actions being rendered wouldn't work properly without Javascript. Essentially, it says "don't script for me because I want to do my own client-side scripting and I don't want Barracuda interfering with that".
And finally, updated HttpServletRequestWrapper.java to catch exceptions when attempting to decode a query string. It seems that runtime exceptions are being thrown. Kirk Daries says that catching the exception and ignoring it makes things work fine, so that is what has now been done.
jrk_20030624.1 - Update HTMLActionRenderer to behave better with input elements or button elements of type "button" when javascript isn't allowed (eg... the client is not registered with Barracuda as supporting javascript, javascript is disabled on a client that normally supports javascript, or the render strategy has been intentionally set to not allow scripting). Instead of throwing an exception, modify these elements by setting their "type" attribute to "submit". However, if the pre-existing type is something other than "submit" or "button", then throw the exception, otherwise we'd be overstepping our bounds.
Also updated BScriptResource to contain static constants for references to existing Barracuda scripts so we don't have to write the full path to those scripts all the time. Besides being cleaner, this is less error prone. Modified HTMLActionRenderer to use these constants.
Also cleaned up HTMLActionRenderer and consolidated some common code. Added new private static utility method clientScriptingAllowed() to encapsulate logic for determining if scripting is enabled/allowed. Updated some of the Javadoc comments as well. Still more to do such as fix it so that if scripting is disabled on the client, we actually see that and modify the render strategy to that of flagging scripting not allowed. Also, may need to figure out how to deal with null form elements.
jrk_20030623.1 - Updating Barracuda to finally get rid of the concept of dom-based caching marker which was part of the components. This is now entirely localized to DefaultDOMWriter so if you need to control caching behavior, return your own customized instance of DefaultDOMWriter after setting the applicable properties to your needs. This change affects AbstractBComponent, BComponent, and DefaultDOMWriter. Also updated Javadoc for DefaultDOMWriter to make its use more understandable.
csc_062003.1 - Pretty significant upgrade of ObjectRepositoryAssembler, per extensive discussion on the email list.
csc_061803.1 - Modified ObjectRepositoryAssembler to support the setting of Shorts, Longs, Doubles and Floats in addition to the String, Boolean, and Integer support that was already there. While I was at it I discovered that the previous implementation only supported the setting of primitives, so I modified things so that you can set both primitives and their first class counterparts.
csc_060903.3 - Preliminary work for Jake's review on a new way to configure pluggable classes. Basically, I modified org.enhydra.barracuda.plankton.Classes to offer a couple of new methods for getting a Class or an instance of a Class (using some simple caching for efficiency sake). Then I created a new org.enhydra.barracuda.core.event.A_Classes. This class defines constants that refer to default class names...they can be overridden via the Object Repository scripting approach. The basic idea here is that when a class needs to instantiate something that implements the interface, it uses Classes.newInstance(String clName), where clName is the value defined in A_Classes. I have currently implemented this in ApplicationGateway, for both DefaultEventGateway and DefaultEventPool. This is to provide an example of the approach I have in mind. Jake and others...your comments and feedback would be appreciated.
csc_060903.2 - Move the instantiation of the EventPool down beneath the application gateway assembly, allowing application gateway to override the EventPool constants if necessary. Note that the reason ApplicationGateway instantiates event pool and event broker here is to ensure that the classes provided can be instantiated - we want to verify this at startup, rather than at actual event dispatch time.
csc_060903.1 - Make the default constructor of DefaultEventPool use static constants that can be overridden from object-repository.xml
jrk_20030602.1 - Added a couple items to the interfaces of DOMLoader and DOMFactory.
1. DOMFactory now has getInstance(String docPath) which is meant to load the dom directly from a file rather than a pre-compiled class. This was done to support XMLC's deferred parsing, but is also generic so any other DOM implementation that supports loading directly from file could be used as well. XMLCDeferredParsingDOMFactory was updated to support this. See the javadoc for details.
2. DOMLoader was modified to support the addition to DOMFactory by adding getDOMFromFile() methods analogous to the existing getDOM() methods. Also added convenience getDOM(className) methods so that you can pass a fully qualified class name rather than having to pass a JVM loaded class. DefaultDOMLoader was updated to support this. See the javadoc for details.
These changes shouldn't adversely effect anyone since it is doubtful that anyone has, so far, created their own DOMFactory or DOMLoader implementation. So, these changes should be transparent for most people and provide cool new functionality!
jrk_20030531.1 - Backed out changes to DefaultDOMLoader where no default was provided for the domFactory so things would blow up as soon as getDOM() was called since, if not set, no dom factory would exist. This had been done to solve a dom-implementation dependency issue with anything that referenced the DefaultDOMLoader; especially the DefaultApplicationAssembler. I have now solved this in an alternative way. The application assembler no longer directly refers to DefaultDOMLoader. It is loaded via runtime reflection. Also, added support for defining a dom loader other than the default DefaultDOMLoader in assembly configuration. See the javadoc for DefaultApplicationAssembler, DefaultDOMLoader, and Barracuda's event-gateway.xml file for more details
jrk_20030530.1 - Renamed DefaultDOMFactory to XMLCStdDOMFactory to make it more clear what DOM implementation it backs. Also updated the EventGateway interface to include more of the methods that the DefaultEventGateway supports so that no implementation-specific check needs to be done in the DefaultApplicationAssembler. This makes the DefaultApplicationAssembler much more generic and able to work with implementations of the EventGateway interface. Had to update ApplicationGateway as well since it implements EventGateway to account for the interface method addtions.
jrk_20030529.2 - Updated component testcases to account for the jrk_20030528.1 change in behavior of the DefaultDOMLoader. Basically, since DefaultDOMLoader no longer uses a default DOMFactory instance, one must be set before using getDOM(). This is taken care of when running via a webapp in the assembly descriptor configuration. However, since the testcases don't run within the context of a webapp, they need to have have the DOMFactory programatically set. So, for each of the component testcases, I added...
protected void setUp() { //Make sure we specifically define a DOMFactory since the DefaultDOMLoader no longer //uses a default to avoid dom implementation-specific compile dependencies. //This is taken care of more simply in the assembly descriptor when running //via a webapp. DefaultDOMLoader.getGlobalInstance().setDefaultDOMFactory(new XMLCDeferredParsingDOMFactory()); }Now all is well!
csc_052903.1 - review DefaultDOMLoader for threadsafety - I didn't see any glaring issues, but Shawn did suggest a couple of improvements that I think were worth making just to be safe (safe, get it? _thread_ safe? Ha ha ha ha ha...ok, so it wasn't that funny) Note that this fix does break some of the test cases, but that is because of a problem in them that results from jrk_20030528.1...Jake will update the test cases tonight or tomorrow.
jrk_20030529.1 - Updated handling of <set-property> and <constant> in DefaultApplicationAssembler to recognize the concept of a "delegate runtime value". What this means is that the value of the parameter to be set is a runtime object rather than something that can be provided as a literal value in the configuration file. Currently, the only supported delegate runtime value is a ServletContext object. The syntax of this new configuration option is...
<set-property name="servletContext" delegateRuntimeValue="true"/>
Obviously this assumes that the class this property is to act upon have either a public "setServletContext()" method or a public "servletContext" field.
Also updated XMLCDeferredParsingDOMFactory to take advantage of this feature, the reason being that it needs to read context init parameters to provide extra optional information to the DeferredParsingFactory which the DeferredParsingDOMFactory backs. Also modified it to create the DeferredParsingFactory once instead of every time DOMFactory#getInstance() is called. This should provide a slight performance improvement.
jrk_20030528.1 - Updated DefaultDOMLoader to not pre-set a default DOMFactory implementation. This should solve the issue reported by James Carnegie where the DefaultApplicationAssembler had a compile dependency upon XMLC simply because it accessed a DOMLoader via DefaultDOMLoader.getGlobalInstance() and the default dom factory that it pre-set used XMLC to load the DOM. Since there is now no default dom factory pre-set, one must set themselves it via the application assembler with <dom-loader factory="..."/> or programatically via DefaultDOMLoader#setDefaultDOMFactory(DOMFactory) before using any of the getDOM() methods. Also updated the javadoc for DefaultDOMLoader to account for this change and for some general cleanup and clarity.
csc_052803.2 - expanded the StateMap interface to support a clearState() method. This was necessary because the current implementation of SoftHashMap does not allow you to get the entrySet for the map (it throws an UnsupportedOperationException), so by adding this method we at least make it possible to clear the cache.
csc_052803.1 - minor mod to ApplicationGateway so that when debugging is turned on it will show the headers as well.
csc_052703.1 - added a new SoftHashMap class to org.enhydra.barracuda.plankton.data and then modified ObjectRepository to provide access to this (both globally, and as based on session). The basic reason behind this is that soft references make better caches than weak references because weak will be reclaimed as soon as possible, whereas soft will be retained as long as possible. This was showing itself in the client side redirects - on a fairly regular basis, gc would run between a redirect, and the information in the weak session repository would get lost. I modified DefaultEventContext to use the new soft session repository, which should allow cached information to survive gcs.
--------------- RELEASED 1.2.0 ---------------------
jrk_20030520.1 - Further updated XMLC to fix a couple bugs. Completely removed endorsed packages (javax.*, org.xml.*, org.w3c.dom.*) from XMLC's xerces package. This makes it so XMLC's xerces can exist in WEB-INF/lib. Simplified XMLC by moving xmlc jars (xmlc, xerces, xhtml, wireless) into on jar called xmlc-all-runtime.jar. There is no more need to copy the xerces jar to and external shared classloader. Note that all XMLC jars including jtidy, gnu-regexp, xmlc-all-runtime, and xmlc-taskdef are based on the XMLC CVS source with the tag XMLC_2_2_POST_BETA_1_BARRACUDA_1_2_0.
jrk_20030520.1 - Updated HTMLSelectRenderer to be in-line with the html dom level1 interfaces which don't include a setSelected(boolean) method in HTMLOptionElement. My comments in that file go into detail about this, so read them if you want more info. No behavioral changes should be seen from this change except that Barracuda will compile in the presence of the official html dom level1 interfaces provided by Xerces2.
csc_051703_1 - Very minor changes to the toString() method in ValidationException to make it show sub-exceptions as well (makes debugging a little easier)
csc_051503_1 - Modified FormType to add a new TIMESTAMP data type (java.sql.Timestamp)
jrk_20030514 - updating to XMLC-2.2beta1 release. The Xmlc taskdef moved from the org.enhydra.barracuda.taskdefs package to org.enhydra.xml.xmlc.taskdef package. Updated the Localize taskdef to account for that. Also had to modify LocalizeXmlcUtilsImpl to make the constructor public. It had been protected to prevent direct instantiation, but since the XmlcUtil class needs to be able to instantiate it and it is in a different package, I had to make the constructor public.
jrk_20030508 - Modified the plankton URLRewriter to not attempt to override normal servlet spec behavior. The only thing that is still there is the ability to turn off url rewriting based on the static REWRITE_URLS variable. This variable has been changed from a default of "false" to a default of "true". This makes the normal servlet spec behavior the default. For buggy servers such as early Tomcat servers or Enhydra-3.xx servers, one may disable URL rewriting by setting REWRITE_URLS to false in the assembly descriptor or programatically at runtime.
jrk_20030416.1 - updated DefaultApplicationAssembler to support the loading of one or more application assembler files without using File IO. This uses a servlet 2.3 specific method, but I use reflection to fall back to only supporting the loading of a single assembler file for servlet 2.2.
Also added the ability to set the default dom factory for the DefaultDOMLoader and/or register specific dom factories with specific dom classes in the assembler file. See sample.event-gateway.xml for more info.
Updated sample.event-gateway.xml for both Barracuda and Diez contrib app to set the xmlc deferred parsing factory as the default factory. Removed code I had added to the DBRApplicationGateway to set the dom factories since this is now done in the assembler file.
Updated xmlc-2.2.jar because Richard Kunze added a fix to make it so the deferred parsing factory would load classes not compiled for deferred parsing. the opposite is not true, which is why we made the deferred parsing factory the default dom factory in the assembly descriptor.
csc_041603.2 - Added logic to ObjectRepositoryAssembler so that you can get it to continue assembling a file even if errors are encountered. This is useful because it allows your assembler file to specify things which may not always be there (depending on your deploy configuration). Of course, if those things aren't there, then subsequent assembly may not work either, so use with caution...
To take advantage of this functionality, you can either specify a startup parameter in the GlobalRepositoryAssembler section of web.xml, like this:
<init-param> <param-name>LogHeartbeat</param-name> <param-value>true</param-value> </init-param>or, you can specify it within the object-repository.xml file itself, like this:<object class="org.enhydra.barracuda.plankton.data.ObjectRepositoryAssembler"> <prop name="globalContinueOnErr">true</prop> </object>or, you can specify it on a per-line item in object-repository.xml, like this:<object name="$cts" class="com.atmr.kilimanjaro.CodeTables" continue_on_err="true" />Note that the default remains false, so this should not affect any existing code at all...you have to explicitly turn this behavior on if you want it.
csc_041603.1 - Minor change to HttpConverter to add a couple of extra convenience methods.
csc_041403.2 - Pretty significant set of changes. Updated BSelect to remove the setDisableBackButton and getDisableBackButton methods (these weren't) used anywhere. Modified BSelect to act like BInput in terms of the addEventListener method (you can now specify a disabled prop there). Added new setAction()/getAction() methods to both of these classes, which effectively mirror the functionality of the addEventListener methods, except you provide the event to be fired, rather than the handler to receive it. In retrospect, I think this is the way we should have done it in the first place, and I'd like to actually remove the addListener functionality from both BSelect and BInput in the fairly near future. I also modified AbstractBComponent so that when you add a stepchild, it will automatically inherit the parents views if it doesn't have any; also modified the add tempView method so that it will add temp views to step children if they exist. This makes it MUCH easier to pass back nested components from a template model (where the view may not yet be assigned) - for instance, you can now actually do something like this:
BSelect bselect = new BSelect(dlm); ... BAction baction = new BAction(new DoSwitchCompany()); bselect.addStepChild(baction); return bselect;and it will actually work - both components will be bound to the same view when it is actually created by TemplateHelper. Very nice...
csc_041403.1 - Fixed a minor annoyance in HTMLActionRenderer - when binding an Action/Link to an anchor element, only set the url href if the component actually has either a url string or an event specified; otherwise, just leave what is in the template. This will fix the issue where if you are using a BAction but only setting visibility (not the URL), it was overriding it with a default ActionEvent.
jrk_20030411.3 - Fixed NullPointerException bug in HTMLListRenderer where the item passed to the list is assumed to be non-null. Put a null check in addItemToList() and added a logging warning. I noticed this when I hit the submit button in Diez' File Upload example without having chosen a file to upload. I got a nifty stack trace! Won't happen any more, though.
jrk_20030411.2 - created new XMLCDeferredParsingDOMFactory.java class for use in enabling XMLC deferred parsing support with Barracuda apps. I also updated Diez' contrib app to register this custom factory to be used with his html classes. That way, DefaultDOMLoader knows to load certain template classes with deferred parsing while using the defaut dom loading factory for the rest of the classes. Note that in order to enable deferred parsing, one must add the XMLC compile flag "-for-deferred-parsing" to the options.xmlc file. Also, one must copy the .xmlc files generated from compilation (not .xmlc files from src_mockup directories) and the .html files to the xmlc class file destination. Diez' build has been updated to do this and has deferred parsing enabled!
jrk_20030411.1 - enhanced HTMLActionRenderer and BAction to enable the concept of custom client-side form validation. Added addScriptFunction(String) and getScriptFunctions() to BAction and modified HTMLActionRenderer to add these function names as a list of arguments for a new javascript function called doSubmitAndLock() which takes a form object as its first argument and then an infinite number of function names as arguments after that. This can be found in a new file called FormControl.js. If provided, each added function will be called in the order added. The only constraints are that they take a form object as an argument (or no arguments) and return a boolean. If any function returns false, the submit will be canceled. Custom functions are added before any Barracuda specific functions such as "cshl_SubmitAndReplace" for disabling the back button. Custom functions may submit the form via a javascript submit, but this is unnecessary as doSubmitAndRelace() will submit the form via a javascript submit if nothing else does and no function returned false. Functions are named without parenthasis such as... addScriptFunction("checkValue")
dbr_20030408.1 - fixed a problem in DefaultFormMap that was detected by Shawn Wilson. It prevents empty strings from beeing parsed. This ensures correct behaviour for the ValidTypeValidator.
jrk_20030407.1 - fixed a problem with the HTMLActionRenderer setting any and all input elements, with an action listener, disabled before submitting form. This caused data-critical input elements such as radio buttons and checkboxes to not send their data to the server. Now only input elements of type "submit", "button", and "image" are set as disabled. At the same time I did this, I did some major cleanup and reorganization of HTMLActionRenderer. Behavior shouldn't really have changed (besides the mentioned bug fix) except that it should be easier to read and more efficient than before.
csc_040203.2 - fix a mapping problem in FormType - wrapped the logic in a block to catch NumberFormatExceptions...not sure why this hadn't been done originally!
csc_040203.1 - fix a bug in HttpSessionStateMap - null pointer exception when trying to remove a key from the session who's value is null. This had already been fixed for the call to getState().
jrk_20030318 - Introduction of XMLC-2.2 along with a number of other changes, such as...
1. Verified that xmlc-2.2 (current cvs) is not only compatible with Barracuda, it solves all the gotchas that we had before. You can now have a stock install of Ant with Xerces2 and xml-apis.jar in ANT_HOME/lib and successfully build Barracuda at the same time. You can have Xerces2 and xmlParserAPIs.jar in CATALNIA_HOME/common/endorsed and xmlc's xerces in CATALNIA_HOME/shared/lib or WEB-INF/lib and xmlc classes based upon xml files will work (remember under xmlc-2.1, these bombed out because there was a clash between xerces1 and xerces2). So, basically, we don't have to expound on any caveats to using xmlc anymore. Things just work with default installs!!!! Note that I still am not copying xerces to WEB-INF/lib because even though xerces is wrapped (org.enhydra.apache.xerces), it still contains org.w3c.dom, javax.xml, and org.xml packages. David Li is working on getting rid of those and once that happens we can put it back in WEB-INF/lib.
1b. Note I have removed the Xmlc taskdef from Barracuda's source now that it exists over at the XMLC project CVS. Also note that it has already been enhanced by David Li to notice not only changes to *ML files but also corresponding *.xmlc files. And I applied a patch from Stefan Armbruster which allows the task to recursively look in parent directories for options.xmlc so that one can have nested subdirectories containing *ML templates all using a single options.xmlc file. The xmlc-taskdef.jar is now incldued in WEB-INF/jars. I also applied another patch from Stefan to fix some logging issues in the Localize task. I also fixed the EventBuilder task to use whatever XMLReader is available rather than failing if it can't find the Xerces parser. This should probably be used elsewhere where SAX2 parsers are utilized.
2. Modified DefaultDOMWriter and in the process, removed printPretty, preventCaching, and maxAge from DefaultViewHandler and ComponentGateway. Dealing with these values is now entirely localized to DefaultDOMWriter. If you want to override defaults, then override getDOMWriter() or just create a DefaultDOMWriter and set the properties. before calling the write() method.
3. Updated Diez' page model to conform to the new stuff and am now successfully overriding getDOMWriter() and being able to set OutputOptions so that the doctype will be written for his example pages. cool!
4. Updated build.xml and version.properties to account for the new xmlc jars.
5. Removed the core.util.dom.io package. All classes (very few) referencing that package now reference org.enhydra.xml.io.*. I believe that all needed custom modifications have already been moved into XMLC's source. They must have because everything seems to work perfectly.
csc_031103.2 - added Cloneable, Serializable support for DefaultListModel (it was already implemented previously for DefaulListSelectionModel)
csc_031103.1 - updated ExceptionUtil so that when printing stacktraces to HTML, it wraps the trace in <pre> tags for better readability
csc_031003.1 - added a convenience method setValue(Object) to BInput.
csc_030703.1 - realized that my changes from yesterday actually broke stuff in the contrib directory, so I fixed it there as well. Thanks to Jake for pointing this out. Verified that everything compiles now, and unit tests run. Rebuilt the jars.
csc_030603.2 - changed the signature of the getItem() method in the TemplateModel interface from: getItem(String key) to: getItem(TemplateDirective td) This gives the model implementation access to the full TemplateDirective, and opens up some interesting pattern opportunities based on the key data portion of directives (rather than on a naming convention applied to key name, which was the only option available before). While changing the signature might seem like it will have a big impact on existing code, I don't think it will do so because AbstractTemplateModel implements this method and simply calls the old getItem(String key) method. So old code should continue to work, but it you want to implement something under the new signature, you certainly can. The only caveat is that if you implement this new method directly, you should make sure you call super.getItem() for TemplateDirectives that go unhandled or are still handled in the old getItem(String key) method.
csc_030603.1 - removed the ViewContext param from DefaultViewHandler's handleViewEvent, preCompRender and postCompRender as everyone pretty much agreed that these methods are not widely used. If you do have code that uses these methods you can now get the context within these methods simply by calling getViewContext() (which was added yesterday).
csc_030503.1 - added a getViewContext() method to DefaultViewHandler so that the getTemplateClass() method has some means to get the ViewContext, so it can work its way back to the EventContext and thus to the source event (to return different template classes for that if necessary). Note that this actually renders the ViewContext parameter in handleViewEvent, preCompRender, and postCompRender obsolete, but for now we'll just leave them in there (so we don't break existing code)
jrk_20030217.1 - Updated build to use log4j-sandbox jars for log4j initialization. These include log4j-sandbox-selector-[version].jar and log4j-sandbox-servlet-[version].jar. These replace barracuda-log4j.jar and barracuda-webapp.jar. Since I am now a committer on the log4j-sandbox project after contributing the custom selector and initialization stuff that had been homed in Barracuda's source, I felt it made sense to remove the duplicates in Barracuda's source. The same concepts hold. The selector jar must exist alongside log4j.jar and the servlet jar must exist in any webapp's WEB-INF/lib which is using the sandbox servlet initialization. In web.xml, you should now use org.apache.log4j.servlet.InitContextListener instead of the old Log4jApplicationWatch
dbr_070203.1 - reworked shawn's patch from 121102 to work with jdk1.3
csc_012003.1 - Improved the parental functionality in the PArrayList and PHashMap plankton code - basically, when setting parent, only do so if isInheritParents() = true AND the parent is not already set to something. Also, when removing items from data sets, only clear the parent if the parent of the object being removed matches the current container from which it is being removed.
csc_121302.1 - Added support for case insensitive event mapping; what this means is that getlogin.event maps to the same class as GetLogin.event. Also added a test case to verify this behavior. This should not have ANY impact on existing applications. Thanks to Jacob Kjome [hoju@visi.com] for suggesting the idea.
csc_121202.1 - Fixed a minor problem in BAction where the sep variable was not getting changed to '&' soon enough while processing an array of items.
saw_121102.2 - Added in Cookie support to the HttpRequester class in Plankton. This effectively lets you connect to a URL that returns a cookie, and then you can reuse the requester for other URLs that are going to require that cookie. Thanks to Shawn Wilson [shawnw@atmreports.com] for implementing this.
saw_121102.1 - Updated BTemplate and TemplateHelper to properly release references between the component and the models. Basically, whenever you use a BTemplate the destroyCycle() method MUST be called when you're done with it, or the template models will retain a reference to the BTemplate, and the objects will never get cleaned up. This was a problem in TemplateHelper where we create temporary BTemplate components and then discard them. We also had to modify BTemplate itself so that a) if you add a model it first tries to deregister the model (ie. in case you are overwriting an existing model, which BlockIterator does) and b) when destroy cycle is called we need to run through and deregister all the models before nulling out the model list. This effectively fixes the only known memory leak in Barracuda, so its a very important patch. Thanks to Shawn Wilson [shawnw@atmreports.com] for contributing
jrk_20021207.1 - Updated ObjectRepositoryAssembler to load assembler files the same way that DefaultApplicationAssembler does. Moved things around a good deal to make it work just like DefaultApplicationAssembler. Modified the inner class to be the same name as in DefaultApplicationAssembler (AssemblerXMLReader).
csc_120602.2 - Bunch of minor formatting changes (ie. remove tabs that crept into the code, etc
csc_120602.1 - Change HttpServletRequestWrapper so that getParameterMap returns map values as String[], like its supposed to according to the spec. Also make it handle multiple values (previously it didn't). Thanks to Udovenko Sergey [Sergey.Udovenko@swx.com] for bringing this to my attention.
csc_120502.1 - Added support to BaseEvent class to support the notion of params. This means adding the following methods: - void setParam(String key, String val) - void setParam(String key, String[] vals) - Map getParams() You can use these events to "add" parameters to a URL request. Basically, if you shove any values in here, then when this event is dispatched (by adding it to the event queue) then the param values will get pulled out and appended into the underlying Http req object. Thus to the code that handles this event, it will look like the parameters where there all along. Pretty slick! Thanks to Jack Hodges [Jack.Hodges@efi.com] for submitting this patch
jrk_120302_1 - Change DefaultApplicationAssembler so that single file reading does not use File IO. I also got rid of unnecessary commented out stuff and rearranged things quite a bit. I plan to add non File IO reading of multiple files as well, but I'd like to get this in quickly because single file configuration is what most people use.
csc_120202_1 - Change all references to 'protected static Logger' to be 'protected static final Logger' per discussion with Jake
jrk_2002-12-02 - I reversed all changes Christian made previously to ResouceGateway. Using the Thread context classloader, we can load resources from the WebappClassloader just fine even if ResourceGateway is in a parent classloader. So, ResourceGateway is now back to core.helper.servlet.ResourceGateway.
jrk_2002-12-01.1 and .2 - removed references to java.sql and javax.sql in src_tests/org/enhydra/barracuda/plankton/TestStringUtil.java since nothing was actually using those packages except possibly some commented out stuff. Franck Routier reported this when running under IBM's jdk1.3.1 which, apparently doesn't include the javax.sql package where Sun's j2sdk1.4.1 does. We'll have to include that jar file in WEB_INF/jars if we want to use javax.sql in the future.
csc_122702.3 - minor fixes to the previous checkin
csc_122702.2 - moved core.helper.servlet.ResourceGateway --> core.webapp.servlet.ResourceGatewaychanged as this file needs to be included in the barracuda-webapp.jar in order to correctly load resources
csc_122202.2 - changed the forms package to use getVal()/getVals() instead of the longer getSingleValue()/getMultipleValue(); added back in the old convenience methods and made them part of the interface; also removed the deprecated classes from org.enhydra.barracuda.core.util, recompiled everything and verified the test cases work properly
csc_122202.1 - Fix a bug in DefaultApplicationAssembler. Patch provided by Srinivas Yermal [syermal@encover.com]. Here is his description: In the startElement method, listenerFactories dont get added to the objStack (object stack) when the factory attribute is a field. But the endElement seems to be popping them out at all times. And I get a EmptyStackException. So I suggested that we add the listenerFactory to the object stack at all times. The fix therefore is to move the "objStack.push(lf);" statement out of the if block it is currently under.
csc_112102.1 - finish fixing the nested directives problem that I rolled back out in csc_111902.1. Basically, the csc_100802.1 change was very close to being correct, BUT, it was skipping directives in nodes immediately below the node with a directive (and then correctly processing everything further down the DOM). The solution then, is that when we get a component or a node back from the model, we need to find the chunk of DOM to which it is bound, to run through all the child elements, and if any of them actually implement Element, then create one BTemplate and bind it to newNode. Test cases work correctly now.
Note that during the process of rebuilding jars, I discovered that changes to build.xml to restructure the location of the Barracuda jars from lib-ext to lib require you to delete the existing build.properties and version.properties in the src directory. Subsequent compiles will copy the new files into place and all will be well. Just thought I'd mention that.
csc_111902.1 - roll back changes in TemplateHelper that got added in csc_100802.1 - these changes where not processing nested directives correctly (the test case was failing too...not sure how I missed that originally). What this means is that nested directives in an iterative loop may not got processed correctly again (that was what 100802.1 was orginally supposed to fix); I'm working on a solution for that.
csc_111302.1 - Minor enhancements to CollectionsUtil (add support for Object arrays)
csc_110402.1 - Revert back changes to URLEncoder and URLDecoder calls; the deprecated methods which I replaced used calls that are only available in JDK 1.4 causing problems for folks using JDK 1.3 still)
csc_110102.1 - Major refactoring changes on the plankton stuff. Moved everything out of core.util.* into barracuda.plankton, barracuda.webapp, and barracuda.log4j. Note that at this point there are a couple of classes that will need to stay under core.util. Specifically, these include core.util.dom, core.util.http.ContextServices and SessionServices, core.util.l10n.Locales, and core.util.srv.SimpleServiceFinder. Now, these simple classes have been modified to extend from their counterparts in the new plankton packages, so in general you should switch everything in your code from core.util to plankton, unless it still needs one of the methods in the classes that remain under core.util. For now, everything else in core.util has been deprecated, so what you can do is recompile your app with the deprecation option turned on, and you will see everyplace that needs to be changed. Once I am sure everything is working, I will actually remove the deprecated classes just so everything is clearer (even though it will require more work on the part of the developer). Jake tagged the tree prior to this commit with BARRACUDA_PRE_REFACTORING, so if you want to see what was there before hand you can easily do so.
jrk_102602.1 - Added
org.enhydra.barracuda.core.util.logging.Log4jCRS
which is a
LoggerRepositorySelector
. Log4j uses a default one, but we
can make it use our own and then have more control over the
LoggerRepository (Hierarchy) being used. This allows us to put Log4j in
a parent classloader and allow all applications to use that instance of
Log4j without stomping on each others logger configuration. For those who
still want to use Log4j from within each webapp, that is still completely
supported. There isn't anything different that a user will have to do in
configuring Log4j or using Loggers. Everything will work as it always has
transparently. The one thing that needs to be remembered, however, is that
log4j needs to live wherever you move the logger repository selector or,
in our case, wherever you put plankton.jar. So, if plankton.jar gets moved
to a parent classloader such as Tomcat's shared/lib, you need to make double
sure that you remove the log4j jar file from your webapp's WEB-INF/lib folder.
Otherwise, you will get mysterious
java.lang.IncompatibleClassChangeError
messages at application
startup and your logging won't work; neither will your application.
So, you are *always* safe if you put keep plankton in WEB-INF/lib, but if you
move plankton to a parent classloader, Log4j must move to that parent classloader
as well and be removed from WEB-INF/lib.
Log4jInit
and Log4jApplicationWatch
have been modified
to make use of Log4jCRS
. Other than that, no changes were
necessary to enable this functionality. See the javadoc of Log4jCRS
for more information on what it is and does
ndc_101202.1 - Applied patch from Denny Chambers [dchambers@snapserver.com] to add caption support to BTable
csc_100802.1 - Applied patch from Rajesh Poddar [Rajesh.Poddar@efi.com] to TemplateHelper, which causes BTemplate delegate components to be rendered immediately, rather than waiting for the iteration to finish. This effectively fixes the nested directives bug that so many people have run into - you can now use nested directives inside of an iterative model, and all the nested directives will get processed before the next iteration occurs. Cool.
jrk_092102.1 - Added org.enhydra.barracuda.core.util.logging.Log4jApplicationWatch which is a ServletContextListener. Application servers supporting Servlet 2.3 will use run this class just before application shutdown. We use this to call LogManager.shutdown(). This releases handles to log files, thereby unlocking them. This has been a problem up until now. Unfortunately, it doesn't seem to unlock the Log4j jar itself. Still searching for answers to that.
In order to use this functionality, a $lt;listener$gt; must be set up in the web.xml. For those using servlet 2.2, this can be safely commented out, but the log files will be locked until full server shutdown.
dbr_083102.1 - Added the getSingleValue/getMultipleValues methods to FormElement, DefaultFormElement, FormMap and DefaultFormMap. The old getVal method now is deprecated.
A new Validator, CardinalityValidator has been created. It purpose is to control the number of elements returned from a FormElement.
csc_082802.1 - CopyAndReplace - moved the ssi processing code up in front of the mapping code. This was done in response to a patch submitted by Stefan Armbruster [sarmbruster@web.de] which allows CopyAndReplace to work if you only want to do SSI processing, and don't need to do any mapping. This change means that you no longer have to supply an empty mappings file.
csc_082602.1 - Added a minor modification to the ObjectRepositoryAssembler which makes it possible to see what file the assembler is configuring from without actually having to turn on logging. This makes it very easy to see what apps a particular instance of Tomcat is running when it fires up, as well as making it possible to see when an individual app was successfully reloaded. To turn on the logging, search the Barracuda web.xml for 'LogHeartbeat'
csc_082302.2 - Modify the ClientSideRedirect logic so that when it persists state across multiple requests, it does so without placing information in the session. Previously, the event dispatcher was the code invoking the call to persist the context; now it happens in ApplicationGateway, allowing us to remove the persistContext() funtion from the EventContext interface (developers shouldn't be calling this method anyway). Now, when it comes time to persist, we store the event context statemap and local object repository info in a newly created WeakGlobalRepository. We use a weak structure to ensure that we don't get stale objects accumulating in memory (previously, by storing in the session this was taken care of for us). In order to store the info in this weak global repository, we need a key unique to the jvm, and we have to append this onto the outging url (ie. that the client side redirect is pointing to). This has the side effect of changing the url in the browser to include something like this onto the end of it: $ctxid=_1030135624563. I also modified the Simple Login app to test this code change out (we now store the login flag in the local repository, instead of the session, so the client side redirect that happens when you're already logged in should cause the auto-login flag to be propogated throughout the course of the redirect. Run the simple login app, login, and then click to return to the login screen--you'll see the redirect happen and should observe the browser url changing too.
csc_082302.1 - Added a Barracuda Workbench gui app to the testbe package (the classes are included in barracuda_testbed.jar), and added a Barracuda_WorkBench.bat to lib-ext which demonstrates how to launch the app. The purpose of this app is to provide a place to add gui testing utilities that we write for the purpose of working with Barracuda or Barracuda based webapps. Right now there are 2 components: a URLStressTester (which allows you to stress test a simple URL) and a JDBC SQL utility (that allows you to connect to a DB via JDBC and execute SQL commands against it; you will need to make sure that the appropriate JDBC drivers are available on your classpath in order to actually use this). The purpose of these utilities is not to be exhaustively robust, but rather simply to make available some simple utilities that I use frequently and find quite helpful for debugging.
--------------- RELEASED 1.1.1 ---------------------
csc_072202.1 - modify ObjectRepositoryAssembler so that it tries to use the javax.xml.parsers.SAXParser class first, then it looks for the org.apache.xerces.parsers.SAXParser if it can't find the javax class.
ndc_073002.1 - I noticed a problem where I was getting two attribute of the same name in my html output. In my template html lets say I had something like this:
<img src="foo.png" alt="foo image">In my model I had some code like this:
BComponent img = new BComponent(); img.setAttr(" alt", "foobar"); return img;The resulting html would look like this:
<img src="foo.png" alt="foo image" alt="foobar">
Because of the extra space in " alt" it does not match this attribute with the attribute in the html template. So instead of overwriting the attribute, it adds the attribute. I am adding a trim() to the key.toString().
dbr_072302.1 - FormType now uses the provided locale when reporting a ParseException in the DATE FormType.
csc_071602.1 - modify DefaultItemMap's toString() method so that if there is a null value in the item map we don't get a null pointer exception here
csc_062102.1 - minor changes to the Barracuda Admin app (moved the default Admin.properties and renamed it to AdminDefs.properties; added additional logging to the BarracudaAdmin class.
csc_061902.1 - somewhere along the way FormType lost earlier changes that I applied to allow it to map 'Y' and 'N' values to Boolean types
--------------- RELEASED 1.1.0 ---------------------
csc_061702.1 - applied the same changes identified in sam_061602.1 to BlockIterateHandler, BTemplateGateway, and BrowserCheck.
sam_061602.1 - small change to BTemplateViewHandler contributed by
Stefan Armbruster
csc_061402.1 - Research various issues associated with EventConnectorFactory. Turns out that if you want to use it with inner class event handlers, those handlers MUST be declared as public static or you will get an instantiation exception at runtime (even though everything will compile fine at compile time). I did modify the factory to at least try getting an instance of the class when its instantiated--that way, if there are errors, they'll be caught when the servlet starts up, rather than waiting for a user to stumble into that section of code.
csc_061302.1 - Very minor tweak to DefaultViewHandler...changed the scope of the class variables from public to protected (I had opverlooked this yesterday)
jrk_061302.1 - Added support for using FileAppender's in the Log4jInit servlet which is loaded at application startup. If no custom path is provided, a default path set to WEB-INF/logs is used. A system property is set up to reference this path which is named based on the following scheme: [webapp name].log.home. So, in Baracuda's case, it would be Barracuda.log.home. This is referenced in the xml file as ${Barracuda.log.home}. More details are in the Javadoc for org.enhydra.barracuda.core.util.logging.Log4jInit.java and Barracuda's web.xml.
I also added some other Appenders that might be useful to people such as the DailyRollingFileAppenderExt and the SMTPAppender. They are not used by default, but are available. The current default appender is the FileAppender and will, by default, log to WEB-INF/logs at application startup.
Now I just have to figure out why I am getting duplicat logging statements from Log4j? I have a question out on the log4j-user email list which will, hopefully, be answered in short order.
csc_061202.1 - More work to fix the previous change. Basically, I had been setting the Cache-Control header to "public", and this was not correct. It needs to be set to "max-age=0"; this will cause IE to NOT reload the page if you go back in the browser history, but if you re-visit the URL the page will be reloaded. This is now the default behaviour in DefaultDOMWriter if you do not specify the prevent caching flag.
Now, there will be cases where we want to set max-age to a non-zero value; I modified DefaultDOMWriter to allow for this. Then, I also realized that DefaultViewHandler needs to make it easy to set this value, so I created a protected variable called maxAge which your event handler code can modify if you want to specify the number of seconds before the page is considered stale. Also, I realized that the printPretty and preventCaching vars in DefaultViewHandler should NOT be static, as we probably don't want these values to apply system wide. So I changed their scope accordingly. After testing, things seem to work better all-around now.
csc_061202.1 - Added logic to explicitly set the response headers so as to allow the browsers to cache pages (previously, we were only setting the hdrs when we DIDN'T want the browser to cache). There's a couple of resources on which this change was based:
csc_061102.1 - Updated DefaultDOMWriter to add some logging stmts
csc_060702.1 - I changed FormType's BigDecimal stuff to use the String constructor since the javadocs say that using the Double constructor is unpredicatable. Also modified to stripping out the dollar sign if its there. Added a StringUtil class (and test case) to org.enhydra.barracuda.core.util. Renamed DateUtils to DateUtil for consistency.
dbr_060702.1 - added support for BigDecimal in
org.enhydra.barracuda.core.forms.FormType.java. Code was submitted by
Diez Roggisch
jdv_060602 - apply Jason Vincents patch to Localize
We decided to modify our clean target in our build.xml file to remove all *.xmlc and all localized html files from our xmlc/resources directory. In doing so, i noticed that localized html files are created if the timestamp of them is equal to the xmlc files timestamp. They were created initially in the same second as the xmlc files, so they would be compiled again on the next build, even though neither had changed. I tweaked Localize.java to fix this (search for jdv_060602, in two locations).Jake then updated the build.xml to add new targets to cleanup localization generated .xmlc and .*ml files. Look for the "source.xmlc.clean" target.
csc_060502.1 - removed an unnecessary import stmt from org.enhydra.barracuda.core.util.dom.io.DOMFormatter. This import stmt was causing jikes compiler to fail - thanks to Franck Routier [Franck.Routier@hospvd.ch] for finding/fixing this
jdv_053102.1 - apply Jason Vincents patch to Localize2 and rename taskdef to Localize.java. Removed Localize2.java from cvs. Updated build.xml to reference Localize instead of Localize2. Verified that the newly regenerated Locaization examples still work as expected.
csc_053102.2 - improved the logging in ObjectRepositoryAssembler, added a simple test case, and moved log4j.properties to the /WEB-INF directory (previously the build was copying it to WEB-INF/classes). Q: Do we still need log4j_localize.properties and log4j_testing.properties?
csc_053102.1 - changed the logger variable in some classes back to localLogger; this prevents variable conflicts when you extend these classes (ie. in inner classes)
csc_052902.1 - added support to ObjectRepositoryAssembler for a property tag. This makes it easy to set variables (espec. static constants) at assembly time. See the object-repository.xml for an example. Right now Strings, Integers, and Booleans are supported.
csc_051302.1 - modified BlockIterateHandler so that when it renders DOM nodes it does not render closing tags for HTML elements for which closing tags are forbidden. Also added an initHandler() method.
jrk_051002.1 - I am removing the regular xmlc-2.0.1 and replacing it with xmlc-2.1-preview. This new xmlc is independent of xerces, jtidy, and gnu-regexp. Of course, those other libraries are still needed and are included here as jtidy-r7-patched and gnu-regexp-1.1.4. They are based on the newest versions of the libraries currently available (with some patches added to jtidy to make it dom3 compatible).
xmlc-2.1-preview still requires Xerces-1.x.x and I suggest using the latest Xerces-1.4.4. Xerces-2.x.x support willl come in a while, but there are too many dependencies at this time.
The one caveat with using this new version of xmlc with Xerces is that Xerces needs to have org.apache.xerces.dom.DocumentTypeImpl.java patched so that the following method:
void setOwnerDocument(CoreDocumentImpl doc) is changed to: protected void setOwnerDocument(CoreDocumentImpl doc)
xmlc-2.1-preview has one or more classes that subclass DocumentTypeImpl, override the setOwnerDocument, and make calls to super(doc). If the method is not visible to the subclass (which it isn't unless it is specifically marked as public or protected), then the JVM denies access to the method and the code bombs.
I will, temporarily, provide the modified source and binary forms of DocumentTypeImpl at ftp.visi.com/users/hoju/pub. All you need to do is drop in the new compile class into the org.apache.xerces.dom package in the Xerces jar file. Then you are set to go.
BTW, if you are using j2sdk1.4, make sure you put the Xerces jar file in the $JAVA_HOME/jre/lib/endorsed directory. Do *not* assume that the $JAVA_HOME/jre/lib/ext directory is the equivalent of this. It absolutely needs to be in the endorsed directory or you will run into some very strange behavior. Otherwise, with JDK's previous to 1.4.0, you can put the xerces jar file anywhere in your classpath for compilation and in Tomcat's $TOMCAT_HOME/common/lib directory if you are using Tomcat4.x.x.
That should be everything. This should be easier to use and more efficient than xmlc-2.0.1. More updates will continue on xmlc-2.1, but this should work great in the meantime.
Please report any bugs you find to the list promptly!
jrk_051002.1 - modified ScriptDetector... made it so prepareClientResponse(Document, ViewContext) checks the DETECT_CLIENT_SCRIPTING_ENABLED before anything and then just ignore documents that we don't yet support in actually preparing the response instead of throwing a DOMException. Probably want to re-visit this if we ever turn this back on by default to cover XHTMLDocument, WMLDocuemnt, and any other type of document that we wish to support in finding whether the browser supports scripting for that document.
Specifically, this fixes cases where an XMLDocument is passed in like in the "Hello XML World" example in the component tutorial and we were throwing an exception because we don't explicitly support any other document than HTMLDocument.
jrk_050802.1 - applying modifications to FormType.java submitted by
Chris Webb I've reorgainsed the class org.enhydra.barracuda.core.forms.FormType to be a bit more OO.
This is a drop in replacement with no side effects on any other classes. It should be a bit
more efficient as well as the nested if statement has been replaced by sub-class method calls
and there is no need to store any state about the return class type. The main benefit for this change I believe is maintainability. It should also be possible
now to add new types without changing the FormType class by sub-classing FormType and adding
new static definitions. This means that only real generic types are defined in FormType and
extensions defined somewhere else.
csc_050702.1 - modified TemplateHelper so that it will support nested iteration directives embedded within the same nodes. Cool. This was actually pretty tricky to implement, since it requires that when we hit an ITERATE_END, we not only loop back up to the starting node, but we skip all directives contained in that node until we get to nodes that pertain to the current iteration loop. Also required that when we hit an ITERATE_END, we ignore it unless it matches the current iteration context. RE-ran the test suite and everything passed muster, so I think this change is good to go (ie. I'm pretty sure it doesn't break anything).
csc_041802.1 - technically the tree is frozen, but since its not actually getting pulled until tonight, I'm checking this minor change in now. Added a getRootSource method to BaseEvent/DefaultBaseEvent...if the source is an instance of BaseEvent, it'll chain as deeply as possible to find the base event. Useful for handling hierarchical events where you want to know what the actual event fired by the client was.
csc_041702.1 - Emergency source check in to prepare for move to SourceForge. I've added some minor (but important) fixes to the component classes, mostly relating to making sure references get freed up so that objects can garbage collect properly. I've also patched the FormMap class (see previous entry below), plus I've added 3 new classes to the core.event.helper package BlockIterator, AbstractBlockIterator, and BlockIterateHandler. These are used to handle very large DOM templates; I'll have to document them in detail later.
csc_041602.1 - readded a getVals() method whioch seems to have gotten deleted from the previous revision of DefaultFormMap
jrk_041602.1 - committing patch submitted by Jefferson K. French
jrk_041502.1 - Ok, this is the update that everyone has been waiting for!
The Form Mapping overhaul. Very special thanks go to Iman Crawford
Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/forms/: AbstractFormValidator.java And.java DefaultFormMap.java DefaultFormValidator.java FormType.java FormValidator.java Or.java Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/forms/validators/: DateRangeValidator.java DateValidator.java DigitValidator.java EqualsValidator.java MaxLengthValidator.java MinLengthValidator.java NotNullValidator.java RangeValidator.java ValidTypeValidator.java
Its more consistent now. All FormValidators are supposed to validate, if the
entered value is null. This wasn't the case, so e.g. the MinLengthValidator
forced the user to enter something. The solution had been monsters like this:
new Or(new Not(new NotNullValidator()), new MinLengthValidator(10))
.
Now, every mandatory form field needs a NotNullValidator attached to it. What value is interpreted as null is also more consistent: the AbstractFormValidator now has a isNull-method.
Also, we made sure all validators validated the element.origVal. In some cases the validator would validate element.val and would cause inconsistancies when element.defaultVal was not null, but parseexceptions had occurred.
public boolean isNull(Object val, FormElement element)
Checks the nullness of the element parameter. This was to insure all validator derived from AbstractFormValidators had the same concept of nullness.
private Object mapElement(FormElement element, Object origVal, Locale loc)
Checked the type of origVal and not parse it if it is the expected type of the element parameter.
public void validate(FormElement element, FormMap map, boolean deferExceptions) throws ValidationException
Changed validation to take place on the element.origVal
instead of
public Object parse(String origVal) throws ParseException
Make sure FormType.SHORT and FormType.LONG parses values that have zeros following the decimal place.
public boolean isNull(Object val, FormElement element)
This is to encourage checking for nullness in a consistant way.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove
any other null checks. Moved a call to element.getType
to happen after a null
check on the element parameter... Restructered code to check the range calling
element.getVal
if no parseexception had been raised. Also validate against val
parameter if it is of type Date.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any
other null checks. Removed code to get and parse element.origVal
, the parameter val
is the origVal Restructered code to check the range calling element.getVal if no parseexception
had been raised. Also validate against val parameter if it is of type Date.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any
other null checks. Removed code to get and parse element.origVal
, the parameter val
is the origVal
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks. Check for any parseexceptions being raise, fail if there was one.
allowMultiples = true
. Needs some unit
testing code and some real testing not ready for use. Also contains a method to make a copy of an
element for the purpose of deferring exceptions.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
make sure to call the ancestor's isNull method to check nullness. Removed any other null checks.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks. Make sure no parseexceptions occurerd for the element parameter.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks. Comment out a call to element.getOrigVal as the parameter val is the same.
jrk_041402.1 - Somewhat major changes here, although most shouldn't change
behavior you are seeing if you are successfully running a Barracuda app currently. These changes
make Barracuda more versatile with Servlet engines using multiple classloaders. Most these
changes have to do with classloading. The main issue is that when Barracuda libs are put in a
servlet container's lib directory so that they can be accesed by all webapps running under that
container, any call to Class.forName() will end up causing a ClassNotFoundException. The reason
is that it is looking for resources in the current classloader only and not searching all classloaders
it has access to. The proper way to do this in Java2 is:
Thread.currentThread().getContextClassLoader().loadClass(String)
After adding that, I was able to run most of the Barracuda apps from the $TOMCAT_HOME/lib directory.
I still ran into a couple other errors. One was a related error in the DefaultPropertiesModel where
I was getting a MissingResourceException. The fix to that is, when calling ResourceBundle.getBundle
we need to pass in the classloader.
The last nasty error I was getting was a NullPointerException in java.util.ArrayList. This stemed from the getViews() method in BComponent not checking for null before sending an existing ArrayList into a new ArrayList constructor.
I added the null check and just retun null if "views" was null. Not sure why "views" is null, though. We will have to look for the root cause later. It only seems to happen when running Barracuda apps with Barracuda libs in $TOMCAT_HOME/lib. Never happens when running libs out of WEB-INF/lib of any given webapp???
I also updated log4j.properties loading in BCategory. Not perfect yet, but better. Still working on this....
Look for //jrk_20020414 to find changes...
UPDATE: Those using Enhydra 3.x.x will probably run into problems using
Thread.currentThread().... and must revert to using Class.forName(). This was discussed on the
list and James Carnegie
jrk_040702.1 - modified TemplateHelper to fix a bug reported by
Tim Daly
> in AbstractBComponent L495, hasViews() returns true if there are views > _or_ tempViews: > > public boolean hasViews() { > return ((views!=null && views.size()>0) || > (tempViews!=null && tempViews.size()>0)); > } > > > in BComponent L252, getViews() doesn't return any tempViews: > > public List getViews() { > return new ArrayList(views); > } > > which can lead to an IndexOutOfBoundsException in TemplateHelper L330: > > > if (!bcomp.hasViews()) { > ...; > } else { > newNode = ((View) bcomp.getViews().get(0)).getNode(); > }
jrk_040702.1 - modified HttpServletRequestWrapper to fix parameter handling
for servers like ATG Dynamo which, upon a call to getParameter(), do not always return all
parameters if the request was a post with extra parameters on the url string. Actually, this
is just an update to an existing fix to look for parameters by "parameterName=" rather than just
"parameterName" (notice the lack of the "=" sign). This just updates the functionality to match
the way servlet engines grab parameters. Patch suggested by Andras Balogh
csc_032202.1 - found and fixed a really obscure bug in TemplateHelper, that was causing parts of the template to get processed twice, which not only was extra overhead, but also caused null pointer exceptions in certain cases (ie. when the element the step child was bound too got removed and then the step child was rendered it wouldn't have a parent, thereby causing a null pointer exception when adding teh element back into the template).
The solution in this particular case was to modify TemplateHelper so that in the main render() method, it only removes child nodes and replaces them from the master template if the component we are rendering is not a step child. I added a test case to TestBTemplateRender and verified that it seems to work. Thanks to Thuong Nguyen [thuong.nguyen@theplatform.com] for coming up with a sample piece of markup that clearly illustrated the problem.
csc_031902.1 - modified HTMLTableRenderer to implement the createDefaultNode routine. This will allow you to return a BTable component from the a template model and have it automatically get associated with the proper node.
csc_031502.2 - modified DefaultViewHandler to rename logger to localLogger; modified BTemplateViewHandler to not even reference a logger (it can always use localLogger if it needs to). This name change is useful since code which uses these classes often defines its own logger classes (calling them logger)
csc_031502.1 - created a FormUtil class which contains some simple utility functions to assist in form validation
csc_031402.2 - updated the FormMap/DefaultFormMap classes with some minor modifications. First, use a static final defaultLoc throughout rather than constantly grabbing a default loc every time we map an item. Second, add 2 mapElement methods that take a key and origVal--look up the form element that matches the key and then set the value accordingly. This makes it possible to map individual elements (rather than mapping the whole shebang all at once from a request or statemap).
csc_031402.1 - very minor change to FormType so that it will correctly map Boolean types from "y" and "n", along with other strings
csc_031202.1 - AbstractBComponent - tweaked destroyCyle so that it checks to make sure children are non-null before trying to iterate through and invoke destroy cycle on them. This should fix a null pointer exception that Peter Mergaerts [PMERGAER@janbe.jnj.com] was getting on occasion
csc_030802.1 - Found and fixed a bug in AbstractBComponent; when removing al step children, need to invoke their destroyCycle() method to ensure that they correctly release references to data, allowing them to be reclaimed by system gc
csc_030602.1 - Added a WeakSession repository to the ObjectREpository class. This basically gives you a place to put things that are scoped to session but can be reclaimed by the garbage collecter as needed. Excellent place to put things like multi-page results sets; if its there, you don't have to re-query the DB, if it's not then you know you need to.
csc_025102.1 - Modified DefaultEventContext so that when persisting/restoring state, it saves Local ObjectRepository state as well across client side redirects)
csc_022102.1 - Removed GlobalRepository, and revamped ObjectRepository (both found in org.enhydra.barracuda.plankton.data). Basically, ObjectRepository now extends StateMap, and can be used to easily access common storage areas, scoped as:
The basic idea here is too make it really easy to access common storage spaces (in particular: Global, Session, and Local). So this class provides static methods for all of these. To make this integrate with Barracuda, I modified ApplicationGateway and ComponentGateway to set up the Session repository (has to pass it a ref to the req obj), and then to clean up these repositories when the request is complete.
What this means is that you can easily access session information from anywhere in your code now... simply call ObjectRepository.getSessionRepository() and proceed to put data in or take it out. Same thing for global and local.
jrk_021902.1 - Made change supplied by Stephen Peterson
jrk_021802.1 - Made changes supplied by Diez B. Roggisch
The problem is that we (and surely others as well) need support for file uploads. These come as MIME-Requests. The standard HttpServletRequest can't deal with them, so you have to use your own wrapper. Unfortunately BARRACUDA doesn't allow to install yourt own wrapper. So I made some changes to ApplicationGateway. It now doesn't create a HttpServletRequestWrapper by default. Instead a method wrap is called. This method creates either a HttpServletRequestWrapper or it invokes a RequestMapper.wrap method. The RequestMapper is a simple interface, and it can be installed by setting a class variable in ApplicationGateway.
jrk_021502.1 - Made changes supplied by Stephen Peterson. I made a some formatting changes and added contributors where appropriate.
This class associates a given event with a given event handler. This class reduces the need for the anonymous inner classes typically found in gateways. To associate an event with an event handler reduces to a single line of code:
specifyLocalEventInterests(new EventConnectorFactory(Handler.class), Event.class);
in some of my setups I kept getting a NullPointerException in DefaultView.searchForTemplates() ... I never quite found exactly what was wrong with my setup, but adding a null check on curnode at the start of searchForTemplates() took care of it. (jrk - I also added a logger.warn() line if the node is null)
csc_021502.1 - Modified all the test cases to use assertTrue() instead of assert() (assert is now a keyword in JDK 1.4)
csc_021102.3 - Fixed a bug in BComponent, whereby renderView didn't really do anything. This meant that if you used a plain-jane BComponent (ie. to control enabled/disabled), the custom renderer never got invoked. By adding this functionality into BComponent, you can now use plain BComponents to control both visibility and enabled/disabled rendering, plus, we were able to remove all the duplicated renderView methods from all of the individual components that extend from BComponent. Much much better now...
csc_021102.2 - Modified HTMLComponentRenderer so that is again sets enabled/disabled at the end of the render cycle. This was commented out at some point way back, and I can't figure out why...there's a chance that it might cause a problem if you pass back a disabled BAction component (since the component would be disabled, the HTMLComponentRenderer would remove any references to href and target; perhaps this might cause a problem when the HTMLActionRenderer tries to render next...but I can't see anything obvious in the code, so if you run into anything, let me know). This change is necessary so that you can use a plain-jane BComponent to control simple things like visibility and enabled/disabled status.
csc_021102.1 - Modified the BTemplateViewHandler so as to allow the abstract method to return either a TemplateModel or a List of TemplateModels. Before now, you could only return one. If you are extending from this class anywhere, please note that the method signature changed from singular to plural: getTemplateModels (note the 's'!)
csc_020602.1 - removed all references to log4j stuff in the org.enhydra.barracuda.taskdefs package. Basically, if you need loggin here, use that provided by Ant. This eliminates the need for log4j_localize.properties to be in your classes directory (which was a major pain in the butt for projects that were simply using Barracuda)
csc_020502.1 - added a new GenerateSSIs taskdef. This taskdef is primarily useful if you use ssi based mockups, when you want to edit your mockups in a single HTML file and then have pieces of it automatically written out to .ssi files. The taskdef will parse a given file (or fileset) looking for html comments that look like this (where 'foo' can be the name of any ssi file):
<!-- start foo.ssi --> ... <!-- end foo.ssi -->
When the taskdef sees these tags it will write the contents to the target ssi file IFF the source file is newer than the ssi file or force="true". For complete details, see the source comments.
csc_020202.1 - added a NameSpace, ObjectRepository, and GlobalObjectRepository classes to org.enhydra.barracuda.core.util. These classes are useful for establishing a common storage facility, where commonly used resources (ie. datasource) can be placed. Also created an ObjectRepositoryAssembler which can be used to automatically insert items into the default ObjectRepository at startup (the assembler class implements HttpServlet, and can be pointed at a file like /WEB-INF/object-repository.xml) to automatically set up items in the OR when the servlet starts. Also made a few minor improvements to miscellaneous classes.
csc_013102.1 - added several methods to HttpServletRequestWrapper to comply with Servlet 2.3 spec. Upgraded the servlet.jar included in WEB-INF/ant/lib/ to use the new servlet 2.3 jar.
csc_013002.1 - Couple of significant changes.
jrk - Overhauled ScriptDetector.java and ScriptingCheck.js to fix bugs where mailto: and javascript: href values were improperly getting $csjs and $u parameters added to them. Also fixed a bug were hash values on URL's were not working with the scripting check because we were indiscriminately appending the scripting flags where, in order for a hash to work to link to a particular anchor in a document, the hash value needs to be the last item on the URL string.
I also enhanced the Javadoc comments in ScriptDetector removed a lot of the old code that didn't make sense anymore. In addition, I modified prepareClientResp so that it is overloaded rather than using instanceof all the time to check for the type of document we are dealing with. This provides compile-time checking rather than running into errors at runtime. I left in a version of prepareClientResp that takes a generic Document and uses instanceof for backward compatibility but I strongly recommend using the more specific HTMLDocument version and other versions (when they become supported).
The next thing to do is to create an "Assume Scripting Enabled" mode where no scripting check is run, but Barracuda will still think the client supports scripting.
dbr_012202.1 - Applied a patch from Diez B. Roggisch [diez.roggisch@artnology.com] that provides BAction setParam with support for String[] so both types of request parameters are supported now.
dbr_122801.1 - Applied patches from Diez B. Roggisch [diez.roggisch@artnology.com] that fixed bugs in both the DigitValidator and the DateValidator where they wouldn't validate if the desired FormType wasn't a String.
csc_011902.1 - Added back in UserReport.properties and UserReport_es.properties...these somehow got removed from cvs. I restored these files from the Barracuda 1.0.1 zip, and tested that the CompTest3 example works again now...Thanks to Jacob kjome [apu@mediaone.net] for catching this.
dbr_011602.1 - Applied a patch from Diez B. Roggisch [diez.roggisch@artnology.com] that expands the FormMap interface to optionally take a locale when mapping; if none is passed the default locale will be used.
jdv_121201 - Applied a patch to Localize2 from Jason Vinson [jason.vinson@mindspring.com]. This patch basically adds support for two additional taskdef parameters: masterlocalefile and masterlocaledir. If these parameters are present, Localize2 will perform all localization out of these master files, rather than looking for individual property files on a per-template basis.
As an example of this, if you wanted to localize an app and store all of text in a common directory (ie. ./Locales), using a file naming convention of MasterProps.properties, MasterProps_en.properties, MasterProps_sa.properties, etc, then you would modify your ant build.xml's invocation of Localize to pass two additional parameters, like this:
masterlocaledir="./Locales"
masterlocalefile="MasterProps"
csc_121201.1 - Fixed a bug in HTMLTextRenderer and XMLTextRenderer...only try and set the text value if text is non-null. Checked the link renderers, and found that this fix had already been applied there.
csc_112901.2 - Fixed a bug in ScriptDetector, where we weren't handling the Area element in the anchors section. Also modified BarracudaConfig to call ScriptDetector, since its not extending DefaultViewHandler.
csc_112901.1 - Fixed a bug in CopyAndReplace. Basically, if you are using it to include ssi's, you _don't_ want to copy those ssi's across too (or they get replace run on them twice, once as their own file, and then again after they've been included...this causes problems. SO...modified the build.xml to not copy across ssi files, and then modified the CopyAndReplace taskdef so that if the include file is not found it'll look in the src dir.
After updating from cvs, you MUST delete any *.ssi files which are left in src\org\enhydra\barracuda\config\xmlc.
csc_112801.1 - Created a new Localize2 taskdef (which will eventually replace Localize, once we've had a chance to test it further) and updated build.xml to use this. This new taskdef solves the issues described here: detailed here.
csc_111601.1 - Start reworking the Localize taskdef so as not to need XMLC. This solves a problem which is detailed here.
The first step was to modify the CopyAndReplace taskdef so that it can (optionally) resolve SSIs. The default is false; so if you want it to do this you will need to set the parameter accordingly (see Barracuda's build.xml for examples)
csc_110501.1 - Fix a problem that was introduced with the csc_103101.1 fix. Basically, what we were doing is creating a slightly more complex piece of markup (ie. clone the current node, then add an anchor element into it) and then returning that. The problem is that when template helper goes and automatically creates a view, it does it on the outermost node (in the case of CompEx7, this is a element, which is not valid for a link to be bound to). So the problem is that when we create a more complex piece of markup the component sometimes needs to be bound to an element that is buried down inside the node created. TemplateHelper has no idea how to find the right piece to bind it properly.
The real solution here is to modify createDefaultNode() so as to pass in a reference to the component; this then allows the code that creates the default node to optionally associate the component with the right element in the view then and there (meaning TemplateHelper won't have to do that step). Of course, if the code that creates the default node _doesnt_ create a default view, template helper will fall back to the previous approach, which is simply to create a view on the outermost node returned.
Note that there is a larger issue here which still hasn't been fixed. When the createDefaultNode returns a node with children (HTMLLinkRenderer is an example) wherein it added a view onto the part of that markup, a BTemplate delegate gets created on the nodes _after_ the delegate, but before its rendered. What this means is that even though the delegate component renders properly, the BTemplate render wipes out what was there (since the master template snapshot is taken at the time the view is created, rather than right before the component renders). This whole thing is very complex. The real solution is to revamp the way the views are generated (as described here: http://barracuda.enhydra.org/project/mailingLists/barracuda/msg02326.html) However, I don't have time to implement this right now, so I inserted a temporary fix instead: if the createDefaultNode() method adds a view, the BTemplate delegates will not be created. This isn't ideal, but it works for now.
csc_110201.1 - Added a notion of RenderStrategy, defined in org.enhydra.barracuda.core.comp.renderer.RenderStrategy as either SCRIPT_AS_NEEDED or NEVER_SCRIPT. Strategies can be set on a per-component basis; if the strategy is null, it is obtained from the component's parent; if the root component's strategy is null, it defaults to DEFAULT_RENDER_STRATEGY.
The basic idea here is that sometimes even though a client may have scripting enabled, a developer may still not want the components to render using scripting. All the developer has to do is set a component's render strategy (either at the individual component level, at the root component level, or at the default setting level in RenderStrategy). When a component renderer wishes to make use of Javascript, it must not only check to see that Javascript is enabled, but also that the component's render strategy allows for it.
Note that right now the only renderer that really uses scripting is HTMLActionRenderer. Also note that this change does NOT apply to HTMLScriptRenderer or HTMLScriptResourceRenderer...these renderers MUST always render, regardless of whether or not the client supports scripting (see notes therein for details)
csc_103101.1 - Fix a bug in HTMLLinkRenderer; when it was trying to create a default node, if the type was not <a>, <button>, or <input>, it was just creating an <a> element and returning that. This caused whatever the node containing the directive was (ie. a <td>) to get discarded. Now, when the BLink was added back into the DOM, it would eventually create a containing <td> element so as to be valid markup, but all the attributes of the original node are of course missing.
A much better approach is to clone the current node, and then add a newly created element to that. Thanks to Kirk Daries [Kirk.Daries@sita.co.za] for finding this one.
csc_102601.1 - Fix a minor glitch in the error logging within HTMLListRenderer; a null pointer exception was being generated if logging was enabled and the item being added to the list happens to be a BComponent which is not yet bound to a view. Thanks to Sarens, Filip [FSARENS@janbe.jnj.com] for reporting this problem.
csc_102501.2 - Applied a patch to ensure that when we handle a RedirectException, the resulting redirect url contains the necessary script detector flag (this will prevent another subsequent client side redirection in order to determine it).
bw_102501.1 - Applied a patch submitted by Bill_Wallace@elementk.com. The basic purpose of this change was to make it easier to get info out of the validators about what is being validated. The changes are quite minor, only adding getX() methods where needed. Note that none of the information retrieved is muttable, so getting it is purely informational.
csc_102501.1 - Upgraded build system to use final versions of Ant 1.4.
csc_102401.1 - Fixed a major typo in AbstractBComponent; this bug was causing step children not to get removed correctly, which in turn caused all kinds of really subtle problems when you have a component hierarchy that was getting reused. Because the step child was never getting removed, on the second render it would be pointing to a view that no longer existed. Ouch.
This is a high priority fix--if you have been having problems related to nested components, you should make sure you have a version of the source that includes this patch.
csc_102201.1 - This checking represents some very significant changes that I've been working on over the last several says. The basic thrust behind these changes has been to make Barracuda accurately detect whether or not scripting is actually _enabled_ on the client (not just if its supported, which is what we were doing before). This change is now complete, and the explanation is given here.
Here is a line item explanation of the specific changes:
1. Created org.enhydra.barracuda.core.helper.servlet.ScriptDetector. This class basically provides several key helper methods that are used by other classes within Barracuda. These methods included checkClientReq() and prepareClientResp().
2. Renamed BScript to BScriptResource and then created a new BScript component which actually allows you to attach a client side script to a DOM element. BScripts can take any number of BScriptResources. The way a BScript works is that you specify the script attribute (ie. "onload"), the script command (ie. "sc_CheckPage();"), and then the mode (APPEND, PREPEND, or REPLACE). The mode will determine whether the script command you specify overwrites whatever else is in the template for that element, or whether it simply adds to it (either in front of or after what's there). Note that this change effectively brings full client side scripting capabilities to the Barracuda component model, although we haven't created any library of routines yet. Also note that I moved both of these classes from the main comp directory into a comp.scripting subpackage. Also created renderers for these classes (note that for scripting renderers, they must ALWAYS render, even if the client doesn't support scripting, as they might always enable it later and then it needs to be there).
3. Created a ScriptingCheck.js file to actually provide the client side check (sets all the $csjs values in the page from false to true)
4. Modified ViewUtil to actually check for the $csjs value when determining scripting type
5. Modified ComponentGateway to call ScriptDetector.checkClientReq() prior to processing GET requests; this will ensure that if a request comes in without a $csjs value it will get rerouted immediately so to provide one. Call ScriptDetector.prepareClientResp() after rendering the main component DOM; This will ensure that all the links and forms have the necessary $csjs=false values embedded.
6. Modified ApplicationGateway to call ScriptDetector.checkClientReq() as described above. Note that app gateway can't make the corresponding prepareClientResp() call because it knows nothing about the DOM (ie. the event model is not tied to any particular rendering mechanism).
7. Modified DefaultViewHandler to provide the corresponding call to ScriptDetector.prepareClientResp(). Note that if you are using components within the context of the event model, you really should have your view handlers extend from either DefaultViewHandler or BTemplateViewHandler so that you can pick up this functionality for free. If you are building/ rendering your own component hierarchy, you will need to add the corresponding prepareClientResp() call to your own code to take advantage of the new scripting detection functionality. Of course, if you don't do this, everything just continues to function as it did before.
8. Updated the docs describing this (see /docs/misc_features.html); reran the test suite and rebuilt all the jars.
I think that about covers it. The key point to note here is that this change effectively tells us whether or not the client actually has scripting enabled. While I don't think these changes will break anything, note that you can always turn them off simply by setting ScriptDetector.DETECT_CLIENT_SCRIPTING_ENABLED=false;
csc_101901.1 - Backout out the encoding changes I added to FormGateway under csc_101701.1...turns out they are not needed there since RequestDispatcher.forward() handles this for us.
csc_101701.1 - Diez B. Roggisch [d.roggisch@artnology.com] identified a problem in the HTMLActionRenderer: basically, when we get a components action, the value is encoded for us with a session id if URL rewriting id turned on. This is fine, as long as you don't need to modify the url. Unfortunately, HTMLActionRenderer sometimes needs to do this. So, we created another getAction() method in BAction which allows you to get the action _without_ having it encoded. The HTMLActionRender can then manipulate it as needed and encode it itself.
In addition, there are several gateway classes (ParamGateway, FormGateway) which effectively do a redirect. These need to use URLRewriter when building the target, so that the session info will get preserved through the redirect.
csc_101201.1 - Modify HTMLActionRenderer: when rendering an <input> element whose type="submit", we need to set the forms' onsubmit handler to simply click the button, thereby running it through the same chunk of Javascript as if the user actually pressed the button. IE seems to do this by fault, but Mozilla does not. This fix will work for both. Thanks to Iman L. Crawford [icrawford@greatnation.com] for finding this.
csc_101101.2 - Minor tweaks to BarracudaEventBuilder.dtd; it need to refer to 'req-events' and 'resp-events' (note the plural) rather than 'req-event' and 'resp-event' (singular). Thanks to Diez B. Roggisch [d.roggisch@artnology.com] for catching this one.
csc_101101.1 - Modified ApplicationGateway so the initializeLocal(ServletConfig iconfig) method is deprecated and final; this will prevent it from compiling, and will force people to correct their code to call the right method. Failure to do this was allowing the system to compile but not run.
csc_101001.2 - previously, the HTMLSelectRender's createDefaultNode() was just always creating a select element from scratch. We really want to try nd use the template node if at all possible, however, so that we can inherit any special property settings it might have (like name)
csc_101001.1 - More constructors work; elementinated references to Views in constructors. This is because in most case people will just be passing components back from a model and allowing the model component to actually create a view for them. This streamlines the APIs significantly, although it will break existing code. Fortunately, the changes you need to make to get it to recompile are straightforward and obvious.
Fixed a non-related bug in BInput and BSelect that didn't show up until I made the above change. Basically, if you returned one of these components from a model, and that component had listeners attached to it, the preRender method will create a delegate BAction component for all the views. The problem was that it should also be looking at tempViews too (since these will be set when the model creates the view for the component).
csc_100901.5 - Cleaned up constructors on various components. A lot of the components had single arg constructors which took just a view... in reality, this flavor is almost never used, so I removed them.
csc_100901.4 - Fixed a very serious (yet difficult to spot!) bug in HTMLListRenderer and HTMLTableRenderer whereby it was setting the template node to null after render, rather than setting it back to its original value. Fixed now.
csc_100901.3 - DefaultFormElement was incorrectly passing in a 'false' value to the final constructor. Thanks to Diez B. Roggisch [d.roggisch@artnology.com] for catching this.
csc_100901.2 - Modified web.xml to conform to the new 2.3 DTD. Thanks to Jacob Kjome [apu@mediaone.net] for this patch.
csc_100901.1 - Reverse yesterdays change...just use the noargs init method and then call getServletConfig() to get the ServletConfig object.
csc_100801.1 - Make sure the ApplicationGateway class invokes super.init() in the init(ServletConfig) method. Also applied this fix to ResourceGateway. Thanks to Diez B. Roggisch [d.roggisch@artnology.com] for catching this.
csc_100501.2 - 1.0 RELEASE (source is tagged in cvs under BARRACUDA_1_0_FINAL
csc_100501.1 - Modified ApplicationGateway so that it creates the DispatchQueue using a factory method. This makes it possible for someone to provide a different implementation. Thanks to Diez B. Roggisch [d.roggisch@artnology.com] for the suggestion.
csc_100401.1 - Very minor change to remove some vestige code from AbstractTemplateModel: basically it still had a resetModel() method in it, which went away from the interface long ago. I just overlooked it in AbstractTemplateModel.
csc_100301.2 - Several changes.
First of all, there was a problem in the jsrsClientServerHTTPLib script. Basically, it was not setting the selected options correctly. In addition, I modified the posted script to not include button, submit and reset elements. Furthermore, I made it so that when you run it with debuggin turned on, you can manually submit the generated script (in IE anyway). This fixes a problem whereby the values of select elements were not getting passed through to the ParamGateway correctly.
Second, there was a problem in HTMLActionRenderer whereby if the action included url params, when the back button was disabled it would screw up the resulting URL that was created to map the request to the param gateway. There were 2 underlying problems. First of all, the BAction component when constructing an action String needed to be encoding the parameter key/values. Second, when building the disabled action String, the params needed to go outside of the extension. To facilitate this I created a LightweightURL class.
csc_100301.1 - Backed out yesterday's changes for disabling a select element when rendering in HTMLActionRenderer. We can't do this for selects, since it causes the value not to be submitted along with the form if it is disabled. Input and Button elements are still disabled.
csc_100201.2 - Created a NamingHelper class that can be used to retrieve teh name of an HTMLElement. If the element supports the name attribute but the value is not set, a unique name will be automatically created.
merg_100201.1 - Added a close() statement after reading the resource from the inputstream. I noticed that I couldn't redeploy the app when it used the ResourceGateway. This simple .close() fixes it.
csc_100201.1 - When rendering BAction componnents, make sure we disable the element to which they are bound (for input, button, and select elements), thus preventing duplicate submits by double clicking (note that this won't work in NN4)
csc_100101.1 - Modified the DefaultApplicationAssembler so that it can read assembler files from either the /WEB-INF directory OR the /WEB-INF/classes dir; previously, files had to be in /WEB-INF/classes.
merg_092901.1 - HttpServletRequestWrapper: Some servlet containers do not accurately report all parameters submitted with the request. If the request is a post, and there were additional parameters submitted in the url, the additional params are sometimes not returned (ie. on ATG Dynamo). SO...if the value comes back null, then actually check the query string for them.
jk_092801.1 - Supplied a patch for DigitValidator that fixed a logic bug and did general cleanup on the code.
csc_092801.1 - Moved FormGateway from comp.event to comp.helper
csc_092701.1 - We had a problem in BText and BLink, in that the text was always getting placed into the DOM using a CDATASection. This meant that the text was not encoded, so if you returned a String with a markup symbol in it, like '<', it would hose the validity of your DOM.
Basically, the text component should generally encode text before rendering. There are, however, exceptions to this rule, like when you actually want to embed markup in some text.
The solution to this was to modify the DOMUtil.setTextInNode() method to take an extra parameter that indicates whether or not to encode. Then, we modified BText and BLink to each have a setAllowMarkupInText() method...if set, then the text will not be encoded. The default, however, is to always encode.
Finally, built a sample (CompEx7) to test it out, and a test case (TestBTextRender) to validate it.
csc_092501.1 - Minor code cleanup--formatting changes, adding EPL headers, etc.
csc_092101.1 - fixed a problem in TemplateHelper where the BTemplate delegates that get created not only need to inherit the model information from their parent, but also the view settings as well (ie. if the directives are coming from a properties file). The proper way to do this is to make views cloneable (thereby inheriting all their settings)
csc_091801 - fixed EventBuilder so that it would compile under JDK 1.2.2; evidently there is a bug in this version of the JDK which prevents inner classes from accessing protected values in their parent class. Compiled fine in JDK 1.3.
csc_091701 - Created a new BTemplateGateway and BTemplateViewHandler to make it easier to work with template views. BTemplateViewHandler extends DefaultViewHandler, which in turn provides basic component lifecycle functionality (similar to that of ComponentGateway) but for event driven processing. Basically, the idea is that when you need to handle view events (and thus generate a view) this helper class should handle 90% of the use cases. Thanks to Timo Sillanpää [Timo.Sillanpaa@reach-u.com] for suggesting this idea.
Reworked the SimpleLogin (examples/ex1) to use this approach (eliminated a ton of code by doing so). Look here for examples.
Fixed a nasty Javascript bug in HTMLActionRenderer that was causing forms to be submitted twice. Add convenience methods to SessionServices to make it easy to get session info from a ViewContext reference.
csc_091401.1 - the purpose of this mod is to make it possible to process directives in the root node of the template view. We can only do this for BTemplates that are step children because in this case they will only be rendered once and thus its not a big deal to go replacing the root node
csc_091301.2 - Updated TemplateHelper.java to support the notion of recursive template parsing. Basically, there are two known use cases where data coming back from a template model might actually contain additional directives which need to be parsed. In the first case, an anchor element might have a nested image; in the second case, a template model might return a chunk of markup (ie. to insert a header, footer, etc) which in turn might contain directives that need to be parsed.
In both of these cases now, child BTemplateComponents are created and added to the parent component to ensure that the sub-nodes get processed as well. The second part of /Barracuda/CompTest6 verifies this. Also created a test case (TestBTemplateRender) to validate this.
csc_091301.1 - Updated TemplateHelper.java so that when a TemplateModel's getItem() method returns null it will skip that node entirely. Previously, a default "key not found" type message would be displayed, which is really actually redundant with the default implementation of the AbstractTemplateModel. Created CompEx6.java to visually verify this.
csc_091301.0 - Created this document.
Method Summary | |
static void |
main(String[] args)
|
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Method Detail |
public static void main(String[] args)
|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |