RE: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file: (create mbean) state: instantiated (set attributes) state: configured (call create method) ~(call destroy method) state: created (call start method) ~(call stop method) state: started where the ~() methods go backwards from the other methods. Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it. Clustering needed this at least because of the state transfer algorithm: services must first be able to register with the HAPartition and once everyone has done that, the next step can be used to actually exchange the initial state. It was not (at that time, maybe it has changed) possible to make micro-state-transfer on a service-by-service basis. I think another service had a similar needs but I don't remember which one. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Friday, January 24, 2003, at 12:37 PM, Sacha Labourey wrote: Hello David, oh yes! This problem really involves all management parts i.e. how we want to be able to store the config, modify the config, have config repositories, etc. Furthermore, we need to take in account in this new design the really-missing-restart-feature which is not equivalent to the stop-start semantic. Why not? because otherwise, when you are in the stop state, you don't know if it is a definitive stop (in which case you shouln't block the valve for example) or a temporary stop (in which case you may want to give a way to a service/application to provide some temporary state that the service controller can give it back once the service is restarted for example) We must really implement the restart trick for 4.0 as it is one of the only way to cleanly implement the valve trick (block the valve for new invocations as we cycle the app/service). I was planning to move the dependency logic from ServiceController to ServiceContext and make ServiceContext an mbean interceptor. It would also block calls when state was not started. If you change a set of attributes, it would consult the metadata to see what lifecycle state it must downgrade to, go to it, and go back to started. Do you see something wrong with this plan? Well, then you cannot update the list of the JMX interceptors as you cycle your service, right? Otherwise, how do you cycle the ServiceContext interceptor? The ServiceContext has to exist whether or not it is currently part of an interceptor chain for a currently existing mbean, in order to record dependencies on mbeans that haven't been deployed yet. So I don't think changing the interceptor list will be a problem: you always get the ServiceContext from a centralized factory/store which returns the one it already knows about. At one point, independently of where do you manage that, I am pretty sure that you need a part of the system that thinks I do think in a specific way because it is a restart and not a definitive stop. You don't think so? The other way I can think of to handle this is with timeouts: any blocked call will eventually time out if the mbean isn't started first. Timeouts have the property that if something goes wrong in the restart the clients will be informed that there is a problem in a known amount of time. Many calls should be within a transaction anyway, which also times out... david jencks Cheers, sachay --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
David, Thanks so much. To paraphrase, there's basically a JBoss-specific MBean type that requires invoking stop() before setting any attributes and start() after doing so. This sounds quite reasonable. Thanks again. - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 9:00 PM To: [EMAIL PROTECTED] Cc: Subject: Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file: (create mbean) state: instantiated (set attributes) state: configured (call create method) ~(call destroy method) state: created (call start method) ~(call stop method) state: started where the ~() methods go backwards from the other methods. Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it. Anyway, to see why this might be useful, lets hypothesize an mbean that takes a long time to create (just as an object) and has a socket. You want to set the ip address and port on the socket as separate attributes on the mbean. Well, creating a new socket whenever you change the host or port is not very satisfactory since there's a good chance you want to change both. Changing just one will leave the mbean in a unusable state, pointing to the right host but wrong port. You don't want to replace the mbean object with a new one because it takes a long time to create. So , the service lifecycle lets you: stop (mbean is now theoretically unusable: this should be implemented in an interceptor, but is not right now)(this would discard the old socket) change both attributes (while the mbean is off) start (this creates a new socket with all correct parameters)(mbean is now usable again). There are also mbean dependencies, whereby if your mbean has an ObjectName valued attribute, and you tell jboss, your mbean can't start until the referenced mbean has started. This is used to get most of jboss to start in an order that will work. The code that does this is now spread over ServiceController, ServiceConfigurator, and ServiceContext with a little bit of ServiceCreator thrown in. Hope this clarifies what is going on a little bit. There are no attributes that have no effect... its just that say a port number may not get into the socket until you cycle the mbean, in case you want to change the host also. I also mentioned earlier that there's an xmbean attribute indicating what the effect on service lifecycle should be of changing an attribute value. The idea behind this (unimplemented) is that if you set several attributes at once, jboss should be able to cycle the lifecycle state for you. david jencks On Friday, January 24, 2003, at 05:07 PM, Matt Munz wrote: David, We are miscommunicating. In all the mbeans I have written and seen in jboss, aside from egregious bugs, if setting an attribute doesn't have an immediate effect, it does have the desired effect if you run through the service lifecycle (usually stop, start, occasionally stop, destroy, create, start). My view is that mbeans in jboss can take advantage of the service lifecycle. If you don't want to, make all your attribute changes have their effects immediately. All our mbeans are pretty much jboss specific and most heavily use the service lifecycle. They just won't run without it. I still think it is a really convenient extension to vanilla jmx and don't see why we should replace it. I barely know what the service lifecycle is. I have not used it. I am not arguing to replace it. I never said that. You said that. How do I set an attribute correctly, step by step, for a Bean that uses the service lifecycle? It helps me to use a state metaphor when considering lifecycle issues. It sounds like there are several states a lifecycle-oriented bean can be in: destroyed, created, running. In which state is it safe
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 25-January-2003
JBoss daily test results SUMMARY Number of tests run: 1010 Successful tests: 1007 Errors:2 Failures: 1 [time of test: 2003-01-25.12-05 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-25.12-05 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: how's ecperf going?
-Original Message- From: Stefan Reich [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 8:24 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: how's ecperf going? Hi Bill, I am running ecperf regularly on the 3.0 and 3.2 branches. I accumulated a bunch of fixes for scalability and performance problems already, plus a few fixes for inconsistent lock usage that I will merge soon. Here are some things I noticed: * the test fails when I deploy the BMP version, some of the beans that have been created don't seem to end up in the database. This is probably my fault. I was tweaking the shit out of the BMP stuff. * the CMP version must be tweaked to use the util.xml BMP version of the beans (search for SERIALIZABLE in the README) to work correctly * the CMP version doesn't deploy anymore on the current 3.2 branch I wonder if CMP 1.1 is finally trashedWas wondering when that would finally happen. * with the 3.2 branch I get many more spurious esceptions than with 3.0 * a HashMap in the class CachedConnectionManager seems to be the most contended lock * JAWS checks for the existence of a PK before inserting a new row in the database. This is pretty expensive. I guess if you have the correct table integrity checks, the DB will barf and the query is not needed. * the LogInterceptor usage of the NDC class makes it a global source of contention * TxInterceptorCMP suspends and resumes a transaction in all cases, sometimes even twice. This can be very expensive, especially with global transactions. ?? Can you point this out? Since I am running the tests on PowerPC Macs and the Apple VM it is hard to compare the results with other platforms. Stefan Stefan, this is great stuff! If you need any help, let me know and we'll get somebody to help you out. We really appreciate this work. Bill On Thursday, Jan 23, 2003, at 19:11 US/Pacific, Bill Burke wrote: Are you getting decent results? I heard from Scott that you've made some improvements. Need me to merge your changes at all? Just want to know what's up. Thanks, Bill Burke Chief Architect JBoss Group, LLC --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-674167 ] JBoss 3.0.5 running with Compaq Java 1.4.0
Bugs item #674167, was opened at 2003-01-24 09:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=674167group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Duplicate Priority: 5 Submitted By: John Stalker (jstalker) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss 3.0.5 running with Compaq Java 1.4.0 Initial Comment: I downloaded the src for jboss using the 3_0_5 tag and built it (all went fine) using Compaq's Java 1.4.0 on an alpha: uname -a = OSF1 iridium V5.1 1885 alpha alpha. I then fired up the server, only changing a few port numbers in the config file and get this output: JBoss Bootstrap Environment JBOSS_HOME: /home/iridium/prodinfo/tools/jboss JAVA: /usr/opt/java140/bin/java JAVA_OPTS: -DSQENV=jstalker -Dprogram.name=run.sh CLASSPATH: /home/iridium/prodinfo/tools/jboss/bin/run.jar:/usr/opt/java140/lib/tools.jar run.sh: unused non-option argument: 12:36:51,284 INFO [Server] JBoss Release: JBoss-3.0.5 CVSTag=JBoss_3_0_5 12:36:51,335 INFO [Server] Home Dir: /usr/home/prodinfo/tools/jboss-3.0.5 12:36:51,339 INFO [Server] Home URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/ 12:36:51,344 INFO [Server] Library URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/lib/ 12:36:51,357 INFO [Server] Patch URL: null 12:36:51,358 INFO [Server] Server Name: jstalker 12:36:51,360 INFO [Server] Server Home Dir: /usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker 12:36:51,362 INFO [Server] Server Home URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/ 12:36:51,365 INFO [Server] Server Data Dir: /usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/db 12:36:51,366 INFO [Server] Server Temp Dir: /usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/tmp 12:36:51,368 INFO [Server] Server Config URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/conf/ 12:36:51,369 INFO [Server] Server Library URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/lib/ 12:36:51,369 INFO [Server] Root Deployemnt Filename: jboss-service.xml 12:36:51,377 INFO [Server] Starting General Purpose Architecture (GPA)... 12:36:52,109 INFO [ServerInfo] Java version: 1.4.0,Compaq Computer Corp. 12:36:52,110 INFO [ServerInfo] Java VM: Fast VM 1.4.0-1,Compaq Computer Corp. 12:36:52,110 INFO [ServerInfo] OS-System: OSF1 V5.1,alpha 12:36:52,215 INFO [ServiceController] Controller MBean online 12:36:52,471 INFO [MainDeployer] Creating 12:36:52,540 INFO [MainDeployer] Created 12:36:52,546 INFO [MainDeployer] Starting 12:36:52,549 INFO [MainDeployer] Started 12:36:52,575 INFO [JARDeployer] Creating 12:36:52,576 INFO [JARDeployer] Created 12:36:52,580 INFO [JARDeployer] Starting 12:36:52,582 INFO [MainDeployer] Adding deployer: org.jboss.deployment.JARDeployer@80a3040 12:36:52,584 INFO [JARDeployer] Started 12:36:52,614 INFO [SARDeployer] Creating 12:36:52,615 INFO [SARDeployer] Created 12:36:52,617 INFO [SARDeployer] Starting 12:36:52,617 INFO [MainDeployer] Adding deployer: org.jboss.deployment.SARDeployer@80a72b9 12:36:52,652 INFO [SARDeployer] Started 12:36:52,652 INFO [Server] Core system initialized 12:36:52,660 INFO [MainDeployer] Starting deployment of package: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/conf/jboss-service.xml Java stack overflow in make_native_call for method init 12:36:55,081 ERROR [MainDeployer] could not create deployment: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/conf/jboss-service.xml org.jboss.deployment.DeploymentException: instantiating org.jboss.varia.property.PropertyEditorManagerService failed: java.lang.StackOverflowError; - nested throwable: (RuntimeErrorException: instantiating org.jboss.varia.property.PropertyEditorManagerService failed: java.lang.StackOverflowError Cause: java.lang.StackOverflowError) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:153) at org.jboss.system.ServiceController.install(ServiceController.java:231) 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:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy2.install(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:189) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:766) at
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: CatalinaBundle
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Scott M Stark (starksm)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
[JBoss-dev] [ jboss-Bugs-662569 ] 3.2.0beta3 src archive missing tools\lib
Bugs item #662569, was opened at 2003-01-05 04:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=662569group_id=22866 Category: Build System Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Paul W. Ward (pward) Assigned to: Nobody/Anonymous (nobody) Summary: 3.2.0beta3 src archive missing tools\lib Initial Comment: There's no tools\lib directory in the source archive for jboss 3.2.0 beta 3. I'm assuming I can just copy the directory over from the beta 2 release. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=662569group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ANN] JBoss JMX View Gui Betta
Dear Friends, I'm sorry to be so slow, but the normal JBoss development speed is nothing for hobby coder. ;-) Anyway a betta version of the JBoss JMX View Gui Plugin for Eclipse is released just in this minute. This eclipse plugin allow you to browse a unfiltered JBoss JMX tree in a eclipse view. Since this version, you can change MBean attributes. So far this plugin support: +String +int +long +boolean +ObjectName Operation invocation with this primitive datatypes is planed for the next release. Furthermore a graph for monitoring int and long values is planed. See release notes at: https://sourceforge.net/project/shownotes.php?release_id=131182 Download at: http://sourceforge.net/projects/jbossadmingui See screen shots: http://jbossadmingui.sourceforge.net/ Please report any bug to: http://sourceforge.net/tracker/?group_id=59214atid=490275 Please give any feedback to: http://sourceforge.net/forum/?group_id=59214 Please vote no war at: http://www.votenowar.org Thank you! Regards Stefan --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 25-January-2003
JBoss daily test results SUMMARY Number of tests run: 1026 Successful tests: 1023 Errors:2 Failures: 1 [time of test: 2003-01-25.17-30 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-25.17-30 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Cepte Eglence Asil Simdi Basliyor!
Title: MELODI GRAFIK DUYURU www.melodilerim.com / www.grafiklerim.com Merhaba, Melodilerim.Com ve Grafiklerim.Com'dan haberiniz var mý ? Cep telefonlarýnýz için en geniþ melodi arþivi, 1800 melodi...Üstelik sürekli güncelleniyor. Ýþte "Ne Oldu Can - Kayahan" ve "Sen Yoluna Ben Yoluma - Çelik"...Daha albümleri taptazeyken melodileri Melodilerim.Com'da ! Cep telefonlarýnýzýn ekranlarýný þenlendirecek binlerce logo, resimli mesaj, extra-large logo ve hareketli resimler...Hepsi Grafiklerim.Com'da ! Üstelik bu melodi ve logolar cebinize tek bir mesajla çok kolay geliyor... Rengarenk, pýrýl pýrýl sitelerimiz sizleri bekliyor ! Mutlu Günler SMSNET Ekibi Melodi isteðinde bulunmak istiyorum!Resmimi telefonumda görmek istiyorum! Yardým hattýmýz: 0 312 2865891 (her gün 9.00 - 19.30 arasý) Duyuru listemizden çýkmak için lütfen týklayýnýz...To be removed from our mailing list, please click here... --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
