[Bug xml/27710] JBoss 4.0.4 fails to start due exception in DomDocumentBuilderFactory
--- Comment #4 from psj at harker dot dyndns dot org 2006-08-13 17:24 --- Occurs with JamVM 1.4.3 and Classpath 0.92. Does not occur with Cacao 0.96 and the same Classpath 0.92. Presumably because Cacao does not load xercesImpl.jar from lib/endorsed as JamVM does? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27710 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: jboss-4.0.4
Hi Christian. On Mon, 2006-07-31 at 13:22 +0200, Christian Thalinger wrote: Today I was trying again JBoss-4.0.4 and it runs much better than the last time. This includes with Classpath 0.92 release. First time JBoss 4 has started up cleanly with a release version of Classpath? 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 Try increasing the ScanPeriod (or even disabling the ScanEnabled) in server conf/jboss-service.xml to workaround this. Hope this helps, Paul -- Paul Jenner [EMAIL PROTECTED]
Re: jboss-4.0.4:Does not start today - regression?
JBoss does not starts with jamvm today with the class cast exception in the sentence: this.modelAttributes = (ModelMBeanAttributeInfo[]) super.getAttributes(); The exceptions trace and messages are attached. As until now it was a long talk about JBoss running, I suspect that this is a regression, introduced by the recent changes. Could anybody else try with the fresh CVS check? Best regards Audrius run.sh: Missing file: /usr/local/bin/javahome/lib/tools.jar run.sh: Unexpected results may occur. Make sure JAVA_HOME points to a JDK and not a JRE. = JBoss Bootstrap Environment JBOSS_HOME: /home/audriusa/applications/boss JAVA: jamvm JAVA_OPTS: -Xms128m -Xmx512m -Dprogram.name=run.sh CLASSPATH: /home/audriusa/applications/boss/bin/run.jar:/usr/local/bin/javahome/lib/tools.jar = 12:21:32,020 INFO [Server] Starting JBoss (MX MicroKernel)... 12:21:32,021 INFO [Server] Release ID: JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000) 12:21:32,024 INFO [Server] Home Dir: /home/audriusa/applications/boss 12:21:32,024 INFO [Server] Home URL: file:/home/audriusa/applications/boss/ 12:21:32,027 INFO [Server] Patch URL: null 12:21:32,027 INFO [Server] Server Name: default 12:21:32,027 INFO [Server] Server Home Dir: /home/audriusa/applications/boss/server/default 12:21:32,028 INFO [Server] Server Home URL: file:/home/audriusa/applications/boss/server/default/ 12:21:32,028 INFO [Server] Server Log Dir: /home/audriusa/applications/boss/server/default/log 12:21:32,029 INFO [Server] Server Temp Dir: /home/audriusa/applications/boss/server/default/tmp 12:21:32,030 INFO [Server] Root Deployment Filename: jboss-service.xml Failed to boot JBoss: java.lang.RuntimeException: Cannot create MBeanServer at org.jboss.mx.server.MBeanServerImpl.init(MBeanServerImpl.java:239) at org.jboss.mx.server.MBeanServerBuilderImpl.newMBeanServer(MBeanServerBuilderImpl.java:71) at javax.management.MBeanServerFactory$2.run(MBeanServerFactory.java:241) at java.security.AccessController.doPrivileged(AccessController.java:154) at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:236) at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:168) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:420) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:464) at java.lang.Thread.run(Thread.java:740) Caused by: javax.management.NotCompliantMBeanException: Cannot register MBean: JMImplementation:type=MBeanServerDelegate at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:314) at org.jboss.mx.server.MBeanServerImpl.init(MBeanServerImpl.java:215) ...10 more Caused by: java.lang.ClassCastException: [Ljavax/management/MBeanAttributeInfo; at javax.management.modelmbean.ModelMBeanInfoSupport.init(ModelMBeanInfoSupport.java:164) at org.jboss.mx.metadata.MBeanInfoConversion.toModelMBeanInfo(MBeanInfoConversion.java:239) at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:229) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:194) ...11 more
Re: jboss-4.0.4:Does not start today - regression?
On Tue, Aug 08, 2006 at 12:37:52PM +0200, Audrius Meskauskas wrote: JBoss does not starts with jamvm today with the class cast exception in the sentence: this.modelAttributes = (ModelMBeanAttributeInfo[]) super.getAttributes(); The exceptions trace and messages are attached. As until now it was a long talk about JBoss running, I suspect that this is a regression, introduced by the recent changes. Could anybody else try with the fresh CVS check? I get exactly the same exception with CACAO and CVS head. TWISTI
Re: jboss-4.0.4:Does not start today - regression?
Christian Thalinger wrote: I get exactly the same exception with CACAO and CVS head. TWISTI Ok. I fill in the bug report 28652. Audrius
Re: jboss-4.0.4
Hi Robert, Putting JamVM into its own directory would be most helpful! Will save me some work for firecat;) David Fu. 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
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 org.jboss.mx.server.MBeanServerImpl.invoke
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
[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