The latest version can always be found at BSF's homepage http://commons.apache.org/bsf/faq.html.
The page you are looking it is generated from this document. If you want to add a new question, please submit a patch against this document to one of BSF's mailing lists; hopefully, the structure is self-explanatory.
If you don't know how to create a patch, see the patches section of this page.
We use Anakia to render the HTML version from the original XML file.
The Velocity stylesheets used to process the XML files can be found in the xdocs/stylesheets subdirectory of BSF's CVS repository - the build file docs.xml is used to drive Anakia. This file assumes that you have the jakarta-site2 module checked out from CVS as well, but if you follow the instruction from Anakia's homepage, you should get it to work without that. Just make sure all required jars are in the task's classpath.
Bean Scripting Framework (BSF) is a set of Java classes which provides scripting language support within Java applications. It also provides access to Java objects and methods from supported scripting languages. BSF allows one to write JSPs in languages other than Java while providing access to the Java class library. In addition, BSF permits any Java application to be implemented in part (or dynamically extended) by a language that is embedded within it. This is achieved by providing an API that permits calling scripting language engines from within Java, as well as an object registry that exposes Java objects to these scripting language engines.
It's the beanage. Beans were the cool thing when BSF was first being designed, and BSF contains several flavors.
BSF began life in 1999 as a research project of Sanjiva Weerawarana at IBM's T.J. Watson Research Center. The initial intent had been to provide access to JavaBeans from scripting language environments (though there is nothing limiting access only to Java Beans). It was soon moved to IBM's AlphaWorks developer site, where significant interest (both internal and external to IBM) led to its being moved to IBM's developerWorks site, where BSF could operate as an open source project. During this time, significant development was done by Matt Duftler and Sam Ruby, and BSF was incorporated into both IBM products (Websphere) and Apache projects (Xalan). It was this interest on the part of the Apache Software Foundation that ultimately led to BSF's acceptance as a subproject of Jakarta in 2002.
During the process of moving BSF to Jakarta, development continued within IBM, with further improvements to BSF's integration with Jasper being made by John Shin and the addition of debugging support for the Javascript language (a team effort, resulting from the work of IBM researchers Olivier Gruber, Jason Crawford, and John Ponzo, and IBM software developers Chuck Murcko and Victor Orlikowski).
It is the current version, 2.3, that has been donated to Apache Software Foundation from IBM.
BSF's distribution contains file names that are longer than 100 characters, which is not supported by the standard tar file format. Several different implementations of tar use different and incompatible ways to work around this restriction.
BSF's <tar> task can create tar archives that use the GNU tar extension, and this has been used when putting together the distribution. If you are using a different version of tar (for example, the one shipping with Solaris), you cannot use it to extract the archive.
The solution is to either install GNU tar, which can be found here, or use the zip archive instead (you can extract it using jar xf).
BSF can be used standalone, as a class library, or as part of an application server. In order to be used as a class library or as a standalone system, one simply downloads a copy of the bsf.jar file from the BSF web site and includes it in their classpath, along with any required classes or jar files for the desired languages.
In order to use BSF as part of the Tomcat servlet engine, one must currently download patches from the BSF web site that permit Jasper to call BSF. Instructions for this will be posted on the website, and will be accompanied by prebuilt binaries. We hope that these changes will be merged into Tomcat in the near future.
No it doesn't.
You may have seen these lower-case directory names in WinZIP, but WinZIP is trying to be helpful (and fails). If WinZIP encounters a filename that is all upper-case, it assumes it has come from an old DOS box andchanges the case to all lower-case for you.
If you extract (or just check) the archive with jar, you will see that the names have the correct case.
There is a bug in the Solaris reference implementation of the JDK (see http://developer.java.sun.com/developer/bugParade/bugs/4230399.html). This also appears to be true under Linux. Moving the JDK to the front of the PATH fixes the problem.