You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gülcü <no...@qos.ch> on 2004/05/21 12:48:33 UTC
JDK 1.2 Compilation problems
Hi again,
Compiling log4j under JDK 1.2 results remarkably few erros:
build.core:
[javac] Compiling 7 source files to
C:\home\cgu\ASF\logging-log4j\dist\classes
[javac]
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\net\SocketHubReceiver.java:222:
Method getListeners(java.lang.Class) not
found in class javax.swing.event.EventListenerList.
[javac] (SocketNodeEventListener[]) listenerList.getListeners(
[javac] ^
[javac]
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\net\SocketNode.java:201:
Method getListeners(java.lang.Class) not found
in class javax.swing.event.EventListenerList.
[javac] listenerList.getListeners(SocketNodeEventListener.class);
[javac] ^
[javac]
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\net\SocketNode.java:218:
Method getListeners(java.lang.Class) not found
in class javax.swing.event.EventListenerList.
[javac] listenerList.getListeners(SocketNodeEventListener.class);
[javac] ^
[javac]
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\net\SocketReceiver.java:228:
Method getListeners(java.lang.Class) not fo
und in class javax.swing.event.EventListenerList.
[javac] (SocketNodeEventListener[]) listenerList.getListeners(
[javac] ^
[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]
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\plugins\PluginRegistry.java:111:
Method getListeners(java.lang.Class) no
t found in class javax.swing.event.EventListenerList.
[javac] PluginListener[] listeners =
(PluginListener[])listenerList.getListeners(PluginListener.class);
[javac]
^
[javac]
C:\home\cgu\ASF\logging-log4j\src\java\org\apache\log4j\plugins\PluginRegistry.java:131:
Method getListeners(java.lang.Class) no
t found in class javax.swing.event.EventListenerList.
[javac] PluginListener[] listeners =
(PluginListener[])listenerList.getListeners(PluginListener.class);
[javac]
^
[javac] 7 errors
These errors are due to the usage of
javax.swing.event.EventListenerList. I think we could easily replace
this class. Paul, what is your take on the matter?
Other errors included the usage of the javax.rmi.PortableRemoteObject
class which is not part of JDK 1.2. This problem affects only the
o.a.l.db.JNDIConnectionSource class.
In o.a.l.xml, the XMLDecoder failed to compile because it uses
Collections.EMPTY_MAP to initialize the additionalProperties field. I
changed it to
private Map additionalProperties = new HashMap();
As for chainsaw, it generated a long list of errors. We should perhaps
assume JDK 1.3 or later for Chainsaw?
--
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
Re: JDK 1.2 Compilation problems
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:39 PM 5/23/2004, Raymond DeCampo wrote:
>Ceki,
>
>Using PortableRemoteObject.narrow() is considered the best practice to
>ensure interoperability with CORBA and RMI over IIOP.
>
>Most of the references I've found so far focus on the need to use it in
>EJB clients.
>
>At this point I'm not certain if it is necessary in this case (where EJBs
>are not involved). The most likely usage scenario for this class will be
>a J2EE component that is in the same JVM as the JNDI provider. It should
>not be needed in that case. It may be needed when the client is external
>to the JNDI provider although I suspect that it is probably not needed
>when everybody is in a Java environment.
>
>Perhaps the simplest solution will be to remove the use of
>PortableRemoteObject.narrow() and make a note in the documentation that
>the class does not use PortableRemoteObject.narrow() when casting the
>object from JNDI. Then we can deal with issues if they come up.
That's sounds wise. I'll add this to the Javadocs of JNDIConnectionSource.
Otherwise, have you looked at the DBAppender/DBReceiver pair? (I am about
to commit a new version which uses an event buffer and batched updates
which have a very significant impact on performance, upto i.e. 40 (forty)
fold improvement (x40 = 4000%).
>Ray
--
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
Re: JDK 1.2 Compilation problems
Posted by Raymond DeCampo <rd...@twcny.rr.com>.
Ceki Gülcü wrote:
> At 11:46 PM 5/21/2004, Raymond DeCampo wrote:
>
>> Ceki Gülcü wrote:
>>
>>> Other errors included the usage of the javax.rmi.PortableRemoteObject
>>> class which is not part of JDK 1.2. This problem affects only the
>>> o.a.l.db.JNDIConnectionSource class.
>>
>>
>> Ceki,
>>
>> The PortableRemoteObject class should be available in J2EE
>> distributions or RMI/JNDI distributions. We can include one of these
>> for compilation purposes. It should not be necessary to include it in
>> the binary distribution, as anyone using the JNDIConnectionSource
>> class would get this class from their JNDI provider libraries.
>>
>> Please let me know if you need any assistance on this issue.
>
>
> Thank you very much for responding to this. I was hoping you would comment.
>
> Do you have any example of where the current JNDI lookup for the
> datasource would not succeed without a call to
> PortableRemoteObject.narrow? Note that the JMSAppender also uses JNDI
> lookup without ever calling PortableRemoteObject.narrow ant this was
> never reported as a problem by our users.
>
> I am missing something?
>
Ceki,
Using PortableRemoteObject.narrow() is considered the best practice to
ensure interoperability with CORBA and RMI over IIOP.
Most of the references I've found so far focus on the need to use it in
EJB clients.
At this point I'm not certain if it is necessary in this case (where
EJBs are not involved). The most likely usage scenario for this class
will be a J2EE component that is in the same JVM as the JNDI provider.
It should not be needed in that case. It may be needed when the client
is external to the JNDI provider although I suspect that it is probably
not needed when everybody is in a Java environment.
Perhaps the simplest solution will be to remove the use of
PortableRemoteObject.narrow() and make a note in the documentation that
the class does not use PortableRemoteObject.narrow() when casting the
object from JNDI. Then we can deal with issues if they come up.
Ray
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: JDK 1.2 Compilation problems
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:46 PM 5/21/2004, Raymond DeCampo wrote:
>Ceki Gülcü wrote:
>>Other errors included the usage of the javax.rmi.PortableRemoteObject
>>class which is not part of JDK 1.2. This problem affects only the
>>o.a.l.db.JNDIConnectionSource class.
>
>Ceki,
>
>The PortableRemoteObject class should be available in J2EE distributions
>or RMI/JNDI distributions. We can include one of these for compilation
>purposes. It should not be necessary to include it in the binary
>distribution, as anyone using the JNDIConnectionSource class would get
>this class from their JNDI provider libraries.
>
>Please let me know if you need any assistance on this issue.
Thank you very much for responding to this. I was hoping you would comment.
Do you have any example of where the current JNDI lookup for the datasource
would not succeed without a call to PortableRemoteObject.narrow? Note that
the JMSAppender also uses JNDI lookup without ever calling
PortableRemoteObject.narrow ant this was never reported as a problem by our
users.
I am missing something?
>Thanks,
>Ray
--
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
Re: JDK 1.2 Compilation problems
Posted by Raymond DeCampo <rd...@twcny.rr.com>.
Ceki Gülcü wrote:
>
> Other errors included the usage of the javax.rmi.PortableRemoteObject
> class which is not part of JDK 1.2. This problem affects only the
> o.a.l.db.JNDIConnectionSource class.
>
Ceki,
The PortableRemoteObject class should be available in J2EE distributions
or RMI/JNDI distributions. We can include one of these for compilation
purposes. It should not be necessary to include it in the binary
distribution, as anyone using the JNDIConnectionSource class would get
this class from their JNDI provider libraries.
Please let me know if you need any assistance on this issue.
Thanks,
Ray
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org