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.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 Commits 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://barracuda.enhydra.org
Questions, comments, feedback? Let us know...
Copyright 1997-2002 Lutris Technologies, Inc. All rights reserved.