Re: Repository Version Match Error
Have a look at your repository.dtd and repository.xml file.
They both contain an entry version="0.9.6"
OJB will check these version numbers to see if your configuration files
are up to date to avoid weird configuration problems.
solution:
use the files as shipped with the official distribution and add the
mapping information for your classes. the best thing to to is is to
check the repository.xml against.dtd with a validating editor like
xmlspy to detect problems in advance.
cheers,
Thomas
Met @ Uber wrote:
I've got a relatively simple OJB implementation that I'm trying to run.
I build some junit tests to check out if everything was working OK, but
apparently it isn't. The following is a the summarized error (the rest
is attached).
[junit] Caused by: org.apache.ojb.broker.metadata.MetadataException:
Could not read repository class descriptor data, using repository:
repository.xml: Repository version does not match. expected 1.0 but
found: 0.9.6. Please update your repository.dtd and your repository.xml
version attribute entry
As I am _extremely_ new to OJB I have no idea exactly what they mean. I
did some searching for those numbers and I'm still not sure. Any help
would be greatly appreciated. My repository.xml/dtd are also attached.
~ Matthew
P.S. I'm modifying some examples from a WROX book.
Buildfile: build.xml
prepare:
compile:
run-tests:
[junit] Running com.ccw_java.service.core.tests.TestOrganizationCRUD
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.807 sec
[junit] Testsuite: com.ccw_java.service.core.tests.TestOrganizationCRUD
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.807 sec
[junit] - Standard Output ---
[junit] [BOOT] WARN: Value
"org.apache.ojb.broker.accesslayer.ConnectionFactoryConPooledImpl" is illegal for key
"ConnectionFactoryClass" (should be a class, using default value
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl)
[junit] [BOOT] WARN: Value "org.apache.ojb.broker.metadata.PersistentFieldDefaultImpl" is
illegal for key "PersistentFieldClass" (should be a class, using default value
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl)
[junit] [BOOT] WARN: Value "org.apache.ojb.broker.singlevm.PersistenceBrokerImpl" is illegal
for key "PersistenceBrokerClass" (should be a class, using default value
org.apache.ojb.broker.core.PersistenceBrokerImpl)
[junit] [BOOT] WARN: Value "org.apache.ojb.broker.ta.PersistenceBrokerFactoryDefaultImpl" is
illegal for key "PersistenceBrokerFactoryClass" (should be a class, using default value
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl)
[junit] [org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] INFO:
Create PersistenceBroker instance pool, pool configuration was {whenExhaustedAction=0,
maxIdle=-1, maxActive=100, maxWait=2000, removeAbandoned=false,
numTestsPerEvictionRun=10, testWhileIdle=false, minEvictableIdleTimeMillis=100,
testOnReturn=false, logAbandoned=false, removeAbandonedTimeout=300,
timeBetweenEvictionRunsMillis=-1, testOnBorrow=false}
[junit] [org.apache.ojb.broker.metadata.RepositoryPersistor] INFO: OJB Descriptor
Repository: file:/home/mimetnet/Projects/Java/ccw-java/object/repository.xml
[junit] - ---
[junit] Testcase: testCRUD(com.ccw_java.service.core.tests.TestOrganizationCRUD):
Caused an ERROR
[junit] null
[junit] java.lang.ExceptionInInitializerError
[junit] at
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.buildDefaultKey(Unknown
Source)
[junit] at
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.(Unknown Source)
[junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
[junit] at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[junit] at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
[junit] at java.lang.Class.newInstance0(Class.java:308)
[junit] at java.lang.Class.newInstance(Class.java:261)
[junit] at
org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.init(Unknown Source)
[junit] at
org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.(Unknown Source)
[junit] at
org.apache.ojb.broker.PersistenceBrokerFactory.createPersistenceBroker(Unknown Source)
[junit] at
com.ccw_java.common.ServiceLocator.findBroker(ServiceLocator.java:61)
[junit] at
com.ccw_java.service.core.DAO.OrganizationDAO.insert(OrganizationDAO.java:65)
[junit] at
com.ccw_java.service.core.tests.TestOrganizationCRUD.testCRUD(TestOrganizationCRUD.java:59)
[junit] at sun.re
Repository Version Match Error
I've got a relatively simple OJB implementation that I'm trying to run.
I build some junit tests to check out if everything was working OK, but
apparently it isn't. The following is a the summarized error (the rest
is attached).
[junit] Caused by: org.apache.ojb.broker.metadata.MetadataException:
Could not read repository class descriptor data, using repository:
repository.xml: Repository version does not match. expected 1.0 but
found: 0.9.6. Please update your repository.dtd and your repository.xml
version attribute entry
As I am _extremely_ new to OJB I have no idea exactly what they mean. I
did some searching for those numbers and I'm still not sure. Any help
would be greatly appreciated. My repository.xml/dtd are also attached.
~ Matthew
P.S. I'm modifying some examples from a WROX book.
Buildfile: build.xml
prepare:
compile:
run-tests:
[junit] Running com.ccw_java.service.core.tests.TestOrganizationCRUD
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.807 sec
[junit] Testsuite: com.ccw_java.service.core.tests.TestOrganizationCRUD
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.807 sec
[junit] - Standard Output ---
[junit] [BOOT] WARN: Value
"org.apache.ojb.broker.accesslayer.ConnectionFactoryConPooledImpl" is illegal for key
"ConnectionFactoryClass" (should be a class, using default value
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl)
[junit] [BOOT] WARN: Value
"org.apache.ojb.broker.metadata.PersistentFieldDefaultImpl" is illegal for key
"PersistentFieldClass" (should be a class, using default value
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl)
[junit] [BOOT] WARN: Value "org.apache.ojb.broker.singlevm.PersistenceBrokerImpl"
is illegal for key "PersistenceBrokerClass" (should be a class, using default value
org.apache.ojb.broker.core.PersistenceBrokerImpl)
[junit] [BOOT] WARN: Value
"org.apache.ojb.broker.ta.PersistenceBrokerFactoryDefaultImpl" is illegal for key
"PersistenceBrokerFactoryClass" (should be a class, using default value
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl)
[junit] [org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] INFO:
Create PersistenceBroker instance pool, pool configuration was {whenExhaustedAction=0,
maxIdle=-1, maxActive=100, maxWait=2000, removeAbandoned=false,
numTestsPerEvictionRun=10, testWhileIdle=false, minEvictableIdleTimeMillis=100,
testOnReturn=false, logAbandoned=false, removeAbandonedTimeout=300,
timeBetweenEvictionRunsMillis=-1, testOnBorrow=false}
[junit] [org.apache.ojb.broker.metadata.RepositoryPersistor] INFO: OJB Descriptor
Repository: file:/home/mimetnet/Projects/Java/ccw-java/object/repository.xml
[junit] - ---
[junit] Testcase: testCRUD(com.ccw_java.service.core.tests.TestOrganizationCRUD):
Caused an ERROR
[junit] null
[junit] java.lang.ExceptionInInitializerError
[junit] at
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.buildDefaultKey(Unknown
Source)
[junit] at
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.(Unknown Source)
[junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
[junit] at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[junit] at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
[junit] at java.lang.Class.newInstance0(Class.java:308)
[junit] at java.lang.Class.newInstance(Class.java:261)
[junit] at
org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.init(Unknown Source)
[junit] at
org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.(Unknown Source)
[junit] at
org.apache.ojb.broker.PersistenceBrokerFactory.createPersistenceBroker(Unknown Source)
[junit] at
com.ccw_java.common.ServiceLocator.findBroker(ServiceLocator.java:61)
[junit] at
com.ccw_java.service.core.DAO.OrganizationDAO.insert(OrganizationDAO.java:65)
[junit] at
com.ccw_java.service.core.tests.TestOrganizationCRUD.testCRUD(TestOrganizationCRUD.java:59)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] Caused by: org.apache.ojb.broker.metadata.MetadataException: Could not
read repository class descriptor data, using repository: repository.xml: Repository
version does not match. expected 1.0 but found: 0.9.6. Please update your
repository.dtd and your repository.xml version attribute entry
[junit] at org.ap
Help in store function call in PersistenceBroker
Hi
I’m having some problem when I attempt to store the database.
It’s throwing the stack trace following stack trace
com.fedex.cih.jp.JPShipmentImpl.setMDEDetails(JPShipmentImpl.java:424)
2003-07-0
9 02:03:00,843 ERROR [ExecuteThread: '8' for queue:
'default'] jp.JPShipmentImpl
(JPShipmentImpl.java:424) - org.apache.ojb.broker.PersistenceBrokerException:
C
ould not generate primary key values for given Identity
com.fedex.data.ShipmentCoreClearanceImpl{2057001}, exception
was java.lang.Array
IndexOutOfBoundsException
java.lang.ArrayIndexOutOfBoundsException
at org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:263)
at org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:204)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.assertFkAssignment(PersistenceBrokerImpl.java:730)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.assignReferenceFKs(PersistenceBrokerImpl.java:2104)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1935)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1874)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:660)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:158)
at com.fedex.cih.jp.JPShipmentImpl.setMDEDetails(JPShipmentImpl.java:370)
at com.fedex.cih.ejb.ShipmentBean.setMDEDetails(ShipmentBean.java:159)
at
com.fedex.cih.ejb.ShipmentBean_6ssy2e_EOImpl.setMDEDetails(ShipmentBean_6ssy2e_EOImpl.java:202)
at
com.fedex.cih.ejb.ShipmentBean_6ssy2e_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at
weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:821)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
rethrown as org.apache.ojb.broker.PersistenceBrokerException:
Could not generate
primary key values for given Identity
com.fedex.data.ShipmentCoreClearanceImpl{2057001}, exception
was java.lang.ArrayIndexOutOfBoundsException
at org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:275)
at org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:204)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.assertFkAssignment(PersistenceBrokerImpl.java:730)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.assignReferenceFKs(PersistenceBrokerImpl.java:2104)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1935)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1874)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:660)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:158)
at com.fedex.cih.jp.JPShipmentImpl.setMDEDetails(JPShipmentImpl.java:370)
at com.fedex.cih.ejb.ShipmentBean.setMDEDetails(ShipmentBean.java:159)
at
com.fedex.cih.ejb.ShipmentBean_6ssy2e_EOImpl.setMDEDetails(ShipmentBean_6ssy2e_EOImpl.java:202)
at
com.fedex.cih.ejb.ShipmentBean_6ssy2e_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at
weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:821)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
com.fedex.cih.jp.JPShipmentImpl.setMDEDetails(JPShipmentImpl.java:446)
2003-07-0
9 02:03:01,187 DEBUG [ExecuteThread: '8' for queue:
'default'] jp.JPShipmentImpl
(JPShipmentImpl.java:446) - Closing broker in finally setMDEDetails()
: TX
The problem happen when at the BrokerHelp
Where the class descriptor class is return 2 primary key
And the identity class return only contains one (which is
correct since at the reference mapping I’m only setting only one)
.
...
-
To unsubscribe, e-ma
.exe problem
Hi, I am using JBuilder 9. The system works fine when I execute it in the JBuilder or when I execute it as .jar. But when I generate an .exe (with JBuilder) and try to execute it I got the error: Exception in thread "main" javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be instantiated: java.lang.NullPointerException at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at org.apache.ojb.broker.metadata.RepositoryPersistor.buildRepository(Unknown Source) at org.apache.ojb.broker.metadata.RepositoryPersistor.readDescriptorRepository(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.buildDefaultKey(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.(Unknown Source) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(Unknown Source) at
DateTime conversion problem again
Sorry to post this question again, I still can't solve the problem. Any help will be very appreciated! Can anybody tell me how to map DateTime MySql field in OJB? My realization is the next: userDateInserted - of type java.util.Date. After setting the Date, OJB inserts right date. But time is 1 hour minus of the actual time (minutes and seconds are right). Interesting, the userDateInserted has right Date value, but after passing it thru OJB, Date is decreased for 1 hour... Is it some kind of a bug? Am I doing something wrong? Any suggestions? Regards, Mykola Ostapchuk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Hello,
I've spent 2 days trying to migrate my application from OJB 0.9.7 to OJB
1.0.rc3, and still no success.
The problem is - I can't instantiate broker with the next line:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
I'm using default OJB.properties from 1.0 rc3. I have db-ojb-1.0.rc3.jar and
all additional *.jar files in /lib folder.
I debug RepositoryXmlHandler and it seems there're no problems (see code
snap from pevious message below).
Line:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
generates some error I don't know how to cach.
log.error in cach statement doesn't print anything.
try {
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
usersVO.setUsername(username);
usersVO.setPassword(password);
Query query = new QueryByCriteria(usersVO);
usersVO = (UsersVO) broker.getObjectByQuery(query);
} catch (Exception e) {
log.error("PersistenceBrokerException thrown in UsersDAO.findByUP(): "
+ e.toString());
}
With OJB 0.9.7 everything works fine.
I'll very appreciate any help!
Regards,
Mykola Ostapchuk
- Original Message -
From: "Mykola Ostapchuk" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, July 08, 2003 11:52 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
> Sorry for the previous message. Here's the log:
>
>
> 0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - startDoc
> 0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - >
> descriptor-repository
> 0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - < documentation
> 15DEBUG [Thread-5] metadata.RepositoryXmlHandler - >
class-descriptor
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
isolation-level:
> read-uncommitted
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - class:
> com.iprs.web.users.UsersVO
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - proxy: null
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - table: users
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - row-reader:
null
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - extends: null
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - accept-locks:
> true
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - accept-locks:
> true
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
> initialization-method: null
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - refresh: true
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - >
> field-descriptor
> 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - name: userId
> 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - column: US_id
> 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - jdbc-type:
> BIGINT
> > [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: endDoc
> >
> >
> >
> > - Original Message -
> > From: "Thomas Mahler" <[EMAIL PROTECTED]>
> > To: "OJB Users List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, July 08, 2003 1:57 AM
> > Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
> >
> >
> > > this is most likely a problem during the parsing of the repository.
> > > please set the debug level for XmlRepositoryHandler to DEBUG to see
> > > where the repository problems are.
> > >
> > > cheers,
> > > Thomas
> > >
> > > Mykola Ostapchuk wrote:
> > > > Hello,
> > > >
> > > > I have a problem with migrating from OJB 0.9.7 to OJB 1.0.rc3.
> > > > What I did:
> > > > - replaced db-ojb-0.9.7.jar with db-ojb-1.0.rc3.jar.
> > > > - built new OJB internal DB tables.
> > > > - replaced old OJB.properties with a new one.
> > > > - replaced repository.dtd with a new one.
> > > > - modified repository.xml for a new version.
> > > >
> > > > I can't instantiate broker. I see no error messages:
> > > >
> > > > try {
> > > > log.info("Can see this message***");
> > > > broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> > > > log.info("Can not see this
message***");
> > > > } catch (Exception e) {
> > > > log.info("Can not see this
message***");
> > > > }
> > > >
> > > > Is there something I've missed?
> > > >
> > > >
> > > > Regards,
> > > > Mykola Ostapchuk
> > > >
> > > >
> > >
> -
> > > > 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]
> > >
> >
> >
> > -
Re: Rollback not happening
Hi, > I am using WebSphere transaction manager factory, and > ConnectionFactoryManagedImpl. if you are running in an managed environment use declarative or programmatic transaction of your appServer (don't use the OJB tx demarcation e.g beginTransaction(), ...). How do you use OJB - within session beans? If you don't run in a managed environment and you want to use OJB tx-demarcation, don't set 'ConnectionFactoryManagedImpl'. regards, Armin - Original Message - From: "McCaffrey, John G." <[EMAIL PROTECTED]> To: "'OJB Users List'" <[EMAIL PROTECTED]> Sent: Wednesday, July 09, 2003 12:12 AM Subject: Rollback not happening > hmmm. I must be missing something, but I thought if I called > persistanceBroker.beginTransaction(); > persistanceBroker.store(brokerVO); > and if there was an exception and persistanceBroker.commitTransaction(); > never gets called, then the data should not be in the database. > > I am storing a BrokerVO that has N BusinessContact objects, and if one of > the businesContacts fails to insert, I want the whole transaction to > rollback. I am not sure what I am doing wrong here. If any part of the > transaction fails (I am inserting into three tables), I want all of the data > to rollback. > > > > schema="&schema;" table="brkr"> > jdbc-type="DECIMAL" primarykey="true"/> > jdbc-type="VARCHAR" /> > > column="EFCT_STRT_DT" jdbc-type="DATE" > > conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDa teFi > eldConversion"/> > column="EFCT_END_DT" jdbc-type="DATE" > > conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDa teFi > eldConversion"/> > jdbc-type="VARCHAR"/> > > class-ref="com.kraft.esi.msf.common.db.dsna.BusnPtnrVO" auto-retrieve="true" > auto-update="true" auto-delete="true"> > > > > class-ref="com.kraft.esi.msf.common.db.dsna.ApVndrVO" auto-retrieve="true" > auto-update="false" auto-delete="false"> > > > > element-class-ref="com.kraft.esi.msf.common.db.dsna.BpCntctVO" > auto-retrieve="true" auto-update="true" > auto-delete="true" orderby="cntctTypeCode" sort="ASC" > proxy="false" > > > > > > > > > I am using WebSphere transaction manager factory, and > ConnectionFactoryManagedImpl. > > any help would be greatly appreciated. > > -John > > > - > 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]
Re: Rollback not happening
John, Do you call broker.abortTransaction() ; when you catch the exception. -chris worley > hmmm. I must be missing something, but I thought if I called > persistanceBroker.beginTransaction(); > persistanceBroker.store(brokerVO); > and if there was an exception and persistanceBroker.commitTransaction(); > never gets called, then the data should not be in the database. > > I am storing a BrokerVO that has N BusinessContact objects, and if one of > the businesContacts fails to insert, I want the whole transaction to > rollback. I am not sure what I am doing wrong here. If any part of the > transaction fails (I am inserting into three tables), I want all of the > data > to rollback. > > > >schema="&schema;" table="brkr"> >jdbc-type="DECIMAL" primarykey="true"/> >jdbc-type="VARCHAR" /> > >column="EFCT_STRT_DT" jdbc-type="DATE" > > conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDateFi > eldConversion"/> >column="EFCT_END_DT" jdbc-type="DATE" > > conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDateFi > eldConversion"/> >jdbc-type="VARCHAR"/> > >class-ref="com.kraft.esi.msf.common.db.dsna.BusnPtnrVO" > auto-retrieve="true" > auto-update="true" auto-delete="true"> > > > > class-ref="com.kraft.esi.msf.common.db.dsna.ApVndrVO" auto-retrieve="true" > auto-update="false" auto-delete="false"> > > > >element-class-ref="com.kraft.esi.msf.common.db.dsna.BpCntctVO" >auto-retrieve="true" auto-update="true" > auto-delete="true" orderby="cntctTypeCode" sort="ASC" >proxy="false" > > > > > > > > > I am using WebSphere transaction manager factory, and > ConnectionFactoryManagedImpl. > > any help would be greatly appreciated. > > -John > > > - > 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]
Rollback not happening
hmmm. I must be missing something, but I thought if I called persistanceBroker.beginTransaction(); persistanceBroker.store(brokerVO); and if there was an exception and persistanceBroker.commitTransaction(); never gets called, then the data should not be in the database. I am storing a BrokerVO that has N BusinessContact objects, and if one of the businesContacts fails to insert, I want the whole transaction to rollback. I am not sure what I am doing wrong here. If any part of the transaction fails (I am inserting into three tables), I want all of the data to rollback. I am using WebSphere transaction manager factory, and ConnectionFactoryManagedImpl. any help would be greatly appreciated. -John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rollback Causes Errors
It seems like every transaction generates a rollback whether it's needed or not. Can this be turned off? The reason why - it generates errors when I do a delete. See p6spy output: p6spy - 1057694346163|0|0|statement|DELETE FROM usertable WHERE user_id = ? |DELETE FROM usertable WHERE user_id = 'Oliver' p6spy - 1057694346163|0|0|rollback|| ERROR Date = 2003-07-08 15:59:06,163 [Thread-6] org.apache.ojb.broker.accesslayer.ConnectionManagerImpl Line = ? - Rollback on the underlying connection failed java.sql.SQLException: General error: Warning: Some non-transactional changed tables couldn't be rolled back According to http://www.mysql.com/doc/en/Non-transactional_tables.html, this error is caused by: If you get the error/warning: Warning: Some non-transactional changed tables couldn't be rolled back when trying to do a ROLLBACK, this means that some of the tables you used in the transaction didn't support transactions. These non-transactional tables will not be affected by the ROLLBACK statement. Snippet from repository: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where Do Stored Procedures Fit Into An O/R Mapping Layer?
Hi Thomas, Ron, > Yes, I still think this is the right way to approach this. Stored > procedures vary a lot between DB products. And even with the same > Product they can be used in many different styles. > So I think it's better to provide a clean way to plug in user defined > Stored procedure based extensions than to built something > into the OJB > core which will fit only into a small number of environments. Not to stir the pot, and I will readily admit that my understanding of JDBC and OJB is still inadequate, but I thought that the java.sql.Statement classes provided a portable way to make these calls and that it was up to the specific JDBC driver to handle the RDBMS-specific stuff. Perhaps extensions to the o.a.o.b.platforms.Platform interface and the related sub-classes that support SP's and/or UDF's? > > With respect to the specific changes you mention, here are my > > explanations: > > > > I had to extend > > org.apache.ojb.broker.accesslayer.StatementsForClassImpl > because this > > was where the JDBC statement is created that will be used to perform > > the insert/update/delete operation. Out of the box, this class > > creates a PreparedStatement. In my situation, I needed it to create > > a CallableStatement so that I could 'harvest' values that were > > returned by the stored procedure. So, my change was to simply > > replicate the code in prepareStatement(Connection, String, boolean) > > and change "con.prepareStatement" to "con.prepareCall". > > Maybe we can avoid this copy/paste reuse by providing some > abstraction > in OJB? IMHO, this is a good compromise, though I really think greater integration for stored procedures should be considered for 2.0. Just my $.02. > > I had to override getStatementsForClass(ClassDescriptor) because the > > implementation provided by > > org.apache.ojb.broker.accesslayer.StatementManager instantiated the > > StatementsForClassImpl class, not my extension (above). > > Maybe this could be made configurable by using our > ConfigurableFactory > concept and a new entry in OJB.properties? Hmm, I'll give it a try and see if I can't hack something out. BTW, that ConfigurableFactory class solved some other non-db-related problems in my design, so thanks! > > I believe that somewhere in my dialogs with Thomas, we discussed the > > possibility of making the first situation 'pluggable' so > that neither > > of these extensions would be required. Maybe some sort of > > 'StatementFactory' implementation. I don't recall exactly where > > those discussions went. Maybe it's time to reconsider the option > > since others are starting to use stored procedures. > > I agree, if there is something that could make the > integration of user > extensions easier we are happy to implement it! Gotta love OSS... ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:m-relation
Edson,
Can i ask you to give an example of how you add more B objects the the
collection you described below
do you do something like this :
//get broker
broker = brokerfactory.defaultInstance();
//fetch an A object that has say 3 B objects in the collection.
...
//create a new B object
B newB = new B();
//add to the collection
A.getCol().add(newB);
//persist the A
broker.beginTransaction();
broker.store(A);
broker.commitTransaction();
?
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
>>> [EMAIL PROTECTED] 7/8/2003 12:24:28 PM >>>
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try to
give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
And this should work. You don't need to specify auto-retrieve, because
by
default it's true. Auto-update and auto-delete are false by default.
Some
people like to work with specialized collection classes. In particular,
I
work always with RemovalAwareList (a collection that know how to
persists
deletes in the collection). To archieve this, your should be more
specific
in collection descriptor like this:
Of course, you could mixes the several other options that OJB offers to
you,
like auto-increment, proxies and so on. In this case, I'll recomendly
you to
use cvs HEAD that has several fixes for these options over rc3.
Best regards,
Edson Richter
- Original Message -
From: "Christian Eugster" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 07, 2003 11:31 AM
Subject: 1:m-relation
i am working on a mysql-database and ojb rc3. i have an 1:m-relation
with
the following setting in the collection-desriptor of the parent
object:
auto-retrieve="true"
when i try to retrieve an parent-object i get the error-message as
follows:
(setting auto-retrieve to false there is no error). what am i doing
wrong?
java.lang.IllegalArgumentException
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.
java:63)
at java.lang.reflect.Field.set(Field.java:519)
at
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un
known Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(
Unknown Source)
at ch.eugster.pos.db.Receipt.getReceiptsByUserState(Receipt.java:183)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.loadReceipts(ReceiptTableBlock.j
ava:58)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:50)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.(ReceiptTableBlock.java:39
)
at ch.eugster.pos.client.gui.ChildrenBlock.init(ChildrenBlock.java:34)
at
ch.eugster.pos.client.gui.ChildrenBlock.(ChildrenBlock.java:28)
at ch.eugster.pos.client.gui.UserPanel.init(UserPanel.java:58)
at ch.eugster.pos.client.gui.UserPanel.(UserPanel.java:39)
at ch.eugster.pos.client.gui.TabPanel.addUser(TabPanel.java:67)
at ch.eugster.pos.client.gui.TabPanel.userLoggedIn(TabPanel.java:126)
at
ch.eugster.pos.client.gui.LoginPanel.fireLoginEvent(LoginPanel.java:99)
at
ch.eugster.pos.client.gui.LoginPanel.actionPerformed(LoginPanel.java:90)
at
ch.eugster.pos.client.gui.LoginBlock.fireActionEvent(LoginBlock.java:197)
at
ch.eugster.pos.client.gui.LoginBlock.keyPressed(LoginBlock.java:156)
at java.awt.Component.processKeyEvent(Component.java:5051)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2385)
at java.awt.Component.processEvent(Component.java:4902)
at java.awt.Container.processEvent(C
Re: Where Do Stored Procedures Fit Into An O/R Mapping Layer?
Hi Ron, hi Burt, Ron Gallagher wrote: Burt -- When I first approached Thomas regarding what I wanted to accomplish, we both agreed that my implementation did not fit well into the 'core' OJB api. However, we agreed to implement some new features and enhance some existing ones to enable me to extend/customize OJB to support my needs. I'm not sure if that view point has changed. Thomas may be able to comment further. Yes, I still think this is the right way to approach this. Stored procedures vary a lot between DB products. And even with the same Product they can be used in many different styles. So I think it's better to provide a clean way to plug in user defined Stored procedure based extensions than to built something into the OJB core which will fit only into a small number of environments. With respect to the specific changes you mention, here are my explanations: I had to extend org.apache.ojb.broker.accesslayer.StatementsForClassImpl because this was where the JDBC statement is created that will be used to perform the insert/update/delete operation. Out of the box, this class creates a PreparedStatement. In my situation, I needed it to create a CallableStatement so that I could 'harvest' values that were returned by the stored procedure. So, my change was to simply replicate the code in prepareStatement(Connection, String, boolean) and change "con.prepareStatement" to "con.prepareCall". Maybe we can avoid this copy/paste reuse by providing some abstraction in OJB? I had to override getStatementsForClass(ClassDescriptor) because the implementation provided by org.apache.ojb.broker.accesslayer.StatementManager instantiated the StatementsForClassImpl class, not my extension (above). Maybe this could be made configurable by using our ConfigurableFactory concept and a new entry in OJB.properties? I believe that somewhere in my dialogs with Thomas, we discussed the possibility of making the first situation 'pluggable' so that neither of these extensions would be required. Maybe some sort of 'StatementFactory' implementation. I don't recall exactly where those discussions went. Maybe it's time to reconsider the option since others are starting to use stored procedures. I agree, if there is something that could make the integration of user extensions easier we are happy to implement it! cheers, Thomas Those are my thoughts. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] From: "BURT, RANDALL (CONTRACTOR)" <[EMAIL PROTECTED]> Date: 2003/07/08 Tue AM 10:19:27 EDT To: "OJB Users List" <[EMAIL PROTECTED]> Subject: RE: Where Do Stored Procedures Fit Into An O/R Mapping Layer? The project I'm on has come to the point of integrating sp's into the app, and I was wondering if there were any plans to incorporate Mr. Gallagher's ideas into the main OJB distribution. If so, I'd be more than willing to lend a hand. Also, maybe its my ignorance, but could you expand on the modifications you had to make in org.apache.ojb.broker.accesslayer.StatementsForClassImpl and org.apache.ojb.broker.accesslayer.StatementManager.getStatementsForClass(ClassDescriptor)? My (admittedly very limited) understanding of these classes doesn't clue me as to the reason/form of the modifications. Thanks, BTW, to Mr. Gallagher, Mr. Mahler, and the rest of the OJB team for a great framework and documentation. - 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]
Re: 1:m-relation
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try to give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
And this should work. You don't need to specify auto-retrieve, because by
default it's true. Auto-update and auto-delete are false by default. Some
people like to work with specialized collection classes. In particular, I
work always with RemovalAwareList (a collection that know how to persists
deletes in the collection). To archieve this, your should be more specific
in collection descriptor like this:
Of course, you could mixes the several other options that OJB offers to you,
like auto-increment, proxies and so on. In this case, I'll recomendly you to
use cvs HEAD that has several fixes for these options over rc3.
Best regards,
Edson Richter
- Original Message -
From: "Christian Eugster" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 07, 2003 11:31 AM
Subject: 1:m-relation
i am working on a mysql-database and ojb rc3. i have an 1:m-relation with
the following setting in the collection-desriptor of the parent object:
auto-retrieve="true"
when i try to retrieve an parent-object i get the error-message as follows:
(setting auto-retrieve to false there is no error). what am i doing wrong?
java.lang.IllegalArgumentException
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.
java:63)
at java.lang.reflect.Field.set(Field.java:519)
at
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un
known Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(
Unknown Source)
at ch.eugster.pos.db.Receipt.getReceiptsByUserState(Receipt.java:183)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.loadReceipts(ReceiptTableBlock.j
ava:58)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:50)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.(ReceiptTableBlock.java:39
)
at ch.eugster.pos.client.gui.ChildrenBlock.init(ChildrenBlock.java:34)
at ch.eugster.pos.client.gui.ChildrenBlock.(ChildrenBlock.java:28)
at ch.eugster.pos.client.gui.UserPanel.init(UserPanel.java:58)
at ch.eugster.pos.client.gui.UserPanel.(UserPanel.java:39)
at ch.eugster.pos.client.gui.TabPanel.addUser(TabPanel.java:67)
at ch.eugster.pos.client.gui.TabPanel.userLoggedIn(TabPanel.java:126)
at ch.eugster.pos.client.gui.LoginPanel.fireLoginEvent(LoginPanel.java:99)
at ch.eugster.pos.client.gui.LoginPanel.actionPerformed(LoginPanel.java:90)
at
ch.eugster.pos.client.gui.LoginBlock.fireActionEvent(LoginBlock.java:197)
at ch.eugster.pos.client.gui.LoginBlock.keyPressed(LoginBlock.java:156)
at java.awt.Component.processKeyEvent(Component.java:5051)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2385)
at java.awt.Component.processEvent(Component.java:4902)
at java.awt.Container.processEvent(Container.java:1566)
at java.awt.Component.dispatchEventImpl(Component.java:3598)
at java.awt.Container.dispatchEventImpl(Container.java:1623)
at java.awt.Component.dispatchEvent(Component.java:3439)
at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1688
)
at
java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusMa
nager.java:593)
at
java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocu
sManager.java:765)
at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocu
sManager.java:698)
at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(Defaul
Re: 1:m-relation
hi christian, imo you have defined the setter for your collection as Vector. you should use Collection instead. jakob Christian Eugster wrote: i am working on a mysql-database and ojb rc3. i have an 1:m-relation with the following setting in the collection-desriptor of the parent object: auto-retrieve="true" when i try to retrieve an parent-object i get the error-message as follows: (setting auto-retrieve to false there is no error). what am i doing wrong? java.lang.IllegalArgumentException at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl. java:63) at java.lang.reflect.Field.set(Field.java:519) at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un known Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( Unknown Source) at ch.eugster.pos.db.Receipt.getReceiptsByUserState(Receipt.java:183) at ch.eugster.pos.client.gui.ReceiptTableBlock.loadReceipts(ReceiptTableBlock.j ava:58) at ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:50) at ch.eugster.pos.client.gui.ReceiptTableBlock.(ReceiptTableBlock.java:39 ) at ch.eugster.pos.client.gui.ChildrenBlock.init(ChildrenBlock.java:34) at ch.eugster.pos.client.gui.ChildrenBlock.(ChildrenBlock.java:28) at ch.eugster.pos.client.gui.UserPanel.init(UserPanel.java:58) at ch.eugster.pos.client.gui.UserPanel.(UserPanel.java:39) at ch.eugster.pos.client.gui.TabPanel.addUser(TabPanel.java:67) at ch.eugster.pos.client.gui.TabPanel.userLoggedIn(TabPanel.java:126) at ch.eugster.pos.client.gui.LoginPanel.fireLoginEvent(LoginPanel.java:99) at ch.eugster.pos.client.gui.LoginPanel.actionPerformed(LoginPanel.java:90) at ch.eugster.pos.client.gui.LoginBlock.fireActionEvent(LoginBlock.java:197) at ch.eugster.pos.client.gui.LoginBlock.keyPressed(LoginBlock.java:156) at java.awt.Component.processKeyEvent(Component.java:5051) at javax.swing.JComponent.processKeyEvent(JComponent.java:2385) at java.awt.Component.processEvent(Component.java:4902) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3598) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3439) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1688 ) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusMa nager.java:593) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocu sManager.java:765) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocu sManager.java:698) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManag er.java:559) at java.awt.Component.dispatchEventImpl(Component.java:3468) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Window.dispatchEventImpl(Window.java:1585) at java.awt.Component.dispatchEvent(Component.java:3439) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja va:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) rethrown as org.apache.ojb.broker.metadata.MetadataException: Error setting field:positions in object:ch.eugster.pos.db.Receipt at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un known Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown Source) at org.
Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Sorry for the previous message. Here's the log: 0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - startDoc 0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - > descriptor-repository 0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - < documentation 15DEBUG [Thread-5] metadata.RepositoryXmlHandler - > class-descriptor 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - isolation-level: read-uncommitted 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - class: com.iprs.web.users.UsersVO 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - proxy: null 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - table: users 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - row-reader: null 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - extends: null 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - accept-locks: true 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - accept-locks: true 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - initialization-method: null 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - refresh: true 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - > field-descriptor 31DEBUG [Thread-5] metadata.RepositoryXmlHandler - name: userId 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - column: US_id 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - jdbc-type: BIGINT 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - primarykey: true 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - nullable: true 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - indexed: false 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - autoincrement: true 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - sequence-name: null 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - locking: false 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - update-lock: true 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - conversion: null 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - < field-descriptor 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - > field-descriptor 46DEBUG [Thread-5] metadata.RepositoryXmlHandler - name: username 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - column: US_username 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - jdbc-type: VARCHAR 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - primarykey: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - nullable: true 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - indexed: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - autoincrement: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - sequence-name: null 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - locking: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - update-lock: true 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - conversion: null 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - < field-descriptor 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - > field-descriptor 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - name: password 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - column: US_password 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - jdbc-type: VARCHAR 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - primarykey: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - nullable: true 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - indexed: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - autoincrement: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - sequence-name: null 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - locking: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - update-lock: true 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - conversion: null 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - < field-descriptor 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - > field-descriptor 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - name: userFirstName 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - column: US_f_name 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - jdbc-type: VARCHAR 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - primarykey: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - nullable: true 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - indexed: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - autoincrement: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - sequence-name: null 62DEBUG [Thread-5] metadata.RepositoryXmlHandler - locking: false 62DEBUG [Thread-5] metadata.RepositoryXmlHandler -
RE: Where Do Stored Procedures Fit Into An O/R Mapping Layer?
Thanks, Mr. Gallagher. > When I first approached Thomas regarding what I wanted to > accomplish, we both agreed that my implementation did not fit > well into the 'core' OJB api. However, we agreed to > implement some new features and enhance some existing ones to > enable me to extend/customize OJB to support my needs. I'm > not sure if that view point has changed. Thomas may be able > to comment further. I hope so. It seems that support for sp's and UDF's would be a logical, and in many cases, necessary extension to the framework. > I had to override getStatementsForClass(ClassDescriptor) > because the implementation provided by > org.apache.ojb.broker.accesslayer.StatementManager > instantiated the StatementsForClassImpl class, not my > extension (above). I was hoping this was not the case... :( > I believe that somewhere in my dialogs with Thomas, we > discussed the possibility of making the first situation > 'pluggable' so that neither of these extensions would be > required. Maybe some sort of 'StatementFactory' > implementation. I don't recall exactly where those > discussions went. Maybe it's time to reconsider the option > since others are starting to use stored procedures. Sounds like it to me as well. Should this be taken up on the dev list? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : How to insert a long / FK nullable with a null value ?
Tx !! -Message d'origine- De : Charles Anthony [mailto:[EMAIL PROTECTED] Envoyé : mardi 8 juillet 2003 17:30 À : 'OJB Users List' Objet : RE: RE : How to insert a long / FK nullable with a null value ? FieldConversion, not FieldCompletion More info here . http://db.apache.org/ojb/jdbc-types.html >-Original Message- >From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] >Sent: 08 July 2003 16:30 >To: 'OJB Users List' >Subject: RE : How to insert a long / FK nullable with a null value ? > > >Hi Thomas ! > >Where can I find some sample with the FieldCompletion ? I >don't knopw how to >use it ands I didn't found anything in the doc , maillist and >tutorial ... > > >Tx ! > > > > > >-Message d'origine- >De : Mahler Thomas [mailto:[EMAIL PROTECTED] >Envoyé : mardi 8 juillet 2003 14:59 >À : 'OJB Users List' >Objet : RE: How to insert a long / FK nullable with a null value ? > >You could also use a special FieldConversion to convert zero >to null and >vice versa. >Have a look at >o.a.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion and >BlankString2NullFieldConversion. > >cheers, >Thomas > >> -Original Message- >> From: Bram Meijboom [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 08, 2003 12:36 PM >> To: 'OJB Users List' >> Subject: RE: How to insert a long / FK nullable with a null value ? >> >> >> make it a Long object and set it to null >> >> >> -Original Message- >> From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 08, 2003 12:33 PM >> To: OJB Users List >> Subject: How to insert a long / FK nullable with a null value ? >> >> >> All, >> >> >> >> >> >> I have a table with a Foreign Key witch is null able. The JDO's java >> object's attribute associated to this table's column is a "long". >> >> >> >> My trouble is that OJB insert "0" each time nothing is >> specified in the JDO >> attribute. But '0' is not a good thing for my application; I >> would like to >> have null value. >> >> >> >> But how could I have a null value with a long type ?? >> >> >> >> >> >> Thanks a lot! >> >> >> >> >> - >> 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] > This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - 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]
RE: RE : How to insert a long / FK nullable with a null value ?
FieldConversion, not FieldCompletion More info here . http://db.apache.org/ojb/jdbc-types.html >-Original Message- >From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] >Sent: 08 July 2003 16:30 >To: 'OJB Users List' >Subject: RE : How to insert a long / FK nullable with a null value ? > > >Hi Thomas ! > >Where can I find some sample with the FieldCompletion ? I >don't knopw how to >use it ands I didn't found anything in the doc , maillist and >tutorial ... > > >Tx ! > > > > > >-Message d'origine- >De : Mahler Thomas [mailto:[EMAIL PROTECTED] >Envoyé : mardi 8 juillet 2003 14:59 >À : 'OJB Users List' >Objet : RE: How to insert a long / FK nullable with a null value ? > >You could also use a special FieldConversion to convert zero >to null and >vice versa. >Have a look at >o.a.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion and >BlankString2NullFieldConversion. > >cheers, >Thomas > >> -Original Message- >> From: Bram Meijboom [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 08, 2003 12:36 PM >> To: 'OJB Users List' >> Subject: RE: How to insert a long / FK nullable with a null value ? >> >> >> make it a Long object and set it to null >> >> >> -Original Message- >> From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 08, 2003 12:33 PM >> To: OJB Users List >> Subject: How to insert a long / FK nullable with a null value ? >> >> >> All, >> >> >> >> >> >> I have a table with a Foreign Key witch is null able. The JDO's java >> object's attribute associated to this table's column is a "long". >> >> >> >> My trouble is that OJB insert "0" each time nothing is >> specified in the JDO >> attribute. But '0' is not a good thing for my application; I >> would like to >> have null value. >> >> >> >> But how could I have a null value with a long type ?? >> >> >> >> >> >> Thanks a lot! >> >> >> >> >> - >> 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] > This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : How to insert a long / FK nullable with a null value ?
Hi Thomas ! Where can I find some sample with the FieldCompletion ? I don't knopw how to use it ands I didn't found anything in the doc , maillist and tutorial ... Tx ! -Message d'origine- De : Mahler Thomas [mailto:[EMAIL PROTECTED] Envoyé : mardi 8 juillet 2003 14:59 À : 'OJB Users List' Objet : RE: How to insert a long / FK nullable with a null value ? You could also use a special FieldConversion to convert zero to null and vice versa. Have a look at o.a.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion and BlankString2NullFieldConversion. cheers, Thomas > -Original Message- > From: Bram Meijboom [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2003 12:36 PM > To: 'OJB Users List' > Subject: RE: How to insert a long / FK nullable with a null value ? > > > make it a Long object and set it to null > > > -Original Message- > From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2003 12:33 PM > To: OJB Users List > Subject: How to insert a long / FK nullable with a null value ? > > > All, > > > > > > I have a table with a Foreign Key witch is null able. The JDO's java > object's attribute associated to this table's column is a "long". > > > > My trouble is that OJB insert "0" each time nothing is > specified in the JDO > attribute. But '0' is not a good thing for my application; I > would like to > have null value. > > > > But how could I have a null value with a long type ?? > > > > > > Thanks a lot! > > > > > - > 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]
Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Hello,
I've set org.apache.ojb.broker.metadata.RepositoryXmlHandler.LogLevel=DEBUG
Here's what I've got:
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: startDoc
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
accept-locks: true
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: endDoc
- Original Message -
From: "Thomas Mahler" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 08, 2003 1:57 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
> this is most likely a problem during the parsing of the repository.
> please set the debug level for XmlRepositoryHandler to DEBUG to see
> where the repository problems are.
>
> cheers,
> Thomas
>
> Mykola Ostapchuk wrote:
> > Hello,
> >
> > I have a problem with migrating from OJB 0.9.7 to OJB 1.0.rc3.
> > What I did:
> > - replaced db-ojb-0.9.7.jar with db-ojb-1.0.rc3.jar.
> > - built new OJB internal DB tables.
> > - replaced old OJB.properties with a new one.
> > - replaced repository.dtd with a new one.
> > - modified repository.xml for a new version.
> >
> > I can't instantiate broker. I see no error messages:
> >
> > try {
> > log.info("Can see this message***");
> > broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> > log.info("Can not see this message***");
> > } catch (Exception e) {
> > log.info("Can not see this message***");
> > }
> >
> > Is there something I've missed?
> >
> >
> > Regards,
> > Mykola Ostapchuk
> >
> >
> > -
> > 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]
Re: Where Do Stored Procedures Fit Into An O/R Mapping Layer?
Burt -- When I first approached Thomas regarding what I wanted to accomplish, we both agreed that my implementation did not fit well into the 'core' OJB api. However, we agreed to implement some new features and enhance some existing ones to enable me to extend/customize OJB to support my needs. I'm not sure if that view point has changed. Thomas may be able to comment further. With respect to the specific changes you mention, here are my explanations: I had to extend org.apache.ojb.broker.accesslayer.StatementsForClassImpl because this was where the JDBC statement is created that will be used to perform the insert/update/delete operation. Out of the box, this class creates a PreparedStatement. In my situation, I needed it to create a CallableStatement so that I could 'harvest' values that were returned by the stored procedure. So, my change was to simply replicate the code in prepareStatement(Connection, String, boolean) and change "con.prepareStatement" to "con.prepareCall". I had to override getStatementsForClass(ClassDescriptor) because the implementation provided by org.apache.ojb.broker.accesslayer.StatementManager instantiated the StatementsForClassImpl class, not my extension (above). I believe that somewhere in my dialogs with Thomas, we discussed the possibility of making the first situation 'pluggable' so that neither of these extensions would be required. Maybe some sort of 'StatementFactory' implementation. I don't recall exactly where those discussions went. Maybe it's time to reconsider the option since others are starting to use stored procedures. Those are my thoughts. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] > > From: "BURT, RANDALL (CONTRACTOR)" <[EMAIL PROTECTED]> > Date: 2003/07/08 Tue AM 10:19:27 EDT > To: "OJB Users List" <[EMAIL PROTECTED]> > Subject: RE: Where Do Stored Procedures Fit Into An O/R Mapping Layer? > > The project I'm on has come to the point of integrating sp's into the app, and I was > wondering if there were any plans to incorporate Mr. Gallagher's ideas into the main > OJB distribution. If so, I'd be more than willing to lend a hand. > > Also, maybe its my ignorance, but could you expand on the modifications you had to > make in org.apache.ojb.broker.accesslayer.StatementsForClassImpl and > org.apache.ojb.broker.accesslayer.StatementManager.getStatementsForClass(ClassDescriptor)? > My (admittedly very limited) understanding of these classes doesn't clue me as to > the reason/form of the modifications. > > Thanks, BTW, to Mr. Gallagher, Mr. Mahler, and the rest of the OJB team for a great > framework and documentation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weblogic, threads, and startup errors
Hi Bonnie,
Well classloaders, especially in servlet containers, are not always the most
predictable things. I am not sure if the classloader of threads started from a web
application is even really covered in any length in the servlet specification. So
let's look at the javadocs of Thread.getContextClassLoader() for an idea of how this
classloader craziness is supposed to work:
"Returns the context ClassLoader for this Thread. The context ClassLoader is provided
by the creator of the thread for use by code running in this thread when loading
classes and resources. If not set, the default is the ClassLoader context of the
parent Thread. The context ClassLoader of the primordial thread is typically set to
the class loader used to load the application.
First, if there is a security manager, and the caller's class loader is not null and
the caller's class loader is not the same as or an ancestor of the context class
loader for the thread whose context class loader is being requested, then the security
manager's checkPermission method is called with a RuntimePermission("getClassLoader")
permission to see if it's ok to get the context ClassLoader."
"If not set, the default is the ClassLoader context of the parent Thread."
Based on this statement on starting a new thread, you would expect it's classloader to
be the same as the parent classloader of the thread it was started from. However,
this is obviously not the case within Weblogic. You would expect, (hope), the a new
thread started from a servlet would use the webapp's classloader, i.e. the parent
classloader that the servlet is using. However, it is obvious that the classloader
given to new threads started within Weblogic is not the same classloader as the one
possessed by the servlet. My guess is that new threads are using either the system of
the container or the primordial classloader rather than the webapp's classloader.
So, based on the statement "The context ClassLoader is provided by the creator of the
thread for use by code running in this thread when loading classes and resources." It
is probably a best practice to make sure you always set the classloader of a new
thread before starting. By using this process you have guaranteed the behavior of the
new thread's classloader.
In closing, my guess on what is currently happening is that new threads are either
using the system classloader of the container or the primordial classloader rather
than the webapp's classloader.
*===*
* Scott T Weaver *
* Jakarta Jetspeed Portal Project *
* [EMAIL PROTECTED] *
*===*
> -Original Message-
> From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 07, 2003 5:27 PM
> To: OJB Users List
> Subject: RE: Weblogic, threads, and startup errors
>
> This did the trick. Thank you! Now I just have to
> understand WHY it did the trick :-)
>
> Bonnie MacKellar
> software engineer
> Mobius Management Systems, Inc.
> [EMAIL PROTECTED]
>
>
> > -Original Message-
> > From: Weaver, Scott [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 07, 2003 5:23 PM
> > To: 'OJB Users List'
> > Subject: RE: Weblogic, threads, and startup errors
> >
> >
> > Actually, it should look like thisL
> >
> > ClassLoader cl = Thread.currentThread().getContextClassLoader();
> > AccountUpdater myNewThread = new AccountUpdater();
> > myNewThread.setContextClassLoader(cl);
> > myNewThreadStart.start();
> >
> > *===*
> > * Scott T Weaver *
> > * Jakarta Jetspeed Portal Project *
> > * [EMAIL PROTECTED] *
> > *===*
> >
> >
> >
> > > -Original Message-
> > > From: Weaver, Scott [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, July 07, 2003 5:21 PM
> > > To: 'OJB Users List'
> > > Subject: RE: Weblogic, threads, and startup errors
> > >
> > > Some simple questions:
> > >
> > > 1. Where do you have the OJB resources (OJB.properties,
> > repository.xml,
> > > etc.)? To make things easy, they should be in the default
> > package of your
> > > webapp's WEB-INF/classes directory.
> > >
> > > 2. Where is your OJB jar? For the most predictable
> > results, it should be
> > > in your webapp's WEB-INF/lib directory. I would discourage
> > loading OJB
> > > from shared or common lib locations within your container
> > as this might be
> > > a source of class loader errors.
> > >
> > > You may want to try setting the context classloader of your
> > new Thread
> > > with the context classloader of your servlet's current
> > thread and see if
> > > that helps.
> > >
> > > In your servlet try this...
> > >
> > > ClassLoader cl = Thread.currentThread().getContextClassLoader();
> > > AccountUpdater myNewThread = new Thread();
> > > myNewThread.setContextClassLoader(cl);
> > > myNewThreadStart.start();
> > >
> > > *===*
> > > * Scott T We
RE: Where Do Stored Procedures Fit Into An O/R Mapping Layer?
The project I'm on has come to the point of integrating sp's into the app, and I was wondering if there were any plans to incorporate Mr. Gallagher's ideas into the main OJB distribution. If so, I'd be more than willing to lend a hand. Also, maybe its my ignorance, but could you expand on the modifications you had to make in org.apache.ojb.broker.accesslayer.StatementsForClassImpl and org.apache.ojb.broker.accesslayer.StatementManager.getStatementsForClass(ClassDescriptor)? My (admittedly very limited) understanding of these classes doesn't clue me as to the reason/form of the modifications. Thanks, BTW, to Mr. Gallagher, Mr. Mahler, and the rest of the OJB team for a great framework and documentation. -Original Message- From: Ron Gallagher [mailto:[EMAIL PROTECTED] Sent: Thursday, May 08, 2003 8:26 AM To: [EMAIL PROTECTED] Subject: Re: Where Do Stored Procedures Fit Into An O/R Mapping Layer? Michael -- > I'd appreciate any and all comments on this question. > I've often wondered where stored procedures should fit > in an object-oriented application. Thomas just checked in a how-to document (xdocs/how-to-work-with-stored-procedures.xml) describing the process that I went through to get OJB to utilize stored procedures. > They're terrific for performance, and they can be a > great interface between the object and relational > layers. Folks who approach problems from a data > modeling slant are usually enthusiastic about them. > > But I've seen them terribly abused. The object bigot > in me worries about diffusing business logic - some in > objects, some in the database. > > How would one use stored procedures with OJB? Thank > you - MOD On my current project, we're using stored procedures to handle two situations: 1) All CUD (Create, Update, Delete) operations. 2) Any application function that involves a large amount of data retrieval and/or creates a large amount of data. The first situation is pretty self-explanatory and our implementation is covered in the how-to that was just posted. We use stored procedures in the second scenario for purely performance reasons. There are several functions in our app that create new entities based on either existing entities or predefined templates. In either case, the process requires the retrieval of a significant amount of data and the creation of an even larger amount of data. While it's possible to do all of this in our java code, it quickly became apparent to us that the transmission of that much data back and forth between the database and client would be a real performance problem. The solution was to create stored procedures to perform these data-intensive functions. One thing to be careful of when using stored procedures is that you're basically doing data access operations outside of the "ojb pipeline". OJB has no knowledge of anything you do through the stored procedure. If your procedure is creating data, there shouldn't be much of an issue. If your procedure is changing or deleting existing data, then you may have a problem depending on the caching mechanism that you are using and the various "refersh" settings that are in your repository. My $.02, 0.0174421 EUR using current exchange rates. Ron Gallagher Atlanta, GA [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]
Re: PersistenceBrokerImpl.delete()
I don't think you overlooked it. I think it never got posted (could be our outgoing mailer doing stupid things). Well, the performance issue would depend on how many obects you're deleting. If you're deleting hundreds of objects in a transaction, there might be a difference, though it might not be a big one. Glad to see a fix coming. (Open source is GREAT, ain't it?) David |-+---> | | "Armin Waibel" | | | <[EMAIL PROTECTED]| | | ait.de> | | | | | | 07/08/2003 08:57| | | AM | | | Please respond | | | to "OJB Users | | | List" | | | | |-+---> >--| | | |To: "OJB Users List" <[EMAIL PROTECTED]> | |cc: | |Subject: Re: PersistenceBrokerImpl.delete() | | | >--| Hi David, sorry for overlook your post twice, such was not my intention. I think you are right - will fix this ASAP! > 1) Shouldn't this be a set, for perfomance reasons. hmm, in that case I don't think List is an performance impact. > 2) Should this be based on Identity, rather than on the object (and it's > equals method) itself? I fully agree with that. regards, Armin - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 2003 2:36 PM Subject: PersistenceBrokerImpl.delete() > I posted this (twice) to the DEV list, but never saw it come through > > PB keeps a list of objects that are marked for delete, and avoids deleting > them twice. > > 1) Shouldn't this be a set, for perfomance reasons. > 2) Should this be based on Identity, rather than on the object (and it's > equals method) itself? > > David > > > This message contains information from Equifax Inc. which may be > confidential and privileged. If you are not an intended recipient, please > refrain from any disclosure, copying, distribution or use of this > information and note that such actions are prohibited. If you have > received this transmission in error, please notify by 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]
OJB article in JavaMagazin 8.2003
Hi all, there is an Article on OJB in the latest issue of the german "JavaMagazin": http://www.entwickler.com/itr/online_artikel/psecom,id,392,nodeid,11.html The article is in german and there is also a short interview Sven had with me earlier this year. cheers, Thomas
RE: How to insert a long / FK nullable with a null value ?
You could also use a special FieldConversion to convert zero to null and vice versa. Have a look at o.a.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion and BlankString2NullFieldConversion. cheers, Thomas > -Original Message- > From: Bram Meijboom [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2003 12:36 PM > To: 'OJB Users List' > Subject: RE: How to insert a long / FK nullable with a null value ? > > > make it a Long object and set it to null > > > -Original Message- > From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2003 12:33 PM > To: OJB Users List > Subject: How to insert a long / FK nullable with a null value ? > > > All, > > > > > > I have a table with a Foreign Key witch is null able. The JDO's java > object's attribute associated to this table's column is a "long". > > > > My trouble is that OJB insert "0" each time nothing is > specified in the JDO > attribute. But '0' is not a good thing for my application; I > would like to > have null value. > > > > But how could I have a null value with a long type ?? > > > > > > Thanks a lot! > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: How do I customize insert for Sybase identity columns?
Hi Brain,
every documentation contribution
is welcome ;-)
I think everybody from OJB give it
one's best, but it's really much to do.
regards,
Armin
- Original Message -
From: "Brian Chaplin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 08, 2003 2:48 PM
Subject: Re: How do I customize insert for Sybase identity columns?
> Armin,
> It worked like a champ.
> Definitely a need for some java doc before release 1.0 :)
> Thanks for the quick response!
> Brian
> "Armin Waibel" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi Brain,
> >
> > - Original Message -
> > From: "Brian Chaplin" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, July 07, 2003 2:44 PM
> > Subject: Re: How do I customize insert for Sybase identity columns?
> >
> >
> > > Armin,
> > > Using SequenceManagerInMemoryImpl didn't work. It looks like the
> > commands
> > > issued in the afterInsert callback are on another connection
> > regardless of
> > > the memory manager being used.
> >
> > with the latest version of OJB (more exact version > rc2) the
> > PersistenceAware callback methods retrieve a
> > PersistenceBroker instance
> > e.g.
> > public void afterInsert(PersistenceBroker broker)
> > throws PersistenceBrokerException;
> >
> > with broker.serviceConnectionManager().getConnection()
> > you will retrieve the current used connection (don't close
> > the connection after use!! - will be done by OJB, only close
> > your statement). Then fire your statement.
> >
> > To isolate your problem, don't use batch-mode
> > 'true' in jdbc-connection-descriptor.
> > If you don't use CVS please update
> > ConnectionManagerImpl#setBatchMode(boolean mode)
> > with
> >
> > return batchMode && platform.supportsBatchOperations();
> >
> > or get latest from CVS. This ensure that if batch-mode 'false'
> > was set, batch mode definitely was not used.
> >
> > Now try again and post your stack trace ;-)
> >
> > regards,
> > Armin
> >
> > >
> > > Should I modify the source code somewhere in this stack trace?
> > >
> > > at
> > >
> >
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(BatchConne
> > ctio
> > > n.java:298)
> > >
> > > at
> > >
> >
org.apache.ojb.broker.util.batch.BatchConnection.commit(BatchConnection.
> > java
> > > :335)
> > >
> > > at
> > >
> >
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Conn
> > ecti
> > > onManagerImpl.java:200)
> > >
> > > at
> > >
> >
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Persi
> > sten
> > > ceBrokerImpl.java:385)
> > >
> > > at
> > >
> >
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
> > (Del
> > > egatingPersistenceBroker.java:120)
> > >
> > >
> > > "Armin Waibel" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]
> > > > Hi Brain,
> > > >
> > > > use another SM implementation (e.g. SequenceManagerInMemoryImpl)
> > > > or implement your own SequenceManager.
> > > >
> > > > HiLo-SM implementation use intern a new connection (because
> > > > we want to avoid 'rollback trouble'), thus your setting is made
> > > > on the wrong connection.
> > > >
> > > > regards,
> > > > Armin
> > > >
> > > > - Original Message -
> > > > From: "Brian Chaplin" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Thursday, July 03, 2003 8:17 PM
> > > > Subject: How do I customize insert for Sybase identity columns?
> > > >
> > > >
> > > > > I'm trying to handle sybase and SQL Server identity columns by
> > > > allowing OJB
> > > > > to control the sequence number generation through the
> > > > > SequenceManagerHighLowImpl.
> > > > >
> > > > > However, to do this I need to issue a "set identity_insert
> > tablename
> > > > on"
> > > > > before the actual insert statement is executed?
> > > > >
> > > > > I did this in the afterInsert method of my BrokerAware
persistence
> > > > object as
> > > > > follows:
> > > > >
> > > > > Connection conn = getConnection();
> > > > >
> > > > > stmt = conn.createStatement();
> > > > >
> > > > > stmt.execute("set identity_insert mcsp_test on");
> > > > >
> > > > > stmt.close();
> > > > >
> > > > >
> > > > >
> > > > > Although the set statment was executed successfully, when the
> > > > persistence
> > > > > broker issued the insert command, it still failed.
> > > > >
> > > > > afterInsert
> > > > >
> > > > > 1057255340516|0|1|statement||set identity_insert mcsp_test on
> > > > >
> > > > > 1057255340516|0|0|batch|INSERT INTO mcsp_test (id,col1) VALUES
> > (?,?)
> > > > |INSERT
> > > > > INTO mcsp_test (id,col1) VALUES ('97','a13')
> > > > >
> > > > > 1057255340531|15|0|statement|INSERT INTO mcsp_test (id,col1)
> > VALUES
> > > > (?,?)
> > > > > |INSERT INTO mcsp_test (id,col1) VALUES ('97','a13')
> > > > >
> > > > > [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl]
ERROR:
> > > > Commit on
> > > > > underlying connection failed, try to rollback
> > > > >
> > > > > JZ0BE: BatchUpdateException: Err
Re: PersistenceBrokerImpl.delete()
Hi David, sorry for overlook your post twice, such was not my intention. I think you are right - will fix this ASAP! > 1) Shouldn't this be a set, for perfomance reasons. hmm, in that case I don't think List is an performance impact. > 2) Should this be based on Identity, rather than on the object (and it's > equals method) itself? I fully agree with that. regards, Armin - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 2003 2:36 PM Subject: PersistenceBrokerImpl.delete() > I posted this (twice) to the DEV list, but never saw it come through > > PB keeps a list of objects that are marked for delete, and avoids deleting > them twice. > > 1) Shouldn't this be a set, for perfomance reasons. > 2) Should this be based on Identity, rather than on the object (and it's > equals method) itself? > > David > > > This message contains information from Equifax Inc. which may be > confidential and privileged. If you are not an intended recipient, please > refrain from any disclosure, copying, distribution or use of this > information and note that such actions are prohibited. If you have > received this transmission in error, please notify by 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]
Re: How do I customize insert for Sybase identity columns?
Armin,
It worked like a champ.
Definitely a need for some java doc before release 1.0 :)
Thanks for the quick response!
Brian
"Armin Waibel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Brain,
>
> - Original Message -
> From: "Brian Chaplin" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 07, 2003 2:44 PM
> Subject: Re: How do I customize insert for Sybase identity columns?
>
>
> > Armin,
> > Using SequenceManagerInMemoryImpl didn't work. It looks like the
> commands
> > issued in the afterInsert callback are on another connection
> regardless of
> > the memory manager being used.
>
> with the latest version of OJB (more exact version > rc2) the
> PersistenceAware callback methods retrieve a
> PersistenceBroker instance
> e.g.
> public void afterInsert(PersistenceBroker broker)
> throws PersistenceBrokerException;
>
> with broker.serviceConnectionManager().getConnection()
> you will retrieve the current used connection (don't close
> the connection after use!! - will be done by OJB, only close
> your statement). Then fire your statement.
>
> To isolate your problem, don't use batch-mode
> 'true' in jdbc-connection-descriptor.
> If you don't use CVS please update
> ConnectionManagerImpl#setBatchMode(boolean mode)
> with
>
> return batchMode && platform.supportsBatchOperations();
>
> or get latest from CVS. This ensure that if batch-mode 'false'
> was set, batch mode definitely was not used.
>
> Now try again and post your stack trace ;-)
>
> regards,
> Armin
>
> >
> > Should I modify the source code somewhere in this stack trace?
> >
> > at
> >
> org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(BatchConne
> ctio
> > n.java:298)
> >
> > at
> >
> org.apache.ojb.broker.util.batch.BatchConnection.commit(BatchConnection.
> java
> > :335)
> >
> > at
> >
> org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Conn
> ecti
> > onManagerImpl.java:200)
> >
> > at
> >
> org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Persi
> sten
> > ceBrokerImpl.java:385)
> >
> > at
> >
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
> (Del
> > egatingPersistenceBroker.java:120)
> >
> >
> > "Armin Waibel" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > Hi Brain,
> > >
> > > use another SM implementation (e.g. SequenceManagerInMemoryImpl)
> > > or implement your own SequenceManager.
> > >
> > > HiLo-SM implementation use intern a new connection (because
> > > we want to avoid 'rollback trouble'), thus your setting is made
> > > on the wrong connection.
> > >
> > > regards,
> > > Armin
> > >
> > > - Original Message -
> > > From: "Brian Chaplin" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, July 03, 2003 8:17 PM
> > > Subject: How do I customize insert for Sybase identity columns?
> > >
> > >
> > > > I'm trying to handle sybase and SQL Server identity columns by
> > > allowing OJB
> > > > to control the sequence number generation through the
> > > > SequenceManagerHighLowImpl.
> > > >
> > > > However, to do this I need to issue a "set identity_insert
> tablename
> > > on"
> > > > before the actual insert statement is executed?
> > > >
> > > > I did this in the afterInsert method of my BrokerAware persistence
> > > object as
> > > > follows:
> > > >
> > > > Connection conn = getConnection();
> > > >
> > > > stmt = conn.createStatement();
> > > >
> > > > stmt.execute("set identity_insert mcsp_test on");
> > > >
> > > > stmt.close();
> > > >
> > > >
> > > >
> > > > Although the set statment was executed successfully, when the
> > > persistence
> > > > broker issued the insert command, it still failed.
> > > >
> > > > afterInsert
> > > >
> > > > 1057255340516|0|1|statement||set identity_insert mcsp_test on
> > > >
> > > > 1057255340516|0|0|batch|INSERT INTO mcsp_test (id,col1) VALUES
> (?,?)
> > > |INSERT
> > > > INTO mcsp_test (id,col1) VALUES ('97','a13')
> > > >
> > > > 1057255340531|15|0|statement|INSERT INTO mcsp_test (id,col1)
> VALUES
> > > (?,?)
> > > > |INSERT INTO mcsp_test (id,col1) VALUES ('97','a13')
> > > >
> > > > [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] ERROR:
> > > Commit on
> > > > underlying connection failed, try to rollback
> > > >
> > > > JZ0BE: BatchUpdateException: Error occurred while executing batch
> > > statement:
> > > > Explicit value specified for identity field in table 'mcsp_test'
> when
> > > > IDENTITY_INSERT is set to OFF.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I'm not sure why. Perhaps it was issued on another connection in
> my
> > > pool
> > > > but this still fails even for a singleton connection.
> > > >
> > > > Is there a way I can override how the persistence broker is
> > > implementing the
> > > > insert statement?
> > > >
> > > > Or is there a way I can customize the insert statement to issue a
> "set
> > > > command"?
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > ---
PersistenceBrokerImpl.delete()
I posted this (twice) to the DEV list, but never saw it come through PB keeps a list of objects that are marked for delete, and avoids deleting them twice. 1) Shouldn't this be a set, for perfomance reasons. 2) Should this be based on Identity, rather than on the object (and it's equals method) itself? David This message contains information from Equifax Inc. which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OJB 1.0 r3:Tutorial 1 : PersistentFieldClass and PersistentFieldDefaultImpl bug/Issue
Hi, > -Original Message- > From: Ajitesh Das [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2003 11:12 AM > To: [EMAIL PROTECTED] > Subject: OJB 1.0 r3:Tutorial 1 : PersistentFieldClass and > PersistentFieldDefaultImpl bug/Issue > > > If I have understood correctly, this > PersistentFieldDefaultImpl uses java > bean introspection > to determine the accessors and mutators. No! PersistentFieldDefault impl does not use JavaBeans introspection! > Here are steps I did: > My persistable Test object contains following properties : > int id; > int age; > int height; > Here is the snap shot of my Test table in DB: > id age height > 112 134 > 217 166 > 322 190 > My OJB.properties: I am using > PersistentFieldClass=org.apache.ojb.broker.metadata.fieldacces > s.PersistentFi > eldPropertyImpl > > I would like to retrieve obj with id = 2, so I wrote following code : > Test example = new Test(); > example.setId(2); > Query query = new QueryByCriteria(example); > broker.beginTransaction(); > Test toBeEdited = (Test) broker.getObjectByQuery(query); > And I am getting NULL.<<>> > If I change the DB Table with > id age height > 112 134 > 20 0 > 322 190 > I am getting/able to retrieve the obj with id = 2. > > I have realized that broker.getObjectByQuery() is issueing SQL > as SELECT * FROM TEST WHERE ID=2 & AGE=0 & HEIGHT=0; > [ please note, in the code, I have only set the ID similar to > the TUTORIAL 1 > update Product code ] > > Where as I am expecting SQL like > SELECT * FROM TEST WHERE ID=2; > [ since I have only set the ID and NOTHING else] > > Am I expecting something wrong ? Yes! new QueryByCriteria(example) produces a query that takes *all* non null values of the object to generate the query. (from the JavaDocs: public QueryByCriteria(java.lang.Object anObject) Build a Query based on anObject all non null values are used as EqualToCriteria ) If you want tbuild queries that only use the primary key columns you should use: new QueryByIdentity(example); cheers, Thomas > Or this is a OJB bug in PersistentFieldDefaultImpl code. > > thanks > aj > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE : RE : How to insert a long / FK nullable with a null value ?
That's great (one more time) !! Thanks a lot ! -Message d'origine- De : Bram Meijboom [mailto:[EMAIL PROTECTED] Envoyé : mardi 8 juillet 2003 14:24 À : 'OJB Users List' Objet : RE: RE : How to insert a long / FK nullable with a null value ? yeps, works correctly, due to the reflection methods the "long" is actually converted to "Long" eg in the auto-increment functionallity of OJB. I have written everyting in objects in stead of primitives to be able to use "nulls" in the database and be somewhat more flexible. dunno if it has some performance inpact. if you encounter any problems with the conversion of the database type to the java type you can always use a "home made" FieldConversion to do it the right way. (done it my self with Strings and Clobs in oracle, dont use the oracle driver but a 3e party driver and it works great) -Original Message- From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 2:12 PM To: 'OJB Users List' Subject: RE : How to insert a long / FK nullable with a null value ? Yes, it works, but I wonder if everything will be fine, because of the jdbc conversion type. It is specified in the OJB documentation that a jdbc BIGINT is mapped to a long, could I really use Long safety ? -Message d'origine- De : Bram Meijboom [mailto:[EMAIL PROTECTED] Envoyé : mardi 8 juillet 2003 12:36 À : 'OJB Users List' Objet : RE: How to insert a long / FK nullable with a null value ? make it a Long object and set it to null -Original Message- From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 12:33 PM To: OJB Users List Subject: How to insert a long / FK nullable with a null value ? All, I have a table with a Foreign Key witch is null able. The JDO's java object's attribute associated to this table's column is a "long". My trouble is that OJB insert "0" each time nothing is specified in the JDO attribute. But '0' is not a good thing for my application; I would like to have null value. But how could I have a null value with a long type ?? Thanks a lot! - 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]
RE: RE : How to insert a long / FK nullable with a null value ?
yeps, works correctly, due to the reflection methods the "long" is actually converted to "Long" eg in the auto-increment functionallity of OJB. I have written everyting in objects in stead of primitives to be able to use "nulls" in the database and be somewhat more flexible. dunno if it has some performance inpact. if you encounter any problems with the conversion of the database type to the java type you can always use a "home made" FieldConversion to do it the right way. (done it my self with Strings and Clobs in oracle, dont use the oracle driver but a 3e party driver and it works great) -Original Message- From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 2:12 PM To: 'OJB Users List' Subject: RE : How to insert a long / FK nullable with a null value ? Yes, it works, but I wonder if everything will be fine, because of the jdbc conversion type. It is specified in the OJB documentation that a jdbc BIGINT is mapped to a long, could I really use Long safety ? -Message d'origine- De : Bram Meijboom [mailto:[EMAIL PROTECTED] Envoyé : mardi 8 juillet 2003 12:36 À : 'OJB Users List' Objet : RE: How to insert a long / FK nullable with a null value ? make it a Long object and set it to null -Original Message- From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 12:33 PM To: OJB Users List Subject: How to insert a long / FK nullable with a null value ? All, I have a table with a Foreign Key witch is null able. The JDO's java object's attribute associated to this table's column is a "long". My trouble is that OJB insert "0" each time nothing is specified in the JDO attribute. But '0' is not a good thing for my application; I would like to have null value. But how could I have a null value with a long type ?? Thanks a lot! - 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]
RE : How to insert a long / FK nullable with a null value ?
Yes, it works, but I wonder if everything will be fine, because of the jdbc conversion type. It is specified in the OJB documentation that a jdbc BIGINT is mapped to a long, could I really use Long safety ? -Message d'origine- De : Bram Meijboom [mailto:[EMAIL PROTECTED] Envoyé : mardi 8 juillet 2003 12:36 À : 'OJB Users List' Objet : RE: How to insert a long / FK nullable with a null value ? make it a Long object and set it to null -Original Message- From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 12:33 PM To: OJB Users List Subject: How to insert a long / FK nullable with a null value ? All, I have a table with a Foreign Key witch is null able. The JDO's java object's attribute associated to this table's column is a "long". My trouble is that OJB insert "0" each time nothing is specified in the JDO attribute. But '0' is not a good thing for my application; I would like to have null value. But how could I have a null value with a long type ?? Thanks a lot! - 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]
RE: How to insert a long / FK nullable with a null value ?
make it a Long object and set it to null -Original Message- From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 12:33 PM To: OJB Users List Subject: How to insert a long / FK nullable with a null value ? All, I have a table with a Foreign Key witch is null able. The JDO's java object's attribute associated to this table's column is a "long". My trouble is that OJB insert "0" each time nothing is specified in the JDO attribute. But '0' is not a good thing for my application; I would like to have null value. But how could I have a null value with a long type ?? Thanks a lot! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to insert a long / FK nullable with a null value ?
All, I have a table with a Foreign Key witch is null able. The JDO's java object's attribute associated to this table's column is a "long". My trouble is that OJB insert "0" each time nothing is specified in the JDO attribute. But '0' is not a good thing for my application; I would like to have null value. But how could I have a null value with a long type ?? Thanks a lot!
Re: OJB 1.0 r3:Tutorial 1 : PersistentFieldClass andPersistentFieldDefaultImpl bug/Issue
Here it's a java thing.
When you initialize your Object Test() its int fields will be instantiated with their
default value, in your code 0.
If you want to retrieve your record with id 2, I suggest you use a
Criteria.addEqualTo() method.
Criteria criteria = new Criteria();
criteria.addEqualTo("id", new Integer(2));
QueryByCriteria query = new QueryByCriteria(Test.class, criteria);
then you can retrieve your object with the broker.
Christophe
Message du 08/07/03 11:12
De : Ajitesh Das
A : [EMAIL PROTECTED]
Copie à :
Objet : OJB 1.0 r3:Tutorial 1 : PersistentFieldClass and PersistentFieldDefaultImpl
bug/Issue
If I have understood correctly, this PersistentFieldDefaultImpl uses java
bean introspection
to determine the accessors and mutators.
Here are steps I did:
My persistable Test object contains following properties :
int id;
int age;
int height;
Here is the snap shot of my Test table in DB:
id age height
1 12 134
2 17 166
3 22 190
My OJB.properties: I am using
PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFi
eldPropertyImpl
I would like to retrieve obj with id = 2, so I wrote following code :
Test example = new Test();
example.setId(2);
Query query = new QueryByCriteria(example);
broker.beginTransaction();
Test toBeEdited = (Test) broker.getObjectByQuery(query);
And I am getting NULL.<<>>
If I change the DB Table with
id age height
1 12 134
2 0 0
3 22 190
I am getting/able to retrieve the obj with id = 2.
I have realized that broker.getObjectByQuery() is issueing SQL
as SELECT * FROM TEST WHERE ID=2 & AGE=0 & HEIGHT=0;
[ please note, in the code, I have only set the ID similar to the TUTORIAL 1
update Product code ]
Where as I am expecting SQL like
SELECT * FROM TEST WHERE ID=2;
[ since I have only set the ID and NOTHING else]
Am I expecting something wrong ?
Or this is a OJB bug in PersistentFieldDefaultImpl code.
thanks
aj
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB 1.0 r3:Tutorial 1 : PersistentFieldClass and PersistentFieldDefaultImpl bug/Issue
Hi, please see comment below. On Tue, Jul 08, 2003 at 02:12:12AM -0700, Ajitesh Das wrote: > If I have understood correctly, this PersistentFieldDefaultImpl uses java > bean introspection > to determine the accessors and mutators. > Here are steps I did: > My persistable Test object contains following properties : > int id; > int age; > int height; > Here is the snap shot of my Test table in DB: > id age height > 112 134 > 217 166 > 322 190 > My OJB.properties: I am using > PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFi > eldPropertyImpl > > I would like to retrieve obj with id = 2, so I wrote following code : > Test example = new Test(); > example.setId(2); > Query query = new QueryByCriteria(example); > broker.beginTransaction(); > Test toBeEdited = (Test) broker.getObjectByQuery(query); > And I am getting NULL.<<>> > If I change the DB Table with > id age height > 112 134 > 20 0 > 322 190 > I am getting/able to retrieve the obj with id = 2. > > I have realized that broker.getObjectByQuery() is issueing SQL > as SELECT * FROM TEST WHERE ID=2 & AGE=0 & HEIGHT=0; > [ please note, in the code, I have only set the ID similar to the TUTORIAL 1 > update Product code ] > > Where as I am expecting SQL like > SELECT * FROM TEST WHERE ID=2; > [ since I have only set the ID and NOTHING else] Imho there is no way for OJB to know whether you set the age an height fields or not, since global primitives per definition are initialized to value 0. I think using Integers instead of int's should fix the problem, with age==null and height==null they should be ignored when the statement is generated. hth, Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OJB 1.0 r3:Tutorial 1 : PersistentFieldClass and PersistentFieldDefaultImpl bug/Issue
If I have understood correctly, this PersistentFieldDefaultImpl uses java bean introspection to determine the accessors and mutators. Here are steps I did: My persistable Test object contains following properties : int id; int age; int height; Here is the snap shot of my Test table in DB: id age height 112 134 217 166 322 190 My OJB.properties: I am using PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFi eldPropertyImpl I would like to retrieve obj with id = 2, so I wrote following code : Test example = new Test(); example.setId(2); Query query = new QueryByCriteria(example); broker.beginTransaction(); Test toBeEdited = (Test) broker.getObjectByQuery(query); And I am getting NULL.<<>> If I change the DB Table with id age height 112 134 20 0 322 190 I am getting/able to retrieve the obj with id = 2. I have realized that broker.getObjectByQuery() is issueing SQL as SELECT * FROM TEST WHERE ID=2 & AGE=0 & HEIGHT=0; [ please note, in the code, I have only set the ID similar to the TUTORIAL 1 update Product code ] Where as I am expecting SQL like SELECT * FROM TEST WHERE ID=2; [ since I have only set the ID and NOTHING else] Am I expecting something wrong ? Or this is a OJB bug in PersistentFieldDefaultImpl code. thanks aj - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
