Great! Thanks Armin and Jakob.
Happy user again, Chris :) -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
