RE: FW: NetBeans and OJB
Well, I develop and setup my small test application from scratch. There is one persistent class, a Test class which has main method, OJB.properties, repository.xml and repository.dtd. It all goes well but when I change Executor to Internal Execution it generates some warnings and exceptions as follows: [BOOT] WARN: Value org.apache.ojb.broker.cache.ObjectCacheDefaultImpl is illegal for key ObjectCacheClass (should be a class, using default value class org.apache.ojb.broker.cache.ObjectCacheDefaultImpl) [BOOT] WARN: Value org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl is illegal for key ConnectionFactoryClass (should be a class, using default value class org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl) [BOOT] WARN: Value org.apache.ojb.odmg.locking.LockManagerDefaultImpl is illegal for key LockManagerClass (should be a class, using default value class org.apache.ojb.odmg.locking.LockManagerDefaultImpl) [BOOT] WARN: Value org.apache.ojb.odmg.locking.InMemoryLockMapImpl is illegal for key LockMapClass (should be a class, using default value class org.apache.ojb.odmg.locking.PersistentLockMapImpl) [BOOT] WARN: Value org.apache.ojb.broker.util.logging.PoorMansLoggerImpl is illegal for key LoggerClass (should be a class, using default value class org.apache.ojb.broker.util.logging.PoorMansLoggerImpl) [BOOT] WARN: Value org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessI mpl is illegal for key PersistentFieldClass (should be a class, using default value class org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessIm pl) [BOOT] WARN: Value org.apache.ojb.broker.core.PersistenceBrokerImpl is illegal for key PersistenceBrokerClass (should be a class, using default value class org.apache.ojb.broker.core.PersistenceBrokerImpl) [BOOT] WARN: Value org.apache.ojb.odmg.collections.DListImpl_2 is illegal for key OqlCollectionClass (should be a class, using default value class org.apache.ojb.odmg.collections.DListImpl) [BOOT] WARN: Value org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl is illegal for key PersistenceBrokerFactoryClass (should be a class, using default value null) [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object java.lang.ExceptionInInitializerError at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker( Unknown Source) at kict.Test.main(Test.java:11) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.openide.execution.ThreadExecutor.executeClass(ThreadExecutor.java:11 6) at org.openide.execution.ThreadExecutor$TERunnable.run(ThreadExecutor.java: 183) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:118) Caused by: org.apache.ojb.broker.OJBRuntimeException: Property for key 'PersistenceBrokerFactoryClass' can not be found in properties file at org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.clinit(Unkn own Source) ... 9 more Following is the first line of my main method: System.setProperty(OJB.properties, c:/work/test/OJB.properties); Following is the line from OJB.properties: repositoryFile=c:/work/test/repository.xml Following segment has been taken from repository.xml: !DOCTYPE descriptor-repository PUBLIC -//Apache Software Foundation//DTD OJB Repository//EN file:///c:/work/test/repository.dtd One thing is to remember that it goes well when Executor is External. I am will be thankful if someone gives me a solution. I have also used Oracle TopLink and was really happy with that. I am really disappointing to think that I've wasted 1 week just to setup that small application. Regards Aamir -Original Message- From: Edson Carlos Ericksson Richter [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 6:47 PM To: OJB Users List Subject: Re: FW: NetBeans and OJB Hi! I could answer you question. In NetBeans, go to Tools - Options - Debbuging and Executing - Execution Types - External Execution - Expert - Working Directory. Unfortunately, there is no equivalent option for Internal Execution (but the default execution for NetBeans apps is External Execution). In Internal Execution mode, the Working Directory is the NetBeans bin directory. So, if you need to use Internal Execution, you should set complete path for repository/ojb.properties. I sugest you to use External Execution, and set Working Directory (to avoid annoiances). I've collected these info in more than a year working with OJB inside NetBeans. Best regards, Edson Richter - Original Message -
[Fwd: How to call a select store procedure in OJB]
Original Message Subject:How to call a select store procedure in OJB Date: Fri, 9 Jan 2004 14:56:15 -0800 (PST) From: Suma Venkatesh [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi Iam working on using store procedures using OJB. I want to call a store procedure which selects a number of items from a table Product.I want to be able to use a store procedure to do this and not a simple select and query by collection. I checked the repository.dtd which defines no such element. Is there a way to acheive this in OJB ? thanks in advance, suma Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/mail_footer_email/evt=21482/*http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error parsing repository.xml
Hi Larry, hmm, stack trace says: Caused by: org.apache.ojb.broker.metadata.MetadataException: Can not read repository class descriptor data, using repository: repository_user.xml and [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: class-descriptor [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: isolation-level: null Seems your parser returns 'null' when attribute is not set or do you set the class-descriptor 'isolation-level' attribute? RepositoryXmlHandler does not check for 'null', seems other parser return an empty string instead of 'null'. Will check in a fix ASAP. regards, Armin Larry V. Streepy, Jr. wrote: Please ignore the last posting, it was the same file by mistake :-( The attached file contains the stack trace with debug information enabled. Thanks. Larry V. Streepy, Jr. wrote: I've got a very strange error cropping up when I try to run a simple test program for OJB. Note that I can build and execute the JUnit tests using the distribution and things work fine. However, when I construct a simple batch file to include all the jar files from the ojb lib directory and add in the directory that contains the properties files I get a NullPointer exception during the parse due to isolation-level being null. Now this appears to be an internal table lookup, so I'm not sure how it can fail. Also, I copied the repository.xml file from the OJB distribution as my starting point, so the isolation-level attribute is being properly specified. I've attached the debug output and the exception trace below. Any help or insights would be appreciated. Thanks. -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc. [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: startDoc [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:class-descriptor [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: isolation-level: null java.lang.ExceptionInInitializerError at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefaultKey(PersistenceBrokerFactoryBaseImpl.java:114) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker(PersistenceBrokerFactoryBaseImpl.java:196) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(PersistenceBrokerFactory.java:104) at com.staffmix.nurse.play.Application.init(Application.java:25) at com.staffmix.nurse.play.Application.main(Application.java:56) Caused by: org.apache.ojb.broker.metadata.MetadataException: Can not read repository class descriptor data, using repository: repository_user.xml at org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:135) at org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:121) at org.apache.ojb.broker.metadata.MetadataManager.clinit(MetadataManager.java:110) ... 5 more Caused by: org.apache.ojb.broker.metadata.MetadataException: Exception when reading metadata information, please check your repository.xml file at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(RepositoryXmlHandler.java:953) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.ojb.broker.metadata.RepositoryPersistor.readMetadataFromXML(RepositoryPersistor.java:343) at org.apache.ojb.broker.metadata.RepositoryPersistor.buildRepository(RepositoryPersistor.java:300) at org.apache.ojb.broker.metadata.RepositoryPersistor.readDescriptorRepository(RepositoryPersistor.java:215) at org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:131) ... 7 more Caused by: java.lang.NullPointerException at org.apache.ojb.broker.metadata.RepositoryXmlHandler.getIsoLevel(RepositoryXmlHandler.java:1174) at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(RepositoryXmlHandler.java:223) ... 21 more
Re: error parsing repository.xml
Hi again, maybe the problem could be the isolation-level set on descriptor-repository element level (repository.xml file), this level is used as default level in class-descriptor. Do you set isolation-level attribute on this level? How does your repository.xml file look like? Should be something like that: descriptor-repository version=1.0 isolation-level=read-uncommitted proxy-prefetching-limit=50 !-- include all used database connections -- database; !-- include ojb internal mappings here -- internal; !-- include user defined mappings here -- user; /descriptor-repository It's also possible to include all mappings in the repository.xml file without using !ENTITY-references. When I run in debug mode I get [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: startDoc [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: proxy-prefetching-limit: 50 [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: descriptor-repository ... You get: [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: startDoc [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: class-descriptor [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: isolation-level: null java.lang.ExceptionInInitializerError regards, Armin Armin Waibel wrote: Hi Larry, hmm, stack trace says: Caused by: org.apache.ojb.broker.metadata.MetadataException: Can not read repository class descriptor data, using repository: repository_user.xml and [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: class-descriptor [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: isolation-level: null Seems your parser returns 'null' when attribute is not set or do you set the class-descriptor 'isolation-level' attribute? RepositoryXmlHandler does not check for 'null', seems other parser return an empty string instead of 'null'. Will check in a fix ASAP. regards, Armin Larry V. Streepy, Jr. wrote: Please ignore the last posting, it was the same file by mistake :-( The attached file contains the stack trace with debug information enabled. Thanks. Larry V. Streepy, Jr. wrote: I've got a very strange error cropping up when I try to run a simple test program for OJB. Note that I can build and execute the JUnit tests using the distribution and things work fine. However, when I construct a simple batch file to include all the jar files from the ojb lib directory and add in the directory that contains the properties files I get a NullPointer exception during the parse due to isolation-level being null. Now this appears to be an internal table lookup, so I'm not sure how it can fail. Also, I copied the repository.xml file from the OJB distribution as my starting point, so the isolation-level attribute is being properly specified. I've attached the debug output and the exception trace below. Any help or insights would be appreciated. Thanks. -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc. [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: startDoc [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: class-descriptor [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: isolation-level: null java.lang.ExceptionInInitializerError at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefaultKey(PersistenceBrokerFactoryBaseImpl.java:114) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker(PersistenceBrokerFactoryBaseImpl.java:196) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(PersistenceBrokerFactory.java:104) at com.staffmix.nurse.play.Application.init(Application.java:25) at com.staffmix.nurse.play.Application.main(Application.java:56) Caused by: org.apache.ojb.broker.metadata.MetadataException: Can not read repository class descriptor data, using repository: repository_user.xml at org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:135) at org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:121) at org.apache.ojb.broker.metadata.MetadataManager.clinit(MetadataManager.java:110) ... 5 more Caused by: org.apache.ojb.broker.metadata.MetadataException: Exception when reading metadata information, please check your repository.xml file at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(RepositoryXmlHandler.java:953) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at
Re: ODMG Update Collection Problem
- Original Message -
From: Armin Waibel [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Friday, January 09, 2004 10:32 AM
Subject: Re: ODMG Update Collection Problem
Hi,
Ralf Geiger wrote:
Hi,
According to the mailing list I know that lots of people have similar
problems...but there is no real solution for it. For me OJB works fine..
except one thing: Updating a 1:N Collection of Elements.
I am using OJB RC5 ODMG-API with mySQL
My Problem:
I am having a 1:N relationship between A and B.
So A has a Collection of Bs.
B has one id which is the foreign-key (aid) and a reference to the
A-Object where B belongs to (refToA).
Updating B works fine like this:
tx.begin()
// Get newA from DB using PersistenceBroker
toBeSavedA.setAid( newA.getAid() );
tobeSavedA.setRefToA( newA );
tx.commit();
So now the Problem is updating the Collection of B-Objects
Lets say a1 has already 2 B-Objects within the collection (b1 and b2):
Now I want to update the Collection and put the Objects (b3 and b4) into
it - b3 and b4 are already existing in the DB just belong to a2.
The situation:
a1{b1,b2}, a2{b3,b4} --- a1{b3,b4}, a2{}, (b1 and b2 have null
references to any A-Object)
Do you lookup a1, a2 via PB-api too? If so, do you lock them before
starting your modification?
regards,
Armin
Yeah, every Object I have has been loaded via PB-API.
My Applicationflow looks like this (web-application using Struts, running in
Tomcat):
1. Action: using PB-API to get all A-Objects and put them into Session-Scope
2. JSP: Show all A-Objects and referenced Bs.. just to see which Bs are
pointing to which a.
3. User Interaction: Edit a1
4. EditAction: using PB-API to get all possible B-Objects so that the User
can define which B-Objects he wants.
5. JSP: Show a1 and a List of B-Objects where he can choose... Let's say he
chose the b3 and b4
6. SaveAction: I get the Object a1 (toBeSaved), the b3 and b4 from the DB
(PB-API) (could have got it from the session-scope bean as well)
7. Now I begin the transaction and lock the toBeSaved-Object...
8. make the changes and commit..
that's all..
regards,
Ralf
If I am not mistaken the steps OJB takes should look like this:
1. Delete the references of b1 (aid=null and refToA=null) and b2 which
are pointing to a1
2. Update the references of b3 and b4 so that they point to a1.
3. Update the Collection of a2 because b3 and b4 are not in the
collection of a2 anymore.
4 Update the Collection of a1: delete the references to b1 and b2 and
fill the collection with b3 and b4.
commit;
I tried several Collections (java.util.Vector, ManageableVector,
ManageableArrayList, DListImpl)
but nothing works.
basically it for me it looks like this:
tx.begin()
// Get the Collection of new Bs with
PersistenceBroker.getCollectionByQuery(B.class, crit) so I get this
Collection: newColOfB{b3,b4}
// Get the Collection of a1:
ManageableArrayList list = a1.getColOfB();
// now update the list:
list.retainAll( newColOfB );
tx.commit();
But nothing has been updated in the DB..
What is it ?? Can somebody please point out how to solve this problem ?
I really lost my nerves. Do I really have to update all references by
myselfe ??
Or am I just too stupid ? It works fine with m:n relationships.. just
setting the new collection..
Thanks for your help,
Ralf Geiger
-
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: join and retrieve single object?
Daniel -- The Query interface defines a setDistinct(boolean) method. Set this to true and you should see better results. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] -Original Message- From: Daniel Perry [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 9:41 AM To: OJB Users List Subject: join and retrieve single object? I want to query the database and retrieve a specific manager, and only their employees whoose training (boolean) matches the requirement. Instead of getting one manager with the x (out of y) employees, i get x managers. My code is: (getObjectsByType) is just a query by criteria shortcut. Criteria crit = new Criteria(); crit.addEqualTo(id, new Integer(managerId)); crit.addEqualTo(employees.training, new Boolean(training)); List mgrs = getObjectsByType(Manager.class.getName(), crit); System.out.println(MANAGERS FOUND: + Integer.toString(mgrs.size())); Is there any way to get just the one manager? Daniel. - 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: FW: NetBeans and OJB
Hi Aamir, first, the following lines can be completely nonsense (never used Netbean, don't have a clue in ClassLoader problematic ;-)) But this sounds like a typical ClassLoader problem. On OJB startup the classes specified in OJB.properties file are loaded. Maybe the OJB config files or/and OJB jars use wrong/different ClassLoader. Maybe you need to notify netbean to include OJB jars(+ used jars) in Internal Execution mode ClassLoader, or you need to move this jars in a directory included by the netbeans Internal ClassLoader. Or does netbeans read the jars two times by different ClassLoader. regards, Armin Muhammad Aamir wrote: Well, I develop and setup my small test application from scratch. There is one persistent class, a Test class which has main method, OJB.properties, repository.xml and repository.dtd. It all goes well but when I change Executor to Internal Execution it generates some warnings and exceptions as follows: [BOOT] WARN: Value org.apache.ojb.broker.cache.ObjectCacheDefaultImpl is illegal for key ObjectCacheClass (should be a class, using default value class org.apache.ojb.broker.cache.ObjectCacheDefaultImpl) [BOOT] WARN: Value org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl is illegal for key ConnectionFactoryClass (should be a class, using default value class org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl) [BOOT] WARN: Value org.apache.ojb.odmg.locking.LockManagerDefaultImpl is illegal for key LockManagerClass (should be a class, using default value class org.apache.ojb.odmg.locking.LockManagerDefaultImpl) [BOOT] WARN: Value org.apache.ojb.odmg.locking.InMemoryLockMapImpl is illegal for key LockMapClass (should be a class, using default value class org.apache.ojb.odmg.locking.PersistentLockMapImpl) [BOOT] WARN: Value org.apache.ojb.broker.util.logging.PoorMansLoggerImpl is illegal for key LoggerClass (should be a class, using default value class org.apache.ojb.broker.util.logging.PoorMansLoggerImpl) [BOOT] WARN: Value org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessI mpl is illegal for key PersistentFieldClass (should be a class, using default value class org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessIm pl) [BOOT] WARN: Value org.apache.ojb.broker.core.PersistenceBrokerImpl is illegal for key PersistenceBrokerClass (should be a class, using default value class org.apache.ojb.broker.core.PersistenceBrokerImpl) [BOOT] WARN: Value org.apache.ojb.odmg.collections.DListImpl_2 is illegal for key OqlCollectionClass (should be a class, using default value class org.apache.ojb.odmg.collections.DListImpl) [BOOT] WARN: Value org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl is illegal for key PersistenceBrokerFactoryClass (should be a class, using default value null) [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object java.lang.ExceptionInInitializerError at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker( Unknown Source) at kict.Test.main(Test.java:11) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.openide.execution.ThreadExecutor.executeClass(ThreadExecutor.java:11 6) at org.openide.execution.ThreadExecutor$TERunnable.run(ThreadExecutor.java: 183) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:118) Caused by: org.apache.ojb.broker.OJBRuntimeException: Property for key 'PersistenceBrokerFactoryClass' can not be found in properties file at org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.clinit(Unkn own Source) ... 9 more Following is the first line of my main method: System.setProperty(OJB.properties, c:/work/test/OJB.properties); Following is the line from OJB.properties: repositoryFile=c:/work/test/repository.xml Following segment has been taken from repository.xml: !DOCTYPE descriptor-repository PUBLIC -//Apache Software Foundation//DTD OJB Repository//EN file:///c:/work/test/repository.dtd One thing is to remember that it goes well when Executor is External. I am will be thankful if someone gives me a solution. I have also used Oracle TopLink and was really happy with that. I am really disappointing to think that I've wasted 1 week just to setup that small application. Regards Aamir -Original Message- From: Edson Carlos Ericksson Richter [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 6:47 PM To: OJB Users List Subject: Re: FW: NetBeans and OJB Hi! I could answer you question. In NetBeans, go to Tools - Options - Debbuging and
Re: Fwd: Using a non-existent collection inside a query
hi edson,
[EMAIL PROTECTED] wrote:
hi edson,
frankly, i'm still confused...
Sorry... I think I don't have sufficient english skills to make more clear...
i understand that collection-proxies do not seem to help because of the
way you built your gui :(
Thanks, I think you had some experiences (some good, some bad) with swing too... But
that's not our point, right ;-)
when you say the relationship does not exist, does this mean that it's
not defined in the repository ?
Yes, I mean that this is not defined in repository. Neither the collection-descriptor,
neither the field used when querying.
i saw the sample code you posted some days ago. now it's clear how you do it.
what do you mean by mounting the query ?
Imagine the object:
public class Customer {
public Integer id;
public String name;
}
Now I load some class that will notify (internally, in my app) that a new table is
avaliable
in database (the documents table), and I can make queries by the document number. But I
don't have a document neither documentNumber in Customer class.
To query I must do
Criteria c = new Criteria();
c.addEqualTo(document.documentNumber, 12345);
But OJB will throw exception: where is no document field in Customer. So I add
dinamically a
document field as an collection descriptor. Uau, OJB now queries the database! Fine
that's
all I want.
But, when I tried to store any Customer object, OJB throw an exception saying that
there is
no document field. Even if I use proxies=true (or not), lazy=true (or not),
auto-update=false (or not) and so on. Nothing works. Always exception.
ojb needs this field (better: the collection referenced by this field) to handle
the m:n-implementors in case of an m:n-relationship.
I've detected that the problem is because OJB is trying to set key fields in
referenced
objects (including my document collection - that doesn't exists at all, is just an
artifact
to make queries) - before storing...
afaik this should only be done if getCascadeStore() is true. imo the method
storeCollections() needs some refactoring to separate handling of
m:n-implementors, but that's another issue.
what other parts of ojb did you need to modify to achieve this behaviour ?
None. Just that if does the job. I had think a lot about this, and I get the
conclusion that
OJB should not set keys in referenced object when auto-update=false, right? Or not?
As long as I don't want do change any default behavior of OJB, I've created the virtual
attribute, and used it...
jakob
Thanks again,
Edson Richter
-
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: FW: NetBeans and OJB
Hi! Just more 2c: When running app in NetBeans using Internal Execution Mode, it always set working directory to %NETBEANS_HOME%\bin (hipotetical path - adapt to your OS of preference). I don't know if there is a way to change this programmatically, and you can have trouble with this kind of setting due to security of Java when deploying your app. The only way (using default NetBeans options, withou hacking anything) to specify a user working directory (where your .properties, .xml and so on are) is using the External Execution Mode. About the JARs (as Armin mentioned), I assume that you have mounted all OJB .jar files in your NetBeans file systems, right? That's all. It work like a charm... AFAIK, there is no separated classloader (just for laughs: some time ago, I have created an Swing component that when diabled, if take the container it was inside, and disable too, then, the container of the container and disable too, and so on. The first time I used the component in a form using the Visual From Editor, and set Enabled=false, I've disabled all NetBeans interface!!! Yes, the Visual Form Editor was running my component inside the NetBeans environment! :D). Of course, if you use External Execution, there is a separate VM and so a separated ClassLoader, but in this case, you have the option to configure the working directory. But the settings for OJB.properties system variable should work too... Ah, a lamp has turn on in my mind: may be NetBeans is putting their own classpath in from of your filesystem jars... In this case, you can have trouble with conflicts or buggy XML parsers, ant, servlet, and so on (the ones used by default in NetBeans sometime are little old - as example, the latest NetBeans still came with Tomcat 4.0.6). Best regards, Edson Richter Hi Aamir, first, the following lines can be completely nonsense (never used Netbean, don't have a clue in ClassLoader problematic ;-)) But this sounds like a typical ClassLoader problem. On OJB startup the classes specified in OJB.properties file are loaded. Maybe the OJB config files or/and OJB jars use wrong/different ClassLoader. Maybe you need to notify netbean to include OJB jars(+ used jars) in Internal Execution mode ClassLoader, or you need to move this jars in a directory included by the netbeans Internal ClassLoader. Or does netbeans read the jars two times by different ClassLoader. regards, Armin Muhammad Aamir wrote: Well, I develop and setup my small test application from scratch. There is one persistent class, a Test class which has main method, OJB.properties, repository.xml and repository.dtd. It all goes well but when I change Executor to Internal Execution it generates some warnings and exceptions as follows: [BOOT] WARN: Value org.apache.ojb.broker.cache.ObjectCacheDefaultImpl is illegal for key ObjectCacheClass (should be a class, using default value class org.apache.ojb.broker.cache.ObjectCacheDefaultImpl) [BOOT] WARN: Value org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl is illegal for key ConnectionFactoryClass (should be a class, using default value class org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl) [BOOT] WARN: Value org.apache.ojb.odmg.locking.LockManagerDefaultImpl is illegal for key LockManagerClass (should be a class, using default value class org.apache.ojb.odmg.locking.LockManagerDefaultImpl) [BOOT] WARN: Value org.apache.ojb.odmg.locking.InMemoryLockMapImpl is illegal for key LockMapClass (should be a class, using default value class org.apache.ojb.odmg.locking.PersistentLockMapImpl) [BOOT] WARN: Value org.apache.ojb.broker.util.logging.PoorMansLoggerImpl is illegal for key LoggerClass (should be a class, using default value class org.apache.ojb.broker.util.logging.PoorMansLoggerImpl) [BOOT] WARN: Value org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessI mpl is illegal for key PersistentFieldClass (should be a class, using default value class org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessIm pl) [BOOT] WARN: Value org.apache.ojb.broker.core.PersistenceBrokerImpl is illegal for key PersistenceBrokerClass (should be a class, using default value class org.apache.ojb.broker.core.PersistenceBrokerImpl) [BOOT] WARN: Value org.apache.ojb.odmg.collections.DListImpl_2 is illegal for key OqlCollectionClass (should be a class, using default value class org.apache.ojb.odmg.collections.DListImpl) [BOOT] WARN: Value org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl is illegal for key PersistenceBrokerFactoryClass (should be a class, using default value null) [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object java.lang.ExceptionInInitializerError at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker( Unknown Source) at kict.Test.main(Test.java:11) at
Re: Fwd: Using a non-existent collection inside a query
i saw the sample code you posted some days ago. now it's clear how you do it. The first step ;-) ojb needs this field (better: the collection referenced by this field) to handle the m:n-implementors in case of an m:n-relationship. That's just the case. If I use the artifact of virtual, the real field is no needed. It will never be read neither writeen to database. Just referenced when querying the database. afaik this should only be done if getCascadeStore() is true. imo the method storeCollections() needs some refactoring to separate handling of m:n-implementors, but that's another issue. The setting of the keys in referenced objects are occurring always. That why I need to put the line with if command in PersistenceBrokerImpl storeCollections method. I've not tried this with M:N, but sometime in the future I will check it (as far as the users get accostumed with this kind of facility, they wants more!). jakob Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
hi edson, [EMAIL PROTECTED] wrote: i saw the sample code you posted some days ago. now it's clear how you do it. The first step ;-) ojb needs this field (better: the collection referenced by this field) to handle the m:n-implementors in case of an m:n-relationship. That's just the case. If I use the artifact of virtual, the real field is no needed. It will never be read neither writeen to database. Just referenced when querying the database. afaik this should only be done if getCascadeStore() is true. imo the method storeCollections() needs some refactoring to separate handling of m:n-implementors, but that's another issue. The setting of the keys in referenced objects are occurring always. That why I need to put the line with if command in PersistenceBrokerImpl storeCollections method. i do not see where this happens ? jakob I've not tried this with M:N, but sometime in the future I will check it (as far as the users get accostumed with this kind of facility, they wants more!). jakob Edson Richter - 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: Fwd: Using a non-existent collection inside a query
i do not see where this happens ?
Here (note: the if(!true.equals( bellow is in my patched version of OJB that is
working
fine):
...
private void storeCollections(Object obj, Vector vecCds) throws
PersistenceBrokerException
{
// get all members of obj that are collections and store all their elements
Iterator i = vecCds.iterator();
while (i.hasNext())
{
CollectionDescriptor cds = (CollectionDescriptor) i.next();
if(!true.equals(cds.getAttribute(virtual))) {
Object col = cds.getPersistentField().get(obj);
Collection currentMtoNKeys = null;
if (col == null)
{
if (cds.isMtoNRelation())
{
deleteMtoNImplementor(cds, obj);
}
}
...
Edson Richter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
Interesting is that this code is right (will only occur if cds.getCascadeStore()
returns true):
private void storeCollectionObject(CollectionDescriptor cds, Object otherObject)
{
// if cascade store: store associated object
if (cds.getCascadeStore())
{
store(otherObject);
}
else
{
if(logger.isEnabledFor(Logger.INFO)) logger.info(Cascade store for this
collection-descriptor ( + cds.getAttributeName()
+ ) was set to false.);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
Really, executing again withou my patch, I've seen that is not the keys, but the field it self. Sorry... The line getting in trouble is Object col = cds.getPersistentField().get(obj); because there is no persistent field at all. I'm a bit lost in too much code, techs, newbie programmers, and so on here... I think 1) if we use getCascadeDelete != true early, we can have trouble with M:N relationships; 2) if we use later, we get a non existent property exception because the field just don't exist in the bean. As far as I can see, this is the way the virtual attribute affect the OJB behavior. Thanks, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error parsing repository.xml
It turns out that my application was picking up an old repository.xml, one that was actually just the user fragment. So, it started with a class-descriptor. Since there was no DTD declared in the file, there was no default value for isolation-level and, thus, the parser returned null. Definitely an error on my part, but until I recompiled the code with debugging on, I didn't even get an error message telling me what was wrong with the file. So, I think that a change to trap and report null values in the parsing would be very helpful. Thanks for looking into this. Armin Waibel wrote: Hi again, maybe the problem could be the isolation-level set on descriptor-repository element level (repository.xml file), this level is used as default level in class-descriptor. Do you set isolation-level attribute on this level? How does your repository.xml file look like? Should be something like that: descriptor-repository version="1.0" isolation-level="read-uncommitted" proxy-prefetching-limit="50" !-- include all used database connections -- database; !-- include ojb internal mappings here -- internal; !-- include user defined mappings here -- user; /descriptor-repository It's also possible to include all mappings in the repository.xml file without using !ENTITY-references. When I run in debug mode I get [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: startDoc [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: proxy-prefetching-limit: 50 [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: descriptor-repository ... You get: [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: startDoc [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: class-descriptor [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: isolation-level: null java.lang.ExceptionInInitializerError regards, Armin Armin Waibel wrote: Hi Larry, hmm, stack trace says: Caused by: org.apache.ojb.broker.metadata.MetadataException: Can not read repository class descriptor data, using repository: repository_user.xml and [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: class-descriptor [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: isolation-level: null Seems your parser returns 'null' when attribute is not set or do you set the class-descriptor 'isolation-level' attribute? RepositoryXmlHandler does not check for 'null', seems other parser return an empty string instead of 'null'. Will check in a fix ASAP. regards, Armin Larry V. Streepy, Jr. wrote: Please ignore the last posting, it was the same file by mistake :-( The attached file contains the stack trace with debug information enabled. Thanks. Larry V. Streepy, Jr. wrote: I've got a very strange error cropping up when I try to run a simple test program for OJB. Note that I can build and execute the JUnit tests using the distribution and things work fine. However, when I construct a simple batch file to include all the jar files from the ojb "lib" directory and add in the directory that contains the properties files I get a NullPointer exception during the parse due to "isolation-level" being null. Now this appears to be an internal table lookup, so I'm not sure how it can fail. Also, I copied the repository.xml file from the OJB distribution as my starting point, so the isolation-level attribute is being properly specified. I've attached the debug output and the exception trace below. Any help or insights would be appreciated. Thanks. -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc. [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: startDoc [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: class-descriptor [org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: isolation-level: null java.lang.ExceptionInInitializerError at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefaultKey(PersistenceBrokerFactoryBaseImpl.java:114) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker(PersistenceBrokerFactoryBaseImpl.java:196) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(PersistenceBrokerFactory.java:104) at com.staffmix.nurse.play.Application.init(Application.java:25) at com.staffmix.nurse.play.Application.main(Application.java:56) Caused by: org.apache.ojb.broker.metadata.MetadataException: Can not read repository class descriptor
Re: Real world OJB applications
Thanks. I've downloaded it and will look at it later this weekend. Is OpenEMed an example of a typical OJB application? David Forslund [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] http://OpenEMed.org (a sourceforge project) uses OJB as its default persistent store. It doesn't use all the features of OJB but has it integrated as an optional (preferred) persistent store mechanism. At 01:23 PM 1/9/2004, Sean Dockery wrote: Are there any OJB applications available with source on the web? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] David W. Forslund [EMAIL PROTECTED] Computer and Computational Sciences http://www.acl.lanl.gov/~dwf Los Alamos National Laboratory Los Alamos, NM 87545 505-663-5218FAX: 505-663-5225 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to program against the ODMG personality correctly?
I posted this right around new years, but I have not seen any responses
since then and some of these questions are still eating at me. Can anyone
provide any answers to some of the questions that I've asked?
Thanks in advance.
Sean Dockery [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hello there.
I'm fairly new to OJB. I've read several of the tutorials and I'm
working
on creating an application from scratch.
Below are three classes that I wrote. One is my DAO class, the second
class
is an inversion-of-control interface that I'm using to populate the
object
after locking it in the DAO class, and the last class is a Struts action
which using the DAO class and provides an implementation of the
UserConfigurator interface.
I was wondering if anyone could provide some feedback and opinions about
the
code. I'm mainly curious about the following:
1) The exception handling code is omitted from the examples for the sake
of
brevity. Is the manner in which I'm handling exceptions correct?
2) I've written my retrieval routine to use a persistence broker query.
Using persistence broker queries in this manner is apparently faster. In
a
reply in another thread, I read...
Philippe Hacquin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
... and they are much more efficient, too, because they use the cache.
This confuses me somewhat. Does this mean that the ODMG personality of
OJB
doesn't use caching? Or do OQL queries bypass caching?
3) I've chose to perform object deletion using the persistence broker
instead of database.deletePersistent. What is the consequence of using
one
over the other?
4) The PB transaction mechanism uses database locks. The ODMG
personality
uses object locks. Yet, the ODMG personality is less performant than the
PB
personality (according to the performance page on the web site.) Last
time
I checked, memory operations were less expensive than database I/O--so I
would have expected ODMG to out-perform PB. Can anyone explain this
apparent contradiction?
5) I've seen an application that uses OJB that performs updates directly
against the database using JDBC. I suspect that the implication is that
cached objects can become out of sync with data in the database. Does
OJB
have a means by which to detect that a row has been changed by another
user?
6) The auto-retrieve attribute must (apparently) be set to true for ODMG.
This seems a little evil in that I will always be retrieving a graph of
objects instead of the single object in which I'm interested. The
application mentioned in question 5 has severe performance problems
related
to database access; I suspect that the root of the performance problems
are
being caused by having auto-retrieve set to true for several key entities
in
the application. What happens to the behaviour of the ODMG
implementation
if auto-retrieve is set to false? (It suggests that this is a no-no on
the
web site, but doesn't elaborate on what problems will arise.) Should I
be
switching to the PB personality of OJB to avoid problems?
7) Why would I choose to use the ODMG personality over the PB
personality?
I've seen some (rather unhelpful) replies saying it depends on your
needs
and I'm looking for something a little more insightful. What does using
the
ODMG personality get me? (I'm not sure what real Object Transactions
are
supposed to be, but that is one of the reasons cited on the web site.)
Thanks very much for your precious time. It is greatly appreciated.
UserDao.java:
package catalyst.dao;
import org.apache.ojb.broker.PersistenceBroker;
import org.apache.ojb.broker.query.Criteria;
import org.apache.ojb.broker.query.Query;
import org.apache.ojb.broker.query.QueryFactory;
import org.apache.ojb.odmg.HasBroker;
import org.apache.ojb.odmg.OJB;
import org.odmg.Implementation;
import org.odmg.Transaction;
import catalyst.domain.User;
public class UserDao {
private static UserDao instance = new UserDao();
private UserDao() {
}
public static UserDao getInstance() {
return instance;
}
private User findUser(Integer userId) throws DaoException {
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.newTransaction();
tx.begin();
try {
PersistenceBroker broker = ((HasBroker) tx).getBroker();
Criteria criteria = new Criteria();
criteria.addEqualTo(userId, userId);
Query query = QueryFactory.newQuery(User.class, criteria);
User user = (User) broker.getObjectByQuery(query);
tx.commit();
return user;
}
catch (Throwable t) {
tx.abort();
throw new DaoException(t);
}
}
private void storeUser(User user, UserConfigurator configurator) throws
DaoException {
Implementation implementation = OJB.getInstance();
Transaction tx = implementation.newTransaction();
tx.begin();
try {
tx.lock(user, Transaction.WRITE);
configurator.configure(user);
tx.commit();
}
catch (Throwable t) {
tx.abort();
throw new DaoException(t);
}
}
public void
Re: Problem with reading records having a PK with value 0 (not null)
Hi Danilo,
The problem lies in the support for primitive data types, since a
primitive type cannot be null, the value 0 is interpreted as null.
It seems that non primitive data types also react the same way (even
if they shouldn't, so from my point of view it is a bug)
I checked in two tests reproduce the described problem
(PersistenceBrokerTest in test suite) and a bug fix for
BrokerHelper in CVS.
Many thanks for your detailed description and sample code.
regards,
Armin
Danilo Tommasina wrote:
Hi Armin,
here a short example.
create TABLE FOO ( TAB_ID INTEGER PRIMARY KEY )
and put an entry into the table with ID = 0 (from SQL not from OJB)
/*/
repoistory.xml
class-descriptor class=org.apache.ojb.test.Foo table=FOO
field-descriptor name=tabId column=TAB_ID jdbc-type=DECIMAL
nullable=false primarykey=true autoincrement=true /
class-descriptor/
//
public class Foo {
public Integer tabId;
//Add getter and setter
}
//
some test code
(...)
Criteria c = new Criteria();
c.addEqualTo( tabId, new Integer( 0 ) );
Query q = new QueryByCriteria( Foo.class, c );
Foo myFoo = (Foo) pb.getObjectByQuery( q );
pb.beginTransaction();
pb.store( myFoo );
pb.commitTransaction();
(...)
and now you have two entries in your database (Integer PK with value 0
was interpreded as null and a new clone has been inserted)
This is actually a minor issue, since it is not possible through OJB to
add a DB entry with a PK = 0, in this case the error will never occur.
However if you are using data inserted by other applications it is
possible to have entries with ID = 0 to work with.
sorry I didn't tested the code, I hope it works...
bye
Danilo
Hi Danilo,
Danilo Tommasina wrote:
Hi,
I reported the same issue some months ago...
The problem lies in the support for primitive data types, since a
primitive type cannot be null, the value 0 is interpreted as null.
It seems that non primitive data types also react the same way (even
if they shouldn't, so from my point of view it is a bug)
if so, I agree sounds like a bug. Can you post a test case to
reproduce the problem or describe what to do with pseudo code?
Fetching an object with ID = 0 works, however OJB will handle the 0
value as null and put the next sequence value into the fetched object
on next store or when calling a
PeristenceBroker.retrieveAllReferencies( Object obj )
For OJB 1.1 a complete refactoring of the primitive data types
handling is scheduled.
Here you can post your proposals for the upcoming 1.1 version
http://nagoya.apache.org/wiki/apachewiki.cgi?OJBProjectPages/OJBOnePointOne
The workaround is to never use IDs = 0 and this is actually what I am
doing ;)
or don't use primitive data types for PK fields in your pc objects (or
do both ;-)).
regards,
Armin
bye
Danilo
Hi,
It looks like OJB cannot fetch correctly records which have a BigInt
primary
key with value 0; at least in the following conditions;
- I'm using RC5
- Have a table (here Locations) with a primary key Id with a
auto-increment
sequence
- I'm using Oracle 9.2
- The table has a 1-N collection using a proxy.
For instance, I have the following mapping:
class-descriptor class=Locations table=LOCATIONS
field-descriptor name=id column=ID
jdbc-type=BIGINT primarykey=true
autoincrement=true
sequence-name=locations_id_seq/
field-descriptor name=latitude column=LATITUDE
jdbc-type=BIGINT/
field-descriptor name=longitude column=LONGITUDE
jdbc-type=BIGINT/
...
collection-descriptor name=collElements
element-class-ref=Elements proxy=true
inverse-foreignkey field-ref=locationid/
/collection-descriptor
/class-descriptor
Now in the database, there is a location with Id=0.
When I use OJB to fetch this record (with a criteria on Id=0), the
resulting
instance is correct except for the Id field which has the next sequence
value.
Tracing the code, what happens is when the query is executed:
- RsIterator.getObjectFromResultSet reteive the simple fields
correctly
- As there is a collection, retrieveCollections is called
- The query to retrieve the collection is built: Query
fkQuery =
getFKQuery(obj, cld, cds);
- This retrieves the PK fields values (getFKQuery1toN ) which
indirectly calls getValuesForObject
- When the value for the Id is retrieved
(getAutoIncrementValue),
it is considered as Null (BrokerHelper.isNull) and thus the sequence is
called.
Can this be considered a bug?
Are there any workarounds?
Thanks,
-Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
OJB behavior question
I'm working on a fairly simple sample program (modified from the
tutorial1 code shipped with OJB) and I'm running into some
unexplainable (by me :-) behavior relating to a 1:N relation.
The relationship is a simple 1:N from a Person object to a Trait
object. I've attached the repository_user.xml and the source code in
question.
As attached, the subordinate Trait objects are properly stamped with
the OID of the Person object. However, if I uncomment the
"reference-descriptor" in Trait (making it a traversable relation from
Trait to Person), the Trait objects are not stamped with the Person
object's OID when they are persisted. I'm sure that I just don't
understand the interplay between these conditions, so if anybody can
explain it, it would help a lot.
Note, you can ignore all the fields relating to timestamp, lock,
lastModified, etc. They are artifacts put in by AXgen and are
irrelevant.
Thanks.
--
signature
Larry V. Streepy, Jr.
Senior Vice President and CTO
Health Language, Inc.
class-descriptor class=com.staffmix.nurse.competencies.TraitImpl
table=Trait
field-descriptor autoincrement=true primarykey=true column=traOID jdbc-type=VARCHAR name=OID/
field-descriptor column=traLockTimestamp jdbc-type=TIMESTAMP name=lockTimestamp/
field-descriptor column=traLockUser jdbc-type=VARCHAR name=lockUser/
field-descriptor column=traLastModified jdbc-type=TIMESTAMP name=lastModified/
field-descriptor column=traLastModifier jdbc-type=VARCHAR name=lastModifier/
field-descriptor column=traTraitName jdbc-type=VARCHAR name=traitName/
field-descriptor column=traPersonOID jdbc-type=VARCHAR name=personOID/
!--
reference-descriptor proxy=true
auto-delete=false auto-retrieve=true auto-update=false
class-ref=com.staffmix.nurse.competencies.PersonImpl
name=person
foreignkey field-ref=personOID/
/reference-descriptor
--
/class-descriptor
class-descriptor class=com.staffmix.nurse.competencies.CompetencyImpl
table=Competency
field-descriptor autoincrement=true primarykey=true column=comOID jdbc-type=VARCHAR name=OID/
field-descriptor column=comLockTimestamp jdbc-type=TIMESTAMP name=lockTimestamp/
field-descriptor column=comLockUser jdbc-type=VARCHAR name=lockUser/
field-descriptor column=comLastModified jdbc-type=TIMESTAMP name=lastModified/
field-descriptor column=comLastModifier jdbc-type=VARCHAR name=lastModifier/
field-descriptor column=comName jdbc-type=VARCHAR name=name/
field-descriptor column=comDescription jdbc-type=VARCHAR name=description/
collection-descriptor proxy=true
collection-class=org.apache.ojb.broker.util.collections.ManageableVector
auto-delete=false auto-retrieve=true auto-update=false
element-class-ref=com.staffmix.nurse.competencies.PersonImpl
indirection-table=CompetencyPerson
name=persons
fk-pointing-to-this-class column=competencyOID/
fk-pointing-to-element-class column=personOID/
/collection-descriptor
/class-descriptor
class-descriptor class=com.staffmix.nurse.competencies.PersonImpl
table=Person
field-descriptor autoincrement=true primarykey=true column=perOID jdbc-type=VARCHAR name=OID/
field-descriptor column=perLockTimestamp jdbc-type=TIMESTAMP name=lockTimestamp/
field-descriptor column=perLockUser jdbc-type=VARCHAR name=lockUser/
field-descriptor column=perLastModified jdbc-type=TIMESTAMP name=lastModified/
field-descriptor column=perLastModifier jdbc-type=VARCHAR name=lastModifier/
field-descriptor column=perEmpid jdbc-type=VARCHAR name=empid/
field-descriptor column=perName jdbc-type=VARCHAR name=name/
collection-descriptor proxy=true
collection-class=org.apache.ojb.broker.util.collections.ManageableVector
auto-delete=true auto-retrieve=true auto-update=true
element-class-ref=com.staffmix.nurse.competencies.TraitImpl
orderby=traitName
name=traits
inverse-foreignkey field-ref=personOID/
/collection-descriptor
collection-descriptor proxy=true
collection-class=org.apache.ojb.broker.util.collections.ManageableVector
auto-delete=false auto-retrieve=true auto-update=false
element-class-ref=com.staffmix.nurse.competencies.CompetencyImpl
indirection-table=CompetencyPerson
name=competencys
fk-pointing-to-this-class column=personOID/
fk-pointing-to-element-class column=competencyOID/
/collection-descriptor
/class-descriptor
package com.staffmix.nurse.play;
import org.apache.ojb.broker.PersistenceBroker;
import org.apache.ojb.broker.PersistenceBrokerException;
import com.staffmix.nurse.competencies.PersonImpl;
import com.staffmix.nurse.competencies.Trait;
import com.staffmix.nurse.competencies.TraitImpl;
/**
* Insert the type's description here.
* Creation date: (04.03.2001 10:34:15)
* @author Thomas Mahler
*/
public class UCEnterNewPerson extends AbstractUseCase
{
/**
* UCEnterNewProduct constructor comment.
*/
public UCEnterNewPerson(PersistenceBroker broker)
{
super(broker);
