RE: ClassCastException at Derby EmbeddedDataSource
Hi, Lin,
I don't see any org.apache.geronimo.* entries in Driver JAR selection.
May this be a problem?
And anyway, selecting non-Derby JAR for Derby access is
counterintuitive, isn't it?
Taking into account that I'm connecting not to the SystemDatabase, but
to another database I've created through Console DB Manager.
Is there a case when choosing an org.apache.derby/derby*/*/jar for
Embedded Derby connection would be a valid choice?
Maybe there's some sense in limiting the list of available JARs after
Database Type is selected?
As for now creating the operational connector to the embedded database
seems impossible without asking questions and editing deployment plans
manually.
Thank you!
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 10:36 PM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug,
while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver (implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver)
or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected,
and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at
org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
dXAMCF.java:52)
at
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon
ne
ction(MCFConnectionInterceptor.java:48)
at
org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce
pt
or.getConnection(LocalXAResourceInsertionInterceptor.java:41)
at
org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor
.i
nternalGetConnection(SinglePoolConnectionInterceptor.java:67)
at
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt
er
ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
at
org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor
.g
etConnection(TransactionEnlistingInterceptor.java:46)
at
org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.g
et
Connection(TransactionCachingInterceptor.java:88)
at
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get
Co
nnection(ConnectionHandleInterceptor.java:43
Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
I went back to the commit list... looks like the last min fix aren't
pulled into geronimo 2.0.1, but they should be avail in the upcoming
geronimo 2.0.2. Sorry about the confusion.
No, for derby, we recommend people to select systemdatabase instead, as
it already has org.apache.derby/derby*/*/jar as the dependency. This
was a change made since geronimo 1.1 and here is some doc about it
(http://cwiki.apache.org/GMOxDOC11/migrating-applications-from-geronimo-v10.html,
check 2) Manually convert the derby jar dependencies to system-datasource).
David Jencks has worked on limiting the list of available JARs on the
portlet, but I think his change is only in trunk (which will be geronimo
2.1).
HTH,
Lin
Zakharov, Vasily M wrote:
Hi, Lin,
I don't see any org.apache.geronimo.* entries in Driver JAR selection.
May this be a problem?
And anyway, selecting non-Derby JAR for Derby access is
counterintuitive, isn't it?
Taking into account that I'm connecting not to the SystemDatabase, but
to another database I've created through Console DB Manager.
Is there a case when choosing an org.apache.derby/derby*/*/jar for
Embedded Derby connection would be a valid choice?
Maybe there's some sense in limiting the list of available JARs after
Database Type is selected?
As for now creating the operational connector to the embedded database
seems impossible without asking questions and editing deployment plans
manually.
Thank you!
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 10:36 PM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug,
while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver (implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver)
or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected,
and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at
org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
dXAMCF.java:52)
at
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon
ne
ction(MCFConnectionInterceptor.java:48)
at
org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce
pt
or.getConnection(LocalXAResourceInsertionInterceptor.java:41
RE: ClassCastException at Derby EmbeddedDataSource
Ok, I see, thank you very much for the clarification.
Ok, let's wait for G2.0.2/2.1. :)
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Friday, October 12, 2007 1:00 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
I went back to the commit list... looks like the last min fix aren't
pulled into geronimo 2.0.1, but they should be avail in the upcoming
geronimo 2.0.2. Sorry about the confusion.
No, for derby, we recommend people to select systemdatabase instead, as
it already has org.apache.derby/derby*/*/jar as the dependency. This
was a change made since geronimo 1.1 and here is some doc about it
(http://cwiki.apache.org/GMOxDOC11/migrating-applications-from-geronimo-
v10.html,
check 2) Manually convert the derby jar dependencies to
system-datasource).
David Jencks has worked on limiting the list of available JARs on the
portlet, but I think his change is only in trunk (which will be geronimo
2.1).
HTH,
Lin
Zakharov, Vasily M wrote:
Hi, Lin,
I don't see any org.apache.geronimo.* entries in Driver JAR
selection.
May this be a problem?
And anyway, selecting non-Derby JAR for Derby access is
counterintuitive, isn't it?
Taking into account that I'm connecting not to the SystemDatabase, but
to another database I've created through Console DB Manager.
Is there a case when choosing an org.apache.derby/derby*/*/jar for
Embedded Derby connection would be a valid choice?
Maybe there's some sense in limiting the list of available JARs after
Database Type is selected?
As for now creating the operational connector to the embedded database
seems impossible without asking questions and editing deployment plans
manually.
Thank you!
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 10:36 PM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see
org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database
pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates
a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug,
while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver
(implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver)
or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected,
and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at
org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
RE: ClassCastException at Derby EmbeddedDataSource
Hi David, Yes, this actually helped, thank you very much! However, the deployment plan I provided was generated by database pool wizard in the console, as follows: Console Navigation - Services - Database Pools Create a new database pool: Using the Geronimo database pool wizard Database Type: Derby embedded XA Driver JAR: org.apache.derby/derby/10.2.2.0/jar This seems to be a logical and trivial way. And org.apache.geronimo.configs is absent in the Driver JAR list. So, maybe there's a problem with database pool wizard that generates a deployment plan that doesn't work as expected? Vasily -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 4:16 AM To: dev@geronimo.apache.org Subject: Re: ClassCastException at Derby EmbeddedDataSource Hi Vasily, when you use a derby datasource you have to make sure you get the derby classes from the same classloader as the embedded derby database. You normally do this by replacing the derby dependency in your plan with something like dep:dependency dep:groupIdorg.apache.geronimo.configs/dep:groupId dep:artifactIdsystem-database/dep:artifactId dep:typecar/dep:type /dep:dependency Hope this helps david jencks On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote: Hi, all, I've come into a strange situation, that looks like maybe a bug, while working on SPECjAppServer2004 deployment on G2.0.1. When working with Embedded XA TranQL connector to internal Derby database, class org.apache.geronimo.jdbc.DelegatingDriver (implements java.sql.Driver) comes out in a place where either org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver) or org.apache.derby.jdbc.InternalDriver (implements org.apache.derby.iapi.services.monitor.ModuleControl) is expected, and this causes a ClassCastException on server side: java.lang.ClassCastException: org.apache.geronimo.jdbc.DelegatingDriver at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter (Unknown Source) at org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown Source) at org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio n( AbstractXADataSourceMCF.java:74) at org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection (Embedde dXAMCF.java:52) at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon ne ction(MCFConnectionInterceptor.java:48) at org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce pt or.getConnection(LocalXAResourceInsertionInterceptor.java:41) at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor .i nternalGetConnection(SinglePoolConnectionInterceptor.java:67) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt er ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78) at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor .g etConnection(TransactionEnlistingInterceptor.java:46) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.g et Connection(TransactionCachingInterceptor.java:88) at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get Co nnection(ConnectionHandleInterceptor.java:43) at org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection (TCC LInterceptor.java:39) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.g et Connection(ConnectionTrackingInterceptor.java:66) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.alloc at eConnection(AbstractConnectionManager.java:87) at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56) ... The deployment plan for the connector can be found here: http://cwiki.apache.org/confluence/download/attachments/64828/sjas- db.xm l This plan is deployed with repository/org/tranql/tranql-connector-derby-embed-xa/1.3/tranql- connect or-derby-embed-xa-1.3.rar Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies
Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug, while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver (implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver) or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected, and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
dXAMCF.java:52)
at
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon
ne
ction(MCFConnectionInterceptor.java:48)
at
org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce
pt
or.getConnection(LocalXAResourceInsertionInterceptor.java:41)
at
org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor
.i
nternalGetConnection(SinglePoolConnectionInterceptor.java:67)
at
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt
er
ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
at
org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor
.g
etConnection(TransactionEnlistingInterceptor.java:46)
at
org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.g
et
Connection(TransactionCachingInterceptor.java:88)
at
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get
Co
nnection(ConnectionHandleInterceptor.java:43)
at
org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection
(TCC
LInterceptor.java:39)
at
org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.g
et
Connection(ConnectionTrackingInterceptor.java:66)
at
org.apache.geronimo.connector.outbound.AbstractConnectionManager.alloc
at
eConnection(AbstractConnectionManager.java:87)
at
org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56)
...
The deployment plan for the connector can be found here:
http://cwiki.apache.org/confluence/download/attachments/64828/sjas-
db.xm
l
This plan is deployed with
repository/org/tranql/tranql-connector-derby-embed-xa/1.3/tranql-
connect
or-derby-embed-xa-1.3.rar
Vasily Zakharov
Intel ESSD
---
Closed Joint Stock Company Intel A/O
Registered legal address: 125252, Moscow, Russian Federation,
Chapayevsky Per, 14.
This e-mail and any attachments may contain confidential material
Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily, when you use a derby datasource you have to make sure you get the derby classes from the same classloader as the embedded derby database. You normally do this by replacing the derby dependency in your plan with something like dep:dependency dep:groupIdorg.apache.geronimo.configs/dep:groupId dep:artifactIdsystem-database/dep:artifactId dep:typecar/dep:type /dep:dependency Hope this helps david jencks On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote: Hi, all, I've come into a strange situation, that looks like maybe a bug, while working on SPECjAppServer2004 deployment on G2.0.1. When working with Embedded XA TranQL connector to internal Derby database, class org.apache.geronimo.jdbc.DelegatingDriver (implements java.sql.Driver) comes out in a place where either org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver) or org.apache.derby.jdbc.InternalDriver (implements org.apache.derby.iapi.services.monitor.ModuleControl) is expected, and this causes a ClassCastException on server side: java.lang.ClassCastException: org.apache.geronimo.jdbc.DelegatingDriver at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter (Unknown Source) at org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown Source) at org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio n( AbstractXADataSourceMCF.java:74) at org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection (Embedde dXAMCF.java:52) at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon ne ction(MCFConnectionInterceptor.java:48) at org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce pt or.getConnection(LocalXAResourceInsertionInterceptor.java:41) at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor .i nternalGetConnection(SinglePoolConnectionInterceptor.java:67) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt er ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78) at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor .g etConnection(TransactionEnlistingInterceptor.java:46) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.g et Connection(TransactionCachingInterceptor.java:88) at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get Co nnection(ConnectionHandleInterceptor.java:43) at org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection (TCC LInterceptor.java:39) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.g et Connection(ConnectionTrackingInterceptor.java:66) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.alloc at eConnection(AbstractConnectionManager.java:87) at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56) ... The deployment plan for the connector can be found here: http://cwiki.apache.org/confluence/download/attachments/64828/sjas- db.xm l This plan is deployed with repository/org/tranql/tranql-connector-derby-embed-xa/1.3/tranql- connect or-derby-embed-xa-1.3.rar Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
