2011/12/21 - Jakarta has been retired.

Issue: 1
Date: June 2002
Url: http://jakarta.apache.org/site/news/200206.html

Welcome to the issue #1 of the Jakarta Newsletter. The aim of the newsletter is to try and let people know what's been going on in the jakarta projects when they have been unable to monitor all of them themselves. The editorship of the various sections and overall will probably vary which should hopefully lead to a fairly dynamic monthly newsletter.

So who's sending this to you? I'm a UK software developer working mainly with database webapps, with an interest in the development processes involved. My involvement at jakarta has been mainly as a user of various subprojects, a lurker on the general and commons-dev lists, a long time lurker and occasional conributor to Ant, and lately this Newsletter has become my pet project.

This month we have news based contributions from several projects and a plea for requirements from Avalon. I'd like to thank those who contributed and hope that you enjoy the read. If you would like to comment further on any of the highlighted discussions then please do so on the appropriate list, if you want to comment on the newsletter itself then please point your comments to general@jakarta.apache.org.

Rob Oxspring

Editor: Rob Oxspring

Discussions on general have been fairly light weight this month. The main points have been in regard to issue #0 of the newsletter [1] and some discussion about how best to setup the scarab installation for bug reporting [2].

The other main "on topic" thread regarded java.sun.com's new look. Is it time for jakarta to have a facelift? can we learn lessons from sun? The answer seems to be wait for maven or forrest but generally the familiar open source rule of "your itch, you scratch it" applies [3]. The same thread also discusses the idea of announced and arranged live chats about the various jakarta project with key developers on hand to help explain and assist.

Editor: Berin Loritsch

The Avalon team is in the process of identifying the requirements for a new version of the Avalon Framework. The changes are minimal, and focus on a tighter definition of the contract between the container and the component. The container is the code that manages all the components and how to access them. The Avalon team has identified some anti-patterns related to its use, and wants to provide a way to make it easier to use correctly.

What we want to find out from the community at large is:

1) Are you currently using Avalon in one of your projects?

2) If not, what would it take for you to consider using it on a future project?

3) If yes, what did you like best? What were your greatest challenges? If you could choose one way to improve Avalon, what would it be?

Slated for the next version of Avalon already:

1) Enhanced Meta Data. We are unifying the way we define meta data for the components. This allows the component to be used in any Avalon compliant container with zero issues. Previously you had to find out how any one container defined meta information (like version, whether the component is threadsafe or not, etc.).

2) (Tentative but likely) Standard way of extending the component lifecycle. Avalon already has a rich lifecycle management system, but sometimes you need an application specific extension. We have plans of allowing that to happen, and use any of the existing containers.

3) Enhanced tutuorials, user documentation. The new docs (when written) will focus first on how to use Avalon (the biggest complaint about our documentation). It will then present the anti-patterns that Avalon is supposed to address, and the patterns it uses to solve those issues.

Editor: Rob Oxspring

Conor MacNeill introduced some documentation about his Ant2 proposal and this lead to a discussion of how we could make ant projects more object oriented and reusable, including a look at how other systems achieve a similar result [1]. In particular the Myrmidon Ant2 proposal featured with discussion moving onto whether templating could solve the problems being faced [2].

The antidote (ant gui) project has seen a small revival this month with a couple of new developers joining forces with Christoph Wilhelms to try and drive the project forward [3,4].

The cvs freeze for Beta3 went without a hitch [5,6] and in preparation for the release Erik Hatcher and Steve Loughran lead the way updating javadocs and manual entries for various tasks [7]. In the aftermath of Beta3 some new version checks and diagnostic information have been discussed and added to aide users in getting the appropriate help later [8].

Among the task specific issues this month was a question regarding how best to add logging capabilities to elements below the task level, a number of solutions were volunteered with pros and cons to each [9]. Lou Fox has been having some problems getting the regexreplace task to do what he wants with line endings [10], also the SOS and VSS tasks were treating some $ symbols a little differently to the rest of ant [11] . With luck the fixes should be part of Ant1.5

Finally, thanks to his contribtion in the form of the new Selector API Bruce Atherton was invited to join the team of committers [12].

Editor: Rob Oxspring

