commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-commons Wiki] Update of "Logging/1.1.0ReleasePlan" by SimonKitching
Date Sat, 18 Feb 2006 11:06:23 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Logging/1%2e1%2e0ReleasePlan

The comment on the change is:
Fix spelling of Ceki Gulcu's name. Other minor fixes.

------------------------------------------------------------------------------
  
  This is an important release: JCL is very widely used in production but a combination of
new specifications and widespread failures from vendors to adhere to the Java 2 classloading
model have resulted in majors problems for the JCL 1.0.x series of releases. 
  
- Thanks to constructive criticism from Ceki Guici and new energy from new developers, changes
have been made to the discovery model used by JCL. The current codebase is now more specification
adnostic: it no longer insists on complience with the classloader models introduced in Java
1.2 and in the servlet specification. It is believed by the team that the current codebase
should solve those problems which can be solved given the deisgn approach taken by JCL.
+ Thanks to constructive criticism from Ceki Gülcü and new energy from new developers, changes
have been made to the discovery model used by JCL. The current codebase is now more specification
agnostic: it no longer insists on compliance with the classloader models introduced in Java
1.2 and in the servlet specification. It is believed by the team that the current codebase
should solve those problems which can be solved given the design approach taken by JCL.
  
  == Status ==
  
@@ -16, +16 @@

  
  Most commons components use a release that uses multiple release candidates. Once the release
is up to the technical standards required for Jakarta Commons releases, it is approved and
released.
  
- JCL 1.1.0 is an important release. Not only is JCL very widely used but the limitations
of the 1.0.x series of releases has been widely reported. It is important that the 1.1 release
not only resolves these problems but also does not introduce any new ones. It is tricky to
unit test situations invovling exotic classloaders. 
+ JCL 1.1.0 is an important release. Not only is JCL very widely used but the limitations
of the 1.0.x series of releases has been widely reported. It is important that the 1.1 release
not only resolves these problems but also does not introduce any new ones. It is also tricky
to unit test situations involving exotic classloaders, so
+ help from users of JCL is needed to verify that this new release works in unusual circumstances.
  
  I'd therefore like to propose the following additions to the process. Release candidates
will be produced as normal until one satisfies the standards required for commons releases.
At that stage, though, the release will be dubbed commons-logging-1.1-alpha1. An announcement
will be made requesting that users, developers and committers test this release. If there
are no problems then a subsequent VOTE will be held to promote this release. 
  
@@ -55, +56 @@

  == Design decisions ==
  
   * Do we remove the Servlet``Context``Cleaner?
-    1. It's obviously too controversial. Maybe the code could be put in the documentation
somewhere, or on the wiki.
+    1. It's obviously controversial. Maybe the code could be put in the documentation somewhere,
or on the wiki.
  
   * Decide whether to merge the weak-hash-map stuff into the main trunk or leave it in an
"optional" jar. If we merge it, we can do away with the optional jar completely which is good.
However it does mean that if there is a bug in it people can't disable it. If bundled in the
main jar there might need to be a little extra code to just ignore it when it throws an exception
on load for java < 1.3.
  
@@ -95, +96 @@

  of log4jlogger is deprecated and will be replaced by a logical logger
  when log4j 1.3 ships.''
  
-  * Servlet``Context``Cleaner ''this will be shipped''
+  * Servlet``Context``Cleaner 
+ 
+ ''this will be shipped''. The critical issue was that projects which repackage JCL (eg by
compiling with gcj) may not have an implementation of javax.servlet to compile against. However
the commons-logging-api.jar project now contains all the stand-alone loggers, and this should
be enough for most circumstances. Because such "repackagers" can create and distribute commons-logging-api.jar,
it has been decided that it is acceptable for the commons-logging.jar to have a compile dependency
on javax.servlet.
  
   * IoC friendly design ''postponed''
  

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message