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.
    Ben

    Marc,
    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.5

    Alex-
    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,
    Petr

    Hi 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.net

    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.net

  • Kudos to kodo JDO

    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!
    Michael

    Thanks 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

  • Java.lang.NoSuchMethodException: kodo.jdo.jdbc.JDOConnectionFactory. init

    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 Jungwirth

    Paul,
    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.com

    An 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

    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 "*&amp*";
    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;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;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" -