[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 23-July-2002
Number of tests run: 669
Successful tests: 663
Errors:6
Failures: 0
[time of test: 23 July 2002 0:30 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
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.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-585372 ] Console appender looping
Bugs item #585372, was opened at 2002-07-23 12:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585372group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Laurence Smith (lasmith) Assigned to: Nobody/Anonymous (nobody) Summary: Console appender looping Initial Comment: I have searched the forums and found there is a known issue when you try and configure log4j twice in that the console appender loops (I couldn't find a bug report though). This causes the logging to the console to stop completely and gradually eats up resources i assume. I have also come accross the same problem when you configure the mbean for the log4j service by calling the constructor (String, int) in jboss.conf. This is so log4j uses the 'configure and watch' API. This is to allow me to turn debugging on and off at runtime (useful if you aren't allowed to take the site down). Here is the line in jboss.conf: MLET CODE = org.jboss.logging.Log4jService ARCHIVE=jboss.jar,log4j.jar CODEBASE=../../lib/ext/ ARG TYPE=java.lang.String VALUE=log4j.properties ARG TYPE=int VALUE=5 /MLET this appears to work ok, however when it comes to reloading the config file after a change the console appenders goes into its infinite loop. I am assuming this is a JBoss issue I have quickly looked at the source, Log4jService.java and cant see anything blatently obvious, so perhaps it is a log4j issue. I tried upgrading log4j to 1.2.5 but still had the same problem. I am running JBoss 2.7 (I would have entered it in the by the way, though I encountered the first problem on 3 aswell. ls -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585372group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] problems with JBossMQ
Hi, something wrong with jboss.mq in the current cvs version. After building jboss starts and runs fine. But if some message is sent to the topic/testTopic next time jboss starts with the following trace: 2002-07-23 18:46:12,409 WARN [org.jboss.system.ServiceController] Problem starting service jboss.mq:service=PersistenceManager java.lang.IllegalAccessError: try to access class org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener from class org.jboss.resource.connectionmanager.LocalTxConnectionManager at org.jboss.resource.connectionmanager.LocalTxConnectionManager.registerConnectionEventListener(LocalTxConnectionManager.java:229) at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:534) at org.jboss.resource.connectionmanager.LocalTxConnectionManager.getManagedConnection(LocalTxConnectionManager.java:224) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:595) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:874) at org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection(LocalDataSource.java:102) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:212) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1088) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:937) at $Proxy10.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:378) at org.jboss.system.ServiceController.start(ServiceController.java:392) at org.jboss.system.ServiceController.start(ServiceController.java:392) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.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:304) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:177) at $Proxy13.start(Unknown Source) at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:220) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:804) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:634) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:599) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.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(URLDeploymentScanner.java:381) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentScanner.java:576) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:449) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:187) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:254) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:937) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:378) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at
Re: [JBoss-dev] Hypersonic 1.7 final released
They have a new config file where a variable embedded can be set to true. /p on 22-07-2 23.31, Jason Dillon at [EMAIL PROTECTED] wrote: Do we know if they have implemented better support for embedded use? I remember Peter (or someone) saying they were considering using our patch for this, but who knows. It would be nice if they have some option so we don't have to hack it up to embed it properly... perhaps it won't spit out to STDOUT anymore too. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Sunday, July 21, 2002 2:26 PM To: JBoss-dev Subject: [JBoss-dev] Hypersonic 1.7 final released Hypersonic 1.7 final was released. Does anyone want to work on integrating it? I am excited to get this working. I want to try to get commit option A with stored procedure cache update notifications. Should be super fast. -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] problems with JBossMQ
Hmmm, I was getting similar errors yesterday when JBossManagedConnectionPool tried to access its inner classes. All I could find to to was make the inner classes public. Anyone have any ideas what's going on? Are there 2 copies of these classes loaded which is interfering with package visibility??? david jencks On 2002.07.23 12:04:33 -0400 Alex Loubyansky wrote: Hi, something wrong with jboss.mq in the current cvs version. After building jboss starts and runs fine. But if some message is sent to the topic/testTopic next time jboss starts with the following trace: 2002-07-23 18:46:12,409 WARN [org.jboss.system.ServiceController] Problem starting service jboss.mq:service=PersistenceManager java.lang.IllegalAccessError: try to access class org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener from class org.jboss.resource.connectionmanager.LocalTxConnectionManager at org.jboss.resource.connectionmanager.LocalTxConnectionManager.registerConnectionEventListener(LocalTxConnectionManager.java:229) at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:534) at org.jboss.resource.connectionmanager.LocalTxConnectionManager.getManagedConnection(LocalTxConnectionManager.java:224) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:595) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:874) at org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection(LocalDataSource.java:102) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:212) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1088) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:937) at $Proxy10.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:378) at org.jboss.system.ServiceController.start(ServiceController.java:392) at org.jboss.system.ServiceController.start(ServiceController.java:392) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.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:304) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:177) at $Proxy13.start(Unknown Source) at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:220) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:804) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:634) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:599) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.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(URLDeploymentScanner.java:381) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentScanner.java:576) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:449) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:187) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:254) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at
Re: [JBoss-dev] problems with JBossMQ
It could be a problem with the newer package based class loading index if somehown the inner class is not resolving to the same class loader as the outer class. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 23, 2002 11:23 AM Subject: Re: [JBoss-dev] problems with JBossMQ Hmmm, I was getting similar errors yesterday when JBossManagedConnectionPool tried to access its inner classes. All I could find to to was make the inner classes public. Anyone have any ideas what's going on? Are there 2 copies of these classes loaded which is interfering with package visibility??? david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-585372 ] Console appender looping
Bugs item #585372, was opened at 2002-07-23 12:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585372group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Laurence Smith (lasmith) Assigned to: Nobody/Anonymous (nobody) Summary: Console appender looping Initial Comment: I have searched the forums and found there is a known issue when you try and configure log4j twice in that the console appender loops (I couldn't find a bug report though). This causes the logging to the console to stop completely and gradually eats up resources i assume. I have also come accross the same problem when you configure the mbean for the log4j service by calling the constructor (String, int) in jboss.conf. This is so log4j uses the 'configure and watch' API. This is to allow me to turn debugging on and off at runtime (useful if you aren't allowed to take the site down). Here is the line in jboss.conf: MLET CODE = org.jboss.logging.Log4jService ARCHIVE=jboss.jar,log4j.jar CODEBASE=../../lib/ext/ ARG TYPE=java.lang.String VALUE=log4j.properties ARG TYPE=int VALUE=5 /MLET this appears to work ok, however when it comes to reloading the config file after a change the console appenders goes into its infinite loop. I am assuming this is a JBoss issue I have quickly looked at the source, Log4jService.java and cant see anything blatently obvious, so perhaps it is a log4j issue. I tried upgrading log4j to 1.2.5 but still had the same problem. I am running JBoss 2.7 (I would have entered it in the by the way, though I encountered the first problem on 3 aswell. ls -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585372group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-585372 ] Console appender looping
Bugs item #585372, was opened at 2002-07-23 12:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585372group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Laurence Smith (lasmith) Assigned to: Nobody/Anonymous (nobody) Summary: Console appender looping Initial Comment: I have searched the forums and found there is a known issue when you try and configure log4j twice in that the console appender loops (I couldn't find a bug report though). This causes the logging to the console to stop completely and gradually eats up resources i assume. I have also come accross the same problem when you configure the mbean for the log4j service by calling the constructor (String, int) in jboss.conf. This is so log4j uses the 'configure and watch' API. This is to allow me to turn debugging on and off at runtime (useful if you aren't allowed to take the site down). Here is the line in jboss.conf: MLET CODE = org.jboss.logging.Log4jService ARCHIVE=jboss.jar,log4j.jar CODEBASE=../../lib/ext/ ARG TYPE=java.lang.String VALUE=log4j.properties ARG TYPE=int VALUE=5 /MLET this appears to work ok, however when it comes to reloading the config file after a change the console appenders goes into its infinite loop. I am assuming this is a JBoss issue I have quickly looked at the source, Log4jService.java and cant see anything blatently obvious, so perhaps it is a log4j issue. I tried upgrading log4j to 1.2.5 but still had the same problem. I am running JBoss 2.7 (I would have entered it in the by the way, though I encountered the first problem on 3 aswell. ls -- Comment By: Laurence Smith (lasmith) Date: 2002-07-23 19:18 Message: Logged In: YES user_id=261097 Sorry I meant JBoss 2.4.7 ls -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585372group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Please support Option B
What is that notifications on A scheme marc is talking about? Dan Christopherson wrote: OK, so it's more a matter of allowing multiple bean instances. Once that's there, B or C doesn't really matter - the extra overhead implied by C is noise compared to the database read (which you need either way). Of course, anybody that can use option A should. -danch Bill Burke wrote: Yes, Tom, be more specific. I know you're smarter than that. You're probably talking about the Instance per Transaction locking scheme. This works fine with commit-option 'B'. Yes, it is not totally optimized, but is does pool dead instances. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Christopherson Sent: Friday, July 19, 2002 10:08 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Please support Option B Whahuh? JBoss doesn't support option B? Tom M. Yeh wrote: Dear All, According to the CSIRO report (http://www.cmis.csiro.au/adsat/jboss.htm), JBoss is doing well with Stateless session beans. It implies reflection, by comparing to static compiled codes, doesn't affect the performance much, while it has great architectural advantages such as pluggable interceptors. However, entity beans is not the case. One of the reason, I think, is this report uses Option B, which JBoss doesn't support (and uses Option C instead). In other words, all beans are trashed after a transaction is completed. It then introduces a lot of overhead since every transaction has to reload all beans involved from database (and you know accessing database kills the performance). After examining the codes and a few talks with Bill, I don't think I am capable to modify the codes to support Option B. Any volunteer is willing to do that? Thanks and Regards, Tom --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 23-July-2002
Number of tests run: 669
Successful tests: 663
Errors:6
Failures: 0
[time of test: 23 July 2002 12:36 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
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.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Hypersonic 1.7 final released
But can we embed by api? Or do we still have to call some main(String[] args) ? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Peter Fagerlund Sent: Tuesday, July 23, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Hypersonic 1.7 final released They have a new config file where a variable embedded can be set to true. /p on 22-07-2 23.31, Jason Dillon at [EMAIL PROTECTED] wrote: Do we know if they have implemented better support for embedded use? I remember Peter (or someone) saying they were considering using our patch for this, but who knows. It would be nice if they have some option so we don't have to hack it up to embed it properly... perhaps it won't spit out to STDOUT anymore too. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Sunday, July 21, 2002 2:26 PM To: JBoss-dev Subject: [JBoss-dev] Hypersonic 1.7 final released Hypersonic 1.7 final was released. Does anyone want to work on integrating it? I am excited to get this working. I want to try to get commit option A with stored procedure cache update notifications. Should be super fast. -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD WonderLand) Testsuite Results: 24-July-2002
Number of tests run: 848 Successful tests: 383 Errors:450 Failures: 15 [time of test: 24 July 2002 0:57 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_jdk131_03 for the junit report of this test. - http://lubega.com/testarchive/sun_jdk131_03/logs/ for the logs for this test. - http://lubega.com for general test information. 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. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Hypersonic 1.7 final released
on 23-07-2 23.01, Jason Dillon at [EMAIL PROTECTED] wrote: But can we embed by api? Or do we still have to call some main(String[] args) ? install new 1.7.0 hsqldb.zip in lib as desribed in hsqldb_home/doc/hsqlAdvancedGuide.html create a file named server.properties add values : server.database=default server.silent=true server.trace=false server.port=1476 server.no_system_exit=true recompile mbean to use hsqldb.Server instead of hsqldb.Embedded_Server run as usual ... or just do this ... in the hsqldb-service.xml file -change the DefaultDS jdbc:hsqldb:http://localhost:1476 to jdbc:hsqldb:. -comment out the hsqldb mbean code You should now be running in memory without files main() sockets ... Have not verified with curent version's ... /p --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why XAExceptions are ignored?
Hi, Igor Fedorenko wrote: Out of curiosity, it there a reason why (at least some of) XAExceptions are ignored? For example, consider following scenario: The methods enlistResource() and delistResource() should both return false in case of an XAException. During transaction completion, when XAResources are ended, the transaction should roll back in case of an XAException. And during the prepare phase, XAExceptions denoting heuristics are caught and remembered, and all XAExceptions except the heuristic commit exception cause the transaction to roll back. At last, during the commit phase, only heuristics are remembered. Other XAExceptions are only logged, since it would be too late to do anything about them anyway; besides, the only other XAExceptions possible here denote internal resource problems, and protocol violations. I do not think throwing an EJBException from our JTA service is an option, since we cannot rely on such exception being thrown without hacking all JTA implementations that work with JBoss. Client calls ejb that is supposed to perform some db update, call another ejb and return some response to the client. Somewhere alone the line XAException occured (to be more specific, TxCapsule could not attach db connection allocated by second ejb to the transaction). Despite of the problem the client recieves normal response from first ejb. That looks like the return value from tx.enlistResource() is ignored, so that the application server does not know that the transaction could not be enlisted. A quick grep of the current CVS HEAD sources seem to indicate that the return values of enlistResource() and delistResource() are ALWAYS ignored. That is IMHO where the bug is. Best Regards, Ole Husgaard. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-585632 ] Problem with XA and Oracle
Bugs item #585632, was opened at 2002-07-23 22:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585632group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Igor Fedorenko (igorfie) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with XA and Oracle Initial Comment: org.jboss.tm.TxCapsule#enlistResource(XAResource) has an optimization that is not compatible with Oracle. The problem occurs only when more then one connections to same database server try to participate in same distributed transaction. Here what happens 1. First db connection joins transaction; TxCapsules sees new resource manager/transaction pair and calls XAResource#start(xid1, XAResource.TMNOFLAGS); everything works fine. 2. When second db connection tries to join the transaction TxCapsule sees same RM/transaction pair and tries to call XAResource#start(xid1, XAResource.TMJOIN) to attach second connection to the transaction. This is not supported by Oracle and the call fails with XA_RETRY error code. It should be possible to turn this optimization on/off on per RM basis. As a temporary workaround I would disable this optimization (unless some other RM does not work without it). I am running Branch_3_0 on Win2k, JDK 1.3.1_04, Oracle 8173. -- Comment By: Ole Husgaard (sparre) Date: 2002-07-24 00:57 Message: Logged In: YES user_id=175257 This is yet another problem with the Oracle driver. Please report it to Oracle - I think they loose market share big time because they do not conform to the JTA specification, and because they are so slow to fix these bugs. Currently I can only recommend against using Oracle with Java, because of this. But just like with the 8.1.5 All XIDs are belong to us-bug, that we got around by adding extra code, it might be possible to add some code that checks if the XAResource class is one of the Oracle classes that have this problem. Unfortunately that may give us yet another Oracle problem once they fix their bug, since TMJOIN _must_ be used here, according to JTA. Best Regards, Ole husgaard. -- Comment By: David Jencks (d_jencks) Date: 2002-07-23 23:20 Message: Logged In: YES user_id=60525 What does work with Oracle? Does it require all work on one tx go over the same connection or that other connections' XAResource get started with TMNOFLAGS or TMRESUME or ??? I've been considering writing a new XA ConnectionManager that would tie managedConnections to transactions, at least until you run out, to reduce the amount of enlist/delist activity. What do you think are the chances of this proposal solving the problem you have identified? My understanding is that calling TMJOIN is the spec required behavior, so I would expect it to break other drivers. However I find this area difficult to pin down as far as spec requirements. Thanks david jencks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585632group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] problems with JBossMQ
Alex Loubyansky wrote: something wrong with jboss.mq in the current cvs version. After building jboss starts and runs fine. But if some message is sent to the topic/testTopic next time jboss starts with the following trace: 2002-07-23 18:46:12,409 WARN [org.jboss.system.ServiceController] Problem starting service jboss.mq:service=PersistenceManager java.lang.IllegalAccessError: try to access class org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener from class org.jboss.resource.connectionmanager.LocalTxConnectionManager Really annoying. It has been bugging me all day, and I still haven't a clue about where the problem is. Also, this makes over half of the HEAD testsuite fail with errors. Best Regards, Ole Husgaard. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-585678 ] set value ignored on CMP bean self call
Bugs item #585678, was opened at 2002-07-23 18:22
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=585678group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Swinth (jswinth)
Assigned to: Nobody/Anonymous (nobody)
Summary: set value ignored on CMP bean self call
Initial Comment:
Given two beans, one CMP and one stateless session
bean, self calls to setDateField are sometimes ignored
when session bean has previously called setDateField in
same transaction.
CMP bean methods:
public abstract java.util.Date getDateField() ;
public abstract void setDateField(java.util.Date);
public void updateDateField() {
Calendar cal = Calendar.getInstance() ;
cal.setTime(getDateField());
cal.add(Calendar.DAY_OF_MONTH,1);
setDateField(cal.getTime());
}
Session bean method:
public void updateCMPBean() {
CMPBeanLocal cmpBean = ... ;
cmpBean.setDateField(new java.util.Date());
cmpBean.updateDateField();
}
If the transaction ends after calling updateCMPBean
then the dateField will be equal to today instead of
tomorrow. If getDateField() is called after
updateCMPBean and before the transaction ends then the
dateField will be correct.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=585678group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-585632 ] Problem with XA and Oracle
Bugs item #585632, was opened at 2002-07-23 18:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585632group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Igor Fedorenko (igorfie) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with XA and Oracle Initial Comment: org.jboss.tm.TxCapsule#enlistResource(XAResource) has an optimization that is not compatible with Oracle. The problem occurs only when more then one connections to same database server try to participate in same distributed transaction. Here what happens 1. First db connection joins transaction; TxCapsules sees new resource manager/transaction pair and calls XAResource#start(xid1, XAResource.TMNOFLAGS); everything works fine. 2. When second db connection tries to join the transaction TxCapsule sees same RM/transaction pair and tries to call XAResource#start(xid1, XAResource.TMJOIN) to attach second connection to the transaction. This is not supported by Oracle and the call fails with XA_RETRY error code. It should be possible to turn this optimization on/off on per RM basis. As a temporary workaround I would disable this optimization (unless some other RM does not work without it). I am running Branch_3_0 on Win2k, JDK 1.3.1_04, Oracle 8173. -- Comment By: Igor Fedorenko (igorfie) Date: 2002-07-23 21:59 Message: Logged In: YES user_id=232950 Oracle wants separate transaction branch for each db connection (TMNOFLAGS, same global transaction id, different branch qualifiers). You should also check for XA_RDONLY status from XAResource#prepare (I think this complies with the spec). You can find an appropriate example here http://www.oracle.co.jp/o8i/JServer/sources/jdbc/demo /samples/oci8/jdbc20-samples/XA3.java.txt. I agree that TMJOIN is suggested but I do not see why starting different transaction branches for each db connection would break the spec. As for suggested XA ConnectionManager it should work fine with oracle. Btw, does JBOSS share state of transaction among nodes of a cluster? If second connection was obtained on a different node would JBOSS still use TMJOIN? -- Comment By: Ole Husgaard (sparre) Date: 2002-07-23 20:57 Message: Logged In: YES user_id=175257 This is yet another problem with the Oracle driver. Please report it to Oracle - I think they loose market share big time because they do not conform to the JTA specification, and because they are so slow to fix these bugs. Currently I can only recommend against using Oracle with Java, because of this. But just like with the 8.1.5 All XIDs are belong to us-bug, that we got around by adding extra code, it might be possible to add some code that checks if the XAResource class is one of the Oracle classes that have this problem. Unfortunately that may give us yet another Oracle problem once they fix their bug, since TMJOIN _must_ be used here, according to JTA. Best Regards, Ole husgaard. -- Comment By: David Jencks (d_jencks) Date: 2002-07-23 19:20 Message: Logged In: YES user_id=60525 What does work with Oracle? Does it require all work on one tx go over the same connection or that other connections' XAResource get started with TMNOFLAGS or TMRESUME or ??? I've been considering writing a new XA ConnectionManager that would tie managedConnections to transactions, at least until you run out, to reduce the amount of enlist/delist activity. What do you think are the chances of this proposal solving the problem you have identified? My understanding is that calling TMJOIN is the spec required behavior, so I would expect it to break other drivers. However I find this area difficult to pin down as far as spec requirements. Thanks david jencks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=585632group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] classloading question
Hi, I am writing special deployer that needs to add some support jar files to a classpath of a module being deployed (almost like with manifest.mf but the list of jar files is kept in a different format). I checked how MainDeployer handles manifest.mf and tried to do similar thing - for each additional jar file I create/deploy sub-DeploymentInfo in deployer's init method. I'm getting following deployment structure DeploymentInfo d0 (url=file:///c:/ejb/classes/, deployer=JARDeployer) + DeploymentInfo d1 (url=file:///c:/support1/classes /, deployer=JARDeployer) Although all these deployments are reported as deployed by MainDeployer mbean, my module does not see support classes. I have couple of question here. First of all - am I moving into right direction or it is not that easy to put jar files on a classpath? Second, what code is actually setting classpath of a deployment? I spent few hours hunting for it but still have no clue. Any help is appreciated. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] problems with JBossMQ
Scott suggested it might be a problem with one of the recent classloader changes, that sorts classes by package, getting confused by inner class names. I haven't had time to take a look, probably won't till the weekend. david jencks On 2002.07.23 21:09:51 -0400 Ole Husgaard wrote: Alex Loubyansky wrote: something wrong with jboss.mq in the current cvs version. After building jboss starts and runs fine. But if some message is sent to the topic/testTopic next time jboss starts with the following trace: 2002-07-23 18:46:12,409 WARN [org.jboss.system.ServiceController] Problem starting service jboss.mq:service=PersistenceManager java.lang.IllegalAccessError: try to access class org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener from class org.jboss.resource.connectionmanager.LocalTxConnectionManager Really annoying. It has been bugging me all day, and I still haven't a clue about where the problem is. Also, this makes over half of the HEAD testsuite fail with errors. Best Regards, Ole Husgaard. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] classloading question
I'm not sure why what you are trying doesn't work. You might take a look at the ClassPathExtension mbean I wrote recently which you can use to put anything in the classpath. system/src/main/org/jboss/deployment/ClassPathExtension.java. Looks like right now it is only in Branch_3_0 david jencks On 2002.07.23 23:44:39 -0400 Igor Fedorenko wrote: Hi, I am writing special deployer that needs to add some support jar files to a classpath of a module being deployed (almost like with manifest.mf but the list of jar files is kept in a different format). I checked how MainDeployer handles manifest.mf and tried to do similar thing - for each additional jar file I create/deploy sub-DeploymentInfo in deployer's init method. I'm getting following deployment structure DeploymentInfo d0 (url=file:///c:/ejb/classes/, deployer=JARDeployer) + DeploymentInfo d1 (url=file:///c:/support1/classes /, deployer=JARDeployer) Although all these deployments are reported as deployed by MainDeployer mbean, my module does not see support classes. I have couple of question here. First of all - am I moving into right direction or it is not that easy to put jar files on a classpath? Second, what code is actually setting classpath of a deployment? I spent few hours hunting for it but still have no clue. Any help is appreciated. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
