[JBoss-dev] [ jboss-Bugs-690506 ] 3.2.0RC2 xa_start error -8 with SQLServer
Bugs item #690506, was opened at 2003-02-21 00:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690506&group_id=22866 Category: JBossTX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Marc Prud'hommeaux (mprudhom) Assigned to: Nobody/Anonymous (nobody) Summary: 3.2.0RC2 xa_start error -8 with SQLServer Initial Comment: When attempting to commit an XA transaction using SQLServer (using the MS driver, configured using the mssql-xa-ds.xml DS configured in the examples), it works fine the first time. The second time, it throws "javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_start (0) returns -8". According to section 4.5 of the X/Open XA specification, -8 indicates "the XID already exists", which indicates that JBoss may be re-using XIDs inappropriately. The exact same code worked for JBoss 3.2.0 beta 3. System info: [chance mprudhom]$ java -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root_1.3.1_020714-12:46) Java HotSpot(TM) Client VM (build 1.3.1_03-69, mixed mode) [chance mprudhom]$ uname -a Darwin chance.local. 6.4 Darwin Kernel Version 6.4: Wed Jan 29 18:50:42 PST 2003; root:xnu/xnu-344.26.obj~1/RELEASE_PPC Power Macintosh powerpc Stack trace: 19:29:19,487 WARN [TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=chance.local.//8, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_start (0) returns -8 at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source) at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.start(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.start(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:110) at org.jboss.tm.TransactionImpl.startResource(TransactionImpl.java:1137) at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:624) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:461) at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:359) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:546) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:837) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102) at com.solarmetric.kodo.impl.jdbc.runtime.DataSourceConnector.getConnection(DataSourceConnector.java:61) at com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFactory.java:179) at com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfiguration.java:336) at com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClassInternal(JDBCPersistenceManagerFactory.java:454) at com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClass(JDBCPersistenceManagerFactory.java:337) at com.solarmetric.kodo.impl.jdbc.RegisterListener.registerClass(RegisterListener.java:53) at javax.jdo.spi.JDOImplHelper.registerClass(JDOImplHelper.java:269) at com.solarmetric.kodo.runtime.AllFieldTypesTest.(AllFieldTypesTest.java) at XAEnvironmentTest.testXATransaction(XAEnvironmentTest.java:99) at XAEnvironmentTest.testXATransaction(XAEnvironmentTest.java:72) at XAEnvironmentTest.start(XAEnvironmentTest.java:323) 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:966) at $Proxy11.start(Unknown Source) 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:231) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:639) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:612) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.cap
[JBoss-dev] JBoss 3.2 xdoclet support
I updated xdoclet to use the 3.2 cmp2 dtd if requested and tried to update the template to include the new elements, in particular optimistic locking and audit fields. I'd really appreciate some feedback on whether this actually works before I update the jb4 cvs copy of xdoclet. Remember that in jb 4 you can get and compile a copy of xdoclet by going to the xdoclet module and running ./build.sh You may need to remove old last.xdoclet.build and last.xdoclet.update files to get a proper cvs update. I still have no plans to upgrade the xdoclet used to build 3.2 Thanks david jencks --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD Matrix2) Testsuite Results: 20-February-2003
JBoss daily test results SUMMARY Number of tests run: 1086 Successful tests: 1020 Errors:46 Failures: 20 [time of test: 2003-02-20.22-35 GMT] [java.version: 1.4.1_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_01-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] See http://users.jboss.org/~starksm/HEAD/2003-02-20.22-35 for the junit report 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: BankStressTestCase Test:testTeller(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: BankStressTestCase Test:testBank(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: BankStressTestCase Test:testMultiThread(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: BankStressTestCase Test:testTransaction(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: BankStressTestCase Test:testTransfer(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: BankStressTestCase Test:testReadOnly(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: BankStressTestCase Test:testPassivation(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: BankStressTestCase Test:testFinder(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: BankStressTestCase Test:testServerFound(org.jboss.test.bankiiop.test.BankStressTestCase) Type:error Exception: java.rmi.RemoteException Message: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No - Suite: CircularityUnitTestCase Test: testDuplicateClass(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.RuntimeMBeanException Message: java.lang.NullPointerException - Suite: CircularityUnitTestCase Test:testUCLOwner(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.RuntimeMBeanException Message: java.lang.IllegalStateException: T1 failed to load Class2 - Suite: CircularityUnitTestCase Test:testLoading(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.RuntimeMBeanException Message: java.lang.Il
[JBoss-dev] [ jboss-Patches-690364 ] local-directory not working on expanded SAR
Patches item #690364, was opened at 2003-02-20 16:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=690364&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Callies (pcallies) Assigned to: Nobody/Anonymous (nobody) Summary: local-directory not working on expanded SAR Initial Comment: To prove this, modify the jboss-service.xml deployment descriptor in the C:\jboss-3.0.6\server\all\deploy\http- invoker.sar to start as follows: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=690364&group_id=22866 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 20-February-2003
JBoss daily test results SUMMARY Number of tests run: 1043 Successful tests: 1038 Errors:2 Failures: 3 [time of test: 2003-02-20.12-08 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.4] See http://users.jboss.org/~starksm/Branch_3_0/2003-02-20.12-08 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: 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: SecurityUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: SecurityUnitTestCase Test: testSecureHttpInvokerFailure(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: HelloClusteredHttpStressTestCase Test:testCNFEObject(org.jboss.test.hello.test.HelloClusteredHttpStressTestCase) Type:error Exception: java.rmi.ServerException Message: Service unavailable last exception: - --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-690177 ] JBoss startup does not work under linux
Bugs item #690177, was opened at 2003-02-20 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690177&group_id=22866 Category: JBoss-IDE Group: None Status: Open Resolution: None Priority: 9 Submitted By: Hans Dockter (hans_d) Assigned to: Hans Dockter (hans_d) Summary: JBoss startup does not work under linux Initial Comment: JBoss 3.2 from cThis bug was mentioned in the froum by Bernd Koeke and others: Eclipse 2.1 M5 Both on Sun JDK 1.4.1_01 SuSE Linux 8.0 I have one JBoss outside the workspace, which I build by hand with build.sh and I use tomcat41 (tomcat 4.1.18 LE jdk1.4). Another JBoss 3.2 is checked out in eclipse for debugging. When I start JBoss by run.sh with a run.conf for remote debugging, e.g. on port 8000 and configure "JBoss remote" it works. But when I want to start it with a "JBoss 3.x" configuration I get the following message in a popup: "org.eclipse.core.runtime.CoreException Could not connect to VM" and in the console window: "Exception in thread "main" java.lang.NoClassDefFoundError:" -- Comment By: John Schult (jdschult) Date: 2003-02-20 15:59 Message: Logged In: YES user_id=491610 An additional configuration that produces same behavior is: RH Linux 8.0 Sun JDK 1.3.1 JBoss 2.4.4 Eclipse M5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690177&group_id=22866 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ³Ì·s°ê»Ú¦æ¾Pemail¦W³æ ¤T¤d¤C¦Ê¤¤Q¸Uµ§
Title: HTML PAGE
¡@
³Ì·s°ê»Ú¦æ¾Pemail¦W³æ
¥þ¥@¬É¦@3750¸Uµ§
¡@
¡@
¡½¥úºÐ¤º®e
³Ì·s¥þ¥@¬É3750¸Uµ§E-mail¦W³æ
»`¶°ªº¨Ó·½¬°ºô»Úºô¸ô»P¦UºØ®Ñ±¸ê®Æ¡C¨C¤@µ§³£¸g¹LÅçÃÒ¡A½T»{½T¹ê¦s¦b¡A¤~¤©¥H«O¯d¡C¦b¹ê»Ú¨Ï¥Î¹Lµ{¤¤¡A¥unµo²{¬Y¨Ç¸ê®Æ¤w¸g¹L®É¡A«h¥ß§Y¤©¥Hç°£¡C³Ì«á¦A¨Ì·Ó°ê®a§O»P¦æ·~§O¨Ó¾ã²z¡A³o¼ËÀ³¥iº¡¨¬¤j¦h¼Æ°ê»Úºô¸ô¦æ¾Pªºn¨D¡C
°ê»ÚE-mail¦a°Ï¤ÀÃþ¡G
¿D¬w¡B¿D¦a§Q¡B¤ñ§Q®É¡B¥[®³¤j¡B¤¤°ê¡B¤¦³Á¡BªâÄõ¡Bªk°ê¡B¼w°ê¡B§Æþ¡B»´ä¡B¦I¤ú§Q¡B¦L«×¡B¦L¥§¡B·Rº¸Äõ¡B¤é¥»¡B°¨¨Ó¦è¨È¡B·s¥[©Y¡B¦è¯Z¤ú¡B·ç¤h¡B¥xÆW¡B®õ°ê¡B¬ü°ê¡B^°ê¡C
°ê»ÚE-mail¦æ·~¤ÀÃþ¡G
¤â¤uÃÀ«~¡B¨T¨®¡B®T¼Ö³õ©Ò¡B°Ó°È¡B¹q¸£¸ê°T¡B¤Æ§©«~¡BÂå°|ÃÄ«~¡B¤Æ¤u¡B¹q¤l¹q¾¹¡BÂAªá¡B¹«~¡B¹A·~¯bªª¡B¾÷±ñ¤u·~¡B®a¨ã¤u·~¡B®a®x¥Î«~¡B«Ø¿v¦a²£¡B¯¼Â´ªA¸Ë¡B§«~¡B«OÀI¡BÄ_¥Û¡B¯]Ä_º¹¢¡B°s©±®ÈÀ]¡Bªk«ß¡B¤å¨ã»ö¾¹¥Î«~¡B¤â´£¹q¸Ü¡B·s»D´CÅé¡B¶l»¼§Ö»¼¡B¥ø·~¡B¾Ç®Õ±Ð¨|¡B¬ì¾Ç¡BÅé¨|¥Î«~¡BªÑ²¼§ë¸ê¡B¯¼Â´ªA¸Ë¡Bª±¨ã¡B¶T©ö¡B®È¹C¡B¤â¿öÄÁªí..µ¥µ¥¡C
¨Ï¥Î»¡©ú¡B±Ð¾Ç¤â¥U¡G
¯S¤½¶}¦h¦~ªº¦æ¾P¬ã¨s¤ß±o¡A¶Ç±Âµo°eemail«H¥óªº¤èªk¡B¬ªù¡C»¡©úµo¤£¥X¥hªºì¦]¡BISPÀÉ«Hªºì²z¡B¦W³æ¾ã²zªº¤èªk¡A¥H¤Î³Q°±Åvªºì¦]µ¥µ¥¡C¨Ã¨Ì¾Ú¨Ï¥Î¥Øªº¡A¸Ô²Ó»¡©ú¦U¬ÛÃö³Ì±j³nÅ骺¨Ï¥Î¤èªk¡C
¡@
¥tªþ°e¶W±j±À¼s¦æ¾P¤u¨ã ¡G
¡½ °ª³tµo«H³nÅé
°ª³tµo«H³nÅéµL¶·¦w¸Ë¡A¨Ï¥Î¤è«K¡A¨C¤p®É¥i send¼Æ¸U«Êemail¡A¥i¤ä´©Html¡]ºô¶®æ¦¡¡^¡BTxt¡]¯Â¤å¦r¡^®æ¦¡ªºEmail¡Cµo°eemailµL¶·¸g ISP¡A¯à±N§Aªº¹q¸£·í§@¤@¥x mail Serverª½±µ¶Ç°e¡A¥\¯à±j¤j¡C
¡½·j´M¾¹¦Û°Êµn³°¾¹
¯à±N±zªººô¯¸¦Û°Êµn³°¦Ü¥þ¥@¬É¦U¤j¤p·j´M¤ÞÀº¡A¥O±zªººô¯¸¤@Á|¦¨¦W¡AÅý±zºô¯¸ªº¤H¬y¶qÅå¤H¦a¥H¿¼Æ¼Wªø¡C³t«×¸§Ö¡A¦p¤â°Êµn³°¶·n¼ÆÓ¤ë®É¶¡¡A²{¦b¥u¶·¼Æ¤ÀÄÁ´N¥i§¹¦¨¡C
¡½ ¹q¤l¶l¥ó¦a§è·j´M¤U¸ü³n¥ó
¥i¥H±qºô¯¸©Î Html¸Ì·j´M¤U¸ü Email¦a§è¡A¥i¦Û©w·j´Mªº½d³ò¡B¼h¼Æ¡A·j´M³t«×¸§Ö¡A±q¦¹¥i¦Ûq¦Û¤vªº¶l¥ó¦Cªí¡A¬Oºô¸ô¦æ¾P±À¼sªº¥²³Æªººë«~¡C
¡½¥ß§YqÁÊ
¡E³Ì·s°ê»Ú¦æ¾Pemail¦W³æ¡A¨C¤ù¯S»ù1600¤¸(§t¶l¸ê)¡C
¡E¤U¤èqÁʳæ¸ê®Æ°È¥²¶ñ¼g¥¿½T¡A¥H«K°e³f¡C
¡E¥»²£«~³z¹L¶l§½»¼°e¦Ü©²¤W¡A¶l®t¥N¦¬³f»ù³f¨ì¥I´Ú¡C
¤¤¤å©m¦W
Ápµ¸¹q¸Ü
¹q¤l«H½c
¶l»¼°Ï¸¹
°e³f¦a§}
¡@
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-669112 ] Server.log not created when using xerces
Bugs item #669112, was opened at 2003-01-16 15:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669112&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 7 Submitted By: Andrew Everitt (andieveritt) Assigned to: Nobody/Anonymous (nobody) Summary: Server.log not created when using xerces Initial Comment: If JBoss is installed into a path with a space in the name (e.g. C:\Program Files\JBoss) and you are using Xerces as the JAXP implementation the server.log file is not created. All logging is written to boot.log. I see the following exception on the screen (but not in boot.log): 16:04:35,656 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml log4j:ERROR Could not parse input source [org.xml.sax.InputSource@95cfbe]. java.net.MalformedURLException: no protocol: log4j.dtd at java.net.URL.(Unknown Source) at java.net.URL.(Unknown Source) at java.net.URL.(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807) at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:767) at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:275) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:841) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:253) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:672) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:602) at org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:704) at org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:486) at org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:425) at org.jboss.logging.Log4jService.startService(Log4jService.java:281) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:164) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:397) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) 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 $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:249) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:802) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:564) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:221) at com.xms.install.jboss.JBossJService.bootJBoss(JBossJService.java:139) at com.xms.install.jboss.JBossJService.start(JBossJService.java:64)
[JBoss-dev] [ jboss-Bugs-690177 ] JBoss startup does not work under linux
Bugs item #690177, was opened at 2003-02-20 18:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690177&group_id=22866 Category: JBoss-IDE Group: None Status: Open Resolution: None Priority: 9 Submitted By: Hans Dockter (hans_d) Assigned to: Hans Dockter (hans_d) Summary: JBoss startup does not work under linux Initial Comment: JBoss 3.2 from cThis bug was mentioned in the froum by Bernd Koeke and others: Eclipse 2.1 M5 Both on Sun JDK 1.4.1_01 SuSE Linux 8.0 I have one JBoss outside the workspace, which I build by hand with build.sh and I use tomcat41 (tomcat 4.1.18 LE jdk1.4). Another JBoss 3.2 is checked out in eclipse for debugging. When I start JBoss by run.sh with a run.conf for remote debugging, e.g. on port 8000 and configure "JBoss remote" it works. But when I want to start it with a "JBoss 3.x" configuration I get the following message in a popup: "org.eclipse.core.runtime.CoreException Could not connect to VM" and in the console window: "Exception in thread "main" java.lang.NoClassDefFoundError:" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690177&group_id=22866 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Schedule forConnection management changes in 3.2
I fixed the immediate problem in jboss 3.2, other versions to follow shortly. The intent of this feature is to encourage you to clean up after yourself by closing all database connections you get before you leave the ejb method they were obtained in. This is contrary to the jca spec requirement that the app server allow you to hold connection handles across ejb method invocations, hooking the handle up to a suitable (tx and security) ManagedConnection for each ejb call. I cannot emphasize enough how strongly I advise you to obtain and close your connection handles in each ejb call. If you require holding connection handles over method invocations, set the CachedConnectionManager SpecCompliant attribute to true in the jboss-jca.sar/META-INF/jboss-service.xml file. I can't imagine how your code could have worked with the previous jboss code without running out of connection handles just as fast, so if there are additional problems please let me know. thanks david jencks On 2003.02.20 05:19 Jonas Partner wrote: > Hi > I was hoping that someone could provide guidance on whether we should > continue trying to develop with 3.2 > or whether to try and drop back to 3.0.x, at the moment 3.2 RC1, RC2 and > a clean 3.2 build from CVS do not seem > to be closing local transaction database connections see the below stack > from the testsuite. This is proving > critical since under moderate usage we can quickly run out of connections > .Since we have a freeze date > approaching in the next week or two we are looking for guidance as to > when the changes in connection > management are likely to be completed and also whether any assistance > with this would be welcome. > > Regards > > Jonas Partner > Software Developer > Xerox Mobile Solutions > Cambridge > > > 2003-02-20 09:20:38,100 INFO [org.jboss.test.jca.ejb.CachedConnectionSessionBean] > ejb activate never called, conn == null > 2003-02-20 09:20:38,100 INFO >[org.jboss.resource.connectionmanager.CachedConnectionManager] > Could not find a close method on alleged connection objects. Please > close your own connections. > java.lang.Exception: Stack Trace > at >org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:357) > at >org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199) > at >org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190) > at >org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) > at >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108) > at >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243) > at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104) > at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208) > at >org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) > at >org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322) > at org.jboss.ejb.Container.invoke(Container.java:652) > 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:549) > at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:338) > at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) > at >sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) > at sun.rmi.transport.Transport$1.run(Transport.java:148) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:144) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) > at java.lang.Thread.run(Thread.java:536) > > > > > > > > Hi > I was hoping that someone could provide > guidance on > whether we should continue trying to develop with 3.2 > or whether to try and drop back to > 3.0.x, at the moment 3.2 RC1, RC2 and > a > clean 3.2 build from CVS do not seem > to be closing local transaction database > connections see the below stack from the > testsuite. This is proving > critical since under moderate usage > face=Arial size=2>w
[JBoss-dev] [ jboss-Bugs-676243 ] FileURLConnection needs URL decode for JDK 1.4
Bugs item #676243, was opened at 2003-01-28 18:23
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=676243&group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Everitt (andieveritt)
Assigned to: Nobody/Anonymous (nobody)
Summary: FileURLConnection needs URL decode for JDK 1.4
Initial Comment:
In the constructor of
org.jboss.net.protocol.file.FileURLConnection a new
File is created from the supplied URL. In JDK 1.4 the
result of URL.getPath() is URL encoded which means on
windows with a path with a space you get
'C:\Program%20Files\foo\bar' - which doesn't work.
I have tested a modified version of FileURLConnection
which URL decodes the result. This resolves the issue.
I have attached the modified version. The only change
is on Line 45:
- file = new File(url.getPath().replace('/',
File.separatorChar).replace('|', ':'));
+ file = new
File(java.net.URLDecoder.decode(url.getPath()).replace('/',
File.separatorChar).replace('|', ':'));
--
>Comment By: Andrew Everitt (andieveritt)
Date: 2003-02-20 14:55
Message:
Logged In: YES
user_id=689882
OK, after some investigation it appears that this may not be
quite the correct fix! The problem is some apparent
inconsistency with when paths are getting URL encoded.
Somethings like:
URL url = new URL("file:///C:/Program Files/foo/bar");
Doesn't seem to get URL encoded and will work fine when
passed to FileURLConnection. However things like:
URL csurl =
Some.class.getProtectionDomain().getCodeSource().getLocation();
and
URL res = Some.class.getClassLoader().getResource("File in
path with space.txt");
returns a path that is URL encoded and so doesn't work when
a file is in a path with a space.
I guess that JBoss is using these calls to get URLs for
resources which then throw up later.
More to follow.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=676243&group_id=22866
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Patch for jboss/jetty CLIENT-CERT authentication
Hi Jboss/Jetty team, Apologies for not submitting this through the patch manager. I wasn't sure where to put it, since jbossweb/jetty isn't a category. I've attached a patch against jboss-3.0.6/jetty to add CLIENT-CERT authentication via HTTPS or AJP13. It also fixes a bug against the Jetty AJP13 Cert handling code. This patch uses the jbosssx api to expose the certificate chain to the JAAS login module as the credential of a SecurityAssocationCallback. It also fixes a bug in the Jetty AJP13 code which put the client cert into the request object as a string (it should be an X509Certificate[]). Cheers, Phil -- If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. -- jetty.patch Description: Binary data
[JBoss-dev] Schedule forConnection management changes in 3.2
Hi I was hoping that someone could provide guidance on whether we should continue trying to develop with 3.2 or whether to try and drop back to 3.0.x, at the moment 3.2 RC1, RC2 and a clean 3.2 build from CVS do not seem to be closing local transaction database connections see the below stack from the testsuite. This is proving critical since under moderate usage we can quickly run out of connections .Since we have a freeze date approaching in the next week or two we are looking for guidance as to when the changes in connection management are likely to be completed and also whether any assistance with this would be welcome. Regards Jonas Partner Software Developer Xerox Mobile Solutions Cambridge 2003-02-20 09:20:38,100 INFO [org.jboss.test.jca.ejb.CachedConnectionSessionBean] ejb activate never called, conn == null2003-02-20 09:20:38,100 INFO [org.jboss.resource.connectionmanager.CachedConnectionManager] Could not find a close method on alleged connection objects. Please close your own connections.java.lang.Exception: Stack Trace at org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:357) at org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322) at org.jboss.ejb.Container.invoke(Container.java:652) 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:549) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:338) at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:536)
