You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Christopher Lowe <c_...@caribsurf.com> on 2006/03/02 21:55:02 UTC
RE: OJB and the X-Files... :)
Hi Armin,
I've been able to successfully recreate this error with the
InheritanceMultipleTableTest Test cases. Again I'm using the broker API and
the latest code from SVN OJB_1_0_RELEASE.
I added the code below to the test and like I described with my project when
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel is
set to WARN it does not return the right class and when I set
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel to
DEBUG it returns the right class.
Employee employee = new Employee();
employee.setId(newEx1.getId());
employee.setId_2(newEx1.getId_2());
Identity employee_oid = broker.serviceIdentity().buildIdentity(employee);
Employee employee1 = (Employee) broker.getObjectByIdentity(employee_oid);
log.debug("Employee: " + employee1);
assertEquals(Executive.class.getName(), employee1.getClass().getName());
Please note that when I test this with the latest release of OJB,
db-ojb-1.0.4.jar, this works fine. This indicates one of two things. Either
I'm downloading and building the code from OJB_1_0_RELEASE incorrectly or a
bug was introduced into the OJB_1_0_RELEASE code. Please look into this and
advise me further, thank you.
Regards,
Chris
-----Original Message-----
From: Armin Waibel [mailto:arminw@apache.org]
Sent: Tuesday, February 28, 2006 12:39 PM
To: OJB Users List
Subject: Re: OJB and the X-Files... :)
Hi Chris,
Christopher Lowe wrote:
> Hi Armin,
>
> I'm not using p6spy, but I removed all p6spy *.jars and *.properties
> files and still the same result.
Now I'm stumped. If it is reproducible in a separate test, please add a
issue in JIRA (with detailed pseudo code or a test case).
> I'm going to have to dissect this portion
> of my project and see if it can figure it out, this is really nagging me.
I
> will let you know.
>
It would be really helpful if you can reproduce this behavior with a
simple test case.
regards,
Armin
> Regards,
> Chris.
>
> -----Original Message-----
> From: Armin Waibel [mailto:arminw@apache.org]
> Sent: Monday, February 27, 2006 10:55 PM
> To: OJB Users List
> Subject: Re: OJB and the X-Files... :)
>
> Hi Christopher,
>
> Christopher Lowe wrote:
>> Hi Armin,
>>
>> Thanks for the tip about building the identity objects. I do agree that
my
>> problem sounds similar to OJB-63. I'm using code downloaded from the SVN
>> OJB_1_0_RELEASE branch as of 23rd of this month. Like what is described
in
>> OJB-63 when I have
>>
>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>> I can see the correct sql being generated with the "clazz_" column in the
>> ResultSet and hence the correct class is created. However when I turn
>> debugging off for this class, i.e I set it to
>>
>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN,
>> the super class is generated. I tried changing the loglevel for the other
>> jdbc access querying and object materialization class entries in the
>> OJB-logging.properties file and only setting the loglevel to DEBUG for
>> SqlGeneratorDefaultImpl works. This is rather strange to me.
>
> This is strange for me too. Did you enable p6spy while executing the
> Query? If yes, please run your test again without p6spy.
>
> regards,
> Armin
>
>> Please advice,
>> thank you.
>>
>> Regards,
>> Chris
>>
>> -----Original Message-----
>> From: Armin Waibel [mailto:arminw@apache.org]
>> Sent: Friday, February 24, 2006 10:20 PM
>> To: OJB Users List
>> Subject: Re: OJB and the X-Files... :)
>>
>> Hi Chris,
>>
>> Christopher Lowe wrote:
>>> Dear All,
>>>
>>> I have a simple inheritance relationship between a Special and
>>> ActivitySpecial. I'm using proxies throughout my project with the cglib
>>> proxy factory and indirection handler (I'm also using the broker API).
> I'm
>>> performing a simple query to find an activity special as follows:
>>>
>>> Special special = (Special) broker.getObjectByIdentity(new Identity(new
>>> Special(24), broker));
>>> log.debug("Special: " + special);
>>>
>> It's recommended to use the service class IdentityFactory to build the
>> Identity and lookup persistent objects.
>>
>
http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+prim
>> ary+key
>>
>>
>>> Now here is the catch. When I set
>>>
>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>> in the OJB-logging.properties file everything works fine. The correct
>> object
>>> is materialized and when the debug statement is printed out the correct
>>> class ActivitySpecial is present. However when I set
>>>
>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN
>>> the object that is materialized is Special. This is really weird
> behavior.
>>> Does anyone have an idea why this would occur?
>> this sounds like OJB-63
>> https://issues.apache.org/jira/browse/OJB-63
>>
>> and was fixed for OJB 1.0.4. Do you use the latest version of OJB?
>>
>> regards,
>> Armin
>>
>>
>>> I've included the mappings
>>> for the classes mentioned above as well as the entries I have for my
>>> database repository.
>>>
>>> Mappings:
>>>
>>> <class-descriptor class="com.dm.beans.Special" table="special">
>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>> primarykey="true" nullable="false" autoincrement="true"/>
>>> <field-descriptor name="supplierId" column="SUPPLIER_ID"
>>> jdbc-type="INTEGER" />
>>> <field-descriptor name="name" column="NAME" jdbc-type="VARCHAR" />
>>> <field-descriptor name="ackOptLock" column="ACK_OPT_LOCK"
>>> jdbc-type="BIGINT" locking="true"/>
>>> <reference-descriptor
>>> name="supplier"
>>> class-ref="com.dm.beans.suppliers.Supplier"
>>> proxy="true"
>>> auto-update="link"
>>> auto-delete="none"
>>> >
>>> <foreignkey field-ref="supplierId"/>
>>> </reference-descriptor>
>>> <collection-descriptor
>>> name="products"
>>>
>>>
> collection-class="org.apache.ojb.broker.util.collections.RemovalAwareList"
>>> element-class-ref="com.dm.beans.Product"
>>> auto-update="link"
>>> auto-delete="link"
>>> proxy="true"
>>> indirection-table="product_special"
>>> >
>>> <fk-pointing-to-this-class column="SPECIAL_ID"/>
>>> <fk-pointing-to-element-class column="PRODUCT_ID"/>
>>> </collection-descriptor>
>>> </class-descriptor>
>>>
>>> <class-descriptor class="com.dm.beans.activity.ActivitySpecial"
>>> table="activity_special">
>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>> primarykey="true" nullable="false"/>
>>> <field-descriptor name="minPersons" column="MIN_PERSONS"
>>> jdbc-type="INTEGER" />
>>> <field-descriptor name="maxPersons" column="MAX_PERSONS"
>>> jdbc-type="INTEGER" />
>>> <field-descriptor name="discount" column="DISCOUNT"
>> jdbc-type="VARCHAR"
>>> />
>>> <reference-descriptor
>>> name="super"
>>> class-ref="com.dm.beans.Special"
>>> >
>>> <foreignkey field-ref="id"/>
>>> </reference-descriptor>
>>> </class-descriptor>
>>>
>>> Database Repository Settings:
>>>
>>> <jdbc-connection-descriptor
>>> jcd-alias="dataSource"
>>> default-connection="true"
>>> platform="MySQL"
>>> jdbc-level="3.0"
>>> useAutoCommit="1"
>>> eager-release="false"
>>> batch-mode="false"
>>> jndi-datasource-name="java:comp/env/jdbc/DestinationDB"
>>> ignoreAutoCommitExceptions="false">
>>>
>>> <!-- alternative cache implementations, see docs section
> "Caching"
>>> -->
>>> <object-cache
>>> class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl">
>>> <!-- meaning of attributes, please see docs section
"Caching"
>>> -->
>>> <!-- common attributes -->
>>> <attribute attribute-name="cacheExcludes"
> attribute-value=""/>
>>>
>>> <!-- ObjectCacheTwoLevelImpl attributes -->
>>> <attribute attribute-name="applicationCache"
>>> attribute-value="org.apache.ojb.broker.cache.ObjectCacheOSCacheImpl"/>
>>> <attribute attribute-name="copyStrategy"
>>>
>
attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr
>>> ategyImpl"/>
>>> <attribute attribute-name="forceProxies"
>>> attribute-value="false"/>
>>>
>>> <!-- ObjectCacheDefaultImpl attributes -->
>>> <attribute attribute-name="timeout" attribute-value="900"/>
>>> <attribute attribute-name="autoSync"
attribute-value="true"/>
>>> <attribute attribute-name="cachingKeyType"
>> attribute-value="0"/>
>>> <attribute attribute-name="useSoftReferences"
>>> attribute-value="true"/>
>>> </object-cache>
>>>
>>> <!-- For more info, see section "Connection Handling" in docs
-->
>>> <connection-pool
>>> maxActive="30"
>>> validationQuery="select 1 from supplier_type;"
>>> testOnBorrow="true"
>>> testOnReturn="false"
>>> whenExhaustedAction="0"
>>> maxWait="10000">
>>>
>>> <!-- Set fetchSize to 0 to use driver's default. -->
>>> <attribute attribute-name="fetchSize" attribute-value="0"/>
>>>
>>> <!-- Attributes with name prefix "jdbc." are passed directly
>> to
>>> the JDBC driver. -->
>>> <!-- Example setting (used by Oracle driver when Statement
>>> batching is enabled) -->
>>> <attribute attribute-name="jdbc.defaultBatchValue"
>>> attribute-value="5"/>
>>>
>>> <!-- Attributes determining if ConnectionFactoryDBCPImpl
>>> should also pool PreparedStatement. This is
>>> programmatically disabled
>>> when using platform=Oracle9i since Oracle statement
>> caching
>>> will conflict
>>> with DBCP ObjectPool-based PreparepdStatement caching
> (ie
>>> setting true
>>> here has no effect for Oracle9i platform). -->
>>> <attribute attribute-name="dbcp.poolPreparedStatements"
>>> attribute-value="false"/>
>>> <attribute attribute-name="dbcp.maxOpenPreparedStatements"
>>> attribute-value="10"/>
>>> <!-- Attribute determining if the Commons DBCP connection
>>> wrapper will allow
>>> access to the underlying concrete Connection instance
>> from
>>> the JDBC-driver
>>> (normally this is not allowed, like in J2EE-containers
>>> using wrappers). -->
>>> <attribute
>>> attribute-name="dbcp.accessToUnderlyingConnectionAllowed"
>>> attribute-value="false"/>
>>> </connection-pool>
>>>
>>> <!-- alternative sequence manager implementations, see "Sequence
>>> Manager" guide -->
>>> <sequence-manager
>>>
>
className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
>>> <!-- attributes supported by SequenceManagerHighLowImpl,
>>> SequenceManagerInMemoryImpl, SequenceManagerNextValImpl
>>> please see "Sequence Manager" guide or/and javadoc of class
>> for
>>> more information -->
>>> <attribute attribute-name="seq.start" attribute-value="1"/>
>>> <attribute attribute-name="autoNaming"
>> attribute-value="true"/>
>>>
>>> <!-- attributes supported by SequenceManagerHighLowImpl
>>> please see "Sequence Manager" guide or/and javadoc of
classes
>>> for more information -->
>>> <attribute attribute-name="grabSize" attribute-value="1"/>
>>>
>>> <!-- optional attributes supported by
>> SequenceManagerNextValImpl
>>> (support depends
>>> on the used database), please see "Sequence Manager" guide
>>> or/and javadoc of
>>> classes for more information -->
>>> <!-- attribute attribute-name="seq.as"
>>> attribute-value="INTEGER"/ -->
>>> <!-- attribute attribute-name="seq.incrementBy"
>>> attribute-value="1"/ -->
>>> <!-- attribute attribute-name="seq.maxValue"
>>> attribute-value="999999999999999999999999999"/ -->
>>> <!-- attribute attribute-name="seq.minValue"
>>> attribute-value="1"/ -->
>>> <!-- attribute attribute-name="seq.cycle"
>>> attribute-value="false"/ -->
>>> <!-- attribute attribute-name="seq.cache"
>> attribute-value="20"/
>>> -->
>>> <!-- attribute attribute-name="seq.order"
>>> attribute-value="false"/ -->
>>>
>>> </sequence-manager>
>>>
>>> Regards,
>>> Chris
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RE: OJB and the X-Files... :)
Posted by Christopher Lowe <c_...@caribsurf.com>.
Great!
Thanks Armin and Jakob.
Happy user again,
Chris :)
-----Original Message-----
From: Armin Waibel [mailto:arminw@apache.org]
Sent: Sunday, March 05, 2006 6:08 AM
To: OJB Users List
Subject: Re: OJB and the X-Files... :)
Hi Chris,
it was fixed (by Jakob) in OJB_1_0_RELEASE branch and will be included
in OJB 1.0.5.
regards,
Armin
Armin Waibel wrote:
> Hi Chris,
>
> Christopher Lowe wrote:
>> Thanks Armin,
>>
>> Please let us know when it is fixed. When is OJB 1.0.5 scheduled to be
>> released?
>
> Hope we can fix it in a few days and start with the vote for 1.0.5 next
> week.
>
> regards,
> Armin
>
>
>>
>> Regards,
>> Chris
>>
>> -----Original Message-----
>> From: Armin Waibel [mailto:arminw@apache.org] Sent: Thursday, March
>> 02, 2006 9:48 PM
>> To: OJB Users List
>> Subject: Re: OJB and the X-Files... :)
>>
>> Hi Chris,
>>
>> thanks much for detailed description. Yes, I can reproduce this issue
>> with latest from OJB_1_0_RELEASE branch too (I checked in a test case:
>> InheritanceMultipleTableTest#testLookupByIdentity_2()).
>> You are right it's a bug. We will fix this ASAP.
>>
>> regards,
>> Armin
>>
>> Christopher Lowe wrote:
>>> Hi Armin,
>>>
>>> I've been able to successfully recreate this error with the
>>> InheritanceMultipleTableTest Test cases. Again I'm using the broker API
>> and
>>> the latest code from SVN OJB_1_0_RELEASE.
>>>
>>> I added the code below to the test and like I described with my project
>> when
>>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel
>>> is
>>> set to WARN it does not return the right class and when I set
>>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel
>>> to
>>> DEBUG it returns the right class.
>>>
>>> Employee employee = new Employee();
>>> employee.setId(newEx1.getId());
>>> employee.setId_2(newEx1.getId_2());
>>> Identity employee_oid =
>>> broker.serviceIdentity().buildIdentity(employee);
>>> Employee employee1 = (Employee)
>>> broker.getObjectByIdentity(employee_oid);
>>> log.debug("Employee: " + employee1);
>>> assertEquals(Executive.class.getName(),
>>> employee1.getClass().getName());
>>> Please note that when I test this with the latest release of OJB,
>>> db-ojb-1.0.4.jar, this works fine. This indicates one of two things.
>> Either
>>> I'm downloading and building the code from OJB_1_0_RELEASE
>>> incorrectly or
>> a
>>> bug was introduced into the OJB_1_0_RELEASE code. Please look into this
>> and
>>> advise me further, thank you.
>>>
>>> Regards,
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Armin Waibel [mailto:arminw@apache.org] Sent: Tuesday, February
>>> 28, 2006 12:39 PM
>>> To: OJB Users List
>>> Subject: Re: OJB and the X-Files... :)
>>>
>>> Hi Chris,
>>>
>>> Christopher Lowe wrote:
>>>> Hi Armin,
>>>>
>>>> I'm not using p6spy, but I removed all p6spy *.jars and
>>>> *.properties
>>>> files and still the same result.
>>> Now I'm stumped. If it is reproducible in a separate test, please add
>>> a issue in JIRA (with detailed pseudo code or a test case).
>>>
>>>
>>>> I'm going to have to dissect this portion
>>>> of my project and see if it can figure it out, this is really
>>>> nagging me.
>>> I
>>>> will let you know.
>>>>
>>> It would be really helpful if you can reproduce this behavior with a
>>> simple test case.
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> Regards,
>>>> Chris.
>>>>
>>>> -----Original Message-----
>>>> From: Armin Waibel [mailto:arminw@apache.org] Sent: Monday, February
>>>> 27, 2006 10:55 PM
>>>> To: OJB Users List
>>>> Subject: Re: OJB and the X-Files... :)
>>>>
>>>> Hi Christopher,
>>>>
>>>> Christopher Lowe wrote:
>>>>> Hi Armin,
>>>>>
>>>>> Thanks for the tip about building the identity objects. I do agree
>>>>> that
>>> my
>>>>> problem sounds similar to OJB-63. I'm using code downloaded from
>>>>> the SVN
>>>>> OJB_1_0_RELEASE branch as of 23rd of this month. Like what is
>>>>> described
>>> in
>>>>> OJB-63 when I have
>>>>>
>>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>
>>>>> I can see the correct sql being generated with the "clazz_" column in
>> the
>>>>> ResultSet and hence the correct class is created. However when I turn
>>>>> debugging off for this class, i.e I set it to
>>>>>
>>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN,
>>
>>>>> the super class is generated. I tried changing the loglevel for the
>> other
>>>>> jdbc access querying and object materialization class entries in the
>>>>> OJB-logging.properties file and only setting the loglevel to DEBUG for
>>>>> SqlGeneratorDefaultImpl works. This is rather strange to me.
>>>> This is strange for me too. Did you enable p6spy while executing the
>>>> Query? If yes, please run your test again without p6spy.
>>>>
>>>> regards,
>>>> Armin
>>>>
>>>>> Please advice,
>>>>> thank you.
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>>
>>>>> -----Original Message-----
>>>>> From: Armin Waibel [mailto:arminw@apache.org] Sent: Friday,
>>>>> February 24, 2006 10:20 PM
>>>>> To: OJB Users List
>>>>> Subject: Re: OJB and the X-Files... :)
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Christopher Lowe wrote:
>>>>>> Dear All,
>>>>>>
>>>>>> I have a simple inheritance relationship between a Special and
>>>>>> ActivitySpecial. I'm using proxies throughout my project with the
>>>>>> cglib
>>>>>> proxy factory and indirection handler (I'm also using the broker
>>>>>> API).
>>>> I'm
>>>>>> performing a simple query to find an activity special as follows:
>>>>>>
>>>>>> Special special = (Special) broker.getObjectByIdentity(new
>>>>>> Identity(new
>>>>>> Special(24), broker));
>>>>>> log.debug("Special: " + special);
>>>>>>
>>>>> It's recommended to use the service class IdentityFactory to build
>>>>> the Identity and lookup persistent objects.
>>>>>
>>
http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+prim
>>
>>>>> ary+key
>>>>>
>>>>>
>>>>>> Now here is the catch. When I set
>>>>>>
>>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>
>>>>>> in the OJB-logging.properties file everything works fine. The correct
>>>>> object
>>>>>> is materialized and when the debug statement is printed out the
>>>>>> correct
>>>>>> class ActivitySpecial is present. However when I set
>>>>>>
>>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN
>>
>>>>>> the object that is materialized is Special. This is really weird
>>>> behavior.
>>>>>> Does anyone have an idea why this would occur?
>>>>> this sounds like OJB-63
>>>>> https://issues.apache.org/jira/browse/OJB-63
>>>>>
>>>>> and was fixed for OJB 1.0.4. Do you use the latest version of OJB?
>>>>>
>>>>> regards,
>>>>> Armin
>>>>>
>>>>>
>>>>>> I've included the mappings
>>>>>> for the classes mentioned above as well as the entries I have for my
>>>>>> database repository.
>>>>>> Mappings:
>>>>>>
>>>>>> <class-descriptor class="com.dm.beans.Special" table="special">
>>>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>>>> primarykey="true" nullable="false" autoincrement="true"/>
>>>>>> <field-descriptor name="supplierId" column="SUPPLIER_ID"
>>>>>> jdbc-type="INTEGER" /> <field-descriptor name="name"
>>>>>> column="NAME" jdbc-type="VARCHAR" />
>>>>>> <field-descriptor name="ackOptLock" column="ACK_OPT_LOCK"
>>>>>> jdbc-type="BIGINT" locking="true"/>
>>>>>> <reference-descriptor name="supplier"
>>>>>> class-ref="com.dm.beans.suppliers.Supplier" proxy="true"
>>>>>> auto-update="link" auto-delete="none"
>>>>>> >
>>>>>> <foreignkey field-ref="supplierId"/>
>>>>>> </reference-descriptor> <collection-descriptor
>>>>>> name="products"
>>>>>>
>>>>>>
>>
collection-class="org.apache.ojb.broker.util.collections.RemovalAwareList"
>>
>>>>>> element-class-ref="com.dm.beans.Product"
>>>>>> auto-update="link"
>>>>>> auto-delete="link"
>>>>>> proxy="true"
>>>>>> indirection-table="product_special"
>>>>>> >
>>>>>> <fk-pointing-to-this-class column="SPECIAL_ID"/>
>>>>>> <fk-pointing-to-element-class column="PRODUCT_ID"/>
>>>>>> </collection-descriptor> </class-descriptor>
>>>>>>
>>>>>> <class-descriptor class="com.dm.beans.activity.ActivitySpecial"
>>>>>> table="activity_special">
>>>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>>>> primarykey="true" nullable="false"/>
>>>>>> <field-descriptor name="minPersons" column="MIN_PERSONS"
>>>>>> jdbc-type="INTEGER" />
>>>>>> <field-descriptor name="maxPersons" column="MAX_PERSONS"
>>>>>> jdbc-type="INTEGER" />
>>>>>> <field-descriptor name="discount" column="DISCOUNT"
>>>>> jdbc-type="VARCHAR"
>>>>>> />
>>>>>> <reference-descriptor name="super"
>>>>>> class-ref="com.dm.beans.Special"
>>>>>> >
>>>>>> <foreignkey field-ref="id"/>
>>>>>> </reference-descriptor>
>>>>>> </class-descriptor>
>>>>>>
>>>>>> Database Repository Settings:
>>>>>>
>>>>>> <jdbc-connection-descriptor
>>>>>> jcd-alias="dataSource" default-connection="true"
>>>>>> platform="MySQL" jdbc-level="3.0"
>>>>>> useAutoCommit="1"
>>>>>> eager-release="false"
>>>>>> batch-mode="false"
>>>>>> jndi-datasource-name="java:comp/env/jdbc/DestinationDB"
>>>>>> ignoreAutoCommitExceptions="false">
>>>>>> <!-- alternative cache implementations, see docs
>>>>>> section
>>>> "Caching"
>>>>>> -->
>>>>>> <object-cache
>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl">
>>>>>> <!-- meaning of attributes, please see docs section
>>> "Caching"
>>>>>> -->
>>>>>> <!-- common attributes -->
>>>>>> <attribute attribute-name="cacheExcludes"
>>>> attribute-value=""/>
>>>>>>
>>>>>> <!-- ObjectCacheTwoLevelImpl attributes -->
>>>>>> <attribute attribute-name="applicationCache"
>>>>>>
attribute-value="org.apache.ojb.broker.cache.ObjectCacheOSCacheImpl"/>
>>>>>>
>>>>>> <attribute attribute-name="copyStrategy"
>>>>>>
>>
attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr
>>
>>>>>> ategyImpl"/>
>>>>>> <attribute attribute-name="forceProxies"
>>>>>> attribute-value="false"/>
>>>>>> <!-- ObjectCacheDefaultImpl attributes -->
>>>>>> <attribute attribute-name="timeout"
>>>>>> attribute-value="900"/>
>>>>>> <attribute attribute-name="autoSync"
>>> attribute-value="true"/>
>>>>>> <attribute attribute-name="cachingKeyType"
>>>>> attribute-value="0"/>
>>>>>> <attribute attribute-name="useSoftReferences"
>>>>>> attribute-value="true"/>
>>>>>> </object-cache>
>>>>>>
>>>>>> <!-- For more info, see section "Connection Handling" in docs
>>> -->
>>>>>> <connection-pool
>>>>>> maxActive="30"
>>>>>> validationQuery="select 1 from supplier_type;"
>>>>>> testOnBorrow="true"
>>>>>> testOnReturn="false"
>>>>>> whenExhaustedAction="0"
>>>>>> maxWait="10000">
>>>>>>
>>>>>> <!-- Set fetchSize to 0 to use driver's default. -->
>>>>>> <attribute attribute-name="fetchSize"
>>>>>> attribute-value="0"/>
>>>>>>
>>>>>> <!-- Attributes with name prefix "jdbc." are passed
>> directly
>>>>> to
>>>>>> the JDBC driver. -->
>>>>>> <!-- Example setting (used by Oracle driver when
>>>>>> Statement
>>>>>> batching is enabled) -->
>>>>>> <attribute attribute-name="jdbc.defaultBatchValue"
>>>>>> attribute-value="5"/>
>>>>>>
>>>>>> <!-- Attributes determining if ConnectionFactoryDBCPImpl
>>>>>> should also pool PreparedStatement. This is
>>>>>> programmatically disabled
>>>>>> when using platform=Oracle9i since Oracle statement
>>>>> caching
>>>>>> will conflict
>>>>>> with DBCP ObjectPool-based PreparepdStatement
>>>>>> caching
>>>> (ie
>>>>>> setting true
>>>>>> here has no effect for Oracle9i platform). -->
>>>>>> <attribute attribute-name="dbcp.poolPreparedStatements"
>>>>>> attribute-value="false"/>
>>>>>> <attribute
>>>>>> attribute-name="dbcp.maxOpenPreparedStatements"
>>>>>> attribute-value="10"/>
>>>>>> <!-- Attribute determining if the Commons DBCP connection
>>>>>> wrapper will allow
>>>>>> access to the underlying concrete Connection
>>>>>> instance
>>>>> from
>>>>>> the JDBC-driver
>>>>>> (normally this is not allowed, like in
>>>>>> J2EE-containers
>>>>>> using wrappers). -->
>>>>>> <attribute
>>>>>> attribute-name="dbcp.accessToUnderlyingConnectionAllowed"
>>>>>> attribute-value="false"/>
>>>>>> </connection-pool>
>>>>>>
>>>>>> <!-- alternative sequence manager implementations, see
>> "Sequence
>>>>>> Manager" guide -->
>>>>>> <sequence-manager
>>>>>>
>>
className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
>>
>>>>>> <!-- attributes supported by SequenceManagerHighLowImpl,
>>>>>> SequenceManagerInMemoryImpl, SequenceManagerNextValImpl
>>>>>> please see "Sequence Manager" guide or/and javadoc of
>>>>>> class
>>>>> for
>>>>>> more information -->
>>>>>> <attribute attribute-name="seq.start"
>>>>>> attribute-value="1"/>
>>>>>> <attribute attribute-name="autoNaming"
>>>>> attribute-value="true"/>
>>>>>>
>>>>>> <!-- attributes supported by SequenceManagerHighLowImpl
>>>>>> please see "Sequence Manager" guide or/and javadoc of
>>> classes
>>>>>> for more information -->
>>>>>> <attribute attribute-name="grabSize"
>>>>>> attribute-value="1"/>
>>>>>>
>>>>>> <!-- optional attributes supported by
>>>>> SequenceManagerNextValImpl
>>>>>> (support depends
>>>>>> on the used database), please see "Sequence Manager"
>>>>>> guide
>>>>>> or/and javadoc of
>>>>>> classes for more information -->
>>>>>> <!-- attribute attribute-name="seq.as"
>>>>>> attribute-value="INTEGER"/ -->
>>>>>> <!-- attribute attribute-name="seq.incrementBy"
>>>>>> attribute-value="1"/ -->
>>>>>> <!-- attribute attribute-name="seq.maxValue"
>>>>>> attribute-value="999999999999999999999999999"/ -->
>>>>>> <!-- attribute attribute-name="seq.minValue"
>>>>>> attribute-value="1"/ -->
>>>>>> <!-- attribute attribute-name="seq.cycle"
>>>>>> attribute-value="false"/ -->
>>>>>> <!-- attribute attribute-name="seq.cache"
>>>>> attribute-value="20"/
>>>>>> -->
>>>>>> <!-- attribute attribute-name="seq.order"
>>>>>> attribute-value="false"/ -->
>>>>>>
>>>>>> </sequence-manager>
>>>>>>
>>>>>> Regards,
>>>>>> Chris
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: OJB and the X-Files... :)
Posted by Armin Waibel <ar...@apache.org>.
Hi Chris,
it was fixed (by Jakob) in OJB_1_0_RELEASE branch and will be included
in OJB 1.0.5.
regards,
Armin
Armin Waibel wrote:
> Hi Chris,
>
> Christopher Lowe wrote:
>> Thanks Armin,
>>
>> Please let us know when it is fixed. When is OJB 1.0.5 scheduled to be
>> released?
>
> Hope we can fix it in a few days and start with the vote for 1.0.5 next
> week.
>
> regards,
> Armin
>
>
>>
>> Regards,
>> Chris
>>
>> -----Original Message-----
>> From: Armin Waibel [mailto:arminw@apache.org] Sent: Thursday, March
>> 02, 2006 9:48 PM
>> To: OJB Users List
>> Subject: Re: OJB and the X-Files... :)
>>
>> Hi Chris,
>>
>> thanks much for detailed description. Yes, I can reproduce this issue
>> with latest from OJB_1_0_RELEASE branch too (I checked in a test case:
>> InheritanceMultipleTableTest#testLookupByIdentity_2()).
>> You are right it's a bug. We will fix this ASAP.
>>
>> regards,
>> Armin
>>
>> Christopher Lowe wrote:
>>> Hi Armin,
>>>
>>> I've been able to successfully recreate this error with the
>>> InheritanceMultipleTableTest Test cases. Again I'm using the broker API
>> and
>>> the latest code from SVN OJB_1_0_RELEASE.
>>>
>>> I added the code below to the test and like I described with my project
>> when
>>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel
>>> is
>>> set to WARN it does not return the right class and when I set
>>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel
>>> to
>>> DEBUG it returns the right class.
>>>
>>> Employee employee = new Employee();
>>> employee.setId(newEx1.getId());
>>> employee.setId_2(newEx1.getId_2());
>>> Identity employee_oid =
>>> broker.serviceIdentity().buildIdentity(employee);
>>> Employee employee1 = (Employee)
>>> broker.getObjectByIdentity(employee_oid);
>>> log.debug("Employee: " + employee1);
>>> assertEquals(Executive.class.getName(),
>>> employee1.getClass().getName());
>>> Please note that when I test this with the latest release of OJB,
>>> db-ojb-1.0.4.jar, this works fine. This indicates one of two things.
>> Either
>>> I'm downloading and building the code from OJB_1_0_RELEASE
>>> incorrectly or
>> a
>>> bug was introduced into the OJB_1_0_RELEASE code. Please look into this
>> and
>>> advise me further, thank you.
>>>
>>> Regards,
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Armin Waibel [mailto:arminw@apache.org] Sent: Tuesday, February
>>> 28, 2006 12:39 PM
>>> To: OJB Users List
>>> Subject: Re: OJB and the X-Files... :)
>>>
>>> Hi Chris,
>>>
>>> Christopher Lowe wrote:
>>>> Hi Armin,
>>>>
>>>> I'm not using p6spy, but I removed all p6spy *.jars and
>>>> *.properties
>>>> files and still the same result.
>>> Now I'm stumped. If it is reproducible in a separate test, please add
>>> a issue in JIRA (with detailed pseudo code or a test case).
>>>
>>>
>>>> I'm going to have to dissect this portion
>>>> of my project and see if it can figure it out, this is really
>>>> nagging me.
>>> I
>>>> will let you know.
>>>>
>>> It would be really helpful if you can reproduce this behavior with a
>>> simple test case.
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> Regards,
>>>> Chris.
>>>>
>>>> -----Original Message-----
>>>> From: Armin Waibel [mailto:arminw@apache.org] Sent: Monday, February
>>>> 27, 2006 10:55 PM
>>>> To: OJB Users List
>>>> Subject: Re: OJB and the X-Files... :)
>>>>
>>>> Hi Christopher,
>>>>
>>>> Christopher Lowe wrote:
>>>>> Hi Armin,
>>>>>
>>>>> Thanks for the tip about building the identity objects. I do agree
>>>>> that
>>> my
>>>>> problem sounds similar to OJB-63. I'm using code downloaded from
>>>>> the SVN
>>>>> OJB_1_0_RELEASE branch as of 23rd of this month. Like what is
>>>>> described
>>> in
>>>>> OJB-63 when I have
>>>>>
>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>
>>>>> I can see the correct sql being generated with the "clazz_" column in
>> the
>>>>> ResultSet and hence the correct class is created. However when I turn
>>>>> debugging off for this class, i.e I set it to
>>>>>
>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN,
>>
>>>>> the super class is generated. I tried changing the loglevel for the
>> other
>>>>> jdbc access querying and object materialization class entries in the
>>>>> OJB-logging.properties file and only setting the loglevel to DEBUG for
>>>>> SqlGeneratorDefaultImpl works. This is rather strange to me.
>>>> This is strange for me too. Did you enable p6spy while executing the
>>>> Query? If yes, please run your test again without p6spy.
>>>>
>>>> regards,
>>>> Armin
>>>>
>>>>> Please advice,
>>>>> thank you.
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>>
>>>>> -----Original Message-----
>>>>> From: Armin Waibel [mailto:arminw@apache.org] Sent: Friday,
>>>>> February 24, 2006 10:20 PM
>>>>> To: OJB Users List
>>>>> Subject: Re: OJB and the X-Files... :)
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Christopher Lowe wrote:
>>>>>> Dear All,
>>>>>>
>>>>>> I have a simple inheritance relationship between a Special and
>>>>>> ActivitySpecial. I'm using proxies throughout my project with the
>>>>>> cglib
>>>>>> proxy factory and indirection handler (I'm also using the broker
>>>>>> API).
>>>> I'm
>>>>>> performing a simple query to find an activity special as follows:
>>>>>>
>>>>>> Special special = (Special) broker.getObjectByIdentity(new
>>>>>> Identity(new
>>>>>> Special(24), broker));
>>>>>> log.debug("Special: " + special);
>>>>>>
>>>>> It's recommended to use the service class IdentityFactory to build
>>>>> the Identity and lookup persistent objects.
>>>>>
>> http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+prim
>>
>>>>> ary+key
>>>>>
>>>>>
>>>>>> Now here is the catch. When I set
>>>>>>
>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>
>>>>>> in the OJB-logging.properties file everything works fine. The correct
>>>>> object
>>>>>> is materialized and when the debug statement is printed out the
>>>>>> correct
>>>>>> class ActivitySpecial is present. However when I set
>>>>>>
>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN
>>
>>>>>> the object that is materialized is Special. This is really weird
>>>> behavior.
>>>>>> Does anyone have an idea why this would occur?
>>>>> this sounds like OJB-63
>>>>> https://issues.apache.org/jira/browse/OJB-63
>>>>>
>>>>> and was fixed for OJB 1.0.4. Do you use the latest version of OJB?
>>>>>
>>>>> regards,
>>>>> Armin
>>>>>
>>>>>
>>>>>> I've included the mappings
>>>>>> for the classes mentioned above as well as the entries I have for my
>>>>>> database repository.
>>>>>> Mappings:
>>>>>>
>>>>>> <class-descriptor class="com.dm.beans.Special" table="special">
>>>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>>>> primarykey="true" nullable="false" autoincrement="true"/>
>>>>>> <field-descriptor name="supplierId" column="SUPPLIER_ID"
>>>>>> jdbc-type="INTEGER" /> <field-descriptor name="name"
>>>>>> column="NAME" jdbc-type="VARCHAR" />
>>>>>> <field-descriptor name="ackOptLock" column="ACK_OPT_LOCK"
>>>>>> jdbc-type="BIGINT" locking="true"/>
>>>>>> <reference-descriptor name="supplier"
>>>>>> class-ref="com.dm.beans.suppliers.Supplier" proxy="true"
>>>>>> auto-update="link" auto-delete="none"
>>>>>> >
>>>>>> <foreignkey field-ref="supplierId"/>
>>>>>> </reference-descriptor> <collection-descriptor
>>>>>> name="products"
>>>>>>
>>>>>>
>> collection-class="org.apache.ojb.broker.util.collections.RemovalAwareList"
>>
>>>>>> element-class-ref="com.dm.beans.Product"
>>>>>> auto-update="link"
>>>>>> auto-delete="link"
>>>>>> proxy="true"
>>>>>> indirection-table="product_special"
>>>>>> >
>>>>>> <fk-pointing-to-this-class column="SPECIAL_ID"/>
>>>>>> <fk-pointing-to-element-class column="PRODUCT_ID"/>
>>>>>> </collection-descriptor> </class-descriptor>
>>>>>>
>>>>>> <class-descriptor class="com.dm.beans.activity.ActivitySpecial"
>>>>>> table="activity_special">
>>>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>>>> primarykey="true" nullable="false"/>
>>>>>> <field-descriptor name="minPersons" column="MIN_PERSONS"
>>>>>> jdbc-type="INTEGER" />
>>>>>> <field-descriptor name="maxPersons" column="MAX_PERSONS"
>>>>>> jdbc-type="INTEGER" />
>>>>>> <field-descriptor name="discount" column="DISCOUNT"
>>>>> jdbc-type="VARCHAR"
>>>>>> />
>>>>>> <reference-descriptor name="super"
>>>>>> class-ref="com.dm.beans.Special"
>>>>>> >
>>>>>> <foreignkey field-ref="id"/>
>>>>>> </reference-descriptor>
>>>>>> </class-descriptor>
>>>>>>
>>>>>> Database Repository Settings:
>>>>>>
>>>>>> <jdbc-connection-descriptor
>>>>>> jcd-alias="dataSource" default-connection="true"
>>>>>> platform="MySQL" jdbc-level="3.0"
>>>>>> useAutoCommit="1"
>>>>>> eager-release="false"
>>>>>> batch-mode="false"
>>>>>> jndi-datasource-name="java:comp/env/jdbc/DestinationDB"
>>>>>> ignoreAutoCommitExceptions="false">
>>>>>> <!-- alternative cache implementations, see docs
>>>>>> section
>>>> "Caching"
>>>>>> -->
>>>>>> <object-cache
>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl">
>>>>>> <!-- meaning of attributes, please see docs section
>>> "Caching"
>>>>>> -->
>>>>>> <!-- common attributes -->
>>>>>> <attribute attribute-name="cacheExcludes"
>>>> attribute-value=""/>
>>>>>>
>>>>>> <!-- ObjectCacheTwoLevelImpl attributes -->
>>>>>> <attribute attribute-name="applicationCache"
>>>>>> attribute-value="org.apache.ojb.broker.cache.ObjectCacheOSCacheImpl"/>
>>>>>>
>>>>>> <attribute attribute-name="copyStrategy"
>>>>>>
>> attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr
>>
>>>>>> ategyImpl"/>
>>>>>> <attribute attribute-name="forceProxies"
>>>>>> attribute-value="false"/>
>>>>>> <!-- ObjectCacheDefaultImpl attributes -->
>>>>>> <attribute attribute-name="timeout"
>>>>>> attribute-value="900"/>
>>>>>> <attribute attribute-name="autoSync"
>>> attribute-value="true"/>
>>>>>> <attribute attribute-name="cachingKeyType"
>>>>> attribute-value="0"/>
>>>>>> <attribute attribute-name="useSoftReferences"
>>>>>> attribute-value="true"/>
>>>>>> </object-cache>
>>>>>>
>>>>>> <!-- For more info, see section "Connection Handling" in docs
>>> -->
>>>>>> <connection-pool
>>>>>> maxActive="30"
>>>>>> validationQuery="select 1 from supplier_type;"
>>>>>> testOnBorrow="true"
>>>>>> testOnReturn="false"
>>>>>> whenExhaustedAction="0"
>>>>>> maxWait="10000">
>>>>>>
>>>>>> <!-- Set fetchSize to 0 to use driver's default. -->
>>>>>> <attribute attribute-name="fetchSize"
>>>>>> attribute-value="0"/>
>>>>>>
>>>>>> <!-- Attributes with name prefix "jdbc." are passed
>> directly
>>>>> to
>>>>>> the JDBC driver. -->
>>>>>> <!-- Example setting (used by Oracle driver when
>>>>>> Statement
>>>>>> batching is enabled) -->
>>>>>> <attribute attribute-name="jdbc.defaultBatchValue"
>>>>>> attribute-value="5"/>
>>>>>>
>>>>>> <!-- Attributes determining if ConnectionFactoryDBCPImpl
>>>>>> should also pool PreparedStatement. This is
>>>>>> programmatically disabled
>>>>>> when using platform=Oracle9i since Oracle statement
>>>>> caching
>>>>>> will conflict
>>>>>> with DBCP ObjectPool-based PreparepdStatement
>>>>>> caching
>>>> (ie
>>>>>> setting true
>>>>>> here has no effect for Oracle9i platform). -->
>>>>>> <attribute attribute-name="dbcp.poolPreparedStatements"
>>>>>> attribute-value="false"/>
>>>>>> <attribute
>>>>>> attribute-name="dbcp.maxOpenPreparedStatements"
>>>>>> attribute-value="10"/>
>>>>>> <!-- Attribute determining if the Commons DBCP connection
>>>>>> wrapper will allow
>>>>>> access to the underlying concrete Connection
>>>>>> instance
>>>>> from
>>>>>> the JDBC-driver
>>>>>> (normally this is not allowed, like in
>>>>>> J2EE-containers
>>>>>> using wrappers). -->
>>>>>> <attribute
>>>>>> attribute-name="dbcp.accessToUnderlyingConnectionAllowed"
>>>>>> attribute-value="false"/>
>>>>>> </connection-pool>
>>>>>>
>>>>>> <!-- alternative sequence manager implementations, see
>> "Sequence
>>>>>> Manager" guide -->
>>>>>> <sequence-manager
>>>>>>
>> className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
>>
>>>>>> <!-- attributes supported by SequenceManagerHighLowImpl,
>>>>>> SequenceManagerInMemoryImpl, SequenceManagerNextValImpl
>>>>>> please see "Sequence Manager" guide or/and javadoc of
>>>>>> class
>>>>> for
>>>>>> more information -->
>>>>>> <attribute attribute-name="seq.start"
>>>>>> attribute-value="1"/>
>>>>>> <attribute attribute-name="autoNaming"
>>>>> attribute-value="true"/>
>>>>>>
>>>>>> <!-- attributes supported by SequenceManagerHighLowImpl
>>>>>> please see "Sequence Manager" guide or/and javadoc of
>>> classes
>>>>>> for more information -->
>>>>>> <attribute attribute-name="grabSize"
>>>>>> attribute-value="1"/>
>>>>>>
>>>>>> <!-- optional attributes supported by
>>>>> SequenceManagerNextValImpl
>>>>>> (support depends
>>>>>> on the used database), please see "Sequence Manager"
>>>>>> guide
>>>>>> or/and javadoc of
>>>>>> classes for more information -->
>>>>>> <!-- attribute attribute-name="seq.as"
>>>>>> attribute-value="INTEGER"/ -->
>>>>>> <!-- attribute attribute-name="seq.incrementBy"
>>>>>> attribute-value="1"/ -->
>>>>>> <!-- attribute attribute-name="seq.maxValue"
>>>>>> attribute-value="999999999999999999999999999"/ -->
>>>>>> <!-- attribute attribute-name="seq.minValue"
>>>>>> attribute-value="1"/ -->
>>>>>> <!-- attribute attribute-name="seq.cycle"
>>>>>> attribute-value="false"/ -->
>>>>>> <!-- attribute attribute-name="seq.cache"
>>>>> attribute-value="20"/
>>>>>> -->
>>>>>> <!-- attribute attribute-name="seq.order"
>>>>>> attribute-value="false"/ -->
>>>>>>
>>>>>> </sequence-manager>
>>>>>>
>>>>>> Regards,
>>>>>> Chris
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: OJB and the X-Files... :)
Posted by Armin Waibel <ar...@apache.org>.
Hi Chris,
Christopher Lowe wrote:
> Thanks Armin,
>
> Please let us know when it is fixed. When is OJB 1.0.5 scheduled to be
> released?
Hope we can fix it in a few days and start with the vote for 1.0.5 next
week.
regards,
Armin
>
> Regards,
> Chris
>
> -----Original Message-----
> From: Armin Waibel [mailto:arminw@apache.org]
> Sent: Thursday, March 02, 2006 9:48 PM
> To: OJB Users List
> Subject: Re: OJB and the X-Files... :)
>
> Hi Chris,
>
> thanks much for detailed description. Yes, I can reproduce this issue
> with latest from OJB_1_0_RELEASE branch too (I checked in a test case:
> InheritanceMultipleTableTest#testLookupByIdentity_2()).
> You are right it's a bug. We will fix this ASAP.
>
> regards,
> Armin
>
> Christopher Lowe wrote:
>> Hi Armin,
>>
>> I've been able to successfully recreate this error with the
>> InheritanceMultipleTableTest Test cases. Again I'm using the broker API
> and
>> the latest code from SVN OJB_1_0_RELEASE.
>>
>> I added the code below to the test and like I described with my project
> when
>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel is
>> set to WARN it does not return the right class and when I set
>> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel to
>> DEBUG it returns the right class.
>>
>> Employee employee = new Employee();
>> employee.setId(newEx1.getId());
>> employee.setId_2(newEx1.getId_2());
>>
>> Identity employee_oid = broker.serviceIdentity().buildIdentity(employee);
>> Employee employee1 = (Employee) broker.getObjectByIdentity(employee_oid);
>>
>> log.debug("Employee: " + employee1);
>>
>> assertEquals(Executive.class.getName(), employee1.getClass().getName());
>>
>> Please note that when I test this with the latest release of OJB,
>> db-ojb-1.0.4.jar, this works fine. This indicates one of two things.
> Either
>> I'm downloading and building the code from OJB_1_0_RELEASE incorrectly or
> a
>> bug was introduced into the OJB_1_0_RELEASE code. Please look into this
> and
>> advise me further, thank you.
>>
>> Regards,
>> Chris
>>
>> -----Original Message-----
>> From: Armin Waibel [mailto:arminw@apache.org]
>> Sent: Tuesday, February 28, 2006 12:39 PM
>> To: OJB Users List
>> Subject: Re: OJB and the X-Files... :)
>>
>> Hi Chris,
>>
>> Christopher Lowe wrote:
>>> Hi Armin,
>>>
>>> I'm not using p6spy, but I removed all p6spy *.jars and *.properties
>>> files and still the same result.
>> Now I'm stumped. If it is reproducible in a separate test, please add a
>> issue in JIRA (with detailed pseudo code or a test case).
>>
>>
>>> I'm going to have to dissect this portion
>>> of my project and see if it can figure it out, this is really nagging me.
>> I
>>> will let you know.
>>>
>> It would be really helpful if you can reproduce this behavior with a
>> simple test case.
>>
>> regards,
>> Armin
>>
>>
>>> Regards,
>>> Chris.
>>>
>>> -----Original Message-----
>>> From: Armin Waibel [mailto:arminw@apache.org]
>>> Sent: Monday, February 27, 2006 10:55 PM
>>> To: OJB Users List
>>> Subject: Re: OJB and the X-Files... :)
>>>
>>> Hi Christopher,
>>>
>>> Christopher Lowe wrote:
>>>> Hi Armin,
>>>>
>>>> Thanks for the tip about building the identity objects. I do agree that
>> my
>>>> problem sounds similar to OJB-63. I'm using code downloaded from the SVN
>>>> OJB_1_0_RELEASE branch as of 23rd of this month. Like what is described
>> in
>>>> OJB-63 when I have
>>>>
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>>> I can see the correct sql being generated with the "clazz_" column in
> the
>>>> ResultSet and hence the correct class is created. However when I turn
>>>> debugging off for this class, i.e I set it to
>>>>
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN,
>>>> the super class is generated. I tried changing the loglevel for the
> other
>>>> jdbc access querying and object materialization class entries in the
>>>> OJB-logging.properties file and only setting the loglevel to DEBUG for
>>>> SqlGeneratorDefaultImpl works. This is rather strange to me.
>>> This is strange for me too. Did you enable p6spy while executing the
>>> Query? If yes, please run your test again without p6spy.
>>>
>>> regards,
>>> Armin
>>>
>>>> Please advice,
>>>> thank you.
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: Armin Waibel [mailto:arminw@apache.org]
>>>> Sent: Friday, February 24, 2006 10:20 PM
>>>> To: OJB Users List
>>>> Subject: Re: OJB and the X-Files... :)
>>>>
>>>> Hi Chris,
>>>>
>>>> Christopher Lowe wrote:
>>>>> Dear All,
>>>>>
>>>>> I have a simple inheritance relationship between a Special and
>>>>> ActivitySpecial. I'm using proxies throughout my project with the cglib
>>>>> proxy factory and indirection handler (I'm also using the broker API).
>>> I'm
>>>>> performing a simple query to find an activity special as follows:
>>>>>
>>>>> Special special = (Special) broker.getObjectByIdentity(new Identity(new
>>>>> Special(24), broker));
>>>>> log.debug("Special: " + special);
>>>>>
>>>> It's recommended to use the service class IdentityFactory to build the
>>>> Identity and lookup persistent objects.
>>>>
> http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+prim
>>>> ary+key
>>>>
>>>>
>>>>> Now here is the catch. When I set
>>>>>
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>>>> in the OJB-logging.properties file everything works fine. The correct
>>>> object
>>>>> is materialized and when the debug statement is printed out the correct
>>>>> class ActivitySpecial is present. However when I set
>>>>>
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN
>>>>> the object that is materialized is Special. This is really weird
>>> behavior.
>>>>> Does anyone have an idea why this would occur?
>>>> this sounds like OJB-63
>>>> https://issues.apache.org/jira/browse/OJB-63
>>>>
>>>> and was fixed for OJB 1.0.4. Do you use the latest version of OJB?
>>>>
>>>> regards,
>>>> Armin
>>>>
>>>>
>>>>> I've included the mappings
>>>>> for the classes mentioned above as well as the entries I have for my
>>>>> database repository.
>>>>>
>>>>> Mappings:
>>>>>
>>>>> <class-descriptor class="com.dm.beans.Special" table="special">
>>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>>> primarykey="true" nullable="false" autoincrement="true"/>
>>>>> <field-descriptor name="supplierId" column="SUPPLIER_ID"
>>>>> jdbc-type="INTEGER" />
>>>>> <field-descriptor name="name" column="NAME" jdbc-type="VARCHAR" />
>>>>> <field-descriptor name="ackOptLock" column="ACK_OPT_LOCK"
>>>>> jdbc-type="BIGINT" locking="true"/>
>>>>> <reference-descriptor
>>>>> name="supplier"
>>>>> class-ref="com.dm.beans.suppliers.Supplier"
>>>>> proxy="true"
>>>>> auto-update="link"
>>>>> auto-delete="none"
>>>>> >
>>>>> <foreignkey field-ref="supplierId"/>
>>>>> </reference-descriptor>
>>>>> <collection-descriptor
>>>>> name="products"
>>>>>
>>>>>
> collection-class="org.apache.ojb.broker.util.collections.RemovalAwareList"
>>>>> element-class-ref="com.dm.beans.Product"
>>>>> auto-update="link"
>>>>> auto-delete="link"
>>>>> proxy="true"
>>>>> indirection-table="product_special"
>>>>> >
>>>>> <fk-pointing-to-this-class column="SPECIAL_ID"/>
>>>>> <fk-pointing-to-element-class column="PRODUCT_ID"/>
>>>>> </collection-descriptor>
>>>>> </class-descriptor>
>>>>>
>>>>> <class-descriptor class="com.dm.beans.activity.ActivitySpecial"
>>>>> table="activity_special">
>>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>>> primarykey="true" nullable="false"/>
>>>>> <field-descriptor name="minPersons" column="MIN_PERSONS"
>>>>> jdbc-type="INTEGER" />
>>>>> <field-descriptor name="maxPersons" column="MAX_PERSONS"
>>>>> jdbc-type="INTEGER" />
>>>>> <field-descriptor name="discount" column="DISCOUNT"
>>>> jdbc-type="VARCHAR"
>>>>> />
>>>>> <reference-descriptor
>>>>> name="super"
>>>>> class-ref="com.dm.beans.Special"
>>>>> >
>>>>> <foreignkey field-ref="id"/>
>>>>> </reference-descriptor>
>>>>> </class-descriptor>
>>>>>
>>>>> Database Repository Settings:
>>>>>
>>>>> <jdbc-connection-descriptor
>>>>> jcd-alias="dataSource"
>>>>> default-connection="true"
>>>>> platform="MySQL"
>>>>> jdbc-level="3.0"
>>>>> useAutoCommit="1"
>>>>> eager-release="false"
>>>>> batch-mode="false"
>>>>> jndi-datasource-name="java:comp/env/jdbc/DestinationDB"
>>>>> ignoreAutoCommitExceptions="false">
>>>>>
>>>>> <!-- alternative cache implementations, see docs section
>>> "Caching"
>>>>> -->
>>>>> <object-cache
>>>>> class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl">
>>>>> <!-- meaning of attributes, please see docs section
>> "Caching"
>>>>> -->
>>>>> <!-- common attributes -->
>>>>> <attribute attribute-name="cacheExcludes"
>>> attribute-value=""/>
>>>>>
>>>>> <!-- ObjectCacheTwoLevelImpl attributes -->
>>>>> <attribute attribute-name="applicationCache"
>>>>> attribute-value="org.apache.ojb.broker.cache.ObjectCacheOSCacheImpl"/>
>>>>> <attribute attribute-name="copyStrategy"
>>>>>
> attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr
>>>>> ategyImpl"/>
>>>>> <attribute attribute-name="forceProxies"
>>>>> attribute-value="false"/>
>>>>>
>>>>> <!-- ObjectCacheDefaultImpl attributes -->
>>>>> <attribute attribute-name="timeout" attribute-value="900"/>
>>>>> <attribute attribute-name="autoSync"
>> attribute-value="true"/>
>>>>> <attribute attribute-name="cachingKeyType"
>>>> attribute-value="0"/>
>>>>> <attribute attribute-name="useSoftReferences"
>>>>> attribute-value="true"/>
>>>>> </object-cache>
>>>>>
>>>>> <!-- For more info, see section "Connection Handling" in docs
>> -->
>>>>> <connection-pool
>>>>> maxActive="30"
>>>>> validationQuery="select 1 from supplier_type;"
>>>>> testOnBorrow="true"
>>>>> testOnReturn="false"
>>>>> whenExhaustedAction="0"
>>>>> maxWait="10000">
>>>>>
>>>>> <!-- Set fetchSize to 0 to use driver's default. -->
>>>>> <attribute attribute-name="fetchSize" attribute-value="0"/>
>>>>>
>>>>> <!-- Attributes with name prefix "jdbc." are passed
> directly
>>>> to
>>>>> the JDBC driver. -->
>>>>> <!-- Example setting (used by Oracle driver when Statement
>>>>> batching is enabled) -->
>>>>> <attribute attribute-name="jdbc.defaultBatchValue"
>>>>> attribute-value="5"/>
>>>>>
>>>>> <!-- Attributes determining if ConnectionFactoryDBCPImpl
>>>>> should also pool PreparedStatement. This is
>>>>> programmatically disabled
>>>>> when using platform=Oracle9i since Oracle statement
>>>> caching
>>>>> will conflict
>>>>> with DBCP ObjectPool-based PreparepdStatement caching
>>> (ie
>>>>> setting true
>>>>> here has no effect for Oracle9i platform). -->
>>>>> <attribute attribute-name="dbcp.poolPreparedStatements"
>>>>> attribute-value="false"/>
>>>>> <attribute attribute-name="dbcp.maxOpenPreparedStatements"
>>>>> attribute-value="10"/>
>>>>> <!-- Attribute determining if the Commons DBCP connection
>>>>> wrapper will allow
>>>>> access to the underlying concrete Connection instance
>>>> from
>>>>> the JDBC-driver
>>>>> (normally this is not allowed, like in J2EE-containers
>>>>> using wrappers). -->
>>>>> <attribute
>>>>> attribute-name="dbcp.accessToUnderlyingConnectionAllowed"
>>>>> attribute-value="false"/>
>>>>> </connection-pool>
>>>>>
>>>>> <!-- alternative sequence manager implementations, see
> "Sequence
>>>>> Manager" guide -->
>>>>> <sequence-manager
>>>>>
> className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
>>>>> <!-- attributes supported by SequenceManagerHighLowImpl,
>>>>> SequenceManagerInMemoryImpl, SequenceManagerNextValImpl
>>>>> please see "Sequence Manager" guide or/and javadoc of class
>>>> for
>>>>> more information -->
>>>>> <attribute attribute-name="seq.start" attribute-value="1"/>
>>>>> <attribute attribute-name="autoNaming"
>>>> attribute-value="true"/>
>>>>>
>>>>> <!-- attributes supported by SequenceManagerHighLowImpl
>>>>> please see "Sequence Manager" guide or/and javadoc of
>> classes
>>>>> for more information -->
>>>>> <attribute attribute-name="grabSize" attribute-value="1"/>
>>>>>
>>>>> <!-- optional attributes supported by
>>>> SequenceManagerNextValImpl
>>>>> (support depends
>>>>> on the used database), please see "Sequence Manager" guide
>>>>> or/and javadoc of
>>>>> classes for more information -->
>>>>> <!-- attribute attribute-name="seq.as"
>>>>> attribute-value="INTEGER"/ -->
>>>>> <!-- attribute attribute-name="seq.incrementBy"
>>>>> attribute-value="1"/ -->
>>>>> <!-- attribute attribute-name="seq.maxValue"
>>>>> attribute-value="999999999999999999999999999"/ -->
>>>>> <!-- attribute attribute-name="seq.minValue"
>>>>> attribute-value="1"/ -->
>>>>> <!-- attribute attribute-name="seq.cycle"
>>>>> attribute-value="false"/ -->
>>>>> <!-- attribute attribute-name="seq.cache"
>>>> attribute-value="20"/
>>>>> -->
>>>>> <!-- attribute attribute-name="seq.order"
>>>>> attribute-value="false"/ -->
>>>>>
>>>>> </sequence-manager>
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RE: OJB and the X-Files... :)
Posted by Christopher Lowe <c_...@caribsurf.com>.
Thanks Armin,
Please let us know when it is fixed. When is OJB 1.0.5 scheduled to be
released?
Regards,
Chris
-----Original Message-----
From: Armin Waibel [mailto:arminw@apache.org]
Sent: Thursday, March 02, 2006 9:48 PM
To: OJB Users List
Subject: Re: OJB and the X-Files... :)
Hi Chris,
thanks much for detailed description. Yes, I can reproduce this issue
with latest from OJB_1_0_RELEASE branch too (I checked in a test case:
InheritanceMultipleTableTest#testLookupByIdentity_2()).
You are right it's a bug. We will fix this ASAP.
regards,
Armin
Christopher Lowe wrote:
> Hi Armin,
>
> I've been able to successfully recreate this error with the
> InheritanceMultipleTableTest Test cases. Again I'm using the broker API
and
> the latest code from SVN OJB_1_0_RELEASE.
>
> I added the code below to the test and like I described with my project
when
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel is
> set to WARN it does not return the right class and when I set
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel to
> DEBUG it returns the right class.
>
> Employee employee = new Employee();
> employee.setId(newEx1.getId());
> employee.setId_2(newEx1.getId_2());
>
> Identity employee_oid = broker.serviceIdentity().buildIdentity(employee);
> Employee employee1 = (Employee) broker.getObjectByIdentity(employee_oid);
>
> log.debug("Employee: " + employee1);
>
> assertEquals(Executive.class.getName(), employee1.getClass().getName());
>
> Please note that when I test this with the latest release of OJB,
> db-ojb-1.0.4.jar, this works fine. This indicates one of two things.
Either
> I'm downloading and building the code from OJB_1_0_RELEASE incorrectly or
a
> bug was introduced into the OJB_1_0_RELEASE code. Please look into this
and
> advise me further, thank you.
>
> Regards,
> Chris
>
> -----Original Message-----
> From: Armin Waibel [mailto:arminw@apache.org]
> Sent: Tuesday, February 28, 2006 12:39 PM
> To: OJB Users List
> Subject: Re: OJB and the X-Files... :)
>
> Hi Chris,
>
> Christopher Lowe wrote:
>> Hi Armin,
>>
>> I'm not using p6spy, but I removed all p6spy *.jars and *.properties
>> files and still the same result.
>
> Now I'm stumped. If it is reproducible in a separate test, please add a
> issue in JIRA (with detailed pseudo code or a test case).
>
>
>> I'm going to have to dissect this portion
>> of my project and see if it can figure it out, this is really nagging me.
> I
>> will let you know.
>>
>
> It would be really helpful if you can reproduce this behavior with a
> simple test case.
>
> regards,
> Armin
>
>
>> Regards,
>> Chris.
>>
>> -----Original Message-----
>> From: Armin Waibel [mailto:arminw@apache.org]
>> Sent: Monday, February 27, 2006 10:55 PM
>> To: OJB Users List
>> Subject: Re: OJB and the X-Files... :)
>>
>> Hi Christopher,
>>
>> Christopher Lowe wrote:
>>> Hi Armin,
>>>
>>> Thanks for the tip about building the identity objects. I do agree that
> my
>>> problem sounds similar to OJB-63. I'm using code downloaded from the SVN
>>> OJB_1_0_RELEASE branch as of 23rd of this month. Like what is described
> in
>>> OJB-63 when I have
>>>
>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>> I can see the correct sql being generated with the "clazz_" column in
the
>>> ResultSet and hence the correct class is created. However when I turn
>>> debugging off for this class, i.e I set it to
>>>
>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN,
>>> the super class is generated. I tried changing the loglevel for the
other
>>> jdbc access querying and object materialization class entries in the
>>> OJB-logging.properties file and only setting the loglevel to DEBUG for
>>> SqlGeneratorDefaultImpl works. This is rather strange to me.
>> This is strange for me too. Did you enable p6spy while executing the
>> Query? If yes, please run your test again without p6spy.
>>
>> regards,
>> Armin
>>
>>> Please advice,
>>> thank you.
>>>
>>> Regards,
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Armin Waibel [mailto:arminw@apache.org]
>>> Sent: Friday, February 24, 2006 10:20 PM
>>> To: OJB Users List
>>> Subject: Re: OJB and the X-Files... :)
>>>
>>> Hi Chris,
>>>
>>> Christopher Lowe wrote:
>>>> Dear All,
>>>>
>>>> I have a simple inheritance relationship between a Special and
>>>> ActivitySpecial. I'm using proxies throughout my project with the cglib
>>>> proxy factory and indirection handler (I'm also using the broker API).
>> I'm
>>>> performing a simple query to find an activity special as follows:
>>>>
>>>> Special special = (Special) broker.getObjectByIdentity(new Identity(new
>>>> Special(24), broker));
>>>> log.debug("Special: " + special);
>>>>
>>> It's recommended to use the service class IdentityFactory to build the
>>> Identity and lookup persistent objects.
>>>
>
http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+prim
>>> ary+key
>>>
>>>
>>>> Now here is the catch. When I set
>>>>
>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>>> in the OJB-logging.properties file everything works fine. The correct
>>> object
>>>> is materialized and when the debug statement is printed out the correct
>>>> class ActivitySpecial is present. However when I set
>>>>
>
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN
>>>> the object that is materialized is Special. This is really weird
>> behavior.
>>>> Does anyone have an idea why this would occur?
>>> this sounds like OJB-63
>>> https://issues.apache.org/jira/browse/OJB-63
>>>
>>> and was fixed for OJB 1.0.4. Do you use the latest version of OJB?
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> I've included the mappings
>>>> for the classes mentioned above as well as the entries I have for my
>>>> database repository.
>>>>
>>>> Mappings:
>>>>
>>>> <class-descriptor class="com.dm.beans.Special" table="special">
>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>> primarykey="true" nullable="false" autoincrement="true"/>
>>>> <field-descriptor name="supplierId" column="SUPPLIER_ID"
>>>> jdbc-type="INTEGER" />
>>>> <field-descriptor name="name" column="NAME" jdbc-type="VARCHAR" />
>>>> <field-descriptor name="ackOptLock" column="ACK_OPT_LOCK"
>>>> jdbc-type="BIGINT" locking="true"/>
>>>> <reference-descriptor
>>>> name="supplier"
>>>> class-ref="com.dm.beans.suppliers.Supplier"
>>>> proxy="true"
>>>> auto-update="link"
>>>> auto-delete="none"
>>>> >
>>>> <foreignkey field-ref="supplierId"/>
>>>> </reference-descriptor>
>>>> <collection-descriptor
>>>> name="products"
>>>>
>>>>
>>
collection-class="org.apache.ojb.broker.util.collections.RemovalAwareList"
>>>> element-class-ref="com.dm.beans.Product"
>>>> auto-update="link"
>>>> auto-delete="link"
>>>> proxy="true"
>>>> indirection-table="product_special"
>>>> >
>>>> <fk-pointing-to-this-class column="SPECIAL_ID"/>
>>>> <fk-pointing-to-element-class column="PRODUCT_ID"/>
>>>> </collection-descriptor>
>>>> </class-descriptor>
>>>>
>>>> <class-descriptor class="com.dm.beans.activity.ActivitySpecial"
>>>> table="activity_special">
>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>> primarykey="true" nullable="false"/>
>>>> <field-descriptor name="minPersons" column="MIN_PERSONS"
>>>> jdbc-type="INTEGER" />
>>>> <field-descriptor name="maxPersons" column="MAX_PERSONS"
>>>> jdbc-type="INTEGER" />
>>>> <field-descriptor name="discount" column="DISCOUNT"
>>> jdbc-type="VARCHAR"
>>>> />
>>>> <reference-descriptor
>>>> name="super"
>>>> class-ref="com.dm.beans.Special"
>>>> >
>>>> <foreignkey field-ref="id"/>
>>>> </reference-descriptor>
>>>> </class-descriptor>
>>>>
>>>> Database Repository Settings:
>>>>
>>>> <jdbc-connection-descriptor
>>>> jcd-alias="dataSource"
>>>> default-connection="true"
>>>> platform="MySQL"
>>>> jdbc-level="3.0"
>>>> useAutoCommit="1"
>>>> eager-release="false"
>>>> batch-mode="false"
>>>> jndi-datasource-name="java:comp/env/jdbc/DestinationDB"
>>>> ignoreAutoCommitExceptions="false">
>>>>
>>>> <!-- alternative cache implementations, see docs section
>> "Caching"
>>>> -->
>>>> <object-cache
>>>> class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl">
>>>> <!-- meaning of attributes, please see docs section
> "Caching"
>>>> -->
>>>> <!-- common attributes -->
>>>> <attribute attribute-name="cacheExcludes"
>> attribute-value=""/>
>>>>
>>>> <!-- ObjectCacheTwoLevelImpl attributes -->
>>>> <attribute attribute-name="applicationCache"
>>>> attribute-value="org.apache.ojb.broker.cache.ObjectCacheOSCacheImpl"/>
>>>> <attribute attribute-name="copyStrategy"
>>>>
>
attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr
>>>> ategyImpl"/>
>>>> <attribute attribute-name="forceProxies"
>>>> attribute-value="false"/>
>>>>
>>>> <!-- ObjectCacheDefaultImpl attributes -->
>>>> <attribute attribute-name="timeout" attribute-value="900"/>
>>>> <attribute attribute-name="autoSync"
> attribute-value="true"/>
>>>> <attribute attribute-name="cachingKeyType"
>>> attribute-value="0"/>
>>>> <attribute attribute-name="useSoftReferences"
>>>> attribute-value="true"/>
>>>> </object-cache>
>>>>
>>>> <!-- For more info, see section "Connection Handling" in docs
> -->
>>>> <connection-pool
>>>> maxActive="30"
>>>> validationQuery="select 1 from supplier_type;"
>>>> testOnBorrow="true"
>>>> testOnReturn="false"
>>>> whenExhaustedAction="0"
>>>> maxWait="10000">
>>>>
>>>> <!-- Set fetchSize to 0 to use driver's default. -->
>>>> <attribute attribute-name="fetchSize" attribute-value="0"/>
>>>>
>>>> <!-- Attributes with name prefix "jdbc." are passed
directly
>>> to
>>>> the JDBC driver. -->
>>>> <!-- Example setting (used by Oracle driver when Statement
>>>> batching is enabled) -->
>>>> <attribute attribute-name="jdbc.defaultBatchValue"
>>>> attribute-value="5"/>
>>>>
>>>> <!-- Attributes determining if ConnectionFactoryDBCPImpl
>>>> should also pool PreparedStatement. This is
>>>> programmatically disabled
>>>> when using platform=Oracle9i since Oracle statement
>>> caching
>>>> will conflict
>>>> with DBCP ObjectPool-based PreparepdStatement caching
>> (ie
>>>> setting true
>>>> here has no effect for Oracle9i platform). -->
>>>> <attribute attribute-name="dbcp.poolPreparedStatements"
>>>> attribute-value="false"/>
>>>> <attribute attribute-name="dbcp.maxOpenPreparedStatements"
>>>> attribute-value="10"/>
>>>> <!-- Attribute determining if the Commons DBCP connection
>>>> wrapper will allow
>>>> access to the underlying concrete Connection instance
>>> from
>>>> the JDBC-driver
>>>> (normally this is not allowed, like in J2EE-containers
>>>> using wrappers). -->
>>>> <attribute
>>>> attribute-name="dbcp.accessToUnderlyingConnectionAllowed"
>>>> attribute-value="false"/>
>>>> </connection-pool>
>>>>
>>>> <!-- alternative sequence manager implementations, see
"Sequence
>>>> Manager" guide -->
>>>> <sequence-manager
>>>>
>
className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
>>>> <!-- attributes supported by SequenceManagerHighLowImpl,
>>>> SequenceManagerInMemoryImpl, SequenceManagerNextValImpl
>>>> please see "Sequence Manager" guide or/and javadoc of class
>>> for
>>>> more information -->
>>>> <attribute attribute-name="seq.start" attribute-value="1"/>
>>>> <attribute attribute-name="autoNaming"
>>> attribute-value="true"/>
>>>>
>>>> <!-- attributes supported by SequenceManagerHighLowImpl
>>>> please see "Sequence Manager" guide or/and javadoc of
> classes
>>>> for more information -->
>>>> <attribute attribute-name="grabSize" attribute-value="1"/>
>>>>
>>>> <!-- optional attributes supported by
>>> SequenceManagerNextValImpl
>>>> (support depends
>>>> on the used database), please see "Sequence Manager" guide
>>>> or/and javadoc of
>>>> classes for more information -->
>>>> <!-- attribute attribute-name="seq.as"
>>>> attribute-value="INTEGER"/ -->
>>>> <!-- attribute attribute-name="seq.incrementBy"
>>>> attribute-value="1"/ -->
>>>> <!-- attribute attribute-name="seq.maxValue"
>>>> attribute-value="999999999999999999999999999"/ -->
>>>> <!-- attribute attribute-name="seq.minValue"
>>>> attribute-value="1"/ -->
>>>> <!-- attribute attribute-name="seq.cycle"
>>>> attribute-value="false"/ -->
>>>> <!-- attribute attribute-name="seq.cache"
>>> attribute-value="20"/
>>>> -->
>>>> <!-- attribute attribute-name="seq.order"
>>>> attribute-value="false"/ -->
>>>>
>>>> </sequence-manager>
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: OJB and the X-Files... :)
Posted by Armin Waibel <ar...@apache.org>.
Hi Chris,
thanks much for detailed description. Yes, I can reproduce this issue
with latest from OJB_1_0_RELEASE branch too (I checked in a test case:
InheritanceMultipleTableTest#testLookupByIdentity_2()).
You are right it's a bug. We will fix this ASAP.
regards,
Armin
Christopher Lowe wrote:
> Hi Armin,
>
> I've been able to successfully recreate this error with the
> InheritanceMultipleTableTest Test cases. Again I'm using the broker API and
> the latest code from SVN OJB_1_0_RELEASE.
>
> I added the code below to the test and like I described with my project when
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel is
> set to WARN it does not return the right class and when I set
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel to
> DEBUG it returns the right class.
>
> Employee employee = new Employee();
> employee.setId(newEx1.getId());
> employee.setId_2(newEx1.getId_2());
>
> Identity employee_oid = broker.serviceIdentity().buildIdentity(employee);
> Employee employee1 = (Employee) broker.getObjectByIdentity(employee_oid);
>
> log.debug("Employee: " + employee1);
>
> assertEquals(Executive.class.getName(), employee1.getClass().getName());
>
> Please note that when I test this with the latest release of OJB,
> db-ojb-1.0.4.jar, this works fine. This indicates one of two things. Either
> I'm downloading and building the code from OJB_1_0_RELEASE incorrectly or a
> bug was introduced into the OJB_1_0_RELEASE code. Please look into this and
> advise me further, thank you.
>
> Regards,
> Chris
>
> -----Original Message-----
> From: Armin Waibel [mailto:arminw@apache.org]
> Sent: Tuesday, February 28, 2006 12:39 PM
> To: OJB Users List
> Subject: Re: OJB and the X-Files... :)
>
> Hi Chris,
>
> Christopher Lowe wrote:
>> Hi Armin,
>>
>> I'm not using p6spy, but I removed all p6spy *.jars and *.properties
>> files and still the same result.
>
> Now I'm stumped. If it is reproducible in a separate test, please add a
> issue in JIRA (with detailed pseudo code or a test case).
>
>
>> I'm going to have to dissect this portion
>> of my project and see if it can figure it out, this is really nagging me.
> I
>> will let you know.
>>
>
> It would be really helpful if you can reproduce this behavior with a
> simple test case.
>
> regards,
> Armin
>
>
>> Regards,
>> Chris.
>>
>> -----Original Message-----
>> From: Armin Waibel [mailto:arminw@apache.org]
>> Sent: Monday, February 27, 2006 10:55 PM
>> To: OJB Users List
>> Subject: Re: OJB and the X-Files... :)
>>
>> Hi Christopher,
>>
>> Christopher Lowe wrote:
>>> Hi Armin,
>>>
>>> Thanks for the tip about building the identity objects. I do agree that
> my
>>> problem sounds similar to OJB-63. I'm using code downloaded from the SVN
>>> OJB_1_0_RELEASE branch as of 23rd of this month. Like what is described
> in
>>> OJB-63 when I have
>>>
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>> I can see the correct sql being generated with the "clazz_" column in the
>>> ResultSet and hence the correct class is created. However when I turn
>>> debugging off for this class, i.e I set it to
>>>
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN,
>>> the super class is generated. I tried changing the loglevel for the other
>>> jdbc access querying and object materialization class entries in the
>>> OJB-logging.properties file and only setting the loglevel to DEBUG for
>>> SqlGeneratorDefaultImpl works. This is rather strange to me.
>> This is strange for me too. Did you enable p6spy while executing the
>> Query? If yes, please run your test again without p6spy.
>>
>> regards,
>> Armin
>>
>>> Please advice,
>>> thank you.
>>>
>>> Regards,
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Armin Waibel [mailto:arminw@apache.org]
>>> Sent: Friday, February 24, 2006 10:20 PM
>>> To: OJB Users List
>>> Subject: Re: OJB and the X-Files... :)
>>>
>>> Hi Chris,
>>>
>>> Christopher Lowe wrote:
>>>> Dear All,
>>>>
>>>> I have a simple inheritance relationship between a Special and
>>>> ActivitySpecial. I'm using proxies throughout my project with the cglib
>>>> proxy factory and indirection handler (I'm also using the broker API).
>> I'm
>>>> performing a simple query to find an activity special as follows:
>>>>
>>>> Special special = (Special) broker.getObjectByIdentity(new Identity(new
>>>> Special(24), broker));
>>>> log.debug("Special: " + special);
>>>>
>>> It's recommended to use the service class IdentityFactory to build the
>>> Identity and lookup persistent objects.
>>>
> http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+prim
>>> ary+key
>>>
>>>
>>>> Now here is the catch. When I set
>>>>
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
>>>> in the OJB-logging.properties file everything works fine. The correct
>>> object
>>>> is materialized and when the debug statement is printed out the correct
>>>> class ActivitySpecial is present. However when I set
>>>>
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN
>>>> the object that is materialized is Special. This is really weird
>> behavior.
>>>> Does anyone have an idea why this would occur?
>>> this sounds like OJB-63
>>> https://issues.apache.org/jira/browse/OJB-63
>>>
>>> and was fixed for OJB 1.0.4. Do you use the latest version of OJB?
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> I've included the mappings
>>>> for the classes mentioned above as well as the entries I have for my
>>>> database repository.
>>>>
>>>> Mappings:
>>>>
>>>> <class-descriptor class="com.dm.beans.Special" table="special">
>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>> primarykey="true" nullable="false" autoincrement="true"/>
>>>> <field-descriptor name="supplierId" column="SUPPLIER_ID"
>>>> jdbc-type="INTEGER" />
>>>> <field-descriptor name="name" column="NAME" jdbc-type="VARCHAR" />
>>>> <field-descriptor name="ackOptLock" column="ACK_OPT_LOCK"
>>>> jdbc-type="BIGINT" locking="true"/>
>>>> <reference-descriptor
>>>> name="supplier"
>>>> class-ref="com.dm.beans.suppliers.Supplier"
>>>> proxy="true"
>>>> auto-update="link"
>>>> auto-delete="none"
>>>> >
>>>> <foreignkey field-ref="supplierId"/>
>>>> </reference-descriptor>
>>>> <collection-descriptor
>>>> name="products"
>>>>
>>>>
>> collection-class="org.apache.ojb.broker.util.collections.RemovalAwareList"
>>>> element-class-ref="com.dm.beans.Product"
>>>> auto-update="link"
>>>> auto-delete="link"
>>>> proxy="true"
>>>> indirection-table="product_special"
>>>> >
>>>> <fk-pointing-to-this-class column="SPECIAL_ID"/>
>>>> <fk-pointing-to-element-class column="PRODUCT_ID"/>
>>>> </collection-descriptor>
>>>> </class-descriptor>
>>>>
>>>> <class-descriptor class="com.dm.beans.activity.ActivitySpecial"
>>>> table="activity_special">
>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>> primarykey="true" nullable="false"/>
>>>> <field-descriptor name="minPersons" column="MIN_PERSONS"
>>>> jdbc-type="INTEGER" />
>>>> <field-descriptor name="maxPersons" column="MAX_PERSONS"
>>>> jdbc-type="INTEGER" />
>>>> <field-descriptor name="discount" column="DISCOUNT"
>>> jdbc-type="VARCHAR"
>>>> />
>>>> <reference-descriptor
>>>> name="super"
>>>> class-ref="com.dm.beans.Special"
>>>> >
>>>> <foreignkey field-ref="id"/>
>>>> </reference-descriptor>
>>>> </class-descriptor>
>>>>
>>>> Database Repository Settings:
>>>>
>>>> <jdbc-connection-descriptor
>>>> jcd-alias="dataSource"
>>>> default-connection="true"
>>>> platform="MySQL"
>>>> jdbc-level="3.0"
>>>> useAutoCommit="1"
>>>> eager-release="false"
>>>> batch-mode="false"
>>>> jndi-datasource-name="java:comp/env/jdbc/DestinationDB"
>>>> ignoreAutoCommitExceptions="false">
>>>>
>>>> <!-- alternative cache implementations, see docs section
>> "Caching"
>>>> -->
>>>> <object-cache
>>>> class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl">
>>>> <!-- meaning of attributes, please see docs section
> "Caching"
>>>> -->
>>>> <!-- common attributes -->
>>>> <attribute attribute-name="cacheExcludes"
>> attribute-value=""/>
>>>>
>>>> <!-- ObjectCacheTwoLevelImpl attributes -->
>>>> <attribute attribute-name="applicationCache"
>>>> attribute-value="org.apache.ojb.broker.cache.ObjectCacheOSCacheImpl"/>
>>>> <attribute attribute-name="copyStrategy"
>>>>
> attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr
>>>> ategyImpl"/>
>>>> <attribute attribute-name="forceProxies"
>>>> attribute-value="false"/>
>>>>
>>>> <!-- ObjectCacheDefaultImpl attributes -->
>>>> <attribute attribute-name="timeout" attribute-value="900"/>
>>>> <attribute attribute-name="autoSync"
> attribute-value="true"/>
>>>> <attribute attribute-name="cachingKeyType"
>>> attribute-value="0"/>
>>>> <attribute attribute-name="useSoftReferences"
>>>> attribute-value="true"/>
>>>> </object-cache>
>>>>
>>>> <!-- For more info, see section "Connection Handling" in docs
> -->
>>>> <connection-pool
>>>> maxActive="30"
>>>> validationQuery="select 1 from supplier_type;"
>>>> testOnBorrow="true"
>>>> testOnReturn="false"
>>>> whenExhaustedAction="0"
>>>> maxWait="10000">
>>>>
>>>> <!-- Set fetchSize to 0 to use driver's default. -->
>>>> <attribute attribute-name="fetchSize" attribute-value="0"/>
>>>>
>>>> <!-- Attributes with name prefix "jdbc." are passed directly
>>> to
>>>> the JDBC driver. -->
>>>> <!-- Example setting (used by Oracle driver when Statement
>>>> batching is enabled) -->
>>>> <attribute attribute-name="jdbc.defaultBatchValue"
>>>> attribute-value="5"/>
>>>>
>>>> <!-- Attributes determining if ConnectionFactoryDBCPImpl
>>>> should also pool PreparedStatement. This is
>>>> programmatically disabled
>>>> when using platform=Oracle9i since Oracle statement
>>> caching
>>>> will conflict
>>>> with DBCP ObjectPool-based PreparepdStatement caching
>> (ie
>>>> setting true
>>>> here has no effect for Oracle9i platform). -->
>>>> <attribute attribute-name="dbcp.poolPreparedStatements"
>>>> attribute-value="false"/>
>>>> <attribute attribute-name="dbcp.maxOpenPreparedStatements"
>>>> attribute-value="10"/>
>>>> <!-- Attribute determining if the Commons DBCP connection
>>>> wrapper will allow
>>>> access to the underlying concrete Connection instance
>>> from
>>>> the JDBC-driver
>>>> (normally this is not allowed, like in J2EE-containers
>>>> using wrappers). -->
>>>> <attribute
>>>> attribute-name="dbcp.accessToUnderlyingConnectionAllowed"
>>>> attribute-value="false"/>
>>>> </connection-pool>
>>>>
>>>> <!-- alternative sequence manager implementations, see "Sequence
>>>> Manager" guide -->
>>>> <sequence-manager
>>>>
> className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
>>>> <!-- attributes supported by SequenceManagerHighLowImpl,
>>>> SequenceManagerInMemoryImpl, SequenceManagerNextValImpl
>>>> please see "Sequence Manager" guide or/and javadoc of class
>>> for
>>>> more information -->
>>>> <attribute attribute-name="seq.start" attribute-value="1"/>
>>>> <attribute attribute-name="autoNaming"
>>> attribute-value="true"/>
>>>>
>>>> <!-- attributes supported by SequenceManagerHighLowImpl
>>>> please see "Sequence Manager" guide or/and javadoc of
> classes
>>>> for more information -->
>>>> <attribute attribute-name="grabSize" attribute-value="1"/>
>>>>
>>>> <!-- optional attributes supported by
>>> SequenceManagerNextValImpl
>>>> (support depends
>>>> on the used database), please see "Sequence Manager" guide
>>>> or/and javadoc of
>>>> classes for more information -->
>>>> <!-- attribute attribute-name="seq.as"
>>>> attribute-value="INTEGER"/ -->
>>>> <!-- attribute attribute-name="seq.incrementBy"
>>>> attribute-value="1"/ -->
>>>> <!-- attribute attribute-name="seq.maxValue"
>>>> attribute-value="999999999999999999999999999"/ -->
>>>> <!-- attribute attribute-name="seq.minValue"
>>>> attribute-value="1"/ -->
>>>> <!-- attribute attribute-name="seq.cycle"
>>>> attribute-value="false"/ -->
>>>> <!-- attribute attribute-name="seq.cache"
>>> attribute-value="20"/
>>>> -->
>>>> <!-- attribute attribute-name="seq.order"
>>>> attribute-value="false"/ -->
>>>>
>>>> </sequence-manager>
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org