RE: OJB and the X-Files... :)
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
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
RE: OJB and the X-Files... :)
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:[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
Re: OJB and the X-Files... :)
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
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:[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
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
RE: OJB and the X-Files... :)
Hi Armin, I'm not using p6spy, but I removed all p6spy *.jars and *.properties files and still the same result. 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. 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
RE: OJB and the X-Files... :)
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. 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
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
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+primary+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=1 !-- Set fetchSize to 0 to use driver's
