Sweet! Thanks a lot! Aleksey
On Thu, Jul 04, 2002 at 08:01:39PM +0100, Rob Oxspring wrote: > Jakarta Newsletter > ================== > 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 [EMAIL PROTECTED] > > Rob Oxspring > > > > Contents > -------- > General > Ant > Avalon > Commons > Jetspeed > Log4j > Lucene > ObJectRelationalBridge > ORO > POI > Struts > Taglibs > Tomcat > > > > General > ======= > 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. > > [1] - http://marc.theaimsgroup.com/?t=102328553200005&r=1&w=2&n=21 > [2] - http://marc.theaimsgroup.com/?t=102391995300001&r=1&w=2&n=12 > [3] - http://marc.theaimsgroup.com/?t=102520044100002&r=1&w=2&n=10 > > > > Avalon > ====== > 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. > > > > Ant > === > 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]. > > [1] - http://marc.theaimsgroup.com/?t=102480404800002&r=1&w=2&n=12 > [2] - http://marc.theaimsgroup.com/?t=102480534600002&r=1&w=2&n=15 > [3] - http://marc.theaimsgroup.com/?t=102359754500002&r=1&w=2&n=19 > [4] - http://marc.theaimsgroup.com/?t=102378075700002&r=1&w=2&n=11 > [5] - http://marc.theaimsgroup.com/?t=102467096900003&r=1&w=2&n=12 > [6] - http://marc.theaimsgroup.com/?t=102478669600003&r=1&w=2&n=2 > [7] - http://marc.theaimsgroup.com/?t=102436209200002&r=1&w=2&n=17 > [8] - http://marc.theaimsgroup.com/?t=102493495300002&r=1&w=2&n=10 > [9] - http://marc.theaimsgroup.com/?t=102338712200003&r=1&w=2&n=12 > [10] - http://marc.theaimsgroup.com/?t=102459759100001&r=1&w=2&n=13 > [11] - http://marc.theaimsgroup.com/?t=102481925900001&r=1&w=2&n=13 > [12] - http://marc.theaimsgroup.com/?t=102531237400002&r=1&w=2&n=9 > > > > Commons > ======= > 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]. > > [1] - http://marc.theaimsgroup.com/?t=102451084800002&r=1&w=2&n=25 > [2] - http://marc.theaimsgroup.com/?t=102468327700006&r=1&w=2&n=99 > > 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]. > > [3] - http://marc.theaimsgroup.com/?t=102458650800005&r=1&w=2&n=25 > [4] - http://marc.theaimsgroup.com/?t=102478064000001&r=1&w=2&n=15 > [5] - http://marc.theaimsgroup.com/?t=102398907200001&r=1&w=2&n=25 > [6] - http://marc.theaimsgroup.com/?t=102477824200003&r=1&w=2&n=20 > [7] - http://marc.theaimsgroup.com/?t=102430815500002&r=1&w=2&n=20 > > 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]. > > [8] - http://marc.theaimsgroup.com/?t=102347883700003&r=1&w=2&n=22 > [9] - http://marc.theaimsgroup.com/?t=102345448200001&r=1&w=2&n=18 > [10] - http://marc.theaimsgroup.com/?t=102503642500002&r=1&w=2&n=21 > [11] - http://marc.theaimsgroup.com/?t=102504081900002&r=1&w=2&n=14 > > 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]. > > [12] - http://marc.theaimsgroup.com/?t=102402777700001&r=1&w=2&n=11 > [13] - http://marc.theaimsgroup.com/?t=102336826000003&r=1&w=2&n=17 > > 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]. > > [14] - http://marc.theaimsgroup.com/?t=102327447100004&r=1&w=2&n=10 > [15] - http://marc.theaimsgroup.com/?t=102384358400001&r=1&w=2&n=10 > [16] - http://marc.theaimsgroup.com/?t=102392973900001&r=1&w=2&n=12 > [17] - http://marc.theaimsgroup.com/?t=102400292600005&r=1&w=2&n=14 > > 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]. > > [18] - http://marc.theaimsgroup.com/?t=102423733200004&r=1&w=2&n=11 > [19] - http://marc.theaimsgroup.com/?t=102510710000006&r=1&w=2&n=11 > [20] - http://marc.theaimsgroup.com/?t=102435473700001&r=1&w=2&n=26 > [21] - http://marc.theaimsgroup.com/?t=102492741300004&r=1&w=2&n=12 > [22] - http://marc.theaimsgroup.com/?t=102461582900003&r=1&w=2&n=10 > [23] - http://marc.theaimsgroup.com/?t=102455617000003&r=1&w=2&n=19 > > > > Jetspeed > ======== > 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: > > Fix all major and critical bugs > New Pluggable Security Model, decoupled from Turbine. New Interfaces for > Authentication and Authorization services. > New Security Registry > Customizer support for Security > Portlet ids > Multiple portlet instances supported on one page > New link tool $jslink > Portlet References > Performance improvements > Profile Browser > New WebPage Portlet > Multiple Template Roots > XML Media Type support > Database Browser > Aggregate Portlet > Unit Testing > HTTP Basic Authentication in Web Page Portlet > Registry categories > Id Generator service > > > > Log4j > ===== > 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. > > [1] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102335790906496&w=2 > [2] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102336327109965&w=2 > [3] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102387540521717&w=2 > > 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. > > [4] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102209832808942&w=2 > [5] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102420694310844&w=2 > > 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. > > [6] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102326443025158&w=2 > [7] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102327620700816&w=2 > > 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. > > [8] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102412323003656&w=2 > [9] - http://qos.ch/containers/sc.html > [10] - http://marc.theaimsgroup.com/?t=102510381000001&r=1&w=2 > > Mark made a proposal [11] for a new log4j component called "Receiver." > > [11] - http://marc.theaimsgroup.com/?l=log4j-dev&m=102523926310678&w=2 > > > > Lucene > ====== > 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/webcr > awler-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/webcr > awler-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". > > > > ObJectRelationalBridge > ====================== > 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. > > [1] - > http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > ache.org&msgNo=274 > [2] - http://jakarta.apache.org/ojb/jdo/jdo-proposal.html > [3] - > http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > ache.org&msgId=382893 > > > > ORO > === > 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. > > > > POI > === > 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]. > > [1] - http://jakarta.apache.org/poi/hssf/formula.html > [2] - http://marc.theaimsgroup.com/?l=poi-dev&m=102382900822300&w=2 > [3] - http://marc.theaimsgroup.com/?l=poi-dev&m=102468743701331&w=2 > [4] - http://marc.theaimsgroup.com/?l=poi-dev&m=102371435712172&w=2 > [5] - http://jakarta.apache.org/poi/casestudies.html > [6] - http://marc.theaimsgroup.com/?l=poi-user&m=102476270711166&w=2 > [7] - http://marc.theaimsgroup.com/?t=102333893500001&r=1&w=2 > [8] - http://marc.theaimsgroup.com/?l=poi-user&m=102518419020006&w=2 > [9] - http://marc.theaimsgroup.com/?l=poi-dev&m=102500927422333&w=2 > > > > Struts > ====== > 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] > > [1] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8226 > [2] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8234 > [3] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8244 > > * 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] > > [4] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8682 > [5] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8621 > > * 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. > > [6] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8253 > > * 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] > > [7] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8434 > [8] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8439 > > * 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. > > [9] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8341 > > * 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. > > [10] - > http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pache.org&msgNo=8691 > > * 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 > > > > Taglibs > ======= > 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. > > > > Tomcat > ====== > 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 > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
