You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announcements@jakarta.apache.org by Rob Oxspring <ro...@imapmail.org> on 2002/07/04 21:01:39 UTC
Jakarta Newsletter - June 2002
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 general@jakarta.apache.org.
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?listName=ojb-dev@jakarta.ap
ache.org&msgNo=274
[2] - http://jakarta.apache.org/ojb/jdo/jdo-proposal.html
[3] -
http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@jakarta.ap
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?listName=struts-dev@jakarta.a
pache.org&msgNo=8226
[2] -
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.a
pache.org&msgNo=8234
[3] -
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.a
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?listName=struts-dev@jakarta.a
pache.org&msgNo=8682
[5] -
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.a
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?listName=struts-dev@jakarta.a
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?listName=struts-dev@jakarta.a
pache.org&msgNo=8434
[8] -
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.a
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?listName=struts-dev@jakarta.a
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?listName=struts-dev@jakarta.a
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Newsletter - June 2002
Posted by Jason Hunter <jh...@acm.org>.
Hi Rob and everyone,
Thanks for putting this together. It's going to be very helpful for
those of us working in the JCP to keep track of what's happening within
Jakarta.
-jh-
Rob Oxspring wrote:
>
> Jakarta Newsletter
> ==================
> Issue: 1
> Date: June 2002
> Url: http://jakarta.apache.org/site/news/200206.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Newsletter - June 2002
Posted by Aleksey Tsalolikhin <at...@earthlink.net>.
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 general@jakarta.apache.org.
>
> 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?listName=ojb-dev@jakarta.ap
> ache.org&msgNo=274
> [2] - http://jakarta.apache.org/ojb/jdo/jdo-proposal.html
> [3] -
> http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@jakarta.ap
> 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?listName=struts-dev@jakarta.a
> pache.org&msgNo=8226
> [2] -
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.a
> pache.org&msgNo=8234
> [3] -
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.a
> 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?listName=struts-dev@jakarta.a
> pache.org&msgNo=8682
> [5] -
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.a
> 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?listName=struts-dev@jakarta.a
> 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?listName=struts-dev@jakarta.a
> pache.org&msgNo=8434
> [8] -
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.a
> 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?listName=struts-dev@jakarta.a
> 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?listName=struts-dev@jakarta.a
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] RE: Jakarta Newsletter - June 2002
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 4 Jul 2002, Rob Oxspring <ro...@imapmail.org> wrote:
> Any chance of applying the patch to bring the online copy in line
> with the one that went out?
Done
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] RE: Jakarta Newsletter - June 2002
Posted by Rob Oxspring <ro...@imapmail.org>.
Any chance of applying the patch to bring the online copy in line with
the one that went out?
Cheers,
Rob
> -----Original Message-----
> From: Rob Oxspring [mailto:roxspring@imapmail.org]
> Sent: 4 July 2002 20:02
> To: announcements@jakarta.apache.org
> Subject: Jakarta Newsletter - June 2002
>
>
> Jakarta Newsletter
> ==================
> Issue: 1
> Date: June 2002
> Url: http://jakarta.apache.org/site/news/200206.html
>
<snip/>