Re: [cp-patches] FYI: make peer libraries versionless
Hi, Mark Wielaard wrote: Hi Tom, On Fri, 2006-07-28 at 19:41 -0400, Thomas Fitzsimmons wrote: I committed this patch to make the peer libraries versionless. This is good practice for dlopen'd libraries. In the case of libjawt.so which is meant to be linked to, making it versionless gives it the SONAME of libjawt.so, which makes it binary compatible with Sun's library. 2006-07-28 Thomas Fitzsimmons [EMAIL PROTECTED] * native/jawt/Makefile.am (libjawt_la_LDFLAGS): Add -avoid-version. * native/jni/gtk-peer/Makefile.am (libgtkpeer_la_LDFLAGS): Likewise. * native/jni/midi-alsa/Makefile.am (libgjsmalsa_la_LDFLAGS): Likewise. * native/jni/midi-dssi/Makefile.am (libgjsmdssi_la_LDFLAGS): Likewise. There was no patch attached (done so now). Also, would you recommend this for the release branch? Yes, along with this one: 2006-07-31 Thomas Fitzsimmons [EMAIL PROTECTED] * native/jni/qt-peer/Makefile.am (libqtpeer_la_LDFLAGS): Add -avoid-version. Tom Index: native/jni/qt-peer/Makefile.am === RCS file: /sources/classpath/classpath/native/jni/qt-peer/Makefile.am,v retrieving revision 1.6 diff -u -r1.6 Makefile.am --- native/jni/qt-peer/Makefile.am 10 Mar 2006 01:36:10 - 1.6 +++ native/jni/qt-peer/Makefile.am 31 Jul 2006 13:49:16 - @@ -72,6 +72,7 @@ qtwindowpeer.cpp \ slotcallbacks.cpp \ slotcallbacks.h +libqtpeer_la_LDFLAGS = -avoid-version BUILT_SOURCES = $(libqtpeer_la_MOC)
Re: [cp-patches] Patch: FYI: minor zip changes
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark I see you have recently closed that PR. But while merging classpath with Mark libgcj I noticed the InflaterInputStream.java is still different in both Mark classpath trees (strangely enough libgcj doesn't use an override, but Mark has an actual change under the libjava/classpath/ tree). Do you know Mark which version we should be using now? Sorry for the mess. I believe the Classpath version ought to work ok now. But, I am not completely certain :-( Tom
Re: [cp-patches] RFC: StrictMath helper methods fixed
Carsten == Carsten Neumann [EMAIL PROTECTED] writes: Carsten this patch changes the helper methods to deal with the IEEE Carsten representation of doubles I introduced with a previous patch Carsten Ok for head ? Looks reasonable to me. At this point I would venture to guess that you know more about your StrictMath additions than anybody else... Tom
[cp-patches] RFC: StrictMath.sinh implemented
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
added another method to StrictMath, the mauve tests for this one are
already in.
Comments or approval, appreciated.
Thanks,
Carsten
2006-07-31 Carsten Neumann [EMAIL PROTECTED]
* java/lang/StrictMath.java (sinh): New method.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEzk52d4NEZjs4PvgRAnYNAJ9uanGxdCF0iBwIffqtwn5M9Zu54ACfUZCk
5B2fCIfyr6z1muxsprBGtUU=
=LVCX
-END PGP SIGNATURE-
Index: cp/classpath/java/lang/StrictMath.java
===
--- cp.orig/classpath/java/lang/StrictMath.java 2006-07-29 14:23:04.0 +0200
+++ cp/classpath/java/lang/StrictMath.java 2006-07-31 19:28:31.0 +0200
@@ -633,6 +633,94 @@
}
/**
+ * Returns the hyperbolic sine of codex/code which is defined as
+ * (exp(x) - exp(-x)) / 2.
+ *
+ * Special cases:
+ * ul
+ * liIf the argument is NaN, the result is NaN/li
+ * liIf the argument is positive infinity, the result is positive
+ * infinity./li
+ * liIf the argument is negative infinity, the result is negative
+ * infinity./li
+ * liIf the argument is zero, the result is zero./li
+ * /ul
+ *
+ * @param x the argument to emsinh/em
+ * @return the hyperbolic sine of codex/code
+ *
+ * @since 1.5
+ */
+ public static double sinh(double x)
+ {
+// Method :
+// mathematically sinh(x) if defined to be (exp(x)-exp(-x))/2
+// 1. Replace x by |x| (sinh(-x) = -sinh(x)).
+// 2.
+// E + E/(E+1)
+// 0 = x = 22 : sinh(x) := --, E=expm1(x)
+// 2
+//
+// 22 = x = lnovft : sinh(x) := exp(x)/2
+// lnovft = x = ln2ovft: sinh(x) := exp(x/2)/2 * exp(x/2)
+// ln2ovftx : sinh(x) := +inf (overflow)
+
+double t, w, h;
+
+long bits;
+long h_bits;
+long l_bits;
+
+// handle special cases
+if (x != x)
+ return Double.NaN;
+if (x == Double.POSITIVE_INFINITY)
+ return Double.POSITIVE_INFINITY;
+if (x == Double.NEGATIVE_INFINITY)
+ return Double.NEGATIVE_INFINITY;
+
+if (x 0)
+ h = - 0.5;
+else
+ h = 0.5;
+
+bits = Double.doubleToLongBits(x);
+h_bits = getHighDWord(bits) 0x7fffL; // ignore sign
+l_bits = getLowDWord(bits);
+
+// |x| in [0, 22], return sign(x) * 0.5 * (E+E/(E+1))
+if (h_bits 0x4036L) // |x| 22
+ {
+ if (h_bits 0x3e30L) // |x| 2^-28
+ return x;// for tiny arguments return x
+
+ t = expm1(abs(x));
+
+ if (h_bits 0x3ff0L)
+ return h * (2.0 * t - t * t / (t + 1.0));
+
+ return h * (t + t / (t + 1.0));
+ }
+
+// |x| in [22, log(Double.MAX_VALUE)], return 0.5 * exp(|x|)
+if (h_bits 0x40862e42L)
+ return h * exp(abs(x));
+
+// |x| in [log(Double.MAX_VALUE), overflowthreshold]
+if ((h_bits 0x408633ceL)
+ || ((h_bits == 0x408633ceL) (l_bits = 0x8fb9f87dL)))
+ {
+ w = exp(0.5 * abs(x));
+ t = h * w;
+
+ return t * w;
+ }
+
+// |x| overflowthershold
+return h * Double.POSITIVE_INFINITY;
+ }
+
+ /**
* Returns the hyperbolic cosine of codex/code, which is defined as
* (exp(x) + exp(-x)) / 2.
*
Re: [cp-patches] Patch: RFC: add javah tool
On Jul 27, 2006, at 3:10 PM, Tom Tromey wrote: This tool uses the ASM library. I added a new configure option for this, point --with-asm to the all jar and javah will be built. Otherwise it won't be. I disabled javah in the Eclipse-based build (something we should discuss -- maybe we should assume the user will download Escher and ASM?). Maybe we should include our own version of ASM (with the package name changed)? Since javah is a crucial program, avoiding an external dependency for it, and ensuring that it is always built, is much more friendly. PGP.sig Description: This is a digitally signed message part
Re: [cp-patches] Patch: RFC: add javah tool
Raif == Raif S Naffah [EMAIL PROTECTED] writes: Raif indeed. but it would be nice to keep the Eclipse related files Raif (.classpath, and .externalToolBuilders files) common to most, if Raif not all, hackers using Eclipse. I completely agree. For now we achieve that by disabling the optional parts of the build -- not the best way, but it does avoid other problems. Raif one way to do this would be to include the dependent jars (those Raif coming from 3rd-party projects) in a project folder --say Raif external-jars. I think checking in jars is even more problematic for the FSF than simply importing the sources. Tom
[cp-testresults] FAIL: cacao build on Mon Jul 31 18:20:05 UTC 2006
(cd .libs rm -f libnativevm.la ln -s ../libnativevm.la libnativevm.la) make[4]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/native/vm' make[4]: Entering directory `/home/cpdev/Nightly/cacao/build/src/native' if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../cacao/src/native -I../.. -I../../../cacao/src -I../../../cacao/src/vm/jit/i386 -I../../../cacao/src/vm/jit/i386/linux -I../../src -D__I386__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_REENTRANT -O0 -g3 -MT jni.lo -MD -MP -MF .deps/jni.Tpo -c -o jni.lo ../../../cacao/src/native/jni.c; \ then mv -f .deps/jni.Tpo .deps/jni.Plo; else rm -f .deps/jni.Tpo; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I../../../cacao/src/native -I../.. -I../../../cacao/src -I../../../cacao/src/vm/jit/i386 -I../../../cacao/src/vm/jit/i386/linux -I../../src -D__I386__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_REENTRANT -O0 -g3 -MT jni.lo -MD -MP -MF .deps/jni.Tpo -c ../../../cacao/src/native/jni.c -fPIC -DPIC -o .libs/jni.o if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../cacao/src/native -I../.. -I../../../cacao/src -I../../../cacao/src/vm/jit/i386 -I../../../cacao/src/vm/jit/i386/linux -I../../src -D__I386__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_REENTRANT -O0 -g3 -MT native.lo -MD -MP -MF .deps/native.Tpo -c -o native.lo ../../../cacao/src/native/native.c; \ then mv -f .deps/native.Tpo .deps/native.Plo; else rm -f .deps/native.Tpo; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I../../../cacao/src/native -I../.. -I../../../cacao/src -I../../../cacao/src/vm/jit/i386 -I../../../cacao/src/vm/jit/i386/linux -I../../src -D__I386__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_REENTRANT -O0 -g3 -MT native.lo -MD -MP -MF .deps/native.Tpo -c ../../../cacao/src/native/native.c -fPIC -DPIC -o .libs/native.o ../../../cacao/src/native/native.c:86:78: error: native/include/gnu_java_lang_management_VMClassLoadingMXBeanImpl.h: No such file or directory ../../../cacao/src/native/native.c:87:72: error: native/include/gnu_java_lang_management_VMMemoryMXBeanImpl.h: No such file or directory ../../../cacao/src/native/native.c:145: error: 'Java_gnu_java_lang_management_VMClassLoadingMXBeanImpl_getLoadedClassCount' undeclared here (not in a function) ../../../cacao/src/native/native.c:146: error: 'Java_gnu_java_lang_management_VMClassLoadingMXBeanImpl_getUnloadedClassCount' undeclared here (not in a function) ../../../cacao/src/native/native.c:147: error: 'Java_gnu_java_lang_management_VMClassLoadingMXBeanImpl_isVerbose' undeclared here (not in a function) ../../../cacao/src/native/native.c:148: error: 'Java_gnu_java_lang_management_VMClassLoadingMXBeanImpl_setVerbose' undeclared here (not in a function) ../../../cacao/src/native/native.c:150: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_getHeapMemoryUsage' undeclared here (not in a function) ../../../cacao/src/native/native.c:151: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_getNonHeapMemoryUsage' undeclared here (not in a function) ../../../cacao/src/native/native.c:152: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_getObjectPendingFinalizationCount' undeclared here (not in a function) ../../../cacao/src/native/native.c:153: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_isVerbose' undeclared here (not in a function) ../../../cacao/src/native/native.c:154: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_setVerbose' undeclared here (not in a function) make[4]: *** [native.lo] Error 1 make[4]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/native' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/native' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cpdev/Nightly/cacao/build/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cpdev/Nightly/cacao/build' make: *** [all] Error 2 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: cacao build on Tue Aug 1 00:24:00 UTC 2006
then mv -f .deps/jni.Tpo .deps/jni.Plo; else rm -f .deps/jni.Tpo; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I../../../cacao/src/native -I../.. -I../../../cacao/src -I../../../cacao/src/vm/jit/i386 -I../../../cacao/src/vm/jit/i386/linux -I../../src -D__I386__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_REENTRANT -O0 -g3 -MT jni.lo -MD -MP -MF .deps/jni.Tpo -c ../../../cacao/src/native/jni.c -fPIC -DPIC -o .libs/jni.o if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../cacao/src/native -I../.. -I../../../cacao/src -I../../../cacao/src/vm/jit/i386 -I../../../cacao/src/vm/jit/i386/linux -I../../src -D__I386__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_REENTRANT -O0 -g3 -MT native.lo -MD -MP -MF .deps/native.Tpo -c -o native.lo ../../../cacao/src/native/native.c; \ then mv -f .deps/native.Tpo .deps/native.Plo; else rm -f .deps/native.Tpo; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I../../../cacao/src/native -I../.. -I../../../cacao/src -I../../../cacao/src/vm/jit/i386 -I../../../cacao/src/vm/jit/i386/linux -I../../src -D__I386__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_REENTRANT -O0 -g3 -MT native.lo -MD -MP -MF .deps/native.Tpo -c ../../../cacao/src/native/native.c -fPIC -DPIC -o .libs/native.o ../../../cacao/src/native/native.c:86:78: error: native/include/gnu_java_lang_management_VMClassLoadingMXBeanImpl.h: No such file or directory ../../../cacao/src/native/native.c:87:72: error: native/include/gnu_java_lang_management_VMMemoryMXBeanImpl.h: No such file or directory ../../../cacao/src/native/native.c:99:69: error: native/include/java_lang_management_VMManagementFactory.h: No such file or directory ../../../cacao/src/native/native.c:146: error: 'Java_gnu_java_lang_management_VMClassLoadingMXBeanImpl_getLoadedClassCount' undeclared here (not in a function) ../../../cacao/src/native/native.c:147: error: 'Java_gnu_java_lang_management_VMClassLoadingMXBeanImpl_getUnloadedClassCount' undeclared here (not in a function) ../../../cacao/src/native/native.c:148: error: 'Java_gnu_java_lang_management_VMClassLoadingMXBeanImpl_isVerbose' undeclared here (not in a function) ../../../cacao/src/native/native.c:149: error: 'Java_gnu_java_lang_management_VMClassLoadingMXBeanImpl_setVerbose' undeclared here (not in a function) ../../../cacao/src/native/native.c:151: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_getHeapMemoryUsage' undeclared here (not in a function) ../../../cacao/src/native/native.c:152: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_getNonHeapMemoryUsage' undeclared here (not in a function) ../../../cacao/src/native/native.c:153: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_getObjectPendingFinalizationCount' undeclared here (not in a function) ../../../cacao/src/native/native.c:154: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_isVerbose' undeclared here (not in a function) ../../../cacao/src/native/native.c:155: error: 'Java_gnu_java_lang_management_VMMemoryMXBeanImpl_setVerbose' undeclared here (not in a function) ../../../cacao/src/native/native.c:226: error: 'Java_java_lang_management_VMManagementFactory_getMemoryPoolNames' undeclared here (not in a function) ../../../cacao/src/native/native.c:227: error: 'Java_java_lang_management_VMManagementFactory_getMemoryManagerNames' undeclared here (not in a function) ../../../cacao/src/native/native.c:228: error: 'Java_java_lang_management_VMManagementFactory_getGarbageCollectorNames' undeclared here (not in a function) make[4]: *** [native.lo] Error 1 make[4]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/native' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/native' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cpdev/Nightly/cacao/build/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cpdev/Nightly/cacao/build' make: *** [all] Error 2 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-jamvm on Tue Aug 1 01:58:47 UTC 2006
Baseline from: Sat Jul 29 05:41:45 UTC 2006 Regressions: FAIL: java.awt.Choice.getSelected FAIL: javax.swing.JComboBox.ComboRobot Improvements: PASS: gnu.java.security.jce.TestOfKeyFactory PASS: gnu.java.security.jce.TestOfKeyPairGenerator PASS: gnu.java.security.jce.TestOfProvider PASS: gnu.javax.crypto.jce.TestOfPR27853 New fails: FAIL: java.lang.StrictMath.sinh FAIL: javax.net.ssl.SSLEngine.TestHandshake FAIL: javax.net.ssl.SSLEngine.TestNoCiphersuites FAIL: javax.net.ssl.SSLEngine.TestNoProtocols Totals: PASS: 2698 XPASS: 0 FAIL: 189 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
jboss-4.0.4
Hi! Today I was trying again JBoss-4.0.4 and it runs much better than the last time. This DB problem is gone (mark, can you remember?), maybe because a shutdown does not crash anymore, and it does not shutdown itself anymore after running a few minutes. And even the startup time is faster with CACAO than Sun 1.5 (on x86_64): Sun: 12:59:21,259 INFO [Server] JBoss (MX MicroKernel) [4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)] Started in 31s:847ms CACAO: 13:00:10,791 INFO [Server] JBoss (MX MicroKernel) [4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)] Started in 20s:144ms But after 2 minutes running I get this exception, every 5 seconds: 13:02:10,416 WARN [URLDeploymentScanner] Scan URL, caught java.io.IOException: Could not list directory '/home/twisti/src/cacao/jboss/jboss-4.0.4.GA/server/default/deploy', reason unknown I thinks it's related to the number of open files. Because, I tried to run the jboss applet with gappletviewer after getting this exception and got this exception from jboss: 13:05:29,510 ERROR [PoolTcpEndpoint] Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8080] ignored exception: java.io.IOException: Too many open files java.io.IOException: Too many open files at gnu.java.net.VMPlainSocketImpl.accept(Native Method) at gnu.java.net.PlainSocketImpl.accept(PlainSocketImpl.java:282) at java.net.ServerSocket.implAccept(ServerSocket.java:369) at java.net.ServerSocket.accept(ServerSocket.java:321) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:407) at org.apache.tomcat.util.net.PoolTcpEndpoint.run(PoolTcpEndpoint.java:647) at java.lang.Thread.run(Thread.java:740) at java.lang.VMThread.run(VMThread.java:120) Maybe we have a leak somewhere in closing files? On shutdown I get a NPE: 13:07:37,901 WARN [JRMPInvoker] Stopping failed jboss:service=invoker,type=jrmp java.lang.NullPointerException at java.rmi.server.UnicastRemoteObject.unexportObject(UnicastRemoteObject.java:240) at org.jboss.invocation.jrmp.server.JRMPInvoker.unexportCI(JRMPInvoker.java:457) at org.jboss.invocation.jrmp.server.JRMPInvoker.stopService(JRMPInvoker.java:386) at org.jboss.invocation.jrmp.server.JRMPInvoker$1.stopService(JRMPInvoker.java:154) at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247) at org.jboss.invocation.jrmp.server.JRMPInvoker.jbossInternalLifecycle(JRMPInvoker.java:645) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:355) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.stop(Unknown Source) at org.jboss.system.ServiceController.stop(ServiceController.java:508) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:355) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.stop(Unknown Source) at org.jboss.deployment.SARDeployer.stop(SARDeployer.java:336) at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:658) at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:631) at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:510) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:355) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at
Re: jboss-4.0.4
Hi Christian! 2006/7/31, Christian Thalinger [EMAIL PROTECTED]: 13:02:10,416 WARN [URLDeploymentScanner] Scan URL, caught java.io.IOException: Could not list directory '/home/twisti/src/cacao/jboss/jboss-4.0.4.GA/server/default/deploy', reason unknown I thinks it's related to the number of open files. Because, I tried to run the jboss applet with gappletviewer after getting this exception and got this exception from jboss: 13:05:29,510 ERROR [PoolTcpEndpoint] Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8080] ignored exception: java.io.IOException: Too many open files java.io.IOException: Too many open files at gnu.java.net.VMPlainSocketImpl.accept(Native Method) at gnu.java.net.PlainSocketImpl.accept(PlainSocketImpl.java:282) Any hints and bugfixes are welcome :-) I don't know if it is related to your problem, but the too many open files thing reminds me of this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25760 Stephan Michels.
Re: jboss-4.0.4
On Mon, 2006-07-31 at 13:55 +0200, Stephan Michels wrote: I don't know if it is related to your problem, but the too many open files thing reminds me of this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25760 Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? TWISTI
Re: jboss-4.0.4
Hi Twisti, On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 13:55 +0200, Stephan Michels wrote: I don't know if it is related to your problem, but the too many open files thing reminds me of this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25760 Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? I've never tried to run JBoss with JamVM. Can you give a quick summary of what you're trying to run so that I can have a go myself? Remember, I know _nothing_ about JBoss! Thanks, Rob. TWISTI
Re: jboss-4.0.4
On Mon, 2006-07-31 at 13:50 +0100, Robert Lougher wrote: I've never tried to run JBoss with JamVM. Can you give a quick summary of what you're trying to run so that I can have a go myself? Remember, I know _nothing_ about JBoss! Who does :-) Well, just download the latest release (4.0.4.GA), unpack it, change to jboss-4.0.4.GA/bin and run it like: $ JAVA_HOME=/home/twisti/tmp/jamvm ./run.sh I set up myself a little fakejdk in /home/twisti/tmp/jamvm, means, I made a java symlink to jamvm. That's it. TWISTI
Re: jboss-4.0.4
Hi Twisti, On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 13:50 +0100, Robert Lougher wrote: I've never tried to run JBoss with JamVM. Can you give a quick summary of what you're trying to run so that I can have a go myself? Remember, I know _nothing_ about JBoss! Who does :-) Well, just download the latest release (4.0.4.GA), unpack it, change to jboss-4.0.4.GA/bin and run it like: $ JAVA_HOME=/home/twisti/tmp/jamvm ./run.sh I set up myself a little fakejdk in /home/twisti/tmp/jamvm, means, I made a java symlink to jamvm. That's it. Thanks a lot. I've downloaded it and I'll try tonight... Rob. TWISTI
Re: Xara backend over cairo?
== êðõ [EMAIL PROTECTED] writes: The benchmark shows good perfomance than Cairo. http://www.xaraxtreme.org/about/performance.html But I don't know whether we can also use it for class path (though it is basically a vector rendering engine). If it is free software and does what we need for Java2D, I don't see why not. Naturally we would need a volunteer to start work on this :-) Tom
[Bug classpath/28552] New: RMI NPE on JBoss-4.0.4 shutdown
When running JBoss-4.0.4 with current CVS head, which is mostly like upcoming 0.92 release, I get a NPE during shutdown: 19:16:45,755 WARN [JRMPInvoker] Stopping failed jboss:service=invoker,type=jrmp java.lang.NullPointerException at java.rmi.server.UnicastRemoteObject.unexportObject(UnicastRemoteObject.java:240) at org.jboss.invocation.jrmp.server.JRMPInvoker.unexportCI(JRMPInvoker.java:457) at org.jboss.invocation.jrmp.server.JRMPInvoker.stopService(JRMPInvoker.java:386) at org.jboss.invocation.jrmp.server.JRMPInvoker$1.stopService(JRMPInvoker.java:154) at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247) at org.jboss.invocation.jrmp.server.JRMPInvoker.jbossInternalLifecycle(JRMPInvoker.java:645) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:355) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.stop(Unknown Source) at org.jboss.system.ServiceController.stop(ServiceController.java:508) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:355) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.stop(Unknown Source) at org.jboss.deployment.SARDeployer.stop(SARDeployer.java:336) at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:658) at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:631) at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:510) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:355) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:1050) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1025) at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:988) at java.lang.VMThread.run(VMThread.java:120) 19:16:45,838 INFO [Server] Shutdown complete Shutdown complete Halting VM -- Summary: RMI NPE on JBoss-4.0.4 shutdown Product: classpath Version: 0.92 Status: UNCONFIRMED Severity: normal Priority: P3 Component: classpath AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: twisti at complang dot tuwien dot ac dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28552 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: jboss-4.0.4
Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti On shutdown I get a NPE: Twisti 13:07:37,901 WARN [JRMPInvoker] Stopping failed Twisti jboss:service=invoker,type=jrmp Twisti java.lang.NullPointerException Twistiat java.rmi.server.UnicastRemoteObject.unexportObject(UnicastRemoteObject.java:240) Could you file a PR for this? I don't know RMI very well (does anybody?) but this seems like a real Classpath bug to me. Tom
Re: jboss-4.0.4
On Mon, 2006-07-31 at 14:06 +0200, Christian Thalinger wrote: Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? The bug showed with jamvm is already in bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27710 I suspect it's something with endorsed dirs. Robert, does jamvm support that? I guess not... TWISTI
Re: jboss-4.0.4
On Mon, 2006-07-31 at 19:04 +0100, Robert Lougher wrote: No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Well, nearly. You have to scan the directories, if any, for zip/jar files and prepend them too. TWISTI
Re: jboss-4.0.4
Hi, No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Rob. On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 14:06 +0200, Christian Thalinger wrote: Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? The bug showed with jamvm is already in bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27710 I suspect it's something with endorsed dirs. Robert, does jamvm support that? I guess not... No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Hopefully it should be available in CVS soon... Thanks, Rob. TWISTI
Re: jboss-4.0.4
On 7/31/06, Robert Lougher [EMAIL PROTECTED] wrote: On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 19:04 +0100, Robert Lougher wrote: No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Well, nearly. You have to scan the directories, if any, for zip/jar files and prepend them too. Yes. I realised that each dir will contain potentially many jars, and that these are what must be prepended just after I posted. Sods law! I guess you do this in cacao and this is what lets you start up jboss. Sorry to keep on spamming, but do you look in a default location if java.endorsed.dirs is unset? The RI does, but this assumes you've got a JRE-like directory structure. Time to put jamvm into it's own directory... Rob. Thanks, Rob. TWISTI
Re: jboss-4.0.4
On Mon, 2006-07-31 at 13:03 -0400, Tom Tromey wrote: Could you file a PR for this? I don't know RMI very well (does anybody?) but this seems like a real Classpath bug to me. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28552 I think Audrius is the person. He fixed all my RMI problems :-) TWISTI
Re: jboss-4.0.4
Christian Thalinger wrote: On Mon, 2006-07-31 at 14:06 +0200, Christian Thalinger wrote: Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? JCVM has class unloading, but I've never tried JBoss. If you want to try it, use the harmony version because it's more up to date: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: jboss-4.0.4
Rob == Robert Lougher [EMAIL PROTECTED] writes: Rob No, but it doesn't look difficult to implement. If I understand it Rob correctly it seems to be as simple as just prepending the value of Rob java.endorsed.dirs to the bootpath? You need to search the endorsed directories for .jar and .zip files and add each one to the boot class path. Tom
Re: jboss-4.0.4
On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 19:04 +0100, Robert Lougher wrote: No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Well, nearly. You have to scan the directories, if any, for zip/jar files and prepend them too. Yes. I realised that each dir will contain potentially many jars, and that these are what must be prepended just after I posted. Sods law! I guess you do this in cacao and this is what lets you start up jboss. Thanks, Rob. TWISTI
Re: jboss-4.0.4
On Mon, 2006-07-31 at 19:35 +0100, Robert Lougher wrote:
Sorry to keep on spamming, but do you look in a default location if
java.endorsed.dirs is unset? The RI does, but this assumes you've got
a JRE-like directory structure. Time to put jamvm into it's own
directory...
Yes, we do. We just default to ${prefix}/jre/lib/endorsed, but we do
not make this directory on install.
TWISTI
[Bug crypto/28556] KeyFactory RSA fails to parse some PKCS8 encoded keys
--- Comment #3 from csm at gnu dot org 2006-07-31 21:00 --- I think the issue is with reading the parameters field of the key; the ASN.1 says that that field is OPTIONAL, but it MAY be an explicit NULL value, like it is here. Using 'openssl asn1parse' the output for this key is: 0:d=0 hl=4 l= 632 cons: SEQUENCE 4:d=1 hl=2 l= 1 prim: INTEGER :00 7:d=1 hl=2 l= 13 cons: SEQUENCE 9:d=2 hl=2 l= 9 prim: OBJECT:rsaEncryption 20:d=2 hl=2 l= 0 prim: NULL 22:d=1 hl=4 l= 610 prim: OCTET STRING -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28556 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: AWT peer event handling (Important)
Hi Sven, First off, some observations: 1) When a property of a Component changes, the corresponding setProperty method of the Component object IS called. E.g. selecting Choice item WILL result in a call to Choice.select(index) method. (Test: Overload the setProperty method) Makes perfect sense. 2) The above call is done from the event dispatch thread. (Test: Print Toolkit.getSystemEventQueue().isDispatchThread() ) 3) The call is from the peer handleEvent and NOT from the peer dispatchEventImpl. The latter must also always call super.dispatchEventImpl for the former to be called. (Test: Construct your own event and send it to EventQueue.postEvent(ie) fake events are passed on to listeners but do not change the state of the Component or its peer.) An example of where this is wrong is the current version of Checkbox. You certainly mean Component dispatchEventImpl() and not peer dispatchEventImpl(). And yes, ComponentPeer.handleEvent() is called from Component.dispatchEventImpl(), so the subclass dispatchEventImpl() must call super. 4) The Component-subclass's processEvent/processXXXEvent methods are only called if the class has listeners (this much we seem to do right) (Test: Overload processEvent) Yep, this is what we do, but not in all cases correctly. The processXXX methods are called if the component has the corresponding listener OR has the event enabled vie enableEvents(). Internally we also should check if a certain event type is enabled in the Toolkit and dispatch the event to the toolkit in that case. 5) The initial setting-up of the native state (on creating the peer) does not trigger any events. (Test: Add a listener). (the obvious paint events, etc are exceptions of course) Hmm ok. So, how this works is that the peer keeps track of the native state, and what happens is: Case 1: The user clicks on something, changing the native state. A callback to the peer occurs, and if the state has changed, the peer updates its state and posts an event. This event is then executed by the event dispatch thread, calling the peer handleEvent() method. The peer handleEvent method checks if it's an event specific to its peer type (or delegates it to super.handleEvent), and then, if the owner's state needs updating, it calls its setProperty() method. Case 2: The program calls Component.setProperty(). If the property isn't changed, do nothing. Otherwise, set the property and call the peer setProperty() method. This triggers a callback and posts an event, but in this case the peer handleEvent() method does NOT call the owner's setProperty() method a second time since the owner's state does not need updating. Case 3: Somebody sticks in a bogus event in the event queue. The peer handleEvent() method does not call its owner's setProperty() method because its state does not need updating. We should add these observations to the Wiki somewhere (developer guidelines or so). So our behaviour here goes from broken, to almost-right to completely wrong (although a bit functional). But we need to strive to do this stuff the Right way. All this behaviour is testable, and by testable I mean you can write a program that relys on it. Which means that this is a compatibility problem. I fully agree. I myself observed a couple of other problems inside AWT that were related to event dispatching (see my focus and Component/Container patches). There's still plenty to do here... /Roman
[commit-cp] classpath ChangeLog native/jni/qt-peer/Makefile.am
CVSROOT:/sources/classpath Module name:classpath Changes by: Thomas Fitzsimmons fitzsim06/07/31 13:50:38 Modified files: . : ChangeLog native/jni/qt-peer: Makefile.am Log message: 2006-07-31 Thomas Fitzsimmons [EMAIL PROTECTED] * native/jni/qt-peer/Makefile.am (libqtpeer_la_LDFLAGS): Add -avoid-version. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8276r2=1.8277 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/qt-peer/Makefile.am?cvsroot=classpathr1=1.6r2=1.7
[commit-cp] classpath ChangeLog java/lang/StrictMath.java
CVSROOT:/sources/classpath Module name:classpath Changes by: Carsten Neumann neumannc 06/07/31 18:02:52 Modified files: . : ChangeLog java/lang : StrictMath.java Log message: 2006-07-31 Carsten Neumann [EMAIL PROTECTED] * StrictMath.java (getLowDWord): Return long instead of int. (getHighDWord): Likewise. (buildDouble): Take two long arguments. (cbrt): Adapted to int - long change. (expm1): Likewise. (cosh): Likewise. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8277r2=1.8278 http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/StrictMath.java?cvsroot=classpathr1=1.11r2=1.12
[commit-cp] classpath INSTALL NEWS ChangeLog
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Roman Kennke rabbit78 06/07/31 19:01:28 Modified files: . : INSTALL NEWS ChangeLog Log message: 2006-07-31 Roman Kennke [EMAIL PROTECTED] * NEWS: Added note about the X peers. * INSTALL: Added install notes about the X peers. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/INSTALL?cvsroot=classpathr1=1.37r2=1.38 http://cvs.savannah.gnu.org/viewcvs/classpath/NEWS?cvsroot=classpathr1=1.160r2=1.161 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8278r2=1.8279
