$URL: svn+ssh://christianc@svn.forge.objectweb.org/svnroot/barracudamvc/Barracuda2/trunk/WEB-INF/src_docs/developers/changes.html $ - $Revision: 146 $
News & Changes
This document highlights major news and changes that have occurred within
Barracuda since its inception. 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 Archives.
- official release on 3/7/06
- in general, this version consists of numerous performance
enhancements, bug fixes, and cruft removal - if you have not already
upgraded to this version, it will be well worth your while to do so
- IMPORTANT: please note that 2.0 is NOT backwards compatible
w/1.x - although API changes are minor, they do exist (we wanted to take
this opportunity to clean things up). If you have already written
Barracuda 1.x applications, please refer to the
WEB-INF/A_Changes_Barracuda_2.0.txt
- one of the most obvious changes (on the surface at least) is that
the documentation structure has been completely revamped and is now
generated through a build process. The content has also been updated
just about everywhere - so once again, the docs should be pretty
up-to-speed.
- Specific Changes...
- updated to XMLC 2.2.8.1
- Finished preliminary work on the "build binaries" target, improving
build.xml and some minor documentation work
- Minor modification to AbstractBComponent so that BLinks can be
rendered even without being bound to a DOM
- completely revamped the project docs - these are built now using Ant
(source lies in WEB-INF/src_docs)
- Moved the /docs tree to /docs_old in prep for new updated docs
- Allow for custom compound components to be used with Barracuda by
implementing BCompoundComponent
- Cleaned up imports and unused variables. This reduces reported
warnings in Eclipse 3.1 significantly
- Updated all build files to use <javac ... source="1.3"
target="1.2"/> with values being parameterized, of course. This allows
for building under JDK1.5 and still producing binaries that are
compatible with JDK1.4.x which is our minimum supported JDK.
- Minor changes to the ObjectRepositoryAssembler to support better
matching of constructors.
- Modify the FormType.DATE, TIME and TIMESTAMP parsing so that we no
longer try to see if we can construct the value from a Long
- Fix some errors that had crept into the HTMLLinkRenderer over time,
so that it was not rendering links properly when they were returned as
items in a list model
- Minor improvement to the GenerateSSIs taskdef, allowing you to
optionally specify an "exclude touch pattern"
- minor changes to ApplicationGateway, where we put some even
information into the MDC structure so that it is available for logging
purposes
- Created MultipartRequestWrapper, taken from Stefan's
FileUploadRequestWrapper in the contrib package with some minor
modifications
- Implemented component support for configurable encoding
- ObjectRepositoryAssembler can now set static vars in classes that do
not have public constructors
- revamp the way onsubmit logic gets called on form submission /
button pressing - see A_Changes_History.txt for details
- improvements to CopyAndReplace task to search in parent directories
for ssi files, and to allow for blocks to be dropped out of the template
at compile time using something like this: <!--#exclude_start--><p>blah
blah blah<!--#exclude_end-->. The CopyAndReplace tag can also now access
a @REL_PATH@ variable in your mappings
file
- Removed all references to the ElementFactory interface, and modified
the DefaultView class so that it no longer parses everything beneath the
node to which it is attached. This should imrpove performance and reduce
overhead in most cases
- Changed all local variables named "enum" to "enumeration" due to
compatibility with JDK 1.5.
- Additional method inlining work in the comp package
- fix a casting problem in ObjectRepository.removeSessionRepository()
- FormElement now takes a Format object, which will be used by
FormUtil.repopulate() and FormUtil.formatForOutput() to render the form
element data in a human readable (and Barracuda reparseable) format. By
default, Dates, Timestamps, and Times will use a standard date formatter
(if none is specifically specified)
- fix a nasty SAX bug in DefaultApplicationAssembler and
OjectRepositoryAssembler
- enhance form mapping so every FormElement can now obtain a reference
to its parent FormMap
- Modified getStateKeys() methods in DefaultStateMap and MapStateMap
to return _copies_ of key set, rather than the underlying tree set
itself
- make sure that when Barracuda submits a form using doSubmitAndLock(),
the onsubmit form handler does actually getting invoked (making it easy
to patch in client side validation code, etc)
- Major changes to the Forms package - now supports fully pluggable
mapping strategies, with a DefaultFormMapper and then two custom mappers:
PrefixFormMapper and UIDFormMapper.
- Added some formatting date/time routines to DateUtil in plankton
- add a getDocument() method to the ViewContext interface and
deprecate/remove the getDocument() method from ElementFactory
- Modify TemplateHelper so that if you return a Node from getItem()
without actually doing an importNode() on it, the importNode() will be
called automatically.
- Modify HTMLActionRenderer so that it gracefully handles situations
when the FormElement is not available
- Major enhancement for BScript support - now you can piggyback
BComponents onto other BComponents when returning them from
TemplateModel's getItem() method
- Add support for items with a list (eg. <option> elements within
BSelect, <li> elements within a BList) to easily set element attributes.
- HttpConverter improvements to handle key/val pairs that include "&"
in them
- misc Ant improvements so that build.xml to be invoked properly from
directories outside of WEB-INF/bin
- fixed HttpSessionStatemap so that if you call removeState() when the
session has expired, now the IllegalStateException will simply be
consumed
- fixed problems in IterativeModel's preIterate() and postIterate()
methods
- major improvements to the BlockIterator stuff - you can now make use
of Block_Iterate_Start and Block_Iterate_End directives, which allows
you to span multiple DOM blocks. This change also includes significant
changes to TemplateHelper.
- performance has been improved in the three DOMWriters (DefaultDOMWriter,
JivanDOMWriter, CommaSeparatedDOMWriter) and in BlockIterateHandler;
ResourceGateway should now allow the browser to cache static objects
correctly
- significant improvements to the long running stuff, so that it will
use a pipe rather than a stringbuffer
- ServletUtil has been updated so that when printing params (ie.
debugging) we don't show passwords (something of a security issue - you
really don't want passwords in log files)
- HttpRequester has been updated to for better handling of cookies,
parameters, and request headers
- numerous performance enhancements and bug fixes
-
- One of the biggest changes worth noting is that we have successfully
negotiated the purchase of all copyrights from Lutris (special thanks to
ATMReports for underwriting this).
After consulting with all additional contributor copyright holders, we
have decided to re-license the code base under well accepted
LGPL rather than
the original Enhydra Public License (EPL).
- XMLC has also been re-licensed under LGPL, thanks to the efforts of
Alfred Madl's team; please support
their work!
- both XMLC and Barracuda are partnering with
ObjectWeb, which should do much
to increase our exposure and upgrade our infrastructure.
- all source codethis release relicenses all the code under the
- This release provides a significant number of bug fixes and minor
enhancements. It should represent a very stable base from which to work.
I anticipate that the next major release will involve a major
cleanup/reorganization of the code base
- Specific changes...
- latest and greatest version of XMLC 2.2.4, and include an
LGPL version of Jivan
- changed all the license verbiage to LGPL
- 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
- added the CommaSeparatedDOMWriter which makes it very easy
to render your DOMs to a comma separated format (ie. download
reports in Excel, flat files, or even in the browser)
- additional work to the DOMWriter interface to add the
following methods:
void prepareResponse(HttpServletResponse resp)
void setLeaveWriterOpen(boolean val)
boolean getLeaveWriterOpen()
- minor tweak to GenerateSSIs taskdef, so that it doesn't
include the ssi comment tags in the generated file
- 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).
- minor tweak to the DispatchQueue interface, adding
setRequiresResponse() and setResponseHandled() to the interface
so that we can programatically manipulate this
- added support for LongRunning events (see
/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
- fixed HTMLComponentRenderer so that empty Text nodes are no
longer seen as invalid children for certain tags
- Added JivanDOMWriter which can be used to render DOMs
created by Jivan
- 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
- bug fixes in ObjectRepositoryAssembler, where it was not
always clearing the argList after the <prop> tag was finished
- Added the ability to easily configure DefaultDOMWriter by
setting DEFAULT_OO_PUBLIC_ID and DEFAULT_OO_SYSTEM_ID via obj
repository assembler.
- Added pre/post iterate methods to the BlockIterator
interface
- DOMFactory, DOMLoader, and DOMWriter interfaces have all
been reworked to provide greater flexibility, while making them
easier to implement at the same time
- you can now configure ApplicationGateway to automatically
respond with a 404 Resource Not Found error for invalid events
- major rework of the ObjectRepository classes for better
threadsafety and general code cleanup.
- SoftHashMap now provides the ability to get map keys,
allowing you to see what's been cached
- the EventBuilder taskdef now allows you to supply custom
templates for event generation
- minor updates to the EventBuilder and Localize taskdefs, so
that the code they generate is not automatically compiled at
that time (see the changelog for more information on this)
- you can now pass BScript components back from your BTemplate
model implementations
- the EventBuilder taskdef now allows you to declare control
events (events that can only be fired programatically but will
NOT be dispatched through the ApplicationGateway); previously
you had to manually define such events
- miscellaneous improvements to HttpServletRequestWrapper
- BAction has a new setDisableFormLocking() which allows
target actions that are aimed at other windows
- aditional form types of TIME, DATE, and TIMESTAMP
- fixed a bug in Classes.getAllInterfaces() that was keeping
BTemplate from finding the right renderer for a document
- both HttpSessionStateMap's and DefaultStateMap's removeState()
method now supports simple wildcarding, allowing you to remove
multiple keys in one fell swoop (ie. all keys that start with "foo*"
- 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.
- 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.
- 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
A_Changes_History.java
- 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:
- 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:
- the addition of org.apache.xerces.reader.xcatalog.dtd,
which exists in the Xerces source, but failed to be included
in the binary release
- 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:
- Download Apache Ant 1.4.1 (or better) and the Ant optional
jar (jakarta-ant-1.4.1-optional.jar)
- Install Ant to a directory of your choosing and add the
optional jar to ANT_HOME/lib
- 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
- Delete crimson.jar from ANT_HOME/lib
- 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
- 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:
- 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)
- 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
- 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.
- 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.
- 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.
- 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...
NOTE: All code changes are now being tracked on the
Barracuda Commits Mailing List Archives. Please subscribe to this list
if you are interested in detailed descriptions 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.
$Date: 2006-03-07 15:58:05 -0500 (Tue, 07 Mar 2006) $