Kodo JDO with JCA provided by Jencks in Tomcat
I'm trying to use both JDO and JCR (Apache's Jackrabbit) in my project. Both support XA
Transactions, and my understanding is that to best ensure data integrity, I should start using them.
Currently, I'm running under Tomcat using the SpringFramework support for transactions. I'd like to
continue running in Tomcat because I already understand that environment and the other app-servers
all feel heavyweight by comparison - all I need is JNDI and XA Transactions. Tomcat itself doesn't
support XA Transactions and JCA, but the open source project jencks is able to provide JCA support
within Tomcat.
I've been looking at the Deployment section of the JDO reference guide (Chapter 8). If I'm reading
this right, all I need to do is set two properties in the jdo.properties file: kodo.TransactionMode
and kodo.ManagedRuntime.
I've done that in my project:
kodo.TransactionMode: managed
kodo.ManagedRuntime: invocation(
TransactionManagerMethod=edu.ucsc.whisper.transaction.KodoTransactionAccess.getTransactionManager )
The getTransactionManager() is a static function that returns the
javax.transaction.TransactionManager provided by Spring's JtaTransactionManager.
I have a unit test that checks the application's initialization process, and I've been using that to
work my way into JCA transactions. Based on that test, this seems to be working. My question is this:
Is it really that simple?
Don't get me wrong, I'll be thrilled if it is, but from everything I'm seeing about configuring the
"Big Iron" app servers (WebLogic, JBoss, etc.), it just seems like adding two properties is too easy
and that I'm probably missing something significant in the process. Can anyone confirm whether or
not I'm on the right track here?
I'm working on setting this up for my heavier-duty integration tests, but I'm concerned that if I am
missing something, I've done just enough to fake Kodo out and that it isn't actually working under
the hood.
Thanks,
Mark
Abe White wrote:
I would be surprised if your transaction manager and JDBC driver
configured themselves for XA automatically, since it imposes some
overhead and is rarely actually needed. In particular, you typically
need an XADataSource for XA transactions, rather than just using the
standard JDBC driver through the DriverManager (as Kodo does internally
when you specify ConnectionDriverName). So I suggest you consult their
documentation. As far as Kodo is concerned, though, as long as you've
set the TransactionMode, ManagedRuntime,
DataSourceMode/ConnectionFactoryMode (depending on Kodo version), and
are using an XA DataSource, you are all set.Hi Abe,
I've been able to get Spring configured so that it uses its JtaTransactionManager, and I have Kodo
setup with the TransactionMode as Managed and the ManagedRuntime is configured to use a static
method I created that returns the TransactionManager. In my logs, I can see Kodo accessing a
non-null instance of the TransactionManager class through this method. The problem that I'm getting
is that the behavior in my unit and integration tests is different than the behavior I'm seeing when
running in Tomcat, even though the Spring and Kodo configuration are nearly identical (Kodo accesses
a different database in Tomcat than it does in testing, other than that, the configuration is the
same). All the unit and integration tests pass; this requires transactions to be created, data
written to the database through Kodo, and then read back through Kodo in a new transaction. When I
deploy the web-app to Tomcat though, Kodo suddenly thinks its running without transactions. Reading
from the database works fine because I've got non-transactional reads turned on, but as soon as I
try to alter any field of a persisted object, Kodo throws an InvalidStateException saying it doesn't
have a transaction. I've included my log output below to demonstrate.
The only thing I haven't done yet, based on your previous message, is configure my database driver
for access through JNDI within Tomcat. Would that cause errors like this, or should I be looking
elsewhere?
My jdo.properties file contains these settings:
# For use of JDOHelper
javax.jdo.PersistenceManagerFactoryClass: kodo.jdo.PersistenceManagerFactoryImpl
# For Kodo JDO 4.0 EA2 and higher
javax.jdo.option.Connection2DriverName: org.postgresql.Driver
javax.jdo.option.Connection2UserName: ------------
javax.jdo.option.Connection2Password: ------------
javax.jdo.option.Connection2URL: jdbc:postgresql://127.0.0.1:5432/my_db
javax.jdo.option.Optimistic: true
javax.jdo.option.RetainState: true
javax.jdo.option.NontransactionalRead: true
kodo.FlushBeforeQueries=true
# For JCA Transaction support
kodo.TransactionMode: managed
kodo.ManagedRuntime: invocation(
TransactionManagerMethod=edu.ucsc.whisper.transaction.KodoTransactionAccess.getTransactionManager )
Thanks,
Mark
2006-04-04 02:03:13,891 DEBUG [org.springframework.transaction.interceptor.TransactionInterceptor] -
<mdslog - TransactionInterceptor starting create if necessary>
2006-04-04 02:03:13,891 DEBUG [org.springframework.transaction.interceptor.TransactionInterceptor] -
<mdslog - TransactionAspectSupport begin createTransactionIfNecessary()>
2006-04-04 02:03:13,891 DEBUG [org.springframework.transaction.interceptor.TransactionInterceptor] -
<Getting transaction for edu.ucsc.whisper.service.UserService.setUserInformation>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager begin getTransaction>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <Using
transaction object [org.springframework.transaction.jta.JtaTransactionObject@42b645]>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] -
<Creating new transaction with name [edu.ucsc.whisper.service.UserService.setUserInformation]>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- JtaTransactionManager begin doBegin>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- JtaTransactionManager end doBegin>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager end getTransaction>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager begin newTransactionStatus>
2006-04-04 02:03:13,892 DEBUG
[org.springframework.transaction.support.TransactionSynchronizationManager] - <Initializing
transaction synchronization>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager end newTransactionStatus>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.interceptor.TransactionInterceptor] -
<mdslog - TransactionAspectSupport end createTransactionIfNecessary()>
2006-04-04 02:03:13,892 DEBUG [org.springframework.transaction.interceptor.TransactionInterceptor] -
<mdslog - TransactionInterceptor finished create if necessary>
2006-04-04 02:03:13,892 INFO [edu.ucsc.whisper.service.DefaultUserService] - <setUserInformation begin>
2006-04-04 02:03:13,892 DEBUG [org.springframework.web.context.support.XmlWebApplicationContext] -
<Publishing event in context [WebApplicationContext for namespace 'xfire-servlet']:
org.acegisecurity.event.authorization.PublicInvocationEvent[source=invocation: method 'getUser',
arguments [mark]; target is of class [edu.ucsc.whisper.core.manager.DefaultUserManager]]>
2006-04-04 02:03:13,892 DEBUG [org.springframework.web.context.support.XmlWebApplicationContext] -
<Publishing event in context [Root WebApplicationContext]:
org.acegisecurity.event.authorization.PublicInvocationEvent[source=invocation: method 'getUser',
arguments [mark]; target is of class [edu.ucsc.whisper.core.manager.DefaultUserManager]]>
2006-04-04 02:03:13,892 DEBUG [org.springframework.orm.jdo.PersistenceManagerFactoryUtils] -
<Opening JDO PersistenceManager, factory = kodo.jdo.PersistenceManagerFactoryImpl@c2c9af>
2006-04-04 02:03:13,893 DEBUG [org.springframework.orm.jdo.PersistenceManagerFactoryUtils] - <New
JDO PersistenceManager = kodo.jdo.PersistenceManagerImpl@cc70c2, factory =
kodo.jdo.PersistenceManagerFactoryImpl@c2c9af>
2006-04-04 02:03:13,893 DEBUG [org.springframework.orm.jdo.PersistenceManagerFactoryUtils] -
<Registering transaction synchronization for JDO PersistenceManager>
2006-04-04 02:03:13,893 DEBUG
[org.springframework.transaction.support.TransactionSynchronizationManager] - <mdslog -
TransactionSynchronizationManager registerSynchronization -
org.springframework.orm.jdo.PersistenceManagerFactoryUtils$PersistenceManagerSynchronization@ff0f8a>
2006-04-04 02:03:13,893 DEBUG
[org.springframework.transaction.support.TransactionSynchronizationManager] - <Bound value
[org.springframework.orm.jdo.PersistenceManagerHolder@552f12] for key
[kodo.jdo.PersistenceManagerFactoryImpl@c2c9af] to thread [http-8443-Processor24]>
2006-04-04 02:03:13,893 DEBUG
[org.springframework.transaction.support.TransactionSynchronizationManager] - <Retrieved value
[org.springframework.orm.jdo.PersistenceManagerHolder@552f12] for key
[kodo.jdo.PersistenceManagerFactoryImpl@c2c9af] bound to thread [http-8443-Processor24]>
2006-04-04 02:03:13,893 DEBUG [org.springframework.orm.jdo.PersistenceManagerFactoryUtils] -
<Persistence manager kodo.jdo.PersistenceManagerImpl@cc70c2, factory
kodo.jdo.PersistenceManagerFactoryImpl@c2c9af is transactional: true>
2006-04-04 02:03:13,893 DEBUG [kodo.Query] - <Executing query: [SELECT UNIQUE FROM
edu.ucsc.whisper.core.DefaultUser WHERE username==searchName
PARAMETERS java.lang.String searchName] with parameters: {searchName=mark}>
2006-04-04 02:03:13,894 DEBUG [kodo.jdbc.JDBC] - <<t 11706420> connection pool: active=0, idle=1>
2006-04-04 02:03:13,894 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> checkout>
2006-04-04 02:03:13,895 DEBUG [kodo.jdbc.JDBC] - <<t 11706420> prepared statement cache: size=9,
max=50, requests=17, hits=8, created=9, redundant=0, overflow=0, leaked=0>
2006-04-04 02:03:13,902 DEBUG [kodo.jdbc.SQL] - <<t 11706420, conn 15885558> [5 ms] executing
prepstmnt 6033738 SELECT t0.userId, t0.TYP, t0.VERSN, t0.enabled, t0.password, t1.userInfoId,
t1.TYPE, t1.VERSN, t1.aboutText, t1.familyName, t1.firstName, t1.gender, t1.namePrefix,
t1.nameSuffix, t1.otherNames, t2.userId, t2.TYP, t2.VERSN, t2.enabled, t2.password, t2.USERINFO,
t2.username, t0.username FROM whisper_user t0 LEFT OUTER JOIN userinfo t1 ON t0.USERINFO =
t1.userInfoId LEFT OUTER JOIN whisper_user t2 ON t1.userInfoId = t2.USERINFO WHERE (t0.username = ?)
[params=(String) mark] [reused=3]>
2006-04-04 02:03:13,906 DEBUG [kodo.jdbc.SQL] - <<t 11706420, conn 15885558> [2 ms] executing
prepstmnt 12702178 SELECT t0.nameOrder, t0.previousName FROM userInfo_PreviousNames t0 WHERE
t0.userInfoId = ? ORDER BY t0.nameOrder ASC [params=(long) 2] [reused=3]>
2006-04-04 02:03:13,908 DEBUG [kodo.jdbc.SQL] - <<t 11706420, conn 15885558> [1 ms] executing
prepstmnt 7374726 SELECT t1.authorityId, t1.TYP, t1.VERSN, t1.authority FROM user_authorities t0
INNER JOIN authorities t1 ON t0.authorityId = t1.authorityId WHERE t0.userId = ? [params=(long) 2]
[reused=3]>
2006-04-04 02:03:13,912 DEBUG [kodo.jdbc.SQL] - <<t 11706420, conn 15885558> [2 ms] executing
prepstmnt 1745355 SELECT t0.organizationId, t0.TYPE, t0.VERSN, t0.city, t0.country, t0.isPrimary,
t0.orgName, t0.positionTitle, t0.postalCode, t0.state, t0.streetAddress1, t0.streetAddress2,
t0.streetAddress3, t0.userId FROM organization t0 WHERE t0.userId = ? [params=(long) 2] [reused=3]>
2006-04-04 02:03:13,912 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> return>
2006-04-04 02:03:13,912 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> [0 ms] close>
2006-04-04 02:03:13,913 INFO [edu.ucsc.whisper.security.WhisperAccessDecisionManager] - <voting on
access to: invocation: method 'getUserInfoForUser', arguments [{DefaultUser: username=mark;
password=871deb9e1c3dd967da1d4f6d01999eb71a4eab71; isEnabled=true}]; target is of class
[edu.ucsc.whisper.core.manager.DefaultUserManager], with auth:
edu.ucsc.whisper.security.WhisperClientAuthenticationToken@798d8: Username: {DefaultUser:
username=mark; password=871deb9e1c3dd967da1d4f6d01999eb71a4eab71; isEnabled=true}; Password:
[PROTECTED]; Authenticated: true; Details: null; Granted Authorities: {DefaultAuthority:
authority=ROLE_USER}>
2006-04-04 02:03:13,913 INFO [edu.ucsc.whisper.security.UserIsOwnerOrAdminVoter] - <voting with auth
= edu.ucsc.whisper.security.WhisperClientAuthenticationToken@798d8: Username: {DefaultUser:
username=mark; password=871deb9e1c3dd967da1d4f6d01999eb71a4eab71; isEnabled=true}; Password:
[PROTECTED]; Authenticated: true; Details: null; Granted Authorities: {DefaultAuthority:
authority=ROLE_USER}, o = invocation: method 'getUserInfoForUser', arguments [{DefaultUser:
username=mark; password=871deb9e1c3dd967da1d4f6d01999eb71a4eab71; isEnabled=true}]; target is of
class [edu.ucsc.whisper.core.manager.DefaultUserManager], config = [ROLE_USER, ROLE_ANONYMOUS,
AFTER_ACL_READ]>
2006-04-04 02:03:13,913 DEBUG [org.springframework.web.context.support.XmlWebApplicationContext] -
<Publishing event in context [WebApplicationContext for namespace 'xfire-servlet']:
org.acegisecurity.event.authorization.AuthorizedEvent[source=invocation: method
'getUserInfoForUser', arguments [{DefaultUser: username=mark;
password=871deb9e1c3dd967da1d4f6d01999eb71a4eab71; isEnabled=true}]; target is of class
[edu.ucsc.whisper.core.manager.DefaultUserManager]]>
2006-04-04 02:03:13,914 DEBUG [org.springframework.web.context.support.XmlWebApplicationContext] -
<Publishing event in context [Root WebApplicationContext]:
org.acegisecurity.event.authorization.AuthorizedEvent[source=invocation: method
'getUserInfoForUser', arguments [{DefaultUser: username=mark;
password=871deb9e1c3dd967da1d4f6d01999eb71a4eab71; isEnabled=true}]; target is of class
[edu.ucsc.whisper.core.manager.DefaultUserManager]]>
2006-04-04 02:03:13,914 DEBUG
[org.springframework.transaction.support.TransactionSynchronizationManager] - <Retrieved value
[org.springframework.orm.jdo.PersistenceManagerHolder@552f12] for key
[kodo.jdo.PersistenceManagerFactoryImpl@c2c9af] bound to thread [http-8443-Processor24]>
2006-04-04 02:03:13,915 DEBUG [kodo.Query] - <Executing query: [SELECT FROM
edu.ucsc.whisper.core.UserAccessControl
WHERE aclObjectId.domainObjectId==searchObjectId.domainObjectId
PARAMETERS edu.ucsc.whisper.core.DomainObjectIdentity searchObjectId] with
parameters: {searchObjectId=edu.ucsc.whisper.core.DefaultUserInfo:mark}>
2006-04-04 02:03:13,917 DEBUG [kodo.jdbc.JDBC] - <<t 11706420> connection pool: active=0, idle=1>
2006-04-04 02:03:13,917 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> checkout>
2006-04-04 02:03:13,917 DEBUG [kodo.jdbc.JDBC] - <<t 11706420> prepared statement cache: size=9,
max=50, requests=21, hits=12, created=9, redundant=0, overflow=0, leaked=0>
2006-04-04 02:03:13,919 DEBUG [kodo.jdbc.SQL] - <<t 11706420, conn 15885558> [2 ms] executing
prepstmnt 11249989 SELECT t0.accessControlId, t0.VERSN, t0.aclObjectId, t0.aclObjectParentId,
t0.permit, t1.userId, t1.TYP, t1.VERSN, t1.enabled, t1.password, t2.userInfoId, t2.TYPE, t2.VERSN,
t2.aboutText, t2.familyName, t2.firstName, t2.gender, t2.namePrefix, t2.nameSuffix, t2.otherNames,
t3.userId, t3.TYP, t3.VERSN, t3.enabled, t3.password, t3.USERINFO, t3.username, t1.username FROM
user_access_control t0 LEFT OUTER JOIN whisper_user t1 ON t0.userId = t1.userId LEFT OUTER JOIN
userinfo t2 ON t1.USERINFO = t2.userInfoId LEFT OUTER JOIN whisper_user t3 ON t2.userInfoId =
t3.USERINFO WHERE (t0.aclObjectId = ?) [params=(String) edu.ucsc.whisper.core.DefaultUserInfo:mark]
[reused=1]>
2006-04-04 02:03:13,920 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> return>
2006-04-04 02:03:13,921 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> [1 ms] close>
2006-04-04 02:03:13,921 DEBUG
[org.springframework.transaction.support.TransactionSynchronizationManager] - <Retrieved value
[org.springframework.orm.jdo.PersistenceManagerHolder@552f12] for key
[kodo.jdo.PersistenceManagerFactoryImpl@c2c9af] bound to thread [http-8443-Processor24]>
2006-04-04 02:03:13,921 DEBUG [kodo.Query] - <Executing query: [SELECT FROM
edu.ucsc.whisper.core.AuthorityAccessControl
WHERE aclObjectId.domainObjectId==searchObjectId.domainObjectId
PARAMETERS edu.ucsc.whisper.core.DomainObjectIdentity searchObjectId] with
parameters: {searchObjectId=edu.ucsc.whisper.core.DefaultUserInfo:mark}>
2006-04-04 02:03:13,923 DEBUG [kodo.jdbc.JDBC] - <<t 11706420> connection pool: active=0, idle=1>
2006-04-04 02:03:13,924 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> checkout>
2006-04-04 02:03:13,924 DEBUG [kodo.jdbc.JDBC] - <<t 11706420> prepared statement cache: size=9,
max=50, requests=22, hits=13, created=9, redundant=0, overflow=0, leaked=0>
2006-04-04 02:03:13,927 DEBUG [kodo.jdbc.SQL] - <<t 11706420, conn 15885558> [2 ms] executing
prepstmnt 4389286 SELECT t0.accessControlId, t0.VERSN, t0.aclObjectId, t0.aclObjectParentId,
t0.permit, t1.authorityId, t1.TYP, t1.VERSN, t1.authority FROM authority_access_control t0 LEFT
OUTER JOIN authorities t1 ON t0.authorityId = t1.authorityId WHERE (t0.aclObjectId = ?)
[params=(String) edu.ucsc.whisper.core.DefaultUserInfo:mark] [reused=1]>
2006-04-04 02:03:13,928 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> return>
2006-04-04 02:03:13,928 DEBUG [kodo.jdbc.JDBC] - <<t 11706420, conn 15885558> [0 ms] close>
2006-04-04 02:03:13,928 INFO [edu.ucsc.whisper.core.dao.JdoAclDao] - <found the controls:
[{AuthorityAccessControl: aclObjectId=edu.ucsc.whisper.core.DefaultUserInfo:mark;
aclObjectParentId=null; permit=READ_WRITE; recipient={DefaultAuthority: authority=ROLE_ADMIN}},
{UserAccessControl: aclObjectId=edu.ucsc.whisper.core.DefaultUserInfo:mark; aclObjectParentId=null;
permit=READ_WRITE; recipient={DefaultUser: username=mark;
password=871deb9e1c3dd967da1d4f6d01999eb71a4eab71; isEnabled=true}}]>
2006-04-04 02:03:13,928 INFO [edu.ucsc.whisper.service.DefaultUserService] - <Updating user info for
mark>
2006-04-04 02:03:13,929 INFO [edu.ucsc.whisper.service.DefaultUserService] - <existing user info =
{DefaultUserInfo: prefix=null; firstName=null; otherNames=null; familyName=null; suffix=null;
previousNames=(); gender=0; aboutText=null}>
2006-04-04 02:03:13,929 INFO [edu.ucsc.whisper.service.DefaultUserService] - <new user info =
{UserInfoData: prefix=Mr.; firstName=Mark; otherNames=David; familyName=Slater; suffix=null;
previousNames=(); gender=0; aboutText=blah blah blah}>
2006-04-04 02:03:13,930 DEBUG
[org.springframework.transaction.interceptor.RuleBasedTransactionAttribute] - <Applying rules to
determine whether transaction should rollback on <4|false|4.0.0EA4> kodo.util.InvalidStateException:
To perform writes on persistent data outside of a transaction, the "NontransactionalWrite" property
must be set on the Transaction.
FailedObject: edu.ucsc.whisper.core.DefaultUserInfo-2>
2006-04-04 02:03:13,930 DEBUG
[org.springframework.transaction.interceptor.RuleBasedTransactionAttribute] - <Winning rollback rule
is: null>
2006-04-04 02:03:13,930 DEBUG
[org.springframework.transaction.interceptor.RuleBasedTransactionAttribute] - <No relevant rollback
rule found: applying superclass default>
2006-04-04 02:03:13,934 DEBUG [org.springframework.transaction.interceptor.TransactionInterceptor] -
<Invoking rollback for transaction on edu.ucsc.whisper.service.UserService.setUserInformation due to
throwable [<4|false|4.0.0EA4> kodo.util.InvalidStateException: To perform writes on persistent data
outside of a transaction, the "NontransactionalWrite" property must be set on the Transaction.
FailedObject: edu.ucsc.whisper.core.DefaultUserInfo-2]>
2006-04-04 02:03:13,934 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager begin rollback>
2006-04-04 02:03:13,934 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager begin processRollback>
2006-04-04 02:03:13,934 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager begin triggerBeforeCompletion>
2006-04-04 02:03:13,934 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] -
<Triggering beforeCompletion synchronization>
2006-04-04 02:03:13,934 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager - synchronization =
org.springframework.orm.jdo.PersistenceManagerFactoryUtils$PersistenceManagerSynchronization@ff0f8a>
2006-04-04 02:03:13,934 DEBUG
[org.springframework.transaction.support.TransactionSynchronizationManager] - <Removed value
[org.springframework.orm.jdo.PersistenceManagerHolder@552f12] for key
[kodo.jdo.PersistenceManagerFactoryImpl@c2c9af] from thread [http-8443-Processor24]>
2006-04-04 02:03:13,934 DEBUG [org.springframework.orm.jdo.PersistenceManagerFactoryUtils] -
<Persistence manager kodo.jdo.PersistenceManagerImpl@cc70c2, factory
kodo.jdo.PersistenceManagerFactoryImpl@c2c9af is transactional: false>
2006-04-04 02:03:13,935 DEBUG [org.springframework.orm.jdo.PersistenceManagerFactoryUtils] -
<Closing JDO PersistenceManager>
2006-04-04 02:03:13,935 DEBUG [org.springframework.orm.jdo.PersistenceManagerFactoryUtils] - <
persistence manager = kodo.jdo.PersistenceManagerImpl@cc70c2, factory =
kodo.jdo.PersistenceManagerFactoryImpl@c2c9af>
2006-04-04 02:03:13,935 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] - <mdslog
- AbstractPlatformTransactionManager end triggerBeforeCompletion>
2006-04-04 02:03:13,935 DEBUG [org.springframework.transaction.jta.JtaTransactionManager] -
<Initiating transaction rollback>
Similar Messages
-
Configuring kodo-jdo-2.5.3 with weblogic 8.1 using JCA
Hi there.
I am trying to configure kodo-jdo-2.5.3 in WebLogic 8.1 using JCA method.
The issue I got was that I got DB authentication failed. I have tested my
JDBC connect -- working fine, I have turned on JDBC log in WL, it looks
fine.
It looks like that KODO was still trying to create its own JDBC connection
even I have specified
<config-property>
<description>The JNDI name of the connection factory to use for
obtaining connections.</description>
<config-property-name>ConnectionFactoryName</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>datasource.oracle9</config-property-value>
</config-property>
"datasource.oracle9" is the JNDI name of my data source.
The error message is the following. I will really appreciate your help.
Melvin
Oct 19, 2003 4:20:53 AM com.solarmetric.kodo.impl.jdbc.RegisterListener
registerClass
SEVERE: com.solarmetric.kodo.runtime.FatalDataStoreException:
java.sql.SQLException: User: melvin, f
ailed to be authenticated. [code=0;state=null]
NestedThrowables:
java.sql.SQLException: User: melvin, failed to be authenticated.
com.solarmetric.kodo.runtime.FatalDataStoreException:
java.sql.SQLException: User: melvin, failed to
be authenticated. [code=0;state=null]
NestedThrowables:
java.sql.SQLException: User: melvin, failed to be authenticated.
at
com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwFatal(SQLExceptions.java:58)
at
com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFacto
ry.java:212)
at
com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfigurat
ion.java:370)
at
com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClassInternal(JDBCPe
rsistenceManagerFactory.java:455)
at
com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClass(JDBCPersistenc
eManagerFactory.java:338)
at
com.solarmetric.kodo.impl.jdbc.RegisterListener.registerClass(RegisterListener.java:53)
at
javax.jdo.spi.JDOImplHelper.registerClass(JDOImplHelper.java:269)
at samples.j2ee.Car.<clinit>(Car.java)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:140)
at samples.j2ee.ejb.CarBean.class$(CarBean.java:11)
at samples.j2ee.ejb.CarBean.list(CarBean.java:136)
at
samples.j2ee.ejb.CarEJB_pgfrtx_EOImpl.list(CarEJB_pgfrtx_EOImpl.java:201)
at jsp_servlet.__index._jspService(__index.java:170)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.jav
a:1053)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:431)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:6310)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:36
22)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
NestedThrowablesStackTrace:
java.sql.SQLException: User: melvin, failed to be authenticated.
at
weblogic.jdbc.common.internal.RmiDataSource.getSubject(RmiDataSource.java:257)
at
weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:188)
at
com.solarmetric.kodo.impl.jdbc.runtime.DataSourceConnector.getConnection(DataSourceConnec
tor.java:63)
at
com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFacto
ry.java:179)
at
com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfigurat
ion.java:370)
at
com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClassInternal(JDBCPe
rsistenceManagerFactory.java:455)
at
com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClass(JDBCPersistenc
eManagerFactory.java:338)
at
com.solarmetric.kodo.impl.jdbc.RegisterListener.registerClass(RegisterListener.java:53)
at
javax.jdo.spi.JDOImplHelper.registerClass(JDOImplHelper.java:269)
at samples.j2ee.Car.<clinit>(Car.java)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:140)
at samples.j2ee.ejb.CarBean.class$(CarBean.java:11)
at samples.j2ee.ejb.CarBean.list(CarBean.java:136)
at
samples.j2ee.ejb.CarEJB_pgfrtx_EOImpl.list(CarEJB_pgfrtx_EOImpl.java:201)
at jsp_servlet.__index._jspService(__index.java:170)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.jav
a:1053)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:431)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:6310)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:36
22)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
<Oct 19, 2003 4:20:53 AM CDT> <Info> <EJB> <BEA-010051> <EJB Exception
occurred during invocation fr
om home: samples.j2ee.ejb.CarEJB_pgfrtx_HomeImpl@1c059f6 threw exception:
com.solarmetric.kodo.runti
me.FatalDataStoreException: java.sql.SQLException: User: melvin, failed to
be authenticated. [code=0
;state=null]
NestedThrowables:
java.sql.SQLException: User: melvin, failed to be authenticated.
com.solarmetric.kodo.runtime.FatalDataStoreException:
java.sql.SQLException: User: melvin, failed to
be authenticated. [code=0;state=null]
NestedThrowables:
java.sql.SQLException: User: melvin, failed to be authenticated.
at
com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwFatal(SQLExceptions.java:58)
at
com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFacto
ry.java:212)
at
com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfigurat
ion.java:370)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getDictionary(JDBCStoreManager.ja
va:753)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getClassMapping(JDBCStoreManager.
java:1023)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getClassMapping(JDBCStoreManager.
java:1037)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCExtent.getResultList(JDBCExtent.java:71)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCExtent.getIterator(JDBCExtent.java:47)
at
com.solarmetric.kodo.runtime.ExtentImpl$MultipleSubclassIterator.newIterator(ExtentImpl.j
ava:344)
at serp.util.MultiIterator.setIterator(MultiIterator.java:74)
at serp.util.MultiIterator.hasNext(MultiIterator.java:29)
at serp.util.LookaheadIterator.setNext(LookaheadIterator.java:133)
at
serp.util.LookaheadIterator.initialize(LookaheadIterator.java:118)
at serp.util.LookaheadIterator.hasNext(LookaheadIterator.java:48)
at serp.util.MultiIterator.setIterator(MultiIterator.java:73)
at serp.util.MultiIterator.hasNext(MultiIterator.java:29)
at
com.solarmetric.kodo.runtime.ExtentImpl$TransactionAwareIterator.hasNext(ExtentImpl.java:
403)
at samples.j2ee.ejb.CarBean.list(CarBean.java:138)
at
samples.j2ee.ejb.CarEJB_pgfrtx_EOImpl.list(CarEJB_pgfrtx_EOImpl.java:201)
at jsp_servlet.__index._jspService(__index.java:170)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.jav
a:1053)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:431)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:6310)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:36
22)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
NestedThrowablesStackTrace:
java.sql.SQLException: User: melvin, failed to be authenticated.
at
weblogic.jdbc.common.internal.RmiDataSource.getSubject(RmiDataSource.java:257)
at
weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:188)
at
com.solarmetric.kodo.impl.jdbc.runtime.DataSourceConnector.getConnection(DataSourceConnec
tor.java:63)
at
com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFacto
ry.java:179)
at
com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfigurat
ion.java:370)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getDictionary(JDBCStoreManager.ja
va:753)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getClassMapping(JDBCStoreManager.
java:1023)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getClassMapping(JDBCStoreManager.
java:1037)Alex Robbins wrote:
Try removing <authentication-mechanism> from the ra.xml file of the Kodo
JCA connector. Then it won't try to authenticate against the WL security
realm. (If you want connector-level authentication as well as DB-conn
authentication i think you'll have to configure WL security. I don't know
how). This worked for me.
Alex.Hi, The following is the ra.xml, please see any problem.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE connector PUBLIC '-//Sun Microsystems, Inc.//DTD Connector
1.0//EN' 'http://java.sun.com/dtd/connector_1_0.dtd'>
<connector>
<display-name>KodoJDO</display-name>
<description>Resource Adapter for integration of the Kodo Java Data
Objects (JDO) implementation with J2EE 1.3 compliant managed
environments</description>
<icon>
<small-icon>kodo16.gif</small-icon>
<large-icon>kodo32.gif</large-icon>
</icon>
<vendor-name>Solarmetric, Inc.</vendor-name>
<spec-version>1.0</spec-version>
<eis-type>jdo</eis-type>
<version>1.0</version>
<license>
<description>See http://www.solarmetric.com for terms and license
conditions.</description>
<license-required>true</license-required>
</license>
<resourceadapter>
<managedconnectionfactory-class>com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl</managedconnectionfactory-class>
<connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface>
<connectionfactory-impl-class>com.solarmetric.kodo.impl.jdbc.ee.JDOConnectionFactory</connectionfactory-impl-class>
<connection-interface>javax.resource.cci.Connection</connection-interface>
<connection-impl-class>com.solarmetric.kodo.ee.EEPersistenceManager</connection-impl-class>
<transaction-support>XATransaction</transaction-support>
<config-property>
<description>The number of hard references to cached objects that the
PersistenceManager's cache will retain (in addition to the soft reference
cache that it maintains). Setting this to a higher value will result in
more objects being retained in the cache, at the cost of utilizing more
memory resources. Setting it to -1 will cause the PersistenceManager to
maintain hard references only. This will result in better performance, but
can have adverse effects on memory usage.</description>
<config-property-name>CacheReferenceSize</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>1000</config-property-value>
</config-property>
<config-property>
<description>The class name of ether the JDBC java.sql.Driver, or an
instance of a javax.sql.DataSource to use to connect to the data
source.</description>
<config-property-name>ConnectionDriverName</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The JNDI name of the connection factory to use for
finding non-transactional connections. If specified, this is the
connection that will be used for access for obtaining sequence
numbers.</description>
<config-property-name>ConnectionFactory2Name</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>jdbc/petshop</config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to be passed to
the JDBC Driver when obtaining a Connection for the ConnectionFactory2
(which will be used to obtain sequence numbers). Properties are of the
form "key=value". If a javax.sql.DataSource class is defined in the
javax.jdo.option.ConnectionDriverName property, then this property will be
used to set bean-like properties in the DataSource instance upon creation.
These properties vary depending on the DataSource in use: see the
documentation for your DataSource for details on the properties to
use.</description>
<config-property-name>ConnectionFactory2Properties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The JNDI name of the connection factory to use for
obtaining connections.</description>
<config-property-name>ConnectionFactoryName</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>PetShopXADataSource</config-property-value>
</config-property>
<config-property>
<description>The password for the user specified in
ConnectionUserName</description>
<config-property-name>ConnectionPassword</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to be passed to
the JDBC Driver when obtaining a Connection. Properties are of the form
"key=value". If a javax.sql.DataSource class is defined in the
javax.jdo.option.ConnectionDriverName property, then this property will be
used to set bean-like properties in the DataSource instance upon creation.
These properties vary depending on the DataSource in use: see the
documentation for your DataSource for details on the properties to
use.</description>
<config-property-name>ConnectionProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The connection retain mode. Possible options are
"persistence-manager", "transaction", and "on-demand". Default value is
"on-demand".</description>
<config-property-name>ConnectionRetainMode</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>on-demand</config-property-value>
</config-property>
<config-property>
<description>The number of seconds to wait between testing
connections retrieved from the connection pool. Only valid when using the
built-in Kodo connection pooling.</description>
<config-property-name>ConnectionTestTimeout</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>10</config-property-value>
</config-property>
<config-property>
<description>The URL for the data source.</description>
<config-property-name>ConnectionURL</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The username for the connection listed in
ConnectionURL.</description>
<config-property-name>ConnectionUserName</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The name of the class to use for caching of data loaded
from the data store. Must implement
com.solarmetric.kodo.runtime.datacache.DataCache.</description>
<config-property-name>DataCacheClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in com.solarmetric.kodo.DataCacheClass upon
initialization.</description>
<config-property-name>DataCacheProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The name of the default class to use for mapping
persistent classes to the database. Must extend
com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.</description>
<config-property-name>DefaultClassMappingClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping</config-property-value>
</config-property>
<config-property>
<description>The number of seconds that data in the data cache is
valid for. A value of 0 or less means that by default, cached data does
not time out.</description>
<config-property-name>DefaultDataCacheTimeout</config-property-name>
<config-property-type>java.lang.Double</config-property-type>
<config-property-value>0.0</config-property-value>
</config-property>
<config-property>
<description>The number of rows that will be pre-fetched when an
element in a Query result is accessed.</description>
<config-property-name>DefaultFetchBatchSize</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>10</config-property-value>
</config-property>
<config-property>
<description>The threshold below which result lists will be
completely instantiated upon their creation. A value of -1 will always
force all results to be completely instantiated, thus disabling lazy
result loading.</description>
<config-property-name>DefaultFetchThreshold</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>30</config-property-value>
</config-property>
<config-property>
<description>The name of the default class to use for managing
subclass indicator columns. Must implement the
com.solarmetric.kodo.impl.jdbc.ormapping.SubclassProvider interface. See
custom class indicator documentation for more information about subclass
providers.</description>
<config-property-name>DefaultSubclassProviderClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.impl.jdbc.ormapping.SubclassProviderImpl</config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in
com.solarmetric.kodo.impl.jdbc.DefaultSubclassProviderClass upon
initialization.</description>
<config-property-name>DefaultSubclassProviderProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The DBDictionary to use for this configuration. This is
auto-detected based on the setting of javax.jdo.option.ConnectionURL, so
you need only set this to override the default with your own custom
DBDictionary or if you are using an unrecognized driver.</description>
<config-property-name>DictionaryClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>A space-separated list of name-value properties
settings to pass to the dictionary defined by
com.solarmetric.kodo.impl.jdbc.DictionaryClass. Many of the DBDictionary
options are automatically configured by concrete subclasses of
GenericDictionary. The defaults can, however, be overridden by using this
property.</description>
<config-property-name>DictionaryProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>If true, then Kodo JDO will allow the use of query
filter extensions. See the query extensions documentation for more
information.</description>
<config-property-name>EnableQueryExtensions</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
<config-property>
<description>A comma-separated list of fetch group names that
PersistenceManagers will load by default when loading data from the
database.</description>
<config-property-name>FetchGroups</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>If true, then all fields of all classes in a given
inheritance hierarchy will by default map into the least-derived type's
default primary table. If false then a new default primary table will be
created for each class in the inheritance hierarchy, and each type's
declared fields will map to that table by default.</description>
<config-property-name>FlatInheritanceMapping</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>true</config-property-value>
</config-property>
<config-property>
<description>A String value indicating whether or not Kodo should
automatically flush modifications to the data store before executing
queries.</description>
<config-property-name>FlushBeforeQueries</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>with-connection</config-property-value>
</config-property>
<config-property>
<description>If false, then the JDO implementation must consider
modifications, deletions, and additions in the PersistenceManager
transaction cache when executing a query inside a transaction. Else, the
implementation is free to ignore the cache and execute the query directly
against the data store.</description>
<config-property-name>IgnoreCache</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
<config-property>
<description>The license key provided to you by SolarMetric. Keys
are available at www.solarmetric.com</description>
<config-property-name>LicenseKey</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>xxxx</config-property-value>
</config-property>
<config-property>
<description>The name of the class to use for obtaining a reference
to the transaction manager in an enterprise environment. Must implement
the com.solarmetric.kodo.ee.ManagedRuntime interface.</description>
<config-property-name>ManagedRuntimeClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.ee.AutomaticManagedRuntime</config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in com.solarmetric.kodo.ManagedRuntimeClass upon
initialization.</description>
<config-property-name>ManagedRuntimeProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The maximum number of connections to pool. If all of
these are in use, then PersistenceManager instances must wait for a
connection to become available. This option has been removed from the
specification, but we still use the javax.jdo.option for backwards
compatibility.</description>
<config-property-name>MaxPool</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>200</config-property-value>
</config-property>
<config-property>
<description>The minimum number of connections to keep in the pool.
This option has been removed from the specification, but we still use the
javax.jdo.option for backwards compatibility.</description>
<config-property-name>MinPool</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>2</config-property-value>
</config-property>
<config-property>
<description>The number of milliseconds to wait for a pooled
connection before throwing an exception if the pool is empty. This option
has been removed from the specification, but we still use the
javax.jdo.option for backwards compatibility.</description>
<config-property-name>MsWait</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>30000</config-property-value>
</config-property>
<config-property>
<description>If true, then the application plans to have multiple
threads simultaneously accessing a single PersistenceManager, so measures
must be taken to ensure that the implementation is thread-safe. Otherwise,
the implementation need not address thread safety.</description>
<config-property-name>Multithreaded</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
<config-property>
<description>If true, then it is possible to read persistent data
outside the context of a transaction. Otherwise, a transaction must be in
progress in order read data.</description>
<config-property-name>NontransactionalRead</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>true</config-property-value>
</config-property>
<config-property>
<description>If true, then it is possible to write to fields of a
persistent-nontransactional object when a transaction is not in progress.
If false, such a write will result in a JDOUserException.</description>
<config-property-name>NontransactionalWrite</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
<config-property>
<description>Selects between optimistic and pessimistic (data store)
transactional modes.</description>
<config-property-name>Optimistic</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
<config-property>
<description>The name of the class that the
PersistenceManagerFactory should create when creating a new
PersistenceManagerImpl. Must extend
com.solarmetric.kodo.runtime.PersistenceManagerImpl.</description>
<config-property-name>PersistenceManagerClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The name of the concrete implementation of
javax.jdo.PersistenceManagerFactory that
javax.jdo.JDOHelper.getPersistenceManagerFactory () should create. For
Kodo JDO, this should be
com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory or
com.solarmetric.kodo.impl.jdbc.ee.EEPersistenceManagerFactory, or a custom
extension of one of these types.</description>
<config-property-name>PersistenceManagerFactoryClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory</config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in com.solarmetric.kodo.PersistenceManagerClass upon
initialization.</description>
<config-property-name>PersistenceManagerProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>A comma-separated list of classes that will be
initialized whenever a new PersistenceManager is instantiated. This can be
used to get around issues with application identity classes not being
associated with their respective persistent classes.</description>
<config-property-name>PersistentTypes</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The name of the class to use to proxy second class
objects in managed instances. Must implement
com.solarmetric.kodo.util.ProxyManager.</description>
<config-property-name>ProxyManagerClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.util.SimpleProxyManager</config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in com.solarmetric.kodo.ProxyManagerClass upon
initialization.</description>
<config-property-name>ProxyManagerProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The name of the class to use for caching of queries
loaded from the data store. Must implement
com.solarmetric.kodo.runtime.datacache.QueryCache.</description>
<config-property-name>QueryCacheClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.runtime.datacache.query.QueryCacheImpl</config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in com.solarmetric.kodo.QueryCacheClass upon
initialization.</description>
<config-property-name>QueryCacheProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>A list of query filter listeners to add to the default
list of extensions. Ignored if com.solarmetric.kodo.EnableQueryExtensions
is false.</description>
<config-property-name>QueryFilterListeners</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The name of the class to use for communicating commit
information among JVMs. Must implement
com.solarmetric.kodo.runtime.event.RemoteCommitProvider.</description>
<config-property-name>RemoteCommitProviderClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in com.solarmetric.kodo.RemoteCommitProviderClass upon
initialization.</description>
<config-property-name>RemoteCommitProviderProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>If true, then fields in a persistence-capable object
that have been changed during a transaction will be rolled back to their
original values upon a rollback. Otherwise, the values will not be changed
upon rollback.</description>
<config-property-name>RestoreValues</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>true</config-property-value>
</config-property>
<config-property>
<description>The name of the class that will be used as the
Collection implementation for returning ResultList instances. It must be
an instance of
com.solarmetric.kodo.runtime.objectprovider.ResultList.</description>
<config-property-name>ResultListClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The property string used to configure the instance of
the ResultListClass.</description>
<config-property-name>ResultListProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>If true, then fields in a persistence-capable object
that have been read during a transaction must be preserved in memory after
the transaction commits. Otherwise, persistence-capable objects must
transition to the hollow state upon commit, meaning that subsequent reads
will result in a database round-trip.</description>
<config-property-name>RetainValues</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
<config-property>
<description>The name of the class to use for generating sequence
numbers when using data store identity. Must implement the
com.solarmetric.kodo.impl.jdbc.SequenceFactory interface.</description>
<config-property-name>SequenceFactoryClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory</config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in com.solarmetric.kodo.impl.jdbc.SequenceFactoryClass upon
initialization.</description>
<config-property-name>SequenceFactoryProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The class names of a SQLExecutionListener
implementation to install on the SQLExecutionManager.</description>
<config-property-name>SQLExecutionListenerClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<description>The name of a custom SQLExecutionManager to be used for
all issuance of SQL to the data store. Must implement
com.solarmetric.kodo.impl.jdbc.SQLExecutionManager.</description>
<config-property-name>SQLExecutionManagerClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl</config-property-value>
</config-property>
<config-property>
<description>The size of the PreparedStatement cache that is
maintained in the DataSource implementation.</description>
<config-property-name>StatementCacheMaxSize</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>70</config-property-value>
</config-property>
<config-property>
<description>The time, in seconds, after which a JDBC query will be
aborted if it has not yet returned any values. This value is simply passed
to the JDBC driver's Statement.setTimeout method; Kodo does not perform
any addition timeout actions. Note that many JDBC drivers either ignore
this request, or improperly handle it, which may result in application
deadlocks.</description>
<config-property-name>StatementExecutionTimeout</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>-1</config-property-value>
</config-property>
<config-property>
<description>If true, the Kodo runtime will automatically attempt to
refresh the database schema when persistent classes are referenced,
allowing the developer to bypass the schematool step. This property is
only intended to be used for development. As automatic schema migration
can result in data loss, this feature should never be enabled on a
production system. Furthermore, this feature has serious adverse affects
on Kodo's runtime performace. Ensure that it is disabled before doing any
performance analysis.</description>
<config-property-name>SynchronizeSchema</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
<config-property>
<description>The name of the class to use to store
persistence-capable objects involved in a PM's transaction cache. Must
implement com.solarmetric.kodo.runtime.StateManagerSet.</description>
<config-property-name>TransactionCacheClass</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>com.solarmetric.kodo.runtime.FifoStateManagerSet</config-property-value>
</config-property>
<config-property>
<description>A space-separated list of properties to pass to the
class defined in com.solarmetric.kodo.TransactionCacheClass upon
initialization.</description>
<config-property-name>TransactionCacheProperties</config-property-name>
<config-property-type>java.lang.String</config-property -
Using Tangosol Coherence in conjunction with Kodo JDO for distributing caching
JDO currently has a perception problem in terms of performance. Transparent
persistence is perceived to have a significant performance overhead compared
to hand-coded JDBC. That was certainly true a while ago, when the first JDO
implementations were evaluated. They typically performed about half as well
and with higher resource requirements. No doubt JDO vendors have closed that
gap by caching PreparedStatements, queries, data, and by using other
optimizations.
Aside from the ease of programming through transparent persistence, I
believe that using JDO in conjunction with distributed caching techniques in
a J2EE managed environment has the opportunity to transparently give
scalability, performance, and availability improvements that would otherwise
be much more difficult to realize through other persistence techniques.
In particular, it looks like Tangosol is doing a lot of good work in the
area of distributed caching for J2EE. For example, executing parallelized
searches in a cluster is a capability that is pretty unique and potentially
very valuable to many applications. It would appear to me to be a lot of
synergy between Kodo JDO and Tangosol Coherence. Using Coherence as an
implementation of Kodo JDO's distributed cache would be a natural desire for
enterprise applications that have J2EE clustering requirements for high
scalability, performance, and availability.
I'm wondering if Solarmetric has any ideas or plans for closer integration
(e.g., pluggability) of Tangosol Coherence into Kodo JDO. This is just my
personal opinion, but I think a partnership between your two organizations
to do this integration would be mutually advantageous, and it would
potentially be very attractive to your customers.
BenMarc,
Thanks for pointing that out. That is truly excellent!
Ben
"Marc Prud'hommeaux" <[email protected]> wrote in message
news:[email protected]...
Ben-
We do currently have a plug-in for backing our data cache with a
Tangosol cache.
See: http://docs.solarmetric.com/manual.html#datastore_cache_config
In article <[email protected]>, Ben Eng wrote:
JDO currently has a perception problem in terms of performance.
Transparent
persistence is perceived to have a significant performance overheadcompared
to hand-coded JDBC. That was certainly true a while ago, when the firstJDO
implementations were evaluated. They typically performed about half aswell
and with higher resource requirements. No doubt JDO vendors have closedthat
gap by caching PreparedStatements, queries, data, and by using other
optimizations.
Aside from the ease of programming through transparent persistence, I
believe that using JDO in conjunction with distributed cachingtechniques in
a J2EE managed environment has the opportunity to transparently give
scalability, performance, and availability improvements that wouldotherwise
be much more difficult to realize through other persistence techniques.
In particular, it looks like Tangosol is doing a lot of good work in the
area of distributed caching for J2EE. For example, executingparallelized
searches in a cluster is a capability that is pretty unique andpotentially
very valuable to many applications. It would appear to me to be a lot of
synergy between Kodo JDO and Tangosol Coherence. Using Coherence as an
implementation of Kodo JDO's distributed cache would be a natural desirefor
enterprise applications that have J2EE clustering requirements for high
scalability, performance, and availability.
I'm wondering if Solarmetric has any ideas or plans for closerintegration
(e.g., pluggability) of Tangosol Coherence into Kodo JDO. This is justmy
personal opinion, but I think a partnership between your twoorganizations
to do this integration would be mutually advantageous, and it would
potentially be very attractive to your customers.
Ben--
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com -
Kodo JDO 2.5.0 beta now available
All,
Kodo JDO 2.5.0 beta 1 is now available at:
http://solarmetric.com/Software/beta/2.5.0/
Some notable new features since 2.4 include:
- Queries have received a major overhaul. Queries now support unbound
variables, Collections as parameters to generate SQL IN (...) clauses,
traversing fields of persistence-capable parameters, and more. The SQL
produced by queries is also much more efficient.
- Kodo JDO EE can now participate correctly in XA transactions.
- Kodo JDO now includes support for custom fetch groups.
- Queries and Extents can be constructed for interfaces.
- Multi-table mappings now permit different tables to have different
primary key column names.
- The data cache framework can now cache query results.
Known issues:
- The JCA resource adapter will not seamlessly work with WebLogic -- to
use it with WebLogic, it is necessary to unzip the kodo.rar and remove
empty config-param-value elements
(i.e. <config-properrty-value></config-property-value>).
- We have done only limited integration testing with our IDE plugins.
- Cached query results do not obey the timeouts configured for the classes
in the query's access path.
As usual, please discuss any issues, desires, etc. on the beta newsgroup:
news://news.solarmetric.com/solarmetric.kodo.beta
Enjoy,
-Patrick
Patrick Linskey
SolarMetric Inc.All,
Kodo JDO 2.5.0 beta 1 is now available at:
http://solarmetric.com/Software/beta/2.5.0/
Some notable new features since 2.4 include:
- Queries have received a major overhaul. Queries now support unbound
variables, Collections as parameters to generate SQL IN (...) clauses,
traversing fields of persistence-capable parameters, and more. The SQL
produced by queries is also much more efficient.
- Kodo JDO EE can now participate correctly in XA transactions.
- Kodo JDO now includes support for custom fetch groups.
- Queries and Extents can be constructed for interfaces.
- Multi-table mappings now permit different tables to have different
primary key column names.
- The data cache framework can now cache query results.
Known issues:
- The JCA resource adapter will not seamlessly work with WebLogic -- to
use it with WebLogic, it is necessary to unzip the kodo.rar and remove
empty config-param-value elements
(i.e. <config-properrty-value></config-property-value>).
- We have done only limited integration testing with our IDE plugins.
- Cached query results do not obey the timeouts configured for the classes
in the query's access path.
As usual, please discuss any issues, desires, etc. on the beta newsgroup:
news://news.solarmetric.com/solarmetric.kodo.beta
Enjoy,
-Patrick
Patrick Linskey
SolarMetric Inc. -
Kodo JDO 2.5.0 now available
All,
Kodo JDO 2.5.0 is now available. Thanks, everyone, for helping out
throughout the 2.5.0 public beta period. You're all great.
You can get Kodo JDO 2.5.0 at:
http://solarmetric.com/Software/Purchase/download.php
Major changes include:
- Major query modifications. Unbound variables are now supported,
Collections can be used as parameters in queries, and several SQL
inefficiencies have been addressed.
- Custom fetch group support.
- Kodo now supports incremental flushing of data to the database.
This can be useful in EJB environments when using container-managed
transactions, in order to handle any flush-related exceptions
within the bean code. It can also be useful in conjunction with
Kodo's automatic flushing capabilities to accelerate querying when
the javax.jdo.option.IgnoreCache property is set to false.
- Added JDOException subclasses for certain interesting exception
types: OptimisticLockException and ObjectNotFoundException.
- Enhancement-time metadata enhancement has been improved. This means
that you may see some errors the next time you re-enhance your
project, but that's for the best -- they were errors anyways.
- Data caching framework now caches JDOQL query results as well as
persistence-capable data. This provides dramatic acceleration for
commonly executed queries.
- The data caching framework has been reworked to separate out the
data cache capabilities from the remote event notification
capabilities. As a result, 2.5.0 data cache configuration is not
compatible with earlier data cache configuration, and custom cache
extensions will likely need some level of revision. For details,
see the release notes in the Kodo JDO Developer's Guide.
For more details, see the Kodo JDO Developer's Guide and the full release
notes, available at:
http://solarmetric.com/docs/2.5.0RC3/docs/index.html
http://solarmetric.com/docs/2.5.0RC3/docs/relnotes.html
Enjoy,
-Patrick
Patrick Linskey
SolarMetric Inc.Minor correction:
http://solarmetric.com/docs/2.5.0RC3/docs/index.html
http://solarmetric.com/docs/2.5.0RC3/docs/relnotes.html
The 2.5.0 final docs are actually at:
http://solarmetric.com/docs/2.5.0/docs/index.html
http://solarmetric.com/docs/2.5.0/docs/relnotes.html
In article <[email protected]>, Patrick Linskey wrote:
All,
Kodo JDO 2.5.0 is now available. Thanks, everyone, for helping out
throughout the 2.5.0 public beta period. You're all great.
You can get Kodo JDO 2.5.0 at:
http://solarmetric.com/Software/Purchase/download.php
Major changes include:
- Major query modifications. Unbound variables are now supported,
Collections can be used as parameters in queries, and several SQL
inefficiencies have been addressed.
- Custom fetch group support.
- Kodo now supports incremental flushing of data to the database.
This can be useful in EJB environments when using container-managed
transactions, in order to handle any flush-related exceptions
within the bean code. It can also be useful in conjunction with
Kodo's automatic flushing capabilities to accelerate querying when
the javax.jdo.option.IgnoreCache property is set to false.
- Added JDOException subclasses for certain interesting exception
types: OptimisticLockException and ObjectNotFoundException.
- Enhancement-time metadata enhancement has been improved. This means
that you may see some errors the next time you re-enhance your
project, but that's for the best -- they were errors anyways.
- Data caching framework now caches JDOQL query results as well as
persistence-capable data. This provides dramatic acceleration for
commonly executed queries.
- The data caching framework has been reworked to separate out the
data cache capabilities from the remote event notification
capabilities. As a result, 2.5.0 data cache configuration is not
compatible with earlier data cache configuration, and custom cache
extensions will likely need some level of revision. For details,
see the release notes in the Kodo JDO Developer's Guide.
For more details, see the Kodo JDO Developer's Guide and the full release
notes, available at:
http://solarmetric.com/docs/2.5.0RC3/docs/index.html
http://solarmetric.com/docs/2.5.0RC3/docs/relnotes.html
Enjoy,
-Patrick
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com -
Please remove Class-Path from kodo-jdo-runtime.jar manifest
This is repost. Class-Path should not be in manifest of
kodo-jdo-runtime.jar
It causes problems with security manager when using signed jars under
webstart. It can potentially cause all kind of other problems due to class
path conflicts
Seems to be a problem in manifest. It is due to Class-Path in manifest. I
deleted manifest from kodo-jdo-runtime and signed it seems to be ok.
I got more meaningful error now - serp.jar is missing
I would suggest to remove Class-Path from this jar. I've seen some very
weired behaviour of systems with Class-Path in different jars. I believe it
should be only in your application jar
Class-Path: serp.jar jca1.0.jar jca.jar crimson.jar xerces.jar jaxp.jar
jdo1_0.jar jdo.jar jdbc2_0-stdext.jar jndi.jar jta-spec1_0_1.jar jta.jar
I would also remove following:
Main-Class: com.solarmetric.kodo.enhance.JDOEnhancer
OpenTools-UI: com.solarmetric.modules.integration.jbuilder.KodoTools
OpenTools-Build: com.solarmetric.modules.integration.jbuilder.KodoBuilder
because it does not belong to kodo-jdo.runtime.jar
"Alex Roytman" <[email protected]> wrote in message
news:ahi05g$veq$[email protected]..
I am having troubles running kodo 2.3 application under web start.
I am getting following error:
Missing signed entry in resource:
http://ptilx1/usorg/webstart/lib/kodo-jdo-runtime.jar
I signed kodo-jdo-runtime.jar as usual
The same deployment worked fine with Kodo 2.2.5Alex-
In article <ahk7vi$cmf$[email protected]>, Alex Roytman wrote:
This is repost. Class-Path should not be in manifest of
kodo-jdo-runtime.jar
It causes problems with security manager when using signed jars under
webstart. It can potentially cause all kind of other problems due to class
path conflictsThanks for the feedback. We will remove the entries. In general, it is nice
to have it in the Class-Path, since they you only need to
kodo-jdo-runtime.jar in the CLASSPATH variable, but we were not aware of
it causing any problems.
Seems to be a problem in manifest. It is due to Class-Path in manifest. I
deleted manifest from kodo-jdo-runtime and signed it seems to be ok.
I got more meaningful error now - serp.jar is missing
I would suggest to remove Class-Path from this jar. I've seen some very
weired behaviour of systems with Class-Path in different jars. I believe it
should be only in your application jar
Class-Path: serp.jar jca1.0.jar jca.jar crimson.jar xerces.jar jaxp.jar
jdo1_0.jar jdo.jar jdbc2_0-stdext.jar jndi.jar jta-spec1_0_1.jar jta.jar
I would also remove following:
Main-Class: com.solarmetric.kodo.enhance.JDOEnhancer
OpenTools-UI: com.solarmetric.modules.integration.jbuilder.KodoTools
OpenTools-Build: com.solarmetric.modules.integration.jbuilder.KodoBuilder
because it does not belong to kodo-jdo.runtime.jarCorrect again: we will remove it in the upcoming release.
"Alex Roytman" <[email protected]> wrote in message
news:ahi05g$veq$[email protected]..
I am having troubles running kodo 2.3 application under web start.
I am getting following error:
Missing signed entry in resource:
http://ptilx1/usorg/webstart/lib/kodo-jdo-runtime.jar
I signed kodo-jdo-runtime.jar as usual
The same deployment worked fine with Kodo 2.2.5
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Kodo Java Data Objects Full featured JDO: eliminate the SQL from your code -
JDO with container (J2EE) managed DataSource
Hello,
I would like to use application server managed DataSource with JDO and
would love to find a piece of documentation/link that would take me
through it.
In absence of such a document, any advice/idea will be appreciated.
Based on the bits and pieces that I have already discovered, I assume that:
when binding the PersistanceManagerFactory to JNDI, I should use
DataSource ds = (DataSource)ic.lookup("jdbc/myDataSourceName");
pmf.setConnectionFactory(ds);
... to set the datasource (instead of ConnectionFactory). Is that it?
I found some older topics (July?) that mentioned that this is NOT
officially supported. Quote:
<i>A couple of warnings, though:
* The use of external datasources is untested.
* If using the datasource within an appserver, the Connections from it
should not be automatically committed/rolled back with the completion of
the
global transaction. Kodo performs its own transaction management on the
Connections it uses. In future releases we'll be able to handle
Connections
that are controlled by the appserver.</i>
Is it still the case now or is this the official way to integrate
application server (Websphere 5.0) with JDO now? Assuming that Kodo was
configured to integrate with TransactionManager of the application server,
is there a reason not to let the application server control the
transactions? Are we going to run into problems if we do it?
Thank you,
PetrHi Ben,
Thank you for your advice, that is an experience that it is good to know
about.
In terms of forcing (configuring) Kodo to use the existing data source
from application server, how did you do it?
Based on the structure bellow, I would assume that you used the Java
Connector option. Other then the experience you mentioned, are you happy
camper?
Thank you,
Petr
Ben Eng wrote:
Here is my experience using Kodo with BEA WebLogic Server. Your mileage may
vary with IBM WebSphere.
When using a JDBC driver in the application server\'s classpath (which would
be the case with a managed DataSource), the JDBC driver does not have access
to your J2EE application\'s classes for deserializing them from BLOBs.
Therefore, the Kodo serialized BLOB mapping would not work in this
configuration. You will need to rely solely on more sophisticated O/R
mappings.
Kodo integrates well with the application servers managed Transactions, when
packaged as a JCA resource adapter. With BEA WLS, I found that I had to
repackage things as follows:
myApp.ear
|
+-application.xml
+-jakarta-commons-logging-1.0.2.jar
+-jdbc2_0-stdext.jar
+-jdo1_0.jar
+-kodo-jdo-runtime.jar
+-serp.jar
+-mysql-connector-java-3.0.3-beta-bin.jar (or whatever your JDBC
driver is)
|
+-kodo.rar
| +-META-INF
| +-MANIFEST.MF
| +-ra.xml
| +-weblogic-ra.xml
+-myEJB.jar
+-META-INF
| +-MANIFEST.MF
+-myEJB.class
Both the kodo.rar and myEJB.jar MANIFEST.MF looks like this:
Manifest-Version: 1.0
Class-Path: serp.jar jdo1_0.jar kodo-jdo-runtime.jar
jakarta-commons-logging-1.0.2.jar jdbc2_0-stdext.jar
mysql-connector-java-3.0.3-beta-bin.jar
When the JDBC driver is packaged with the application EAR like this,
deserialization of BLOB also works fine. If you do have the JDBC driver in
the application server\'s classpath, it will be loaded from there first and
deserialization of BLOBs will break. Unfortunately, this is limitation is
terribly limiting, because CMP EntityBeans and JMS destinations that require
persistent storage will need to use managed DataSources. Probably the best
compromise is to have the JDBC driver in the application server\'s classpath,
not in the application EAR, and live without BLOB mappings (not a big loss
in real world applications).
Ben
\"Petr Bulanek\" <[email protected]> wrote in message
news:[email protected]...
Hello,
I would like to use application server managed DataSource with JDO and
would love to find a piece of documentation/link that would take me
through it.
In absence of such a document, any advice/idea will be appreciated.
Based on the bits and pieces that I have already discovered, I assumethat:
when binding the PersistanceManagerFactory to JNDI, I should use
DataSource ds = (DataSource)ic.lookup(\"jdbc/myDataSourceName\");
pmf.setConnectionFactory(ds);
.. to set the datasource (instead of ConnectionFactory). Is that it?
I found some older topics (July?) that mentioned that this is NOT
officially supported. Quote:
<i>A couple of warnings, though:
* The use of external datasources is untested.
* If using the datasource within an appserver, the Connections from it
should not be automatically committed/rolled back with the completion of
the
global transaction. Kodo performs its own transaction management on the
Connections it uses. In future releases we\'ll be able to handle
Connections
that are controlled by the appserver.</i>
Is it still the case now or is this the official way to integrate
application server (Websphere 5.0) with JDO now? Assuming that Kodo was
configured to integrate with TransactionManager of the application server,
is there a reason not to let the application server control the
transactions? Are we going to run into problems if we do it?
Thank you,
Petr -
Open Source BI Tool Now Supports Kodo JDO
Folks,
To keep you posted on the latest tools that work with Kodo JDO, we
will try and post notices here on our newsgroups. ObjectVisualizer
is a third party open source querying, reporting and graphing tool that
now supports Kodo JDO. Let us know what you think.
Neelan Choksi
President, SolarMetric
ObjectVisualizer is a business intelligence tool that builds upon
Object Persistence technology to provide easy to use query, reporting,
and charting capabilities.
Features include: Query, filter, and aggregate data using objects,
Interactive Data Table, Report Generation, Chart Creation, and Plugin
Architecture.
ObjectVisualizer now supports KodoJDO! ObjectVisualizer 1.0.1 includes
a KodoJDO plugin along with a number of bug fixes and enhancements.
A new Early Access release of ObjectVisualizer Server Edition is also
available. ObjectVisualizer Server Edition EAP-2 has been upgraded to
work with ObjectVisualizer 1.0.1 and includes a number of performance
enhancements.
For more information visit:
http://objectvisualizer.com
Thank you,
Open Source Software Solutions, LLC
http://opensourcesoft.netFolks,
To keep you posted on the latest tools that work with Kodo JDO, we
will try and post notices here on our newsgroups. ObjectVisualizer
is a third party open source querying, reporting and graphing tool that
now supports Kodo JDO. Let us know what you think.
Neelan Choksi
President, SolarMetric
ObjectVisualizer is a business intelligence tool that builds upon
Object Persistence technology to provide easy to use query, reporting,
and charting capabilities.
Features include: Query, filter, and aggregate data using objects,
Interactive Data Table, Report Generation, Chart Creation, and Plugin
Architecture.
ObjectVisualizer now supports KodoJDO! ObjectVisualizer 1.0.1 includes
a KodoJDO plugin along with a number of bug fixes and enhancements.
A new Early Access release of ObjectVisualizer Server Edition is also
available. ObjectVisualizer Server Edition EAP-2 has been upgraded to
work with ObjectVisualizer 1.0.1 and includes a number of performance
enhancements.
For more information visit:
http://objectvisualizer.com
Thank you,
Open Source Software Solutions, LLC
http://opensourcesoft.net -
I first used Kodo JDO 2.3.2 last year while working for a client. I had
tried (unsuccessfully) entity beans and Apache's OBJ before trying JDO.
Unfortunately the client put the project on hold and I couldn't finish the
project. Now I once again find myself working on a prototype for a customer
that is perfect for JDO. I'm now using 2.4.1 and I'm amazed at the
improvements. First off the Eclipse integration is wonderful. The second
thing is the JCA/JTA integration with JBoss, works great! I'm also
impressed that the price hasn't changed. LiDO, another JDO vendor, wanted
$4,000/CPU for their Enterprise version. I told them how rediculous they
were. Who do they think they are, WebLogic? Finally the support here is
top notch.
Anyway, this is just a note to say thanks and keep up the great work,
especially with the Eclipse plugin!
MichaelThanks Patrick, the patch fixes the serialization problems I was having...
"Patrick Linskey" <[email protected]> wrote:
Hello all,
A new patch to Kodo JDO 2.2.1 is now available. It includes:
- a fix that should make serialization (and, as a result,
deserialization) of proxied second class objects such as HashMaps
etc. work correctly.
- Abe's jdoNewInstance() application identity fix (see Abe's post
from last week).
- a faulty invocation of Class.forName() that caused queries to fail
in certain web application environments.
- minor documentation and error reporting fixes.
Links:
http://www.techtrader.com/products/kodo-beta/tt-jdo-2.2.1-patched.jar
http://www.techtrader.com/products/kodo-beta/tt-jdoee-2.2.1-patched.jar
>
As always, this interim release is of beta quality, as is appropriate
for the beta news group. It contains fixes that may cause more problems
than they solve, so treat it with care.
Enjoy.
-Patrick
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com -
I am trying to update 3.x to 4.0.1
Cloning of JDOConnectionFactory is throwing following exception
(JDOConnectionFactory)pmf1.clone();
I had this working with 3.x the only difference was that JDBCConnectionFactory was being used instead of JDOConnectionFactory, and I have to use JDOConnectionFactory in 4.0.1 to get PersistenceManagerFactory.
com.solarmetric.util.ParseException: java.lang.NoSuchMethodException: kodo.jdo.jdbc.JDOConnectionFactory.<init>(boolean)
at com.solarmetric.conf.ConfigurationImpl.clone(ConfigurationImpl.java:752)
at com.bea.rfid.login.console.ejb.CredentialMapperBean.setSessionContext(CredentialMapperBean.java:125)
at com.bea.rfid.login.console.ejb.CredentialMapperEJB_ckhjzn_Impl.setSessionContext(CredentialMapperEJB_ckhjzn_Impl.java:124)
at weblogic.ejb.container.manager.StatelessManager.createBean(StatelessManager.java:296)
at weblogic.ejb.container.pool.StatelessSessionPool.createBean(StatelessSessionPool.java:174)
at weblogic.ejb.container.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:105)
at weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:143)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:133)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:81)
at weblogic.ejb.container.internal.StatelessEJBLocalObject.preInvoke(StatelessEJBLocalObject.java:48)Thanks for the suggestion.
I updated to kodo-4.1.2 now, and still I am getting following exception
javax.ejb.EJBException: Error during setSessionContext: org.apache.openjpa.lib.util.ParseException: java.lang.NoSuchMethodException: kodo.jdo.jdbc.JDOConnectionFactory.<init>(boolean)
at org.apache.openjpa.lib.conf.ConfigurationImpl.clone(ConfigurationImpl.java:873)
at com.bea.rfid.login.console.ejb.CredentialMapperBean.setSessionContext(CredentialMapperBean.java:125)
at com.bea.rfid.login.console.ejb.CredentialMapperEJB_ckhjzn_Impl.setSessionContext(CredentialMapperEJB_ckhjzn_Impl.java:124)
at weblogic.ejb.container.manager.StatelessManager.createBean(StatelessManager.java:296)
at weblogic.ejb.container.pool.StatelessSessionPool.createBean(StatelessSessionPool.java:174)
at weblogic.ejb.container.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:105)
at weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:143)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:133)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:81)
at weblogic.ejb.container.internal.StatelessEJBLocalObject.preInvoke(StatelessEJBLocalObject.java:48)
at com.bea.rfid.login.console.ejb.CredentialMapperEJB_ckhjzn_ELOImpl.getPersistenceManager(CredentialMapperEJB_ckhjzn_ELOImpl.java:42)
at com.connecterra.epcis.server.ejb.EPCISBean.ejbCreate(EPCISBean.java:147)
at com.connecterra.epcis.server.ejb.EPCIS_9tvcog_Impl.ejbCreate(EPCIS_9tvcog_Impl.java:150)
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:585)
at weblogic.ejb.container.pool.StatelessSessionPool.createBean(StatelessSessionPool.java:178)
at weblogic.ejb.container.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:105)
at weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:143)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:133)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:81)
at weblogic.ejb.container.internal.StatelessEJBLocalObject.preInvoke(StatelessEJBLocalObject.java:48)
at com.connecterra.epcis.server.ejb.EPCIS_9tvcog_ELOImpl.getAllSubscriptionInfo(EPCIS_9tvcog_ELOImpl.java:1304)
at com.connecterra.epcis.server.ejb.scheduler.SchedulerBean.refreshTimer(SchedulerBean.java:131)
at com.connecterra.epcis.server.ejb.scheduler.SchedulerBean.initializeTimer(SchedulerBean.java:98)
at com.connecterra.epcis.server.ejb.scheduler.SubscriptionScheduler_jm2ekz_ELOImpl.initializeTimer(SubscriptionScheduler_jm2ekz_ELOImpl.java:63)
at com.connecterra.epcis.server.schedulerservlet.SchedulerServlet.init(SchedulerServlet.java:32)
at javax.servlet.GenericServlet.init(GenericServlet.java:256)
at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:276)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:68)
at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:48)
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:504)
at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1698)
at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1675)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1595)
at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2734)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:892)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:336)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:26)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:641)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:229)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:181)
at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:352)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:52)
at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:186)
at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
Caused by: java.lang.NoSuchMethodException: kodo.jdo.jdbc.JDOConnectionFactory.<init>(boolean)
at java.lang.Class.getConstructor0(Class.java:2647)
at java.lang.Class.getConstructor(Class.java:1629)
at org.apache.openjpa.lib.conf.ConfigurationImpl.clone(ConfigurationImpl.java:863)
... 68 more
; nested exception is: org.apache.openjpa.lib.util.ParseException: java.lang.NoSuchMethodException: kodo.jdo.jdbc.JDOConnectionFactory.<init>(boolean)
at weblogic.ejb.container.internal.EJBRuntimeUtils.throwEJBException(EJBRuntimeUtils.java:141)
at weblogic.ejb.container.internal.BaseLocalObject.handleSystemException(BaseLocalObject.java:657)
at weblogic.ejb.container.internal.BaseLocalObject.handleSystemException(BaseLocalObject.java:604)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:141)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:81)
Truncated. see log file for complete stacktrace
>
<Dec 22, 2006 3:58:34 PM EST> <Error> <Deployer> <BEA-149231> <Unable to set the activation state to true for the application 'WLRFID-EPCIS'.
weblogic.application.ModuleException: [HTTP:101216]Servlet: "SchedulerServlet" failed to preload on startup in Web application: "schedulerservlet".
javax.ejb.EJBException: Error during setSessionContext: org.apache.openjpa.lib.util.ParseException: java.lang.NoSuchMethodException: kodo.jdo.jdbc.JDOConnectionFactory.<init>(boolean)
at org.apache.openjpa.lib.conf.ConfigurationImpl.clone(ConfigurationImpl.java:873)
at com.bea.rfid.login.console.ejb.CredentialMapperBean.setSessionContext(CredentialMapperBean.java:125)
at com.bea.rfid.login.console.ejb.CredentialMapperEJB_ckhjzn_Impl.setSessionContext(CredentialMapperEJB_ckhjzn_Impl.java:124)
at weblogic.ejb.container.manager.StatelessManager.createBean(StatelessManager.java:296)
at weblogic.ejb.container.pool.StatelessSessionPool.createBean(StatelessSessionPool.java:174)
at weblogic.ejb.container.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:105)
at weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:143)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:133)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:81)
at weblogic.ejb.container.internal.StatelessEJBLocalObject.preInvoke(StatelessEJBLocalObject.java:48)
at com.bea.rfid.login.console.ejb.CredentialMapperEJB_ckhjzn_ELOImpl.getPersistenceManager(CredentialMapperEJB_ckhjzn_ELOImpl.java:42)
at com.connecterra.epcis.server.ejb.EPCISBean.ejbCreate(EPCISBean.java:147)
at com.connecterra.epcis.server.ejb.EPCIS_9tvcog_Impl.ejbCreate(EPCIS_9tvcog_Impl.java:150)
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:585)
at weblogic.ejb.container.pool.StatelessSessionPool.createBean(StatelessSessionPool.java:178)
at weblogic.ejb.container.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:105)
at weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:143)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:133)
at weblogic.ejb.container.internal.BaseLocalObject.preInvoke(BaseLocalObject.java:81)
at weblogic.ejb.container.internal.StatelessEJBLocalObject.preInvoke(StatelessEJBLocalObject.java:48)
at com.connecterra.epcis.server.ejb.EPCIS_9tvcog_ELOImpl.getAllSubscriptionInfo(EPCIS_9tvcog_ELOImpl.java:1304)
at com.connecterra.epcis.server.ejb.scheduler.SchedulerBean.refreshTimer(SchedulerBean.java:131)
at com.connecterra.epcis.server.ejb.scheduler.SchedulerBean.initializeTimer(SchedulerBean.java:98)
at com.connecterra.epcis.server.ejb.scheduler.SubscriptionScheduler_jm2ekz_ELOImpl.initializeTimer(SubscriptionScheduler_jm2ekz_ELOImpl.java:63)
at com.connecterra.epcis.server.schedulerservlet.SchedulerServlet.init(SchedulerServlet.java:32)
at javax.servlet.GenericServlet.init(GenericServlet.java:256)
at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:276)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:68)
at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:48)
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:504)
at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1698)
at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1675)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1595)
at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2734)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:892)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:336)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:26)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:641)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:229)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:181)
at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:352)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:52)
at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:186)
at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
Caused by: java.lang.NoSuchMethodException: kodo.jdo.jdbc.JDOConnectionFactory.<init>(boolean)
at java.lang.Class.getConstructor0(Class.java:2647)
at java.lang.Class.getConstructor(Class.java:1629)
at org.apache.openjpa.lib.conf.ConfigurationImpl.clone(ConfigurationImpl.java:863)
... 68 more -
Reading large file with JCA Adapter in OSB
Hello,
We are searching for a solution how to read large file (>50M) from network drive and deliver it to queue via OSB 11gR4 (10.3.4). The problem is when reading the file with JCA File Adapter. It seems that it cannot handle as large files as we have. The documentation provides a way to bypass file size limitation by using Chunk Read but it seems to require BPEL Process execution which is not possible in our environment. Does anyone know if there are ways to implement this without having BPEL Process?
Our usecase:
read file from network drive -> transfer with OSB -> deliver MQ
Other options than JCA File Adapter can be considered, if anyone can advice...If it's a plain routing use case and no message processing is required then you may simply use OSB's FILE transport instead of JCA adapter. Create a messaging type proxy service and select request message type as "binary". Also enable the content streaming (Disk buffer, compression).
From OSB Dev guide -
Oracle JCA Adapter for FTP and Files – Attachments (large payload support), pre- and post-processing of files, using a re-entrant valve for processing ZIP files, content streaming, and file chunked read are not supported with Oracle Service Bus.
http://download.oracle.com/docs/cd/E17904_01/doc.1111/e15866/jca.htm#BABBICIA
You may also refer -
Reading huge flat file in OSB 11gR1
Regards,
Anuj -
Setting PMF parameters with JCA
Hi,
I am trying to use Kodo with JCA (in Jboss 3.2/WebSphere 5), but I don't
see how to communicate properties to the PMF. For instance, how do I tell
it which database driver to use? How do I ask for non-transactional reads
or set other options? I don't see this anywhere in the documentation, but
it seems like a pretty basic thing I'd need to know. Do I need to set all
the properties by hand after pulling the PMF out of JNDI? That would be
annoying.
Thanks,
Paul JungwirthPaul,
You should not specify a ConnectionFactoryName as that is the source of
the HSQL references.
Paul Jungwirth wrote:
Hi again,
So I figured out that each <config-property> element in the kodo-ds.xml
causes JBoss to call at setting method on the PMF. Now my kodo-ds.xml
looks like this:
<connection-factories>
<tx-connection-factory>
<jndi-name>kodo</jndi-name>
<adapter-display-name>KodoJDO</adapter-display-name>
<config-property name="LicenseKey"
type="java.lang.String">***</config-property>
<config-property name="ConnectionFactoryName"
type="java.lang.String">java:/DefaultDS</config-property>
<config-property name="ConnectionDriverName"
type="java.lang.String">oracle.jdbc.driver.OracleDriver</config-property>
<config-property name="ConnectionUserName"
type="java.lang.String">pjungwirth</config-property>
<config-property name="ConnectionPassword"
type="java.lang.String">***</config-property>
<config-property name="ConnectionURL"
type="java.lang.String">jdbc:oracle:thin:@hansen:1521:nfic9i</config-property>
<config-property name="Optimistic"
type="java.lang.Boolean">true</config-property>
<config-property name="RetainValues"
type="java.lang.Boolean">false</config-property>
<config-property name="NontransactionalRead"
type="java.lang.Boolean">true</config-property>
<config-property name="NontransactionalWrite"
type="java.lang.Boolean">false</config-property>
<config-property name="Multithreaded"
type="java.lang.Boolean">true</config-property>
<config-property name="TransactionMode"
type="java.lang.String">managed</config-property>
</tx-connection-factory>
</connection-factories>
But even though I've specified a ConnectionURL and ConnectionDriverName,
Kodo still wants to use hsqldb. I got a whole slew of stack traces that
basically originate in this:
Caused by: java.sql.SQLException: User not found: PJUNGWIRTH
at org.hsqldb.Trace.getError(Unknown Source)
at org.hsqldb.Result.<init>(Unknown Source)
at org.hsqldb.jdbcConnection.executeHSQL(Unknown Source)
at org.hsqldb.jdbcConnection.execute(Unknown Source)
at org.hsqldb.jdbcConnection.setAutoCommit(Unknown Source)
at
org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.begin(LocalManagedConnection.java:147)
... 93 more
How can I make the JCA PMF use the correct database? Am I doing the wrong
thing to set these properties?
Thanks,
Paul Jungwirth
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com -
Kodo JDO 2.3.4 now available
All,
Kodo JDO 2.3.4 is now available at http://www.solarmetric.com/. This release
contains a number of bugfixes and a couple enhancements to the reverse
schema tool.
New features
* The schema generator can now accept a list of tables to generate.
* The reverse mapping tool has additional options for using foreign
key names to generate relation names, generating primitive wrapper-type
fields if a column is nullable, and allowing primary keys on many-to-many
join tables.
Bugfixes
* Fixed problems with many-to-many relations between tables that use
vertical inheritance.
* Fixed bug in schematool that caused it to not generate primary key
columns in subclass tables when using datastore identity + custom
names + vertical inheritance.
* Fixed serp library conflict between reverse mapping tool and main Kodo
libraries.
* Fixed a reverse mapping tool bug in which column names that conflicted with
Java keywords would result in the generation of uncompilable Java classes.
* Fixed problem that caused read-only flag to be ignored in many-to-many
relations.
* Multi-table inheritance deletes are now performed from the leaf table
in the inheritance chain up to the base table. Inserts are performed
from the base table down to the leaf. This supports the common
referential integrity model of establishing a foreign key relation
from inherited tables to their parent tables.
Enjoy!
-Patrick
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.comAn email will be sent out to owners of the query extension or caching
plugins sometime today (Tuesday).
You'll all be thrilled to hear that our spiffy new licensing system in
2.4 will not require multiple jars, which will make life easier for people
with plugins when upgrades are released.
-Patrick
In article <[email protected]>, Alex Roytman wrote:
Could you please post query extensions for 2.3.4
"Patrick Linskey" <[email protected]> wrote in message
news:[email protected]...
All,
Kodo JDO 2.3.4 is now available at http://www.solarmetric.com/. This
release
contains a number of bugfixes and a couple enhancements to the reverse
schema tool.
New features
* The schema generator can now accept a list of tables to generate.
* The reverse mapping tool has additional options for using foreign
key names to generate relation names, generating primitive wrapper-type
fields if a column is nullable, and allowing primary keys onmany-to-many
join tables.
Bugfixes
* Fixed problems with many-to-many relations between tables that use
vertical inheritance.
* Fixed bug in schematool that caused it to not generate primary key
columns in subclass tables when using datastore identity + custom
names + vertical inheritance.
* Fixed serp library conflict between reverse mapping tool and main Kodo
libraries.
* Fixed a reverse mapping tool bug in which column names that conflictedwith
Java keywords would result in the generation of uncompilable Javaclasses.
* Fixed problem that caused read-only flag to be ignored in many-to-many
relations.
* Multi-table inheritance deletes are now performed from the leaf table
in the inheritance chain up to the base table. Inserts are performed
from the base table down to the leaf. This supports the common
referential integrity model of establishing a foreign key relation
from inherited tables to their parent tables.
Enjoy!
-Patrick
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com -
I have an iphone 5 on contract with 3 but the speaker isn't working , I've spoken with my provider and they said I need to take it back to an apple store .is this correct ? Many thanks
If you received you phone as part of the contract then surely from a legal pov your contract is with 3 not Apple unless you bought Applecare, if you bought your phone outright then put your 3 SIM into it then yes you'd have to visit an Apple store with your phone's purchase receipt.
-
Problem with JCA-DB in Business Service character
Hi,
I'm calling to database with JCA in Business Service, but when output contains the character "*&*" the business show "*&*";
Example
OUTPUT FROM BD:_
AMERICA NT & SAN FRANCISCO
OUTPUT FROM BS_
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<OutputParameters xmlns="http://xmlns.oracle.com/pcbpel/adapter/db/SGT/PKG_SGT_OPER/PRC_OPER_SRV_DAT_CON/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<OUT>AMERICA NT &amp; SAN FRANCISCO</OUT>
</OutputParameters>
</Body>
</Envelope>What should I do to show just only the character &?
PD: when I select and edit the html to get this output:
&amp;amp;
Maybe you are looking for
-
Restrict Vendor line items display by Vendor authorization group
Hi Gurus, I have a requirement to restrict Vendor line item diplay for Tcode FBL1N, I have updated the Authorization object F_LFA1_BEK, its work fine if all the vendors have authorization, However it also display vendors whose auth. group is "BLANK"
-
How can I remove the SSD from a broken iPhone 2G?
I have many years soldering experience and with small electronics. Is there any way to remove the solid state in the EP of an iPhone 2G and read the data off of it. My theory is that if a flash drive can do it so seamlessly in small space; MAYBE I ca
-
My IPhone 4 will not charge sine the update.
First it started to just die really quickly not it will not charge past 2%.
-
Scanning software for ScanJet G3110 not installing
I have downloaded the latest version of the recommended software directly from the HP support site. OS is Win7 64 bit. The setup ends in few instants with no error messages but I have not desktop shortcut icons. The setup creates folder: "C:\Program
-
MacBook Pro issues after updating to iOS8
After updating to iOS8 I ran into some strange issues (listed below) for the first time ever. Some of them I noticed the next day, others a couple of days later... - all my contacts disappeared in "contacts" - all my contacts disappeared in "Skype" -