logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: cvs commit: logging-log4j/src/java/org/apache/log4j/plugins PluginRegistry.java
Date Tue, 25 May 2004 11:39:29 GMT
At 06:45 AM 5/25/2004, psmith@apache.org wrote:
>psmith      2004/05/24 21:45:22
>   Modified:    src/java/org/apache/log4j/net SocketHubReceiver.java
>                         SocketNode.java SocketReceiver.java
>                src/java/org/apache/log4j/plugins PluginRegistry.java
>   Log:
>   [Please review this change, particularly the synchronization semantics]


Thank you very much for taking the time to apply these corrections.

I think the changes are safe. Your changes follow the recommended
pattern, as described in the java.util.Collections class:

      * Returns a synchronized (thread-safe) list backed by the specified
      * list.  In order to guarantee serial access, it is critical that
      * <strong>all</strong> access to the backing list is accomplished
      * through the returned list.<p>
      * It is imperative that the user manually synchronize on the returned
      * list when iterating over it:
      * <pre>
      *  List list = Collections.synchronizedList(new ArrayList());
      *      ...
      *  synchronized(list) {
      *      Iterator i = list.iterator(); // Must be in synchronized block
      *      while (i.hasNext())
      *          foo(i.next());
      *  }
      * </pre>
      * Failure to follow this advice may result in non-deterministic behavior.
      * <p>The returned list will be serializable if the specified list is
      * serializable.
      * @param  list the list to be "wrapped" in a synchronized list.
      * @return a synchronized view of the specified list.
     public static List synchronizedList(List list) {
         return (list instanceof RandomAccess ?
                 new SynchronizedRandomAccessList(list) :
                 new SynchronizedList(list));

>   This set of changes removes the dependancy on the EventListenerList
>   class which seems to be JDK1.3.
>   This should allow the non-chainsaw areas of log4j to be compiled under 
> JDK 1.2,
>   although I do not have this installed, and cannot verify.

The changes made a big difference in building the "build.core" target. Just 
one problem remains:

Buildfile: build.xml


    [delete] Deleting directory C:\home\cgu\ASF\logging-log4j\dist\classes
    [delete] Deleting directory C:\home\cgu\ASF\logging-log4j\examples\classes



     [mkdir] Created dir: C:\home\cgu\ASF\logging-log4j\dist\classes
     [javac] Compiling 219 source files to 
Variable active in class org.apache.log4j.plug
ins.PluginSkeleton not accessible from inner class 
org.apache.log4j.net.UDPReceiver. UDPReceiverThread.
     [javac]       active = true;
     [javac]       ^
     [javac] 1 error


I think the problem is related to the different ways in which JDK 1.2 and 
JDK 1.3+ view access rights of inner classes. In any case, the problem is 
related to the Plugin.isActive issue. I'll look into this more closely.

There is another problem with the code I added just a few hours ago. The 
Statement.getGeneratedKeys was introduced in JDBC API version 3.0 which is 
bundled with JDK 1.4. I have not found a way to obtain JDBC 3.0 API 
separately from JDK 1.4. Bummer.

     [javac] Compiling 9 source files to 

Reference to variable supportsGetGe
neratedKeys in interface java.sql.DatabaseMetaData as if it were a method.
     [javac]       supportsGetGeneratedKeys = meta.supportsGetGeneratedKeys();
     [javac]                                                               ^

Reference to variable supportsGet
GeneratedKeys in interface java.sql.DatabaseMetaData as if it were a method.
     [javac]           supportsGetGeneratedKeys 
=   meta.supportsGetGeneratedKeys();
Method getGeneratedKeys() not found in interface
     [javac]           rs = insertStatement.getGeneratedKeys();
     [javac]                                                ^
     [javac] 3 errors


>   All the test cases (bar the Scheduler one, but I don't believe
>   that is related to this change) pass after this change.

No it is not related. The SchedulerTest is very sensitive. If your machines 
is a bit slow or busy the test tends to fail. I just changed it to be a bit 
more lenient. It should work now.

Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  

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

View raw message