Re: [JBoss-dev] jboss-head, Testsuite for all configuration fails
Running the all config from a clean check out and build is fine (at least for booting). Running the testsuite does give an error when booting the all configuration (during jboss-all-config-tests target), but logs indicate is due to port 1098 already being in use. Saw the same on the cruisecontrol run - http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log. Not sure where the error you are seeing came from. Hany Mesha wrote: Hi all, When I run the test suite, it fails with the excpetion below. Is there a problem with head or is it just my env.? Thanks, Hany Mesha ==Begin=== 20:28:08,943 INFO [Server] Starting JBoss (MX MicroKernel)... 20:28:08,944 INFO [Server] Release ID: JBoss [Morpheus] 5.0.0.Alpha (build: CVSTag=HEAD date=200604041919) 20:28:08,946 INFO [Server] Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha 20:28:09,099 INFO [Server] Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/ 20:28:09,100 INFO [Server] Patch URL: null 20:28:09,282 INFO [Server] Server Name: default 20:28:09,283 INFO [Server] Server Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default 20:28:09,283 INFO [Server] Server Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default/ 20:28:09,283 INFO [Server] Server Temp Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default/tmp 20:28:09,284 INFO [Server] Root Deployment Filename: jboss-service.xml 20:28:10,072 INFO [ServerInfo] Java version: 1.5.0_03,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_03-b07,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] OS-System: Linux 2.6.5-7.243-default,i386 20:28:11,228 INFO [Server] Core system initialized 20:28:17,840 ERROR [BasicMBeanRegistry] Cannot register MBean java.lang.NoClassDefFoundError: [Lorg/jboss/remoting/InvokerLocator; at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.privateGetPublicMethods(Class.java:2488) at java.lang.Class.getMethods(Class.java:1406) at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:208) at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:224) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:203) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:262) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1359) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345) at org.jboss.system.ServiceCreator.install(ServiceCreator.java:157) at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171) at org.jboss.system.ServiceController.install(ServiceController.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:262) at
[JBoss-dev] jboss-remoting-testsuite-1.4 Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.4?log=log20060405030135 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:04/05/2006 03:01:35Time to build:44 minutes 56 secondsLast changed:04/04/2006 01:20:10Last log entry:JBREM-404:In configureSocketGroupInfo(), add information to SocketGroupInfo only after doing parameter consistency checks. Unit Tests: (181) Total Errors and Failures: (20)testStartorg.jboss.test.remoting.versioning.transport.http.VersionHTTPInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.http.VersionHTTPInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.http.VersionHTTPInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.http.VersionHTTPInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.http.VersionHTTPInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.multiplex.VersionMultiplexInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.multiplex.VersionMultiplexInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.multiplex.VersionMultiplexInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.multiplex.VersionMultiplexInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.rmi.VersionRMIInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.rmi.VersionRMIInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.rmi.VersionRMIInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.rmi.VersionRMIInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.rmi.VersionRMIInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.socket.VersionSocketInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.socket.VersionSocketInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.socket.VersionSocketInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.socket.VersionSocketInvokerTestCasetestStartorg.jboss.test.remoting.versioning.transport.socket.VersionSocketInvokerTestCasetestMultipleLeasesorg.jboss.test.remoting.lease.LeaseUnitTestCase(java_serialization) Modifications since last build:(first 50 of 92)1.2modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/multiplex/ssl/.keystore.keystore and .truststore need to be in test src directory so they can get copied to test output directory.1.2modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/multiplex/ssl/.truststore.keystore and .truststore need to be in test src directory so they can get copied to test output directory.1.3modifiedtimfoxsrc/main/org/jboss/remoting/util/TimerUtil.javaFixes to Connection pinging and leasing1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/connection/ConnectionValidationServer.javaJBREM-378 - fixed client connection ping so will properly indicate if server is dead and also not activate a new lease on the server side.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/connection/ConnectionValidatorClient.javaJBREM-378 - fixed client connection ping so will properly indicate if server is dead and also not activate a new lease on the server side.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/lease/LeaseUnitTestCase.javaJBREM-374 - updated to use singleton like approach to allow for only one timer thread for leasing.1.2modifiedtelrodsrc/main/org/jboss/remoting/util/TimerUtil.javaJBREM-374 - updated to use singleton like approach to allow for only one timer thread for leasing.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/lease/LeaseUnitTestCase.javaJBREM-374 - updated to use singleton like approach to allow for only one timer thread for leasing.1.1addedtelrodsrc/main/org/jboss/remoting/util/TimerUtil.javaJBREM-374 - updated to use singleton like approach to allow for only one timer thread for leasing.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/lease/LeaseUnitTestCase.javaJBREM-372 - fix for memory leak on leases (on the server side)1.6modifiedrsigalsrc/main/org/jboss/remoting/util/socket/RemotingSSLSocketFactory.javaFixed typo:"javax.net.ssl.trustStorePasswor"1.9modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/http/ssl/custom/HTTPSInvokerTestClient.java*** empty log message ***1.7modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerClientTest.javaJBREM-330 - added assert for callback1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerClientTest.javaJBREM-330 - fix for ssl
[JBoss-dev] Toward JBoss v4.0.4.GA - Part 3 - For developers
Just want to bring to your attention 2 important issues A) Planning any JBossAS release is quite hard due to complexity and the simple reason that developer availability is mostly unknown (work on primary projects, training, consulting, vacations, traveling, conferences, sudden disappearances, etc.) We are often stuck in the AS waiting for a deliverable from project A that depends on project B and breaks project C, etc. - You need to be proactive/aware in terms of coordinating your project releases with JBoss releases. - You need to pre-allocate time for working on jboss issues and help resolving integration problems. - You need to merge early your work/.jars to the AS to give time for solving integration problems. B) Putting on the side the excellent technical work, we need to do a better job promoting it to end-users and developers inside and outside jboss. For every new feature (or even change) that improves and adds value to the JBossAS, except for WRITING A WIKI PAGE about it, you NEED TO LINK IT and make it's presence known! There are hundreds of smaller or bigger features that except the creator very few other people know about it. A start would be to link your wiki page from: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossReleaseNotes Or even: http://wiki.jboss.org/wiki/Wiki.jsp?page=404UpgradeIssues Based on those link we can then compile a meaningful Release Notes, rather than simply listing often incomprehensible JIRA headlines. Thanks /Dimitris -- xxx Dimitris Andreadis Core Developer JBoss Europe SàRL xxx --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues
Various Issues -- - Breakage of jboss commons. Is this the right time, or should do for 4.0.5. Aren't we already overloaded? Who How? - Which thirdparty libs can be removed? So far I've noticed apache-wss4j apache-jaxme. - JBoss.Net is not even included in the docs/examples now. Should it be removed from the 4.0.x module checkout? - The following jboss lists are *NOT* final (GA). What will be updated for 4.0.4.GA? Project leads speak! componentref name=hibernate version=3.2.0.CR1/ componentref name=hibernate-annotations version=3.1beta9/ componentref name=hibernate-entitymanager version=3.1beta7/ componentref name=javassist version=3.2.0.CR1/ componentref name=hibernate version=3.2.0.CR1/ componentref name=hibernate-annotations version=3.1beta9/ componentref name=hibernate-entitymanager version=3.1beta7/ componentref name=jboss/jbossretro version=1.0.0.CR1/ componentref name=jboss/jbossws version=1.0.0.CR6/ componentref name=jboss/jbossws14 version=1.0.0.CR6/ componentref name=jboss/jbossxb version=1.0.0.CR3/ componentref name=jboss/serialization version=1.0.0.CR4/ -- xxx Dimitris Andreadis Core Developer JBoss Europe SàRL xxx --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Toward JBoss v4.0.4.GA - Part 1 - JIRA tasks
When we started work on 4.0.4 we had 300+ issues ahead of us, now after 2 candidate releases we are down to around 80, which is quite an achievement, but still a significant amount of work is left for the final (GA) release. The current target date is 26th/April which includes Easter and is just 3 weeks ahead of us. This gives roughly 2 weeks of bug fixing and 1 week of integration testing. New features shouldn't be introduced at this point. Please take a look at the issues assigned to you and resolve/defer in time: http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestI d=12310181 Take a look at the unassigned ones and help: http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestI d=12310482 The current breakout is roughly shown below. NoComponent 3 Build 2 Clustering 7 CMP 13 Deployment 3 Documentation 1 (+ 6 dependencies) EJB 10 (6 unassigned) Hibernate 1 IIOP2 Installer 5 (5 unassigned) JCA 1 JMX 5 (1 unassigned) Logging 1 Management 2 Naming 1 Other 1 Remoting6 Security6 (1 unassigned) System 1 Testsuite 5 (1 unassigned) Tomcat 6 WebServices 3 XML 1 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 3 - For developers
Forgot also to mention that thing that should go in the admin guide should be linked from this JIRA task: http://wiki.jboss.org/wiki/Wiki.jsp?page=404UpgradeIssues --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 3 - For developers
Actually the correct link: http://jira.jboss.com/jira/browse/JBAS-2821 Forgot also to mention that thing that should go in the admin guide should be linked from this JIRA task: --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 3 - For developers
Ok, so I just found a bug in JIRA, the correct links are: Compatibility http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310487view=rnotes Doco http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310486view=rnotes On Wed, 2006-04-05 at 12:16 +0100, Adrian Brock wrote: You can already get this information from JIRA. Let's keep the process simple please. I already: 1) Describe the change on the JIRA task 2) Update and the relevant WIKI page and link it on the JIRA task 3) Mark the JIRA task as requiring a doco change I am not going to update an arbitrary number of web pages when the information is already available. If people kept their JIRA tasks to a description of the change rather than using them as discussion forums, it wouldn't be as hard to understand. e.g. You can already get this information from JIRA: comaptibility changes http://jira.jboss.com/jira/secure/IssueNavigator.jspa?view=rnotestempMax=1 or doco changes required http://jira.jboss.com/jira/secure/IssueNavigator.jspa?view=rnotestempMax=1 On Wed, 2006-04-05 at 05:49 -0500, Dimitris Andreadis wrote: Forgot also to mention that thing that should go in the admin guide should be linked from this JIRA task: http://wiki.jboss.org/wiki/Wiki.jsp?page=404UpgradeIssues --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 3 - For developers
And even that is broken! It shows displaying 1..20 of 37 but there is no link to view the others :-) Just remove the view=rnotes On Wed, 2006-04-05 at 12:22 +0100, Adrian Brock wrote: Ok, so I just found a bug in JIRA, the correct links are: Compatibility http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310487view=rnotes Doco http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310486view=rnotes -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 3 - Fordevelopers
From: Adrian Brock Let's keep the process simple please. I already: 1) Describe the change on the JIRA task 2) Update and the relevant WIKI page and link it on the JIRA task 3) Mark the JIRA task as requiring a doco change I am not going to update an arbitrary number of web pages when the information is already available. If people kept their JIRA tasks to a description of the change rather than using them as discussion forums, it wouldn't be as hard to understand. Compatibility http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestI d=12310487 Doco http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestI d=12310486 Thanks fine, as long as people use JIRA consistently. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-head, Testsuite for all configuration fails
It turned out that build clean then build all doesn't copy jboss-remoting.jar to the server build lib directory causing this error. I overcome the issue by copying the above jar to build/output/jboss-5.0.0.alpha/server/all/lib directory. Now I see the error reported on cruise control but only on my linux machine. My windows machine is able to run without a problem. Hany MeshaOn 4/5/06, Tom Elrod [EMAIL PROTECTED] wrote: Running the all config from a clean check out and build is fine (atleast for booting).Running the testsuite does give an error whenbooting the all configuration (during jboss-all-config-tests target),but logs indicate is due to port 1098 already being in use.Saw the same on the cruisecontrol run -http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log .Not sure where the error you are seeing came from.Hany Mesha wrote: Hi all, When I run the test suite, it fails with the excpetion below. Is there a problem with head or is it just my env.? Thanks, Hany Mesha ==Begin=== 20:28:08,943 INFO[Server] Starting JBoss (MX MicroKernel)... 20:28:08,944 INFO[Server] Release ID: JBoss [Morpheus] 5.0.0.Alpha (build: CVSTag=HEAD date=200604041919) 20:28:08,946 INFO[Server] Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha 20:28:09,099 INFO[Server] Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/ 20:28:09,100 INFO[Server] Patch URL: null 20:28:09,282 INFO[Server] Server Name: default 20:28:09,283 INFO[Server] Server Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default 20:28:09,283 INFO[Server] Server Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha /server/default/ 20:28:09,283 INFO[Server] Server Temp Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default/tmp 20:28:09,284 INFO[Server] Root Deployment Filename: jboss-service.xml 20:28:10,072 INFO[ServerInfo] Java version: 1.5.0_03,Sun Microsystems Inc. 20:28:10,072 INFO[ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_03-b07,Sun Microsystems Inc. 20:28:10,072 INFO[ServerInfo] OS-System: Linux 2.6.5-7.243-default,i386 20:28:11,228 INFO[Server] Core system initialized 20:28:17,840 ERROR [BasicMBeanRegistry] Cannot register MBean java.lang.NoClassDefFoundError: [Lorg/jboss/remoting/InvokerLocator; at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.privateGetPublicMethods(Class.java:2488) at java.lang.Class.getMethods(Class.java:1406) at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:208) at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:224) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:203) at sun.reflect.GeneratedMethodAccessor1.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke (AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java :140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:262) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:668) at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1359) at org.jboss.mx.server.MBeanServerImpl.createMBean (MBeanServerImpl.java:345) at org.jboss.system.ServiceCreator.install(ServiceCreator.java:157) at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171) at org.jboss.system.ServiceController.install(ServiceController.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java :25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch (Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at
[JBoss-dev] Re: Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues
JBossXB is going to stay at CR3 unless WebServices request new urgent fixes. Dimitris Andreadis wrote: Various Issues -- - Breakage of jboss commons. Is this the right time, or should do for 4.0.5. Aren't we already overloaded? Who How? - Which thirdparty libs can be removed? So far I've noticed apache-wss4j apache-jaxme. - JBoss.Net is not even included in the docs/examples now. Should it be removed from the 4.0.x module checkout? - The following jboss lists are *NOT* final (GA). What will be updated for 4.0.4.GA? Project leads speak! componentref name=hibernate version=3.2.0.CR1/ componentref name=hibernate-annotations version=3.1beta9/ componentref name=hibernate-entitymanager version=3.1beta7/ componentref name=javassist version=3.2.0.CR1/ componentref name=hibernate version=3.2.0.CR1/ componentref name=hibernate-annotations version=3.1beta9/ componentref name=hibernate-entitymanager version=3.1beta7/ componentref name=jboss/jbossretro version=1.0.0.CR1/ componentref name=jboss/jbossws version=1.0.0.CR6/ componentref name=jboss/jbossws14 version=1.0.0.CR6/ componentref name=jboss/jbossxb version=1.0.0.CR3/ componentref name=jboss/serialization version=1.0.0.CR4/ -- xxx Dimitris Andreadis Core Developer JBoss Europe SàRL xxx --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-head, Testsuite for all configuration fails
Documenation is also done by all. On Wed, 2006-04-05 at 09:55 -0400, Tom Elrod wrote: The 'all' target and the 'most' target are the same except that 'all' calls 'modules-all' and 'most' calls 'modules-most'. Anyone know the difference between the two (modules-all and modules-most)? Hany Mesha wrote: It turned out that build clean then build all doesn't copy jboss-remoting.jar to the server build lib directory causing this error. I overcome the issue by copying the above jar to build/output/jboss-5.0.0.alpha/server/all/lib directory. Now I see the error reported on cruise control but only on my linux machine. My windows machine is able to run without a problem. Hany Mesha On 4/5/06, *Tom Elrod* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Running the all config from a clean check out and build is fine (at least for booting). Running the testsuite does give an error when booting the all configuration (during jboss-all-config-tests target), but logs indicate is due to port 1098 already being in use. Saw the same on the cruisecontrol run - http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log. Not sure where the error you are seeing came from. Hany Mesha wrote: Hi all, When I run the test suite, it fails with the excpetion below. Is there a problem with head or is it just my env.? Thanks, Hany Mesha ==Begin=== 20:28:08,943 INFO [Server] Starting JBoss (MX MicroKernel)... 20:28:08,944 INFO [Server] Release ID: JBoss [Morpheus] 5.0.0.Alpha (build: CVSTag=HEAD date=200604041919) 20:28:08,946 INFO [Server] Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha 20:28:09,099 INFO [Server] Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/ 20:28:09,100 INFO [Server] Patch URL: null 20:28:09,282 INFO [Server] Server Name: default 20:28:09,283 INFO [Server] Server Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default 20:28:09,283 INFO [Server] Server Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha /server/default/ 20:28:09,283 INFO [Server] Server Temp Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default/tmp 20:28:09,284 INFO [Server] Root Deployment Filename: jboss-service.xml 20:28:10,072 INFO [ServerInfo] Java version: 1.5.0_03,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_03-b07,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] OS-System: Linux 2.6.5-7.243-default,i386 20:28:11,228 INFO [Server] Core system initialized 20:28:17,840 ERROR [BasicMBeanRegistry] Cannot register MBean java.lang.NoClassDefFoundError: [Lorg/jboss/remoting/InvokerLocator; at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.privateGetPublicMethods(Class.java:2488) at java.lang.Class.getMethods(Class.java:1406) at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:208) at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:224) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:203) at sun.reflect.GeneratedMethodAccessor1.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke (AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java :140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at
RE: [JBoss-dev] jboss-head, Testsuite for all configuration fails
javadoc is generated in all, but its completely upto the module all target definition to make this distinction. The all target should depend on most and add to it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Wednesday, April 05, 2006 6:55 AM To: jboss-development@lists.sourceforge.net Cc: QA Subject: Re: [JBoss-dev] jboss-head, Testsuite for all configuration fails The 'all' target and the 'most' target are the same except that 'all' calls 'modules-all' and 'most' calls 'modules-most'. Anyone know the difference between the two (modules-all and modules-most)? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
The minimal server log shows a time gap of 60 sec before starting the shutdown, and the all config starts before this is complete. http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite/20060405 072327/build/output/jboss-4.0.4.GA/server/minimal/log/server.log 2006-04-05 07:44:00,223 DEBUG [org.jboss.system.ServiceController] stopping service: jboss.deployment:flavor=URL,type=DeploymentScanner 2006-04-05 07:44:00,223 DEBUG [org.jboss.system.ServiceController] stopping dependent services for: jboss.deployment:flavor=URL,type=DeploymentScanner dependent services are: [] 2006-04-05 07:44:00,223 DEBUG [org.jboss.deployment.scanner.URLDeploymentScanner] Stopping jboss.deployment:flavor=URL,type=DeploymentScanner 2006-04-05 07:44:00,223 DEBUG [org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread] Notified that enabled: false 2006-04-05 07:45:00,234 DEBUG [org.jboss.deployment.scanner.URLDeploymentScanner] Stopped jboss.deployment:flavor=URL,type=DeploymentScanner 2006-04-05 07:45:00,234 DEBUG [org.jboss.deployment.SARDeployer] stopping mbean jboss:service=Naming 2006-04-05 07:45:00,235 DEBUG [org.jboss.system.ServiceController] stopping service: jboss:service=Naming 2006-04-05 07:45:00,235 DEBUG [org.jboss.system.ServiceController] stopping dependent services for: jboss:service=Naming dependent services are: [] 2006-04-05 07:45:00,235 DEBUG [org.jboss.naming.NamingService] Stopping jboss:service=Naming 2006-04-05 07:45:00,236 DEBUG [org.jboss.naming.NamingService] JNP server stopped -Original Message- From: Adrian Brock Sent: Wednesday, April 05, 2006 11:25 AM To: Rajesh Rajasekaran Cc: QA; Alexey Loubyansky; Amit Bhayani; Anil Saldhana; Bela Ban; Bill Burke; Brian Stansberry; Clebert Suconic; Dimitris Andreadis; Emmanuel Bernard; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; [EMAIL PROTECTED]; Kabir Khan; Ryan Campbell; Ruel Loehr; Scott M Stark; Thomas Diesler; Tom Elrod Subject: RE: jboss-4.0-testsuite Build Failed JBAS-3050 only waits if the deployment scanner's thread is busy deploying stuff. Something that clearly isn't the case here. At most it is going to wait 5 seconds if you are unlucky and the background thread just went to sleep. I don't see any problem shutting down minimal when done manually. 17:20:52,846 INFO [Server] JBoss (MX MicroKernel) [4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200604051409)] Started in 5s:879ms 17:20:54,768 INFO [Server] Runtime shutdown hook called, forceHalt: true 17:20:54,769 INFO [Server] JBoss SHUTDOWN: Undeploying all packages 17:20:57,878 INFO [Server] Shutdown complete On Wed, 2006-04-05 at 10:58 -0500, Rajesh Rajasekaran wrote: The all config fails to start because port 1098 is still in use by the minimal configuration which started up earlier. The minimal waits for 60 secs to completely shut down before which the all config starts. I guess this change is related to the following issue. http://jira.jboss.com/jira/browse/JBAS-3050 This can be verfied by running the testsuite manually. ant tests from the testsuite folder. This can be avoided by allowing the testsuite to wait for 60 secs or more before different configurations start up. Thanks Rajesh -Original Message- From: Adrian Brock Sent: Wednesday, April 05, 2006 6:51 AM To: QA Cc: Alexey Loubyansky; Amit Bhayani; Anil Saldhana; Bela Ban; Bill Burke; Brian Stansberry; Clebert Suconic; Dimitris Andreadis; Emmanuel Bernard; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; [EMAIL PROTECTED]; Kabir Khan; Rajesh Rajasekaran; Ryan Campbell; Ruel Loehr; Scott M Stark; Thomas Diesler; Tom Elrod Subject: Re: jboss-4.0-testsuite Build Failed Can somebody kill whatever is bound to port 1098 on this machine please. On Wed, 2006-04-05 at 07:46 -0400, [EMAIL PROTECTED] wrote: View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=l og20060405072327 BUILD FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:224: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:148: Exit code: 1 See tests.log in Build Artifacts for details. Date of build: 04/05/2006 07:23:27 Time to build: 21 minutes 29 seconds Last changed: 04/04/2006 17:29:53 -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
An undeployed class loader should probably still delegate to its parent
if it does not have a repository?
-Original Message-
From: Adrian Brock
Sent: Wednesday, April 05, 2006 9:42 AM
To: Scott M Stark
Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net
Subject: RE: jboss-4.0-testsuite Build Failed
Very interesting Mr Bond...
new Thread(new Runnable()
{
public void run()
{
System.exit(0);
}
}, ExitOnShutdown).start();
Can't do that either, because this cannot load a class from
the undeployed classloader. :-)
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
The minimal shutdown is very sensative to the implementation details of the server because there is no jmx invoker in this config. The shutdown relies on the behavior of a service undeployment calling System.exit so JBAS-3050 has likely changed how this behaves. I don't remember why this service could not use a jmx message instead. -Original Message- From: Rajesh Rajasekaran Sent: Wednesday, April 05, 2006 8:59 AM To: Adrian Brock; QA Cc: Alexey Loubyansky; Amit Bhayani; Anil Saldhana; Bela Ban; Bill Burke; Brian Stansberry; Clebert Suconic; Dimitris Andreadis; Emmanuel Bernard; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; [EMAIL PROTECTED]; Kabir Khan; Ryan Campbell; Ruel Loehr; Scott M Stark; Thomas Diesler; Tom Elrod Subject: RE: jboss-4.0-testsuite Build Failed The all config fails to start because port 1098 is still in use by the minimal configuration which started up earlier. The minimal waits for 60 secs to completely shut down before which the all config starts. I guess this change is related to the following issue. http://jira.jboss.com/jira/browse/JBAS-3050 This can be verfied by running the testsuite manually. ant tests from the testsuite folder. This can be avoided by allowing the testsuite to wait for 60 secs or more before different configurations start up. Thanks Rajesh --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
The problem is that ExitOnShutDown.java invokes exit() from stopService() this means the new code thinks the deployment thread is busy, because exit() never returns. I'll make stopService() fork a thread. On Wed, 2006-04-05 at 11:21 -0500, Scott M Stark wrote: The minimal shutdown is very sensative to the implementation details of the server because there is no jmx invoker in this config. The shutdown relies on the behavior of a service undeployment calling System.exit so JBAS-3050 has likely changed how this behaves. I don't remember why this service could not use a jmx message instead. -Original Message- From: Rajesh Rajasekaran Sent: Wednesday, April 05, 2006 8:59 AM To: Adrian Brock; QA Cc: Alexey Loubyansky; Amit Bhayani; Anil Saldhana; Bela Ban; Bill Burke; Brian Stansberry; Clebert Suconic; Dimitris Andreadis; Emmanuel Bernard; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; [EMAIL PROTECTED]; Kabir Khan; Ryan Campbell; Ruel Loehr; Scott M Stark; Thomas Diesler; Tom Elrod Subject: RE: jboss-4.0-testsuite Build Failed The all config fails to start because port 1098 is still in use by the minimal configuration which started up earlier. The minimal waits for 60 secs to completely shut down before which the all config starts. I guess this change is related to the following issue. http://jira.jboss.com/jira/browse/JBAS-3050 This can be verfied by running the testsuite manually. ant tests from the testsuite folder. This can be avoided by allowing the testsuite to wait for 60 secs or more before different configurations start up. Thanks Rajesh -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
Very interesting Mr Bond...
new Thread(new Runnable()
{
public void run()
{
System.exit(0);
}
}, ExitOnShutdown).start();
Can't do that either, because this cannot load a class from the
undeployed classloader. :-)
2006-04-05 17:36:57,751 DEBUG [org.jboss.deployment.MainDeployer]
Undeployed
file:/home/ejort/jboss-4.0/build/output/jboss-4.0.4.GA/server/minimal/deploy/shutdown.sar
2006-04-05 17:36:57,753 ERROR [STDERR] java.lang.NoClassDefFoundError:
java/lang/System
2006-04-05 17:36:57,753 ERROR [STDERR] at
org.jboss.test.jmx.shutdown.ExitOnShutdown$1.run(ExitOnShutdown.java:52)
2006-04-05 17:36:57,754 ERROR [STDERR] at
java.lang.Thread.run(Thread.java:534)
On Wed, 2006-04-05 at 17:33 +0100, Adrian Brock wrote:
The problem is that ExitOnShutDown.java
invokes exit() from stopService()
this means the new code thinks the deployment thread is busy,
because exit() never returns.
I'll make stopService() fork a thread.
On Wed, 2006-04-05 at 11:21 -0500, Scott M Stark wrote:
The minimal shutdown is very sensative to the implementation details of
the server because there is no jmx invoker in this config. The shutdown
relies on the behavior of a service undeployment calling System.exit so
JBAS-3050 has likely changed how this behaves. I don't remember why this
service could not use a jmx message instead.
-Original Message-
From: Rajesh Rajasekaran
Sent: Wednesday, April 05, 2006 8:59 AM
To: Adrian Brock; QA
Cc: Alexey Loubyansky; Amit Bhayani; Anil Saldhana; Bela Ban;
Bill Burke; Brian Stansberry; Clebert Suconic; Dimitris
Andreadis; Emmanuel Bernard; [EMAIL PROTECTED];
jboss-development@lists.sourceforge.net;
[EMAIL PROTECTED]; Kabir Khan; Ryan Campbell; Ruel Loehr;
Scott M Stark; Thomas Diesler; Tom Elrod
Subject: RE: jboss-4.0-testsuite Build Failed
The all config fails to start because port 1098 is still in
use by the minimal configuration which started up earlier.
The minimal waits for 60 secs to completely shut down before
which the all config starts. I guess this change is related
to the following issue.
http://jira.jboss.com/jira/browse/JBAS-3050
This can be verfied by running the testsuite manually. ant
tests from the testsuite folder.
This can be avoided by allowing the testsuite to wait for 60
secs or more before different configurations start up.
Thanks
Rajesh
--
Adrian Brock
Chief Scientist
JBoss Inc.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
On Wed, 2006-04-05 at 11:44 -0500, Scott M Stark wrote:
An undeployed class loader should probably still delegate to its parent
if it does not have a repository?
Agreed. Reflection didn't work either.
I've changed the minimal config to have
attribute name=StopTimeOut0/attribute
to temporarily workaround the issue.
-Original Message-
From: Adrian Brock
Sent: Wednesday, April 05, 2006 9:42 AM
To: Scott M Stark
Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net
Subject: RE: jboss-4.0-testsuite Build Failed
Very interesting Mr Bond...
new Thread(new Runnable()
{
public void run()
{
System.exit(0);
}
}, ExitOnShutdown).start();
Can't do that either, because this cannot load a class from
the undeployed classloader. :-)
--
Adrian Brock
Chief Scientist
JBoss Inc.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
I'll create a jira issue for the class loader behavior. -Original Message- From: Adrian Brock Sent: Wednesday, April 05, 2006 10:16 AM To: Scott M Stark Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net Subject: RE: jboss-4.0-testsuite Build Failed On Wed, 2006-04-05 at 11:44 -0500, Scott M Stark wrote: An undeployed class loader should probably still delegate to its parent if it does not have a repository? Agreed. Reflection didn't work either. I've changed the minimal config to have attribute name=StopTimeOut0/attribute to temporarily workaround the issue. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
The deployment is destroyed before the classloader. It is just that it left a thread lying around referencing the classloader. On Wed, 2006-04-05 at 12:33 -0500, Scott M Stark wrote: I do have to question why the class loader is destroyed before all deployments are though. I'll look into that as part of the JBAS-3063 issue. -Original Message- From: Scott M Stark Sent: Wednesday, April 05, 2006 10:24 AM To: Adrian Brock Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net Subject: RE: jboss-4.0-testsuite Build Failed I'll create a jira issue for the class loader behavior. -Original Message- From: Adrian Brock Sent: Wednesday, April 05, 2006 10:16 AM To: Scott M Stark Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net Subject: RE: jboss-4.0-testsuite Build Failed On Wed, 2006-04-05 at 11:44 -0500, Scott M Stark wrote: An undeployed class loader should probably still delegate to its parent if it does not have a repository? Agreed. Reflection didn't work either. I've changed the minimal config to have attribute name=StopTimeOut0/attribute to temporarily workaround the issue. -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-testsuite Build Failed
I do have to question why the class loader is destroyed before all deployments are though. I'll look into that as part of the JBAS-3063 issue. -Original Message- From: Scott M Stark Sent: Wednesday, April 05, 2006 10:24 AM To: Adrian Brock Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net Subject: RE: jboss-4.0-testsuite Build Failed I'll create a jira issue for the class loader behavior. -Original Message- From: Adrian Brock Sent: Wednesday, April 05, 2006 10:16 AM To: Scott M Stark Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net Subject: RE: jboss-4.0-testsuite Build Failed On Wed, 2006-04-05 at 11:44 -0500, Scott M Stark wrote: An undeployed class loader should probably still delegate to its parent if it does not have a repository? Agreed. Reflection didn't work either. I've changed the minimal config to have attribute name=StopTimeOut0/attribute to temporarily workaround the issue. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues
jboss.net module can't be removed due to the wonderful cvs modules behavior. I don't want a jboss-4.0.xv2 module alias definition. - JBoss.Net is not even included in the docs/examples now. Should it be removed from the 4.0.x module checkout? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 3 - Fordevelopers
Right. Every jira issue with a documentation check box should have an entry section in the highlights section of the release notes. Every jira issue with a compatibility check box should have an entry in the compatibility section. -Original Message- From: Adrian Brock Sent: Wednesday, April 05, 2006 4:16 AM To: jboss-development@lists.sourceforge.net Cc: The Core Subject: Re: [JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 3 - Fordevelopers You can already get this information from JIRA. Let's keep the process simple please. I already: 1) Describe the change on the JIRA task 2) Update and the relevant WIKI page and link it on the JIRA task 3) Mark the JIRA task as requiring a doco change I am not going to update an arbitrary number of web pages when the information is already available. If people kept their JIRA tasks to a description of the change rather than using them as discussion forums, it wouldn't be as hard to understand. e.g. You can already get this information from JIRA: comaptibility changes http://jira.jboss.com/jira/secure/IssueNavigator.jspa?view=rno testempMax=1 or doco changes required http://jira.jboss.com/jira/secure/IssueNavigator.jspa?view=rno testempMax=1 On Wed, 2006-04-05 at 05:49 -0500, Dimitris Andreadis wrote: Forgot also to mention that thing that should go in the admin guide should be linked from this JIRA task: http://wiki.jboss.org/wiki/Wiki.jsp?page=404UpgradeIssues --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues
We have to separate out jbossxb because of the jbossws dependency. This is already being integrated via a binary and that is all that needs to be done for the 4.0.4.GA release. All of the other breakup of common is a future thing. - Breakage of jboss commons. Is this the right time, or should do for 4.0.5. Aren't we already overloaded? Who How? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-head, Testsuite for all configuration fails
The 'all' target and the 'most' target are the same except that 'all' calls 'modules-all' and 'most' calls 'modules-most'. Anyone know the difference between the two (modules-all and modules-most)? Hany Mesha wrote: It turned out that build clean then build all doesn't copy jboss-remoting.jar to the server build lib directory causing this error. I overcome the issue by copying the above jar to build/output/jboss-5.0.0.alpha/server/all/lib directory. Now I see the error reported on cruise control but only on my linux machine. My windows machine is able to run without a problem. Hany Mesha On 4/5/06, *Tom Elrod* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Running the all config from a clean check out and build is fine (at least for booting). Running the testsuite does give an error when booting the all configuration (during jboss-all-config-tests target), but logs indicate is due to port 1098 already being in use. Saw the same on the cruisecontrol run - http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log. Not sure where the error you are seeing came from. Hany Mesha wrote: Hi all, When I run the test suite, it fails with the excpetion below. Is there a problem with head or is it just my env.? Thanks, Hany Mesha ==Begin=== 20:28:08,943 INFO [Server] Starting JBoss (MX MicroKernel)... 20:28:08,944 INFO [Server] Release ID: JBoss [Morpheus] 5.0.0.Alpha (build: CVSTag=HEAD date=200604041919) 20:28:08,946 INFO [Server] Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha 20:28:09,099 INFO [Server] Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/ 20:28:09,100 INFO [Server] Patch URL: null 20:28:09,282 INFO [Server] Server Name: default 20:28:09,283 INFO [Server] Server Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default 20:28:09,283 INFO [Server] Server Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha /server/default/ 20:28:09,283 INFO [Server] Server Temp Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default/tmp 20:28:09,284 INFO [Server] Root Deployment Filename: jboss-service.xml 20:28:10,072 INFO [ServerInfo] Java version: 1.5.0_03,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_03-b07,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] OS-System: Linux 2.6.5-7.243-default,i386 20:28:11,228 INFO [Server] Core system initialized 20:28:17,840 ERROR [BasicMBeanRegistry] Cannot register MBean java.lang.NoClassDefFoundError: [Lorg/jboss/remoting/InvokerLocator; at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.privateGetPublicMethods(Class.java:2488) at java.lang.Class.getMethods(Class.java:1406) at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:208) at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:224) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:203) at sun.reflect.GeneratedMethodAccessor1.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke (AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java :140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:262) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:668) at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431) at java.security.AccessController.doPrivileged(Native Method)
RE: [JBoss-dev] JBossCache 1.3.0.GA released
Is this (and the tutorial issue) not a good reason for 1.3.1.CR1? And then 1 week later, once we have a bug free release, we just rename (and retag it) as 1.3.1.GA. From: Ben Wang Sent: Tuesday, April 04, 2006 8:42 PM To: jboss-development@lists.sourceforge.net Cc: QA Subject: RE: [JBoss-dev] JBossCache 1.3.0.GA released I know this not good timing. :-) But during my work on migrating ejb3 sfsb passivation using JBossCache (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have discovered two bugs. And I will need these two fixed so I can check in my code in head. So first option is to create a patch and use that. Second option is use the snapshot in JBossCache and couting on that 1.4 release will be out soon. I am leaning towards the second option such that if there is any future bug fixes or enahncement then I can create another shapshot rightaway. What do people think? And how do I do that properly? Thanks, -Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajesh Rajasekaran Sent: Tuesday, April 04, 2006 6:04 AM To: jboss-development@lists.sourceforge.net Cc: QA Subject: [JBoss-dev] JBossCache 1.3.0.GA released JBossCache 1.3.0.GA Wasabi has been released and is available for download at http://sourceforge.net/project/showfiles.php?group_id=22866package_id=102339release_id=406920 JBossCache 1.3.0.GA has also been updated in the repository. Thanks Rajesh JBoss QA
[JBoss-dev] Client - server compatibility
Do we guarantee client-server compatibility between different JBoss revisions? In other words, is a client using 4.0.1 client jars guaranteed to connect without problems to a 4.0.4 server? How about the other way around (4.0.4 client jars to 4.0.1 server )? How about different minor versions (4.0 and 4.1)? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Client - server compatibility
Do we guarantee client-server compatibility between different JBoss revisions? After JBoss 4.0.2 3.2.8 we try to guarantee interoperability with previous (4.0.0/4.0.1) versions. In other words, is a client using 4.0.1 client jars guaranteed to connect without problems to a 4.0.4 server? In this case the 4.0.4 server will need to use -Dorg.jboss.j2ee.LegacySerialization due to serialization differences How about the other way around (4.0.4 client jars to 4.0.1 server )? Again in the client use -Dorg.jboss.j2ee.LegacySerialization How about different minor versions (4.0 and 4.1)? 4.0.2+ should be able to speak to 3.2.8 using -Dorg.jboss.j2ee.Serialization on the 3.2.8 side 4.0.2+ to prior to 3.2.8 version (e.g. 3.2.7) unlikely to work. I believe the goal primarily is to maintain interop between point releases (x.0.0 and x.0.1), and try to maintain interop when the minor version changes (e.g. x.0.0 and y.2.0) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues
jbossws1.0 should be a final release. I think the only thing holding back jbossretro from a final release is feedback on the efficacy based on the current jbossws14 in 4.0.4CR2. -Original Message- From: Dimitris Andreadis Sent: Wednesday, April 05, 2006 3:33 AM To: jboss-development Cc: The Core Subject: Toward JBoss v4.0.4.GA - Part 2 - Build/thirdparty Issues Importance: High Various Issues -- - Breakage of jboss commons. Is this the right time, or should do for 4.0.5. Aren't we already overloaded? Who How? - Which thirdparty libs can be removed? So far I've noticed apache-wss4j apache-jaxme. - JBoss.Net is not even included in the docs/examples now. Should it be removed from the 4.0.x module checkout? - The following jboss lists are *NOT* final (GA). What will be updated for 4.0.4.GA? Project leads speak! componentref name=hibernate version=3.2.0.CR1/ componentref name=hibernate-annotations version=3.1beta9/ componentref name=hibernate-entitymanager version=3.1beta7/ componentref name=javassist version=3.2.0.CR1/ componentref name=hibernate version=3.2.0.CR1/ componentref name=hibernate-annotations version=3.1beta9/ componentref name=hibernate-entitymanager version=3.1beta7/ componentref name=jboss/jbossretro version=1.0.0.CR1/ componentref name=jboss/jbossws version=1.0.0.CR6/ componentref name=jboss/jbossws14 version=1.0.0.CR6/ componentref name=jboss/jbossxb version=1.0.0.CR3/ componentref name=jboss/serialization version=1.0.0.CR4/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-3.2-testsuite build.243 Build Fixed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060405233748Lbuild.243 BUILD COMPLETE-build.243Date of build:04/05/2006 23:37:48Time to build:49 minutes 24 secondsLast changed:04/05/2006 17:48:26Last log entry:Upgrade to joesnmp 0.3.4 Unit Tests: (1851) Total Errors and Failures: (0)All Tests Passed Modifications since last build:(first 50 of 2)1.4.2.11modifieddimitrisbuild/build-thirdparty.xmlUpgrade to joesnmp 0.3.41.4.2.10modifieddimitrisbuild/build-thirdparty.xmltidy up