There were two main discussions applying to the whole of commons this month: Thanks to mass approval the new commons-user list was set up to allow users to find solutions without the intimidation of votes, commits and similar discussion [1]. The more controversial discussion regarded the take up of maven betas for the build process in various components, can we require betas for building? can we drop ant support without a formal vote? See what you think [2].

Collections recieved a donation of code from avalon this month [3] and it was decided that some naming and layout conventions were needed [4,5]. The implementation of the primitive collections came under scrutiny as Ola Berg noticed that myIntList.contains("Foo"); would throw a ClassCastException rather than returning false, the decision seems to be that they are best as they are but the pros and cons are all presented [6]. The same theme was tackled in a thread that went on to discuss the differences and similarities between assertions, predicates and closures [7].

Comparators came under discussion the month too: How should nulls be treated in comparators? The NullFirstComparator and NullLastComparators were proposed and implementations discussed [8]. In collaboration with BeanUtils a BeanComparator was posted comparing the results of a method or property for order [9] although the class seems to be homeless at the moment. Also regarding collections was some discussion to the thread safety of StaticBucketMap [10] and a proposed reorganisation of util and collections [11].

CLI had some issues with how best to support options such as java's -D see the discussion [12] for full details. Plans are afoot to move into the commons proper and make a release, see the comments and action plan [13].

Betwixt also has plans to move to proper in preparation for a 1.0 release [14], but there may be some a couple of bugs to resolve first [15,16] along with some new features that Stephen Colebourne wants to add [17].

Elsewhere in commons there was the release for JXPath 1.0 [18], how the discovery package should discover its configuration [19] and a discussion as to the distinction between BeanUtils, Reflect and Introspect [20]. Components new to commons were also proposed this month; Berin Loritsch introduced a component to find out how many CPUs are available on a machine and similar information [21], Patrick Luby is planning on separating tomcat's Daemon code into commons [22] and Avalon-Excalibur began the process of integrating its components into commons effort [23].

Editor: David Sean Taylor

The Jetspeed team has spent the month working towards the release of Jetspeed 1.4 Beta in early July. This is our first beta release, substantiating a significant improvement in quality and features. The Jetspeed 1.4 Beta release will include the following new features:

Editor: Ceki Gülcü

The month started with a question by John Armstrong [1] on whether log4j offered any guarantees on binary compatibility between various versions. To which Ceki replied by stating [2] the current policy of not removing deprecated methods until at least two release cycles are completed. This reply did not seem to satisfy John Armstrong and a long discussion ensued. A historical perspective [3] seemed to satisfy most people, at least the discussion petered off.

Mike McAngus started [4] a discussion about timezone and locale related issues in log4j date formats. James Cakalic and Mike discussed the importance of the decimal character separator. Possible performance improvements were also suggested. Mark Womack submitted code for timezone support for date elements of pattern layout. Unfortunately, the code was anonymous and we could not take into consideration. The idea seemed to catch on though.

Ceki asked for clarifications [6] on java buffered IO because his experience did not match the myth. Georg Lundesgaard mentioned [7] the character conversion buffering aspect as explained in the OutputStreamWriter javadocs.

Costin Manolache related his experience [8] with configuring log4j with JMX. He mentioned the web-application logging insulation problem. In response, Ceki wrote a specification [9] for solving the logging separation problem. This was followed by a promising discussion [10] on Tomcat-dev.

Mark made a proposal [11] for a new log4j component called "Receiver."

Editor: Otis Gospodnetic

1.2 released on June 12, 2002:

This is its first release since it migrated from Sourceforge to Jakarta. This release includes fixes for a number of bugs, improved query parsing, etc. All changes can be seen here: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-lucene/CHANGES.txt?rev=1.15

Lucene Sandbox repository has been added. The plan is to give the commit rights for that repository more freely, and allow developers to use that repository for storing outside contributions, so that we don't have to rely on mailing list archives. Also, the Sandox will, and already does, host some contributions that are still in development. Currently, a web crawler with hooks for text indexing with Lucene is being developed there: http://cvs.apache.org/viewcvs/jakarta-lucene-sandbox/contributions/webcrawler-LARM/

This project is looking for developers, so if you would like to get involved with web crawler and text indexing development, this is a good opportunity to do so.

Its well-written documentation is available in a few formats here: http://cvs.apache.org/viewcvs/jakarta-lucene-sandbox/contributions/webcrawler-LARM/doc/

1.3-dev1 version:

Development of the next release, version 1.3, has started. Brian Goetz added preliminary support for range queries (<from date> TO <to date>), and we applied some contributed fixes that make it possible to use Lucene on read-only media, like CD-ROMs.

A list of items that we would like to work on in the future is listed in our TO-DO list: http://cvs.apache.org/viewcvs/jakarta-lucene/TODO.txt

I am in the process of applying patches/contributions that further improve the query parser by allowing Lucene API users to programmatically specify the logical operator between query terms that they want to use (AND or OR). In addition to that, a contribution burried in the list archives will advance Lucene's query support by allowing queries such as "Java app*" (find all documents containing a phrase "Java app", followed by anything). This will allow one to find documents containing either "Java application" or "Java applet" or anything else that starts with "Java app".

Editor: Thomas Mahler

OJB joined Jakarta in June!

ObJectRelationalBridge (OJB) is an Object/Relational mapping tool that allows transparent persistence for Java Objects against relational databases.

OJB provides multiple APIs::

• A full featured ODMG 3.0 compliant API.
• A JDO compliant API (work in progress)
• A low-level PersistenceBroker API which serves as the OJB persistence kernel.

There has been a long discussion on using the commons-logging API for OJB. OJB currently uses its own wrapper API for logging. We came up with a proposal to extend commons-logging with features we need urgently for OJB logging [1].

There has also been a discussion on a proposal [2] that tries to define an implementation strategy for the new OJB JDO layer. Matthew Baird answered [3] that he will assemble a draft for a functional specification of the proposed Object Transaction Management layer. This document is almost finished and will be the base for our next implementation steps.

Editor: Daniel F. Savarese

Jakarta-Oro development has continued its trend of making small incremental additions and fixes in response to user requirements, rather than the major development initiatives that have been discussed. The most recent set of fixes and improvements were made available in a 2.0.7-dev-1 developer release on June 27th. The most pressing need for the project is the contribution of comprehensive unit tests for the core Perl regular expression classes. Without these, we will not be able to quickly press forward toward Perl 5.6 (soon 5.8) compatibility. Long term goals are to include factory class(es) for plugging in any regular expression package using the org.apache.oro.text.regex interfaces, provide a J2ME version of the package, and build more commonly used high-level text processing functionality into the package, becoming a general purpose Java text-processing toolkit rather than strictly a regular expression package.

Editor: Avik Sengupta

The POI team made two releases in June. A production release of version 1.5.1 on June 17, and a dev milestone release 1.7.0 on June 24. The dev release was notable for the inclusion of a large body of formula support. This was preceeded by some expected wrestling with the undocumented parts of the excel file format [2].

The dev list was animated for a while on the issue of whether poi should have a calculation engine built in. Andy summarised the discussion [3].

To better understand how POI and its components are being used in practice, a call for case studies was made [4]. These have been put up on the project site [5].

There have been many requests for a java viewer for excel files. Andy hacked up "Sucky Viewer" as a GUI component built on POI/HSSF [6].

Logging has been the cause of a large number of problem reports. It was therefore decided that POI would have logging disabled by default, and thus no extra libraries would be required to run POI [7]. However, developers would have the option of enabling logging at runtime using either commons logging or log4j. This decision was further validated when there were reports of significant performance hit with logging enabled [8]. As a result, the 1.5.1 and 1.7-dev versions have logging disabled.

The POI team is working towards a 2.0 release that adds the functionality for formula, charting and Word documents. There are many feature requests that have been asked for, but these are the top priority at the moment [9].

Editor: Joe Germuska

* Path-based action mapping in 1.1
One of the architectural advances from Struts 1.0 to Struts 1.1 involved supporting multiple applications with a single Struts controller servlet. As part of the initial implementation of this functionality, some configuration flexibility was lost: the multi-application controller only supports mapping URLs to Struts "actions" by extension (i.e. "*.do") while Struts 1.0 also supported mapping by path prefix (i.e. "/do/*"). After James Young asked if any fixes were in the works [1], Craig McClanahan pointed out some of the complexities involved [2]. Ted Husted described a possible solution and asked for feedback about whether to pursue it. [3]

* Tiles add-in to moved to core
Craig McClanahan moved the "Tiles" add-in into the core CVS source tree from the "contrib" directory [4]. Ted Husted initiated a discussion about some code modifications to "Tiles" to make it work more closely with the core code base.[5]

