Re: cvs commit: logging-log4j/src/java/org/apache/log4j/plugins PluginRegistry.java

[Ceki Gülcü <ce...@qos.ch>]

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]

Paul,

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

init:

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

init:

jndiCheck:

build.core:
     [mkdir] Created dir: C:\home\cgu\ASF\logging-log4j\dist\classes
     [javac] Compiling 219 source files to 
C:\home\cgu\ASF\logging-log4j\dist\classes
     [javac] 
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\net\UDPReceiver.java:210: 
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

BUILD FAILED


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.

build.db:
     [javac] Compiling 9 source files to 
C:\home\cgu\ASF\logging-log4j\dist\classes
     [javac] 
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\db\ConnectionSourceSkeleton.java:52: 
Reference to variable supportsGetGe
neratedKeys in interface java.sql.DatabaseMetaData as if it were a method.
     [javac]       supportsGetGeneratedKeys = meta.supportsGetGeneratedKeys();
     [javac]                                                               ^
     [javac] 
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\db\DataSourceConnectionSource.java:61: 
Reference to variable supportsGet
GeneratedKeys in interface java.sql.DatabaseMetaData as if it were a method.
     [javac]           supportsGetGeneratedKeys 
=   meta.supportsGetGeneratedKeys();
     [javac] 
^
     [javac] 
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\db\DBAppender.java:166: 
Method getGeneratedKeys() not found in interface
  java.sql.PreparedStatement.
     [javac]           rs = insertStatement.getGeneratedKeys();
     [javac]                                                ^
     [javac] 3 errors

BUILD FAILED

>
>   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