Barracuda - News & Changes
barracuda.gif (11456 bytes) This document highlights major news and changes that have occurred within Barracuda. If you are looking for detailed descriptions of code level changes, please refer to A_Changes_History.java or see the Barracuda Commits Mailing List.

1.2.5 Release Notes

  • This release is more of an bug fix and update to version 1.2.0. There are still a few new features of note, though. Things have really stabilized. Here are a few of the notable additions in the 1.2.5 release:
    • 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.
    • 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.
    • Renamed DefaultDOMFactory to XMLCStdDOMFactory to make it more clear what DOM implementation it backs.
    • 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 (actually dynamic loading), 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!
    • 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.
    • Make the default constructor of DefaultEventPool use static constants that can be overridden from object-repository.xml
    • 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.
    • 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.
    • Pretty significant upgrade of ObjectRepositoryAssembler, per extensive discussion on the email list. tag now supprts name='$this'; tags can now return values, using the return="" attribute; and static methods on classes with no public constructors can now be invoked. In short, I think everything you want can now be done Jake :-) Note that I also upgraded the way we obtain an instance of the parser to follow the Sun convention (per Sun's JDK 1.4 and discussion with Shawn). Also note that the javadocs and comments in ObjectRepositoryAssembler are all up-to-date, and I have expanded the object-repository.xml to better illustrate all the various possibilities. Finally, please notice that the test case (TestObjectRepositoryAssembler) has been improved to verify all the new funcitonality works. Woo hoo! Way cool! :-)
    • 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.
    • Update HTMLActionRenderer to work more nicely in non-javascript environments. 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".
    • Added write(Node, OutputStream) to the DOMWriter interface.
    • 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
    • Using deferred parsing (and loading with DefaultDOMLoader) on all the examples in Barracuda except the tutorials (see A_Changes_History for info on why). Amazingly, this results in a 70% reduction in file size for the barracuda-config.jar. Before compiling for deferred parsing it was 960k and after it was 289k; a 671k reduction!
    • Update Barracuda to use XMLC-2.2 final
    • See details on mods mentioned above and other bugfixes/enhancements in org.enhydra.barracuda.A_Changes_History.java

1.2.0 Release Notes

  • It's been about 9 months since the 1.1.1 release and both the Barracuda code and the project as a whole have undergone significant changes. Below are changes of note:
    • The home of Barracuda has moved from barracuda.enhydra.org to barracudamvc.org. The move was done to increase our flexibility in using server resources and deciding on our own software and configuration. The move was facilitated by the Barracuda community. See information about donated money and hosting. Thanks go to all who donated money/resources/time and to the Barracuda community in general for keeping Barracuda moving forward!
    • The org.enhydra.barracuda.plankton package has added to provide a clear distinction between generally reusable classes and the more Barracuda specific classes in the org.enhydra.core.util package. This allows you to use plankton.jar in general servlet projects without having to have any barracuda jars around. For the most part, this shouldn't cause much trouble because most classes that had some Barracuda specific functionality in addition to general functionality now simply extend the plankton classes to obtain their general functionality. If changes are required to your code, they should be minimal (hopefully).
    • Nested directives are now supported by BTemplate. This means one can use nested directive within an Iterative model and all the directives will be rendered before the next iteration.
    • <caption> support has been added to BTable thanks to Denny Chambers.
    • DefaultApplicationAssembler no longer uses File IO to load configuration files. This makes Barracuda more inline with the servlet spec which provides no guarantee of access to the file system within a webapp. This means Barracuda should successfully deploy directly from a .war file. Additionally, DefaultApplicationAssembler will now load multiple assembler files (under servlet-2.3) given a pattern to match such as '/WEB-INF/event-' or '/WEB-INF/event*.xml'.
    • BaseEvent now supports adding parameters to events so you can add new parameters even if they didn't exist in the original request, thanks to a patch by Jack Hodges.
    • event mapping is now case insensitive. So, if you have an event called "GetEvent.event", you can also call "getevent.event" and it will work.
    • The plankton HttpRequester now supports URL's that return cookies, thanks to Shawn Wilson
    • Added getViewContext() method to DefaultViewHandler
    • TemplateModel interface changed from getItem(String key) to getItem(TemplateDirective td) which allows you full access to the TemplateDirective. This might seem like a big change, but most people use AbstractTemplateModel which implements the old getItem(String) method so existing code will continue to work.
    • modified BAction and HTMLActionRenderer to allow for the addition of custom javascript functions to be called before a form is submitted. This allows provide customized form validation and let you return false to disable the form submit. To take advantage of this, you can add multiple javascript functions to BAction by calling addScriptFunction("myCustomValidationScript"). The functions will be called in the order provided. Just make sure your script functions are available or you will get javascript errors.
    • Now able to pass back nested components such as:
                        BSelect bselect = new BSelect(dlm);
                        ...
                        BAction baction = new BAction(new DoSwitchCompany());
                        bselect.addStepChild(baction);
                        return bselect;
                      
    • Modified FormType to add a new TIMESTAMP data type (java.sql.Timestamp)
    • URLRewriter now rewrites URL's by default unless you turn it off programatically or from the application gateway. It used to be off by default to account for a bug in old versions of Tomat and Enhydra3. Given the more modern times, this behavior was reversed to be more in line with default servlet functionality.
    • Added Log4j startup configuration using a package from the log4j-sandbox project. See web.xml, InitContextListener, and Log4j repository selectors for more information.
    • XMLC taskdef moved to the org.enhydra.xml.xmlc.taskdef package. If you use the Localize taskdef, you shouldn't see much of a difference except for now needing to add the xmlc-taskdef-2.2.jar to the classpath in your build file.
    • Support for XMLC-2.2. This makes it so that Barracuda/XMLC apps finally won't conflict with Xerces2 which most app servers and Ant use. This is because XMLC's Xerces package has been moved into the org.enhydra.apache package, effectively hiding XMLC's Xerces implementation from other Xerces implementations. Additionally, XMLC no longer includes any endorsed packages. These need to be provided either via j2sdk1.4.x or via a the inclusion of, for instance, xmlParserAPIs.jar or xml-apis.jar which comes with Xerces2. Also, at runtime, Barracuda currently depends on Xerces2 because the Xerces SAX parser is specified in the web.xml to read the assembly descriptor. Either way, if you create documents outside the scope of using XMLC, you will need some DOM implementation. Xerces2 is a fine choice. Xerces2 can be in common/endorsed on Tomat and ANT_HOME/lib in Ant and everything will work just fine. No more conflicts! Additionally, XMLC-2.2 includes support for the new XMLC deferred parsing which not only brings back runtime reloading, the reloading is server agnostic. In additon, deferred parsing can be used to load an html template directly without having to pre-compile the templates. To enable deferred parsing for your pre-compiled classes, make sure to:
      • add to options.xmlc: -for-deferred-parsing
      • Make sure to add bcel-5.1.jar to the classpath in your Ant buld file
      • add to event-gateway.xml: <dom-loader factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory" />
      • copy generated .xmlc and processed .html files to the same place as your XMLC classes exist
      • load XMLC classes using: Document doc = DefaultDOMLoader.getGlobalInstance().getDOM(MyPageHTML.class, iLocale);
      • You can now modify the .html file sitting next to the corresponding XMLC class file (under WEB-INF/classes), hit reload, and see your change take effect immediately!
        Note that if you use the XMLC deferred parsing factory directly, you can skip the dom loader config and DefaultDOMLoader steps. Additionally, you can skip the copy step if you load .html files directly. You can also skip the copy step if you add a resource path to the .html files which can then sit in some standard location. These might be your reference templates and you can edit them wherever they lay. See XMLC's documentation and Tomcat webapp example for more information... http://forge.objectweb.org/projects/xmlc/
    • The contrib package has been enhanced/bugfixed and the reusable contrib libraries are available in the barracuda-contrib.jar which is built via the 'contrib' target in the main build. See the documentation on the Barracuda contrib package for more information
    • See details on mods mentioned above and other bugfixes/enhancements in org.enhydra.barracuda.A_Changes_History.java

1.1.1 Release Notes

  • This release represents a fairly incremental set of changes from the 1.1 version. Most notable changes include:
    • Support for XMLC-2.1, plus one or two minor fixes to Barracuda to make it compatible (look in A_Changes_History.java for details)
    • We have added a new contrib package, which provides a place for users to contribute working code (although these contents are not built into the main jars by default)
    • Other minor mods are duly noted in A_Changes_History.java

1.1 Release Notes

  • Community Changes - Its been almost seven months since 1.0.2 release, and the community has undergone some changes in that time. Most specifically, Lutris no longer sponsers Enhydra.org, although ObjectWeb has take up that baton. Given the turbulence associated with this transition, the Barracuda community has laid out a vision for where we'd like to go from here...
  • General Enhancements - There have been lots and lots of basic bug fixes and feature enhancements since the 1.0.2 release. Most notably, 
    • the Form Mapping and Validation framework has been overhauled (big thanks to Diez  Roggisch and Iman Crawford)
    • The FormType class was completely rewritten by Chris Webb; it should be completely backwards compatible
    • Christian Cryder has made a number of significant bug fixes in the component package, especially in regards to BTemplate. 
    • Jacob Kjome has been largely responsible for getting us a new version of XMLC that works with JDK 1.4 and Xerces 1.4.4. 
    • Jake has also taken the initiative to revamp the build process so that Barracuda no longer uses a custom version of Ant (of course this means that you'll need to install Ant separately now)
    • Jake has also revamped the classloading, to conform with the standard approach in the newer JDK's. Basically, instead of using Class.forName() we should instead by using Thread.currentThread().getContextClassLoader().loadClass(String). Note that this does cause some problems in older appservers (like Enhydra Multiserver 3.1) that do not support the Servlet 2.2 spec.
    • Christian added some very useful ObjectRepository classes which can be scoped globally, by session, or to req-response cycle. It may be a lot easier to use this mechanism than to try and store data in Event statemaps. There is also an ObjectRepositoryAssembler class which allows you to populate the global repository from XML at startup.
    • Upgraded to the latest Log4J 1.2 and JUnit 3.7 releases
    • Christian added a new GenerateSSIs taskdef which makes it easy to generate ssi files from your HTML mockups.
    • Changed ScriptDetector.java to set DETECT_CLIENT_SCRIPTING_ENABLED = false to accomodate a bug in IE 5.5.
    • Lots of other stuff... ;-)
  • Code Changes - While we always strive for backwards compatibility, sometimes its necessary to require coding changes in order to fix/improve something properly. This is true for this release of Barracuda, and since we had to bite the bullet we figured we might as well address all of the major issues at once:
    • JDK 1.4 - If you are using JDK 1.4 and Tomcat 4.0.2+, you MUST copy the WEB-INF/jars/xerces-1.4.4-patched.jar to JDK_HOME/jre/lib/endorsed. This is because all new versions of Tomcat (and any other App Server complying with the Sun classloading spec) will fail to load XML and DOM libraries from the webapp directories. See Apache bug 6374 for more information. The bug is actually about a problem in the way Tomcat, 4.0.2 - 4.0.3, tries to implement the Sun classloading spec requirement. This has been fixed in the latest beta's of Tomcat 4.0.4 and the 4.1 nightly and alpha builds. However, this just means that they fixed a glitch in implementation. The child classloader (WEB-INF/lib...WEB-INF/classes) is still not allowed to load XML and DOM libraries. They need to be in a parent classloader. Putting Xerces in TOMCAT_HOME/common/lib resolves the issue in JDK 1.3 and below, but JDK 1.4, which already contains XML and DOM libraries, overrides other XML and DOM libraries that are put into the classpath. The only way to overcome this is to use the Endorsed Standards Override Mechanism detailed in Integrating with JDK 1.4. Another option will be available in Tomcat 4.1 where Tomcat provides its own TOMCAT_HOME/common/endorsed directory to put XML and DOM libraries such as Xerces. Using Tomcat's override mechanism, you don't have to mess with the JDK's endorsed directory. However, this would only be useful on machines where you only need to run webapps under Tomcat like a dedicated server. If you also need to compile code you will need to use the JDK_HOME/jre/lib/endorsed solution. 
    • Ant 1.4.1 - Download the zip file, install on your system. Follow the instructions in ANT_HOME/docs/manual/install.htm. Make sure you define a ANT_HOME system variable and put ANT_HOME/bin in your system PATH.
      • You will also want to download the optional jar and place it in the ANT_HOME/lib directory. 
      • You will also need to copy the JUnit, Xalan, and Xerces jars from WEB-INF/jars to the ANT_HOME/lib directory (if you use JDK 1.4, you will only have to copy the JUnit jar). This is because Ant is using a separate classloader for its own taskdefs and simply putting JUnit (and supporting jars) in the classpath doesn't mean that Ant's classloader will pick them up. The Barracuda taskdefs are different in that they are loaded by the system classloader rather than the ant classloader. This is why we don't have to put barracuda-ant.jar in ANT_HOME/lib.
    • XMLC - We are using a custom build of XMLC 2.1 while we await a new release from the XMLC community. This version works with Xerces 1.4.4, with two minor modifications, and will work just fine in JDK 1.4+. The modifications to Xerces are as follows:
      1. the addition of org.apache.xerces.reader.xcatalog.dtd, which exists in the Xerces source, but failed to be included in the binary release
      2. a change to org.apache.xerces.dom.DocumentTypeImpl.java where, in the original source, the method "void setOwnerDocument(CoreDocumentImpl)" was only "package" viewable. We had to mark it as "protected" to allow subclasses outside the package to invoke "super()" which happens in at least one case in XMLC
  • Building Barracuda - The following steps are required to build Barracuda:
    1. Download Apache Ant 1.4.1 (or better) and the Ant optional jar (jakarta-ant-1.4.1-optional.jar)
    2. Install Ant to a directory of your choosing and add the optional jar to ANT_HOME/lib
    3. Copy the following jars from /WEB-INF/jars to ANT_HOME/lib:
      • junit-3.7.jar
      • xalan-2.3.1.jar
      • xerces-1.4.4-patched.jar
    4. Delete crimson.jar from ANT_HOME/lib
    5. Add ANT_HOME/bin to your system PATH variable so you won't have to type the full path to the Ant batch script every time you want to run Ant
    6. If you are using JDK1.4+, copy xalan-2.3.1.jar and xerces-1.4.4-patched.jar to JAVA_HOME/jre/lib/endorsed if you haven't already

    With the above setup, the only difference in building Barracuda using JDK1.3.x and JDK1.4+ will be the JDK versions. The supporting libraries will all be of the same version.

    Now you can simply cd to the Barracuda src directory and type ant clean jars. This should rebuild the entire system and place the corresponding jars in the /WEB-INF/lib-ext directory.

    Here are the ant targets you will normally use:

    • clean - cleans up all the files and resets Barracuda to an initialized state
    • taskdefs - builds the custom taskdefs needed by Barracuda to complete the compile process (these are stored in /WEB-INF/jars/barracuda-ant.jar)
    • compile_core - compiles just the core Barracuda classes
    • compile_rest - invokes compile_core, xmlc, build_events all in one fell swoop
      • deploy_mockups - deploys mockup HTML files so that they can be compiled by XMLC
      • xmlc - actually invokes XMLC to compile *ML files into Java objects using Barracuda's Localization taskdef
      • build_events - uses Barracuda event builder taskdef to create the event class hierarchy needed for the examples
    • compile - compiles all the core classes, and then compiles all the rest (this is typically what you will invoke to compile the whole system)
    • jars - builds jar files from the compiled classes, and places them in WEB-INF/lib-ext
    • javadoc - builds the system javadocs
    • test - runs the unit tests on the Barracuda system.

    For convenience sake, there are several batch files in the src directory to assist you in the build process (on Win32):

    • ant_1_clean.bat
    • ant_2_taskdefs.bat
    • ant_3_compile.bat
    • ant_4_unit_tests.bat
    • ant_5_jars.bat
    • ant_6_javadocs.bat

    You can edit these files to see the actual ant targets invoked by each. The numeric element in the file name shows you the basic order in which you would invoke the batch files to build the system one step at a time. Obviously, if you run ant_1_clean and then ant_5_jars, all intermediate steps (minus testing) will be performed automatically.

  • Using Barracuda - Using Barracuda is very straightforward; the system is precompiled, so all you need to do is copy the appropriate jars into place. Typically, Barracuda is used for building webapps. Consequently, all you need to do is:
    1. if you are using Tomcat 4.02+ and JDK 1.4, make sure the WEB-INF/jars/xerces-1.4.4-patched.jar is in JDK_HOME/jre/lib/endorsed (or TOMCAT_HOME/common/endorsed in Tomcat 4.1)
    2. Barracuda related jars must also be in your classpath, either in the appserver lib directories (ie. TOMCAT_HOME/lib), or in actual webapp directory (../WEB-INF/lib). These jars include:
      • WEB-INF/jars/xmlc-2.1-preview.jar 
      • WEB-INF/jars/gnu-regexp-1.1.4.jar 
      • WEB-INF/jars/jtidy-r7-patched.jar 
      • WEB-INF/lib-ext/barracuda-core.jar and WEB-INF/lib-ext/plankton.jar  -or-  WEB-INF/lib/barracuda.jar
    3. WEB-INF/lib/log4j-1.2.4.jar should generally be placed in each webapps' WEB-INF/lib directory (so that you can have separate logging for each webapp). Note that if this is the case, the Barracuda libraries (those beginning with "barracuda") will have to be in the WEB-INF/lib directory as well. Supporting libraries that don't reference log4j will be able to be in a place globally available to all webapps such as TOMCAT_HOME/lib.

    Note that the Barracuda project itself can be installed as a web-app. All you have to do is create a virtual root in your appserver pointing to BARRACUDA_HOME.

  • Programming Changes - There are a few changes you'll need to make to your code in order to use the new version.

    1. Remove all references to BCategory - previously, you may have written code that uses Barracuda's BCategory to provide Log4J logging. This is no longer recommended, so you should change all references from something like this:
      protected static BCategory logger = BCategory.getBInstance(Foo.class.getName());

      to something like this:

      protected static Logger logger = Logger.getLogger(Foo.class.getName());

      To do this, all you really need to do is search and replace:

      • import org.enhydra.barracuda.core.util.logging.*; --> import org.apache.log4j.*;
      • BCategory --> Logger
      • getBInstance --> getLogger

      Then recompile and you should be in business!

      Note that there is now a new way to configure Log4j: you can use the new Log4jInit servlet and load that on application startup by specifying it in the web.xml. Make sure that it loads before stuff like the ApplicationGateway servlet. See Barracuda's web.xml for details. 

      What this allows you to do is to specify a config file of any name in any location relative to your webapp. The real kicker, though, is that you can specify a time delay in milliseconds. Log4j will use this to re-read your config file every [time you specified] milliseconds ( using configureAndWatch() ) so that you don't have to shut down your appserver in order to change what gets logged. 

      There are two caveats with this. One is that you can add new packages/classes to be logged, but you can't remove them once they have started logging. An alternative to this will likely be available in Log4j-1.3. The second caveat is that in order for configureAndWatch() to work, the webapp needs to be deployed from a directory. If it is deployed directly from a .war file, configureAndWatch() won't work because it requires an absolute file path. This has been taken into account in the Log4jInit and it will just do a normal configure(), which can take a java.net.URL, in this case. If the file you specified doesn't exist then it gives up and lets log4j try to autoconfigure itself on the default files which would have to be located in WEB-INF/classes and be called log4j.properties or log4j.xml.

    2. Localize2 - The original localization taskdef was called Localize; this was replaced by a better version called Localize2. As of this release, Localize2 has been renamed to replace the original Localize. You will need to update your build.xml to reference Localize, rather than Localize2.

1.0 Release Notes

  • General Features - [TODO_1_0]
  • Enhydra / XMLC - We are currently using XMLC 2.0.1, which means that if you are using Enhydra as your multiserver and want to use Barracuda 'as-is' you need to be using Enhydra 3.1.1b1. If you want to use EAS 4.0, you will need to recompile everything (there's a dependency in the XMLC stuff somewhere...). If you want to use Enhydra 3.1 you will need to replace the xmlc.jar (found in WEB-INF/jars) with the enhydra.jar from your Enhydra 3.1 installation and rebuild (using 'ant clean dist' in the src directory). This is due to the fact that the version of XMLC was changed between versions 3.1 and 3.1.1b of Enhydra.

  • JDK 1.4 - Several people have reported problems with building Barracuda under JDK 1.4. Initial research indicates that the JDK is bundling an older version of the DOM classes which are incompatible with XMLC. We are currently looking into this...


Changes History

NOTE: All code changes are now being tracked on the Barracuda Commit Mailing List. Please subscribe to this list if you are interested in detailed decriptions of what has changed.

  • ??/??/?? - 1.0 Final Release. [TODO_1_0]

  • 07/20/01 - Beta 2 release. This release offers lots of incremental improvements and bug fixes over Beta 1. If you are still using Beta 1, we highly recommend you upgrade! At this point, we are trying to finish up the Todo List to get to a 1.0 Final release...

  • 04/20/01 - Beta 1 release.

 

For all the latest information on Barracuda, please refer to http://barracudamvc.org
Questions, comments, feedback? Let us know...