* FormBean: Interface or Class?
The discussion about whether the "FormBean" concept was best implemented as an interface or a class resurfaced, and Craig McClanahan wrote a decisive response explaining the motivation for maintaining it as a class.[6] In summary, designing FormBean as an interface would facilitate inappropriate tangling of the "model" layer with the "view" layer, while making it a class of its own encourages clean separation of those layers.

* Struts and the Java Standard Tag Library (JSTL)
After announcing the 1.0 release of the JSTL, Shawn Bayern offered assistance towards integrating the rich Struts tag libraries with the JSTL, which in many cases offers equivalent functionality.[7] Craig McClanahan indicated that a likely goal for a post 1.1 release of Struts would be thorough integration with the JSTL expression language, and aiming towards an eventual replacement of the Struts "bean" and "logic" tag libraries with the equivalent tags from JSTL.[8]

* New Committer: James Holmes
James Holmes, author of the popular Struts Console tool, was proposed as a committer by Ted Husted [9] and was accepted unanimously.

* Steps towards Struts 1.1b2
As much of the activity on the list in June involved "swatting" bugs in the current 1.1b1 release, Craig McClanahan proposed steps towards a Struts 1.1b2 by around July 8th [10] The requirements for the next beta are basically closing any remaining bugs and improving documentation of new Struts features. Committers responded promptly with +1 votes and further contributions.

* Other Struts News:

• 24 June 2002 - Tiles Article in DeveloperWorks
• 23 June 2002 - Struts Controller UML Diagrams
• 12 June 2002 - Struts Console version 1.12.1
• 12 June 2002 - Easy Struts 0.2
• 12 June 2002 - Artimus 0.4
• 11 June 2002 - Struts Builder v0.4 beta
• 07 Jun 2002 - O'Reilly Chapter 7
• 05 Jun 2002 - Struts Console version 1.12
• 07 Jun 2002 - Easy Struts on SourceForge
• 04 Jun 2002 - FL Child Support Payments: Powered by Struts
• 03 Jun 2002 - strutsGuessingGame1.0

* Struts News and Status page: http://jakarta.apache.org/struts/news.html

Editor: Shawn Bayern

On June 21, Jakarta Taglibs released version 1.0 of the "Standard Taglib," a compliant implementation of the JSP Standard Tag Library (JSTL), which is a new specification from the Java Community Process. The Taglibs group has also begun efforts to reorganize its web site and improve the process for responding to new submissions and ideas.

Editor: Henri Gomez

The TOMCAT 5.0 proposal was launched by Remy. The goal was to design the next generation Tomcat, using the best parts of Tomcat 3.3 and 4.x, using an improved version of coyote (2.0) code as the core, and using catalina 2.0 as the servlet container. The great thing in that proposal is that members from the 2 olds teams, 3.3 and 4.x agreed on contributing and working together putting the best they learn from 3.3/4.x. There was a proposal from the Avalon team to use Avalon as core, but it was rejected by Remy, who would prefer to have something more suitable and lighter for the TOMCAT core.

Pier then ask for a Tomcat HA (High Availability), arguing that Tomcat 4.x (he didn't speak about 3.2 or 3.3) was too unstable so it couldn't use it in his production site. There was then a lengthy discussion about stability which should be a major goal and so on. Many people (tomcat-dev) reported having no problems with Tomcat 4.0 or 3.3. Note, the thread was conducted at the same times that many of us performed extensive tests on mod_jk 1.2.0 and so tested the connector with Apache 1.3/2.0 and Tomcat 3.3/4.0.4 to detect failure in the connector (or in tomcat), and it appears that there are no major problems with both 3.3/4.0.4.

As some writers commented, the stability of a web application depends on many parts, tomcat being one of them, the real java application and remote side (SQL/enterprise applications) being also mandatory.

To summarise, I could say that all of us (tomcat developpers) want to have the stablest engine possible and the thread is open.

The major goals for Apache Tomcat 5.0 are to:

• Improve scalability, reliability and performance over previous versions
• Have simpler/cleaner code, so more people can get involved
• Merge of the various ideas in 3.x and 4.x
• Get the community together
• Provide maximum modularity and compliance to the standards
• Make it easy to continue to maintain the existing codebases