Support Ex-Jakarta |
Issue: 7
The month has been quite busy for apache folks, with new apache projects, new jakarta subprojects and talk of even more. In case you're getting concerned that its all talk here, at least Lucene, Ant and HttpClient are expecting releases in the near future. As always, I want 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
" Ideas, suggestions, and comments on the overall Jakarta project " Editor: Rob Oxspring Robert Simmons kicked of a debate over the use of forum software to make it easier for users to get involved with jakarta subprojects [1,2]. The Jakarta developers seemed united in preferring mailing lists and pointed out archives [3] and services such as gmane [4] for more casual use of the lists. The Pluto subproject was proposed as a reference implementation of the Portlet API and was heavily discussed [5]. Relating to the portals theme, Charon was propsed ro implement the Web Services for Remote specification, although this recieved only a little discussion [6,7]. Dani Estermann asked for some advice on choosing a logging stratergy for future code. Some advocated using the JDK logging if Java 1.4 was guarenteed, others recommended using Log4j whatever the situation. It was also suggested that the use of a facade such as commons-logging should be limitted to situations where chioce is needed. Browse the archive for further detail [8]. Is it time for a new look Jakarta? Maybe a unified Apache site look and feel? Christoph Wilhelms suggested the use of his FakeForrest skin to give Jakarta a facelift [9]. This offers a Forrest[10] look a like and could act as a stepping stone towards the eventual use of forrest for the websites. Finally, several people have been elected as new members of the Jakarta PMC [11], they are:
Due to the diverse nature of the commons group, this section has been split up to make it easier to pick out the topics of interest. This months stories come from the following:
"definitive implementations of common encodings" Editor: Tim O'brien The codec project is alive again, and moving towards a release. Codec's short-term goals include: moving towards definitive implementations of common encodings such as Base64 and Hex, and developing a cohesive framework for expansion. "HttpClient provides client side HTTP 1.0/1.1 connectivity to any Java component" Editor: Jeffrey Dever Release 2.0 Alpha 2! After many months and a great resurgence of developers, the new build of HttpClient is finally here. The new group of developers has done extensive refactoring to move the project along the new vision. The code base has reached a significant level of maturity and we expect that another released build (possibly a beta) will be ready near the end of February Also check out the new HttpClient logo on the website created by Jeff Dever with the Gimp!
" Database Software Editior: Martin Poeschl The DB project was created to allow the collection of similar technologies into one larger subcommunity. The following jakarta projects moved to the db project
" a fast and flexible framework for logging application debugging messages " Editor: Mark Womack This month's edition contains items from December and January. Initial implementations of Plugin, PluginRegistry, and Receivers were checked in for review [1]. Plugins will be part of the log4j v1.3 release. They allow developers to add functionality to log4j on a per LoggerRepository basis and are fully configurable via log4j configuration files. Receivers are an implementation of Plugin that will "post" remote logging events to the LoggerRepository the receiver is configured for. There was a brief discussion started by Scott Klein about a new gui tool for viewing log4j logging events that cascaded into a discussion of possibly creating a viewer that combines the best aspects of the current log4j gui viewers, Chainsaw and LF5. This led to an informal decision to package Chainsaw and LF5 in their own executable jars, separately from the core log4j jar, for v1.3. [2] Jay Funnell contributed the NetSendAppender[3]. This appender uses the Windows "NET SEND" command to transport log messages. A new servlet package was added to contain log4j related classes that can be used within web applications. It contains a useful set of classes, and is expected to grow with future contributions. Initial contributions are: InitServlet, InitContextListener (both from Jacob Kjome) [4], ConfigurationServlet (Luther Birdzell) [5], and CookieMDCFilter [6]. A new selector package was added to contain implementations of the log4j RepositorySelector interface [7]. The RepositorySelector is a powerful device that allows for LoggerRepositories to be separated from each other, each maintaining their own space. The selector can be implemented to choose the active repository based on a specific criteria. An initial contribution from Jacob Kjome, ContextClassLoaderSelector [8], chooses the repository based on the context class loader and is compatible for use in Tomcat 4.1.X. Like other Apache projects, wiki pages for the log4j project have been started, and are coming along nicely [9]. It was decided to created a log4j-sandbox cvs repository [10]. This cvs will contain new, experimental, and contributed log4j related code. Once proven, the classes will be considered for inclusion in the core log4j release. Initial candidates for filling the sandbox are the filter, selector, and servlet packages. log4jMini, a compact version of log4j, was added to the log4j cvs [11]. The current version is out of sync with the changes in v1.2 and now that it is in cvs, developers can submit changes to make it v1.2 compatible [12]. Changes are planned for v1.3 release related to better memory efficiency within several log4j classes [13]. Creating a top level Apache project, logging.apache.org, is being explored [14]. The goal of this top level project would be to bring all of the log4X related logging frameworks under the ASF umbrella. Another major goal would be to implement cross-language/cross-platform logging within each of these frameworks. There was also some interesting discussion about the current state of log4j and how the logging.apache.org project would affect it [15].
" A high-performance, full-featured text search engine " Editor: Otis Gospodnetic This month's notes come straight from Lucene's CHANGES.txt file. In addition to that I'll only mention that the Lucene team is preparing for packaging the first release candidate for the 1.3 release. a. Queries are no longer modified during a search. This makes it possible, e.g., to reuse the same query instance with multiple indexes from multiple threads. b. Term-expanding queries (e.g. PrefixQuery, WildcardQuery, etc.) now work correctly with MultiSearcher, fixing bugs 12619 and 12667. c. Boosting BooleanQuery's now works, and is supported by the query parser (problem reported by Lee Mallabone). Thus a query like "(+foo +bar)^2 +baz" is now supported and equivalent to "(+foo^2 +bar^2) +baz". d. New method: Query.rewrite(IndexReader). This permits a query to re-write itself as an alternate, more primitive query. Most of the term-expanding query classes (PrefixQuery, WildcardQuery, etc.) are now implemented using this method. e. New method: Searchable.explain(Query q, int doc). This returns an Explanation instance that describes how a particular document is scored against a query. An explanation can be displayed as either plain text, with the toString() method, or as HTML, with the toHtml() method. Note that computing an explanation is as expensive as executing the query over the entire index. This is intended to be used in developing Similarity implementations, and, for good performance, should not be displayed with every hit. f. Scorer and Weight are public, not package protected. It now possible for someone to write a Scorer implementation that is not in the org.apache.lucene.search package. This is still fairly advanced programming, and I don't expect anyone to do this anytime soon, but at least now it is possible. g. Added public accessors to the primitive query classes (TermQuery, PhraseQuery and BooleanQuery), permitting access to their terms and clauses.
"APIs for manipulating various file formats based upon Microsoft's OLE 2 Compound Document format" Editor: Glen Stampoultzis Rainer completed the HPSF documentation. It now includes general property set streams. Carey Sublette let us know about an issue surrounding incompatibilities between how Excel processes unicode. Even though unicode is the standard according to the Excel97 Developers kit it seems that Excel sometimes allows invalid characters from the Cp1252 codepage. He plans on submitting a patch. Jason Height has been trying to implement the DBCell and Index records. Andy wrote up some details on how to refactor and complete the formula parsing [1]. Patch for custom formula palette's added by Brian Sanders Gump build has made a positive build of Jakarta POI using the latest release of Centipede Performance branch made and committed by Andy. This reduces memory dramatically and increases execution speed but still has a few things to be ironed out before a merge occurs back to the trunk.
|
About Jakarta About Apache
Retired Subprojects |
|
||