NoClassDefFoundError trying to use MSSQL with JBoss 3.2.1
speakmon Jun 17, 2003 7:45 PMHi,
I'm new to Jboss and I'm trying to get it to talk to my SQL Server 2000 db. I'm running JBossMQ by itself ina JBoss session as described in the FAQ. I've followed the guides in the forum for connecting the DB, but I can't figure out this exception:
16:20:16,871 INFO [HTTPServerILService] Creating
16:20:16,871 INFO [HTTPServerILService] Created
16:20:16,871 INFO [OILServerILService] Creating
16:20:16,871 INFO [OILServerILService] Created
16:20:16,871 INFO [UILServerILService] Creating
16:20:16,871 INFO [UILServerILService] Created
16:20:16,871 INFO [OIL2ServerILService] Creating
16:20:16,871 INFO [OIL2ServerILService] Created
16:20:16,871 INFO [UILServerILService] Creating
16:20:16,871 INFO [UILServerILService] Created
16:20:16,871 INFO [DLQ] Creating
16:20:16,871 INFO [DLQ] Created
16:20:16,871 INFO [RARDeployment] Starting
16:20:16,871 WARN [ServiceController] Problem starting service jboss.jca:service=ManagedConnectionFactory,name=MSSQLDS
java.lang.NoClassDefFoundError: org/jboss/resource/JBossResourceException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
at java.lang.Class.getConstructor0(Class.java:1762)
at java.lang.Class.newInstance0(Class.java:276)
at java.lang.Class.newInstance(Class.java:259)
at org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeployment.java:533)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966)
at $Proxy9.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:392)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
at $Proxy5.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
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 $Proxy12.start(Unknown Source)
at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:231)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613)
at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
at $Proxy7.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:458)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:200)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:211)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:190)
16:20:16,886 INFO [MainDeployer] Deployed package: file:/D:/apps/prod/JBossMQ/server/jms/deploy/MSSQLDS-ds.xml
16:20:16,886 ERROR [URLDeploymentScanner] MBeanException: Exception in MBean operation 'checkIncompleteDeployments()'
Cause: Incomplete Deployment listing:
MSSQLDB-ds.xml:
<local-tx-datasource>
<jndi-name>MSSQLDS</jndi-name>
<connection-url>jdbc:microsoft:sqlserver://dsewiresql01:1433/DatabaseName=JBossMQ</connection-url>
<driver-class>com.microsoft.jdbc.sqlserver.SQLServerDriver</driver-class>
<user-name>jbossmq</user-name>
jbossmq
<min-pool-size>2</min-pool-size>
<max-pool-size>10</max-pool-size>
<security-domain>MssqlDbRealm</security-domain>
</local-tx-datasource>
jbossmq-service.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: jbossmq-service.xml,v 1.10.2.9 2003/04/24 12:51:10 ejort Exp $ -->
<!-- ==================================================================== -->
<!-- JBossMQ -->
<!-- ==================================================================== -->
<!-- ==================================================================== -->
<!-- Invocation Layers -->
<!-- ==================================================================== -->
<!--
| InvocationLayers are the different transport methods that can
| be used to access the server.
-->
<!--
<depends optional-attribute-name="Invoker">jboss.mq:service=Invoker
RMIConnectionFactory
RMIXAConnectionFactory
60000
-->
<depends optional-attribute-name="Invoker">jboss.mq:service=Invoker
ConnectionFactory
XAConnectionFactory
8090
60000
true
<depends optional-attribute-name="Invoker">jboss.mq:service=Invoker
UILConnectionFactory
UILXAConnectionFactory
8091
<!-- FIXME: ping disabled because of deadlock problem -->
0
<!-- 60000 -->
true
<depends optional-attribute-name="Invoker">jboss.mq:service=Invoker
OIL2ConnectionFactory
OIL2XAConnectionFactory
8092
60000
true
<!--
New Unified Invocation Layer as of 3.0.7 - experimental
Synchronization moved to the message level to improve throughput
-->
<depends optional-attribute-name="Invoker">jboss.mq:service=Invoker
UIL2ConnectionFactory
UIL2XAConnectionFactory
8093
60000
true
<!-- Used to disconnect the client if there is no activity -->
<!-- Ensure this is greater than the ping period -->
70000
<!-- The size of the buffer (in bytes) wrapping the socket -->
<!-- The buffer is flushed after each request -->
2048
<!-- Large messages may block the ping/pong -->
<!-- A pong is simulated after each chunk (in bytes) for both reading and writing -->
<!-- It must be larger than the buffer size -->
1000000
<!--
| The HTTP IL is configured in the deploy directory and available by
| default in both the "default" and "all" server configurations. To customize
| its attributes please see the jboss-service.xml file included in
| the META-INF directory of jbossmq-httpil.sar directory. The rationale
| for not including its configuration here is due to the fact that it
| includes a required dependant web module which would have required
| a stand alone WAR file. It was elected, therefore, to put everything
| in the deploy directory.
-->
<!-- ==================================================================== -->
<!-- JBossMQ Interceptor chain configuration -->
<!-- ==================================================================== -->
<!-- To tune performance, you can have the Invoker skip over the TracingInterceptor -->
<!-- and/or the SecurityManager, but then you loose the ability to trace and/or enforce security. -->
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=TracingInterceptor
org.jboss.mq.server.TracingInterceptor
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=SecurityManager
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=DestinationManager
<!--
| The ClientMonitorInterceptor disconnects clients that have been idle for to long.
| This interceptor is not enabled by default since the server might disconnect clients
| when the it is under high load.
-->
<!--
80000
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=ClientReconnectInterceptor
-->
<!--
| The ClientReconnectInterceptor is used to allow a client to connect to the server even
| if it's clientID is allready being used by another client. This interceptor will disconnect
| the previously connected client to allow the new connection to succeed. This is not enabled
| by default since the JMS spec states that the 2nd client connecting to the server with the same
| id should get an exception.
-->
<!--
org.jboss.mq.server.ClientReconnectInterceptor
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=DestinationManager
-->
<depends optional-attribute-name="PersistenceManager">jboss.mq:service=PersistenceManager
<depends optional-attribute-name="StateManager">jboss.mq:service=StateManager
<!--
| The MessageCache decides where to put JBossMQ message that
| are sitting around waiting to be consumed by a client.
|
| The memory marks are in Megabytes. Once the JVM memory usage hits
| the high memory mark, the old messages in the cache will start getting
| stored in the DataDirectory. As memory usage gets closer to the
| Max memory mark, the amount of message kept in the memory cache aproaches 0.
|
| ATTENTION: When the "file" or "rollinglogged" Persistence Manager is used
| you have to set the "CacheStore" to the CacheStore (the commented out line)
| and not to the PM itself.
-->
500
600
<!--
<depends optional-attribute-name="CacheStore">jboss.mq:service=CacheStore
-->
jboss.mq:service=PersistenceManager
<!--
| The CacheStore decides where to store JBossMQ message that
| that the MessageCache has decided to move in secondary storage.
|
| Now you can specify a absolut path by using an ULR like:
| file:///c:/temp
| ATTENTION: the directory MUST exists because it will not be
| created.
-->
tmp/jbossmq
<!--
| The StateManager is used to keep JMS persistent state data.
| For example: what durable subscriptions are active.
-->
<!-- This file is pulled from the configuration URL of the server -->
jbossmq-state.xml
<!--
| The PersistenceManager is used to store messages to disk.
|
| Now you can specify a absolut path by using an ULR like:
| file:///c:/temp
| ATTENTION: the directory MUST exists because it will not be
| created. Also for the "file" Persistance Manager the directory
| MUST be empty otherwise the startup fails ("rollinglogged" works
| fine.
-->
<!--
data/jbossmq/file
<depends optional-attribute-name="MessageCache">jboss.mq:service=MessageCache
-->
<!--
| The jdbc2 PersistenceManager is the new improved JDBC implementation.
| This implementation allows you to control how messages are stored in
| the database.
|
| Use this PM if you want the reliablity a relational database can offer
| you. The default configuration is known to work with hsqldb, other databases
| will requrie teaking of the SqlProperties.
-->
<depends optional-attribute-name="MessageCache">jboss.mq:service=MessageCache
<depends optional-attribute-name="ConnectionManager">jboss.jca:service=LocalTxCM,name=MSSQLDS
BLOB_TYPE=OBJECT_BLOB
INSERT_TX = INSERT INTO JMS_TRANSACTIONS (TXID) values(?)
INSERT_MESSAGE = INSERT INTO JMS_MESSAGES (MESSAGEID, DESTINATION, MESSAGEBLOB, TXID, TXOP) VALUES(?,?,?,?,?)
SELECT_ALL_UNCOMMITED_TXS = SELECT TXID FROM JMS_TRANSACTIONS
SELECT_MAX_TX = SELECT MAX(TXID) FROM JMS_MESSAGES
SELECT_MESSAGES_IN_DEST = SELECT MESSAGEID, MESSAGEBLOB FROM JMS_MESSAGES WHERE DESTINATION=?
SELECT_MESSAGE = SELECT MESSAGEID, MESSAGEBLOB FROM JMS_MESSAGES WHERE MESSAGEID=? AND DESTINATION=?
MARK_MESSAGE = UPDATE JMS_MESSAGES SET TXID=?, TXOP=? WHERE MESSAGEID=? AND DESTINATION=?
UPDATE_MESSAGE = UPDATE JMS_MESSAGES SET MESSAGEBLOB=? WHERE MESSAGEID=? AND DESTINATION=?
UPDATE_MARKED_MESSAGES = UPDATE JMS_MESSAGES SET TXID=?, TXOP=? WHERE TXOP=?
UPDATE_MARKED_MESSAGES_WITH_TX = UPDATE JMS_MESSAGES SET TXID=?, TXOP=? WHERE TXOP=? AND TXID=?
DELETE_MARKED_MESSAGES_WITH_TX = DELETE FROM JMS_MESSAGES WHERE TXID IN (SELECT TXID FROM JMS_TRANSACTIONS) AND TXOP=?
DELETE_TX = DELETE FROM JMS_TRANSACTIONS WHERE TXID = ?
DELETE_MARKED_MESSAGES = DELETE FROM JMS_MESSAGES WHERE TXID=? AND TXOP=?
DELETE_MESSAGE = DELETE FROM JMS_MESSAGES WHERE MESSAGEID=? AND DESTINATION=?
CREATE_MESSAGE_TABLE = CREATE TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL, \
DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1), \
MESSAGEBLOB OBJECT, PRIMARY KEY (MESSAGEID, DESTINATION) )
CREATE_TX_TABLE = CREATE TABLE JMS_TRANSACTIONS ( TXID INTEGER )
<!-- ==================================================================== -->
<!-- System Destinations -->
<!-- ==================================================================== -->
<!-- Dead Letter Queue -->
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager
<depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager
Can anybody tell me what's going on here? Any help would be greatly appreciated.
Thanks!
--Ben