Re: Bug in doDelete with the markedForDelete list
Ahh, so the right thing to do would be to compare the Identity of each object in the list, and not rely on the equals() method. Thanks for clarifying. Larry. Armin Waibel wrote: Hi Larry, Larry V. Streepy, Jr. wrote: As I think about this thread, I'm beginning to wonder about the consequences of the changes being proposed. The essence of the problem revolves around the equality of business objects. The problem was that the equals() method returns true, even when they have different primary keys. This means that you truly have two different real objects, but for business reasons you want them to compare equals. So, from a business perspective, they are the same object, but you want multiple, distinct persisted forms. So, are we now saying that object identity (using "==") is the mechanism that OJB will use in all cases, as opposed to object equality (using equals())? If so, is this what was originally intended in the OJB code? Further, is anyone relying on the current behavior? Official and internal OJB use ...broker.Identity objects as object entity (e.g. ObjectCache or Locking in odmg). Identiy based on the PK values and the TopLevel class of the object. The problem found by Guillaume is a particular one. To avoid e.g. infinite loops (a object in collection has back reference to main object), we held a list of all stored/deleted objects (main object + references) when a store/delete call was done. regards, Armin Although it might make the code more complex, this might need to be a behavior that is configurable. Meaning that you would have to abstract the object equality comparisons and let them be controlled by specific implementations as needed by the business environment. Just wanted to raise the questions because the change you are discussing is subtle, yet potentially very large in scope. Thanks. Larry. Armin Waibel wrote: Hi, Guillaume Nodet wrote: Armin, I dit not see any identity based List. There are Maps (in the jarakarta-commons-collections for exemple) and a Set could be easily build on top of this map. Maybe just inlining the contains function directly in the doDelete function, walking through the array should do the work. Thanks, I will do this, but encapsulate it in a new class, because I assume that we need such an function on store method too (nowStoring List). regards, Armin Guillaume -Message d'origine- De : Armin Waibel [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 février 2004 19:14 À : OJB Users List Objet : Re: Bug in doDelete with the markedForDelete list Hi Guillaume, Guillaume Nodet wrote: Another way could be to use a specific Map that test an object equality with a '==' instead of a 'equals'. agree, seems to be the smartest way to get around your problem. Do you know an object identity based ArrayList/List implementation? regards, Armin Guillaume -Message d'origine- De : Guillaume Nodet [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 février 2004 12:22 À : OJB Objet : Bug in doDelete with the markedForDelete list Hi Armin ! I've found a problem using objects instead of Identity in the markedForDelete list of PersistenceBrokerImpl class. Here is my problem: I want to delete an object A that contains a collection of B objects. When i put 2 B objects that are equals in my collection, and trying to delete the A objects, the markedForDelete.contains(obj) statement returns true when trying to delete the second B object. They are trully equals, but have different primary keys... Could this list use Identity instead of objects ? Regards, Guillaume - 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] -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Langauge, Inc.
Re: Bug in doDelete with the markedForDelete list
As I think about this thread, I'm beginning to wonder about the consequences of the changes being proposed. The essence of the problem revolves around the equality of business objects. The problem was that the equals() method returns true, even when they have different primary keys. This means that you truly have two different real objects, but for business reasons you want them to compare equals. So, from a business perspective, they are the same object, but you want multiple, distinct persisted forms. So, are we now saying that object identity (using "==") is the mechanism that OJB will use in all cases, as opposed to object equality (using equals())? If so, is this what was originally intended in the OJB code? Further, is anyone relying on the current behavior? Although it might make the code more complex, this might need to be a behavior that is configurable. Meaning that you would have to abstract the object equality comparisons and let them be controlled by specific implementations as needed by the business environment. Just wanted to raise the questions because the change you are discussing is subtle, yet potentially very large in scope. Thanks. Larry. Armin Waibel wrote: Hi, Guillaume Nodet wrote: Armin, I dit not see any identity based List. There are Maps (in the jarakarta-commons-collections for exemple) and a Set could be easily build on top of this map. Maybe just inlining the contains function directly in the doDelete function, walking through the array should do the work. Thanks, I will do this, but encapsulate it in a new class, because I assume that we need such an function on store method too (nowStoring List). regards, Armin Guillaume -Message d'origine- De : Armin Waibel [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 février 2004 19:14 À : OJB Users List Objet : Re: Bug in doDelete with the markedForDelete list Hi Guillaume, Guillaume Nodet wrote: Another way could be to use a specific Map that test an object equality with a '==' instead of a 'equals'. agree, seems to be the smartest way to get around your problem. Do you know an object identity based ArrayList/List implementation? regards, Armin Guillaume -Message d'origine- De : Guillaume Nodet [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 février 2004 12:22 À : OJB Objet : Bug in doDelete with the markedForDelete list Hi Armin ! I've found a problem using objects instead of Identity in the markedForDelete list of PersistenceBrokerImpl class. Here is my problem: I want to delete an object A that contains a collection of B objects. When i put 2 B objects that are equals in my collection, and trying to delete the A objects, the markedForDelete.contains(obj) statement returns true when trying to delete the second B object. They are trully equals, but have different primary keys... Could this list use Identity instead of objects ? Regards, Guillaume - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc.
Re: Help, I'm stuck and I can't get out! (Infinite Loop)
For the slow people in the class, can you please explain this problem in a little more detail? If I have to tweak cache timeouts to get correct behavior on simple references, then there 's a bug hiding in here somewhere. Thanks. Edson Carlos Ericksson Richter wrote: Exists some circustantes that results in infinite loop due to use of EmptyCache with two way navigable references. Are you using this? If yes, try to set a in the recerenced bean with a very low time-out (let's say, 1 sec). It solved almost vast majority of my cases. Best regards, Edson Richter - Original Message - From: Clay Mitchell To: OJB Users List Sent: Saturday, February 07, 2004 2:16 PM Subject: Help, I'm stuck and I can't get out! (Infinite Loop) I seem to have gotten myself stuck in a infinite loop here... Any idea what it's doing and why? Thanks -Clay [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.ProductType, Query from class com.exigentic.onyx.ProductType where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Specification, Query from class com.exigentic.onyx.Specification where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Product, Query from class com.exigentic.onyx.Product where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.SpecType, Query from class com.exigentic.onyx.SpecType where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Specification, Query from class com.exigentic.onyx.Specification where [specId = 28]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false ## Here's my repository: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 3/2/2004 -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Langugae, Inc.
Re: Checking repository.xml with dtd
Order doesn't affect "well formedness," but it certainly affects
"correctness" as described in the DTD or XML Schema.
Tino Schöllhorn wrote:
Hello Armin,
that was ist thank. But: isn't that nuts? I wasn't aware that the
order of elements in an xml-file has anything to do with its corectness.
regards
Tino
Armin Waibel wrote:
Hi Tino,
(I'm not an xml-expert ;-) )
try to keep the order of elements declared in repository.dtd
First all reference-descriptor, then all collection-descriptor
regards,
Armin
Tino Schöllhorn wrote:
Hi,
I want to ensure that the repository.xml-file is "syntactically" (is
that english) correct. So I am trying to validate it against its dtd
with the following code:
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating(true);
DocumentBuilder builder = factory.newDocumentBuilder();
builder.setErrorHandler(new ErrorHandler() {
// some error handling code here
});
Document doc = builder.parse(new File(repositoryFile));
Whenever I start this with my repositoy.xml file I get the following
messages:
ERROR: 30:-1 :org.xml.sax.SAXParseException: In Element
"class-descriptor" ist hier "reference-descriptor" nicht zulässig.
[ojb-generator] ERROR: 40:-1 :org.xml.sax.SAXParseException: In
Element "class-descriptor" ist hier "reference-descriptor" nicht
zulässig.
So it seems that there is an error in my xml-file: but it works fine
and the repository.dtd says that "referecne-descriptor" should be a
valid element.
Nontheless the application is running fine with my
repository.xml-file - so I don't think there is an error. For those
who are interested I attach the repository_user.xml file.
What am I missing ?
Thanks for any help.
Tino
name="departments"
element-class-ref="kos.om.Department"
auto-retrieve="true"
auto-update="true"
auto-delete="false"
proxy="true"
indirection-table="Department_Person">
auto-retrieve="true"
auto-update="true">
auto-retrieve="true"
auto-update="true">
auto-retrieve="true"
auto-update="true"
proxy="true">
name="persons"
elemgent-class-ref="kos.om.Person"
auto-retrieve="true"
auto-update="false"
indirection-table="Department_Person">
name="subDepartments"
element-class-ref="kos.om.Department"
auto-retrieve="true"
auto-update="false"
indirection-table="Department_Department">
name="parentDepartments"
element-class-ref="kos.om.Department"
auto-retrieve="true"
auto-update="false"
indirection-table="Department_Department">
--------
-
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]
--
Larry V. Streepy, Jr.
Senior Vice President and CTO
Health Language, Inc.
Re: insert object, and don't specify a value for one of the fields
I really wasn't advocating such a complex approach. I simply stated that it would be useful to allow some simple mechanism to support the use of database defaults during row insertion. Using a ConversionStrategy would require that the OJB interaction layer know the default column value, which may be cause unneeded coupling between the database team and the domain software team (if such a division exists). I think this can easily be handled without any sublanguage at all. Thomas Mahler wrote: Hi all, I agree that it would be nice to have a declaration of initial and default values, etc. in the repository.xml. So we would need a little "sub language" that allows you to specify the semantics you want. For simple cases it will be only constant of arbitrary java types. For other cases user want to perform some computations. SO the "sub language" will tend to grow and to become a full fledged programming language. So instead instead of embarking on this adventure of creating an expression evaluator language I strongly recommend to use user defined ConversionStrategies. You can do any computation in a ConversionStrategy and it can be defined on a per field basis. See http://db.apache.org/ojb/jdbc-types.html for a docuemntation of this feature. cheers, Thomas Larry V. Streepy, Jr. wrote: If use of default database values on insert is a common use case, it would seem reasonable to submit an enhancement request to support some specification in the class descriptor to support control of this semantic. I don't know enough databases to know if this will be a problem in implementing the DB specific handling or not. But it sounds like a useful feature. Manukyan, Sergey wrote: Maybe I should give you my manager's phone number and you will explain it to him ... ;) I think in anyway we should have a mechanism to control what fields take part in operations. Regards. Sergey. -Original Message- From: Andy Malakov [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 2:24 PM To: OJB Users List Subject: Re: insert object, and don't specify a value for one of the fields Simplest solution may be to change business logic. Since you want it to be writable from OJB side, who said "dateChanged" should be initially set by database? Sorry :-) - Original Message - From: "Manukyan, Sergey" <[EMAIL PROTECTED]> To: "'OJB Users List'" <[EMAIL PROTECTED]> Sent: Wednesday, February 04, 2004 1:31 PM Subject: RE: insert object, and don't specify a value for one of the fields Hi Armin, If I declare this field as readonly, then it will be always readonly, but I need to update on UPDATE operations, and omit on INSERT operations. I guess the possible solution I am seeking for could be to declare something like this: Or can I somehow dynamically exclude this field from participating in operation, whatever this operation might be? Similar to ObjectModification class mechanism, but that will exclude this field from operation only for this Broker? I know I can dynamically change the class descriptor and set this field to anonymous and then revert it back to normal, but I am afraid this will impact other Brokers operations with this class, -Sergey -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 11:30 AM To: OJB Users List Subject: Re: insert object, and don't specify a value for one of the fields Hi Sergey, Manukyan, Sergey wrote: Folks, The thing is I need to insert a record where for one of the fields I want to omit value, not specify at all, not even null, nothing. So that in INSERT operation it will not be present at all and will be populated by the default value from database. Is there a way how I can do that? you can try to declare field as access="readonly". regards, Armin Thank you, -Sergey ** ** LEGAL DISCLAIMER ** ** This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this E-mail message from your computer. - 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: insert object, and don't specify a value for one of the fields
If use of default database values on insert is a common use case, it would seem reasonable to submit an enhancement request to support some specification in the class descriptor to support control of this semantic. I don't know enough databases to know if this will be a problem in implementing the DB specific handling or not. But it sounds like a useful feature. Manukyan, Sergey wrote: Maybe I should give you my manager's phone number and you will explain it to him ... ;) I think in anyway we should have a mechanism to control what fields take part in operations. Regards. Sergey. -Original Message- From: Andy Malakov [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 2:24 PM To: OJB Users List Subject: Re: insert object, and don't specify a value for one of the fields Simplest solution may be to change business logic. Since you want it to be writable from OJB side, who said "dateChanged" should be initially set by database? Sorry :-) - Original Message - From: "Manukyan, Sergey" <[EMAIL PROTECTED]> To: "'OJB Users List'" <[EMAIL PROTECTED]> Sent: Wednesday, February 04, 2004 1:31 PM Subject: RE: insert object, and don't specify a value for one of the fields Hi Armin, If I declare this field as readonly, then it will be always readonly, but I need to update on UPDATE operations, and omit on INSERT operations. I guess the possible solution I am seeking for could be to declare something like this: Or can I somehow dynamically exclude this field from participating in operation, whatever this operation might be? Similar to ObjectModification class mechanism, but that will exclude this field from operation only for this Broker? I know I can dynamically change the class descriptor and set this field to anonymous and then revert it back to normal, but I am afraid this will impact other Brokers operations with this class, -Sergey -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 11:30 AM To: OJB Users List Subject: Re: insert object, and don't specify a value for one of the fields Hi Sergey, Manukyan, Sergey wrote: Folks, The thing is I need to insert a record where for one of the fields I want to omit value, not specify at all, not even null, nothing. So that in INSERT operation it will not be present at all and will be populated by the default value from database. Is there a way how I can do that? you can try to declare field as access="readonly". regards, Armin Thank you, -Sergey ** ** LEGAL DISCLAIMER ** ** This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this E-mail message from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc.
Re: Collection prefetching patch
I disagree that this is a proper decision in all cases. There are
semantic reasons why one would want an empty collection versus a null
instance. If this change is going to be made, the behavior should be
controlled by an attribute of the collection descriptor.
Thanks.
Larry.
Guillaume Nodet wrote:
I submit another patch that corrects my problem:
In AbstractPersistentField, lines 321 -> 328 replace the code
String name = fieldName.substring(0, index);
PersistentField pField = createInternPersistentField(realClass,
name);
Object attrib = pField.get(realObj);
if (attrib != null || value != null)
{
if (attrib == null)
{
by the following code:
String name = fieldName.substring(0, index);
PersistentField pField = createInternPersistentField(realClass,
name);
Object attrib = pField.get(realObj);
if (attrib != null
|| (value != null
&& (!(value instanceof Collection) || ((Collection)
value).size() > 0)))
{
if (attrib == null)
{
-Message d'origine-
De : Guillaume Nodet [mailto:[EMAIL PROTECTED]
Envoye : mercredi 4 fevrier 2004 09:40
A : OJB Users List
Objet : Collection prefetching patch
I saw that ojb do automatically create empty collections and set them to the
appropriate field even if they are empty.
In my own, case, this appears with nested objects, and thus it actually
creates the nested object despite the fact that it was null when i stored
the object.
Wouldn't it be better to create the collection only when it is not empty ?
In the CollectionPrefetcher, lines 213 -> 218, there is the following code:
ManageableCollection col =
createCollection(collectionClass);
for (Iterator it2 = list.iterator(); it2.hasNext();)
{
col.ojbAdd(it2.next());
}
result = col;
What would be the impact to replace it with the following. IMHO, it would
improve performance a little, and avoid creating unnecessary collections.
ManageableCollection col = null;
for (Iterator it2 = list.iterator(); it2.hasNext();)
{
if (col == null)
{
col = createCollection(collectionClass);
}
col.ojbAdd(it2.next());
}
result = col;
Another way to solve my problem is to implement my own PersistentField class
that avoids setting empty collections on nested object if they are not
created yet, but i guess the one above is better.
Regards,
Guillaume Nodet
-
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]
--
Larry V. Streepy, Jr.
Senior Vice President and CTO
Re: Installation of OJB
I struggled with this same problem when learning and working with OJB. My final solution was to run the build of OJB and then setup my project build to extract the generated SQL (the schema.ddl file) and copy it into my build area and use ant sql tasks to generate the tables. I know that this creates a minor dependency between the two projects, but that's fairly easy to manage. I have no need for setting up and utilizing torque in my project (I use Axgen to generate everything from UML), so it seemed like major complications to solve a simple problem. YMMV. Larry. Brian McCallister wrote: I have considered including the torque stuff in the ojb-blank project before, and opted against it as I thought I might be pushing too much complexity on users then. Right now there isn't an *ideal* way to create the internal tables as most of the time people don't need them (though the hi/lo sequence table is needed enough that this may be incorrect, since it is the default sequence manager). What are thoughts on including the torque generator stuff in ojb-blank? The ojb-core schema is already included in the src/schema directory, but the build-torque and torque related jars are not included. Now that I think about it, I have done this for all of the projects I have built around ojb-blank bits anyway, so that is a certain argument in favor. In the short term, Thomas D has has a nice little walkthrough on getting torque from OJB setup in the xdoclet docs, but that is sort of hidden =) (note, we should probably move that into its own HOWTO). -Brian On Feb 2, 2004, at 3:19 AM, Ralf Bode wrote: Hi to all, just a question about to install OJB i read, that i have to load the sources and run some build-scripts okay. but is there an easy-way? i only need a build-script for the binary-version of OJB, that "installs" OJB-internal-tables into database. or is there a reason for "building" all ? thanks for advice! greetings ralf __ Gesendet von Yahoo! Mail - http://mail.yahoo.de Mit Yahoo! Suche finden Sie alles: http://suche.yahoo.de - 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]
question about default collection class
I've got a question regarding the default behavior of OJB. Given a M:N relation which is being decomposed with a standard indirection table, the default collection class (RemovalAwareCollection) is deleting the target objects when they are removed from the subject. This seems counter-intuitive to the typical use cases where M:N relations exist to relate objects that have their own life cycle. Wouldn't it be more intuitive for OJB to use a normal ManageableVector unless the collection descriptor indicated that auto-delete="true"? My basic point is that it would seem more "correct" if the auto-delete setting controlled the default collection class to be used for a collection instance. Comments? Am I missing some other obvious rationale? Thanks. -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc.
Re: OJB behavior question
Thomas, I tried removing the collection-class entry and it had no
effect. The only difference in the two executions is the existence of
the reference from Trait to Person. When that is in place, the
traPerOID field is not updated with the person's OID. This is smelling
more like a bug. Is there additional information or source code that I
should provide to help in tracking this down?
Thanks.
Thomas Mahler wrote:
Hi Larry,
Hmm, I had a look at your code and did find any flaws.
Did you try to ommit the collection-class entry?
I think it is at least superfluous.
But I have no idea what could be wrong here, as your repository looks OK.
Thomas
Larry V. Streepy, Jr. wrote:
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.
--
Larry V. Streepy, Jr.
Senior Vice President and CTO
Health Language, Inc.
table="Trait">
table="Competency">
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"
>
table="Person">
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"
>
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"
>
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);
}
/** perform this use case*/
public void apply()
{
// this will be our new object
PersonImpl newPerson = new PersonImpl();
// now read in all relevant information and fill the new object:
System.out.println("please enter a new person");
String in = readLineWithMessage("enter name:");
newPerson.setName(in);
in = readLineWithMessage("enter empid:");
newPerson.setEmpid(in);
// now perform persistence operations
try
{
// 1. open transaction
broker.beginTransaction();
while( (in = readLineWithMessage("Enter trait:")) != null
) {
String traitName = in.trim();
if( traitName.length() == 0 )
break;
TraitImpl trait = new TraitImpl();
trait.setTraitName( traitName );
newPerson.addTrait( trait );
}
// 2. make the new object persistent
broker.store(newPerson);
broker.commitTransaction();
}
catch (Persi
Re: Working on store procedure
Suma, I was suggesting that you could use JDBC directly to execute the stored procedure and retrieve the results. The use the results to feed OJB queries to materialize the objects. Suma Venkatesh wrote: Hi Ron,thomas and Larry Thank you so much for the response. I did not receive any answers prior to todays email and hence was my frustration.Sorry about that. If OJB doesnt support a store procedure performing only selects, can i atleast call a custom store procedure ? Larry's answer: However, I would expect that you could write the SP so that it returns a set of OIDs which you could then use to quickly materialize the objects. @@How to call this SP which would return OIDs.I mean in which tag should the call be placed in repository_user.xml Is it under , OR because i think the broker calls them based on the operations they perform. Let me know. thanks in advance, suma "Larry V. Streepy, Jr." <[EMAIL PROTECTED]> wrote: As has been stated a couple of times, there is no support for directly specifying the use of a stored procedure so that OJB will use it for data retrieval. However, I would expect that you could write the SP so that it returns a set of OIDs which you could then use to quickly materialize the objects. [EMAIL PROTECTED] wrote: Hi I posted the below question 3 days ago. Is it that new joiners are not answered OR is my question too obvious !!! Iam completely new to OJB and trying to learn it. Please help me. 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 Colorado USA at (+1) 303-307-4400. a way to acheive this in OJB ? To summarize: How to call a custom store procedure in OJB which does NO insert,update and delete operations. thanks in advance, suma This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc.
Re: Problem using strongly typed collections
I know that it may have just been omitted from your example data model,
but do you have a
public void setBs( Collection )
method in A?
Guillaume Nodet wrote:
The problem is the object model cannot be modified.
-Message d'origine-
De : Thomas Mahler [mailto:[EMAIL PROTECTED]
Envoye : mardi 13 janvier 2004 17:41
A : OJB Users List
Objet : Re: Problem using strongly typed collections
Hi Guilaume,
Guillaume Nodet wrote:
I've got an object model with strongly typed collections:
class A {
private BList bs;
public BList getBs();
}
class B {
...
}
class BList implements Collection {
...
}
When I store the object, everything is good, but when i read it later i've
got an exception
thrown from AbstractPersistentField.set when trying to set the B
collection,
which is a
ManageableCollection.
IMO the is caused by the fact that you Blist attribute is now filled
with a ManeageableCollection and not with BList!
You have to tell in the collection-descriptor that the "bs" attribute
must use a special collection-class="BList".
To make this work You BList must implement the interface
o.a.ojb.broker.ManageableCollection.
See tutorial 3 for more details.
OJB was configured to use
PersistentFieldDirectAccessImpl.
So i tried with PersistentFieldIntrospectorImpl and adding a set method
public void setBs(Collection list)
but I've got the following exception:
Can't get WriteMethod for property:bs in object:A
Is there a way to store and read my collection without writing a custom
PersistentField ?
IMO this is only a secondary error!
cheers,
thomas
Guillaume Nodet
-
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]
--
Larry V. Streepy, Jr.
Senior Vice President and CTO
Health Language, Inc.
Re: Newbie: Problems with passing persistent Objects via a RMI-Connection
Philipp, this appears to be the same problem/question asked by another posting last night. Here's the response I sent to that request: I'll try to answer your question, although I'm still somewhat new to OJB myself. OJB uses RemovalAwareCollection as the default implementation class for holding the collection instance. RemovalAwareCollection implements java.util.Collection. So, when your container class is serialized to the client, it contains a reference to the implementation class (RemovalAwareCollection), which must be available to the client either on the local classpath or via the URL class loader. You can control the class used for collection handling in the OJB.properties file. Thus, you could write your own class to handle the collection if you want to avoid distributing the OJB jar file. Steckel, Philipp wrote: Hello, i am using the Persistence-Broker API and a mySQL-Database. My Server-Application holds persistent Objects in the following way: I have a Container-Object called ProductCon, which holds n Product-Objects in a Vector. I have made this struct persistent using a 1:n mapping and it works really fine. I would like to pass the ProductCon-Object (and the associated Product-Objects) to the Client-Application via RMI. But after having started the Client-Application, the compiler tells me that the Client-App needs the OJB-Libraries, like org.apache. ojb.broker.util.collections.RemovalAwareCollection. The point is, that I don't want to ship the client-app with these libraries. Obviously, the Persistence-Broker added some sort of Code to the ProductCon- or Product-Objects which needs the libraries. Is there any possibility to configure the Broker or what to solve this problem? I would like to just send the Objects via RMI, not the associated ojb-code. Here is the code to retreive the objects (like in the Tutorial): dbBroker = PersistenceBrokerFactory.defaultPersistenceBroker(); query = new QueryByCriteria(ProductCon.class,null); versandvorlageCon = (ProductCon)dbBroker.getObjectByQuery(query); This is used to store(like in the tutorial): dbBroker.beginTransaction(); dbBroker.store(ProductCon); dbBroker.commitTransaction(); I guess, that this is a simple newbie-problem. If there is more information/code needed, please just tell me. Thanks a lot in advance, Philipp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc.
Re: Working on store procedure
As has been stated a couple of times, there is no support for directly specifying the use of a stored procedure so that OJB will use it for data retrieval. However, I would expect that you could write the SP so that it returns a set of OIDs which you could then use to quickly materialize the objects. [EMAIL PROTECTED] wrote: Hi I posted the below question 3 days ago. Is it that new joiners are not answered OR is my question too obvious !!! Iam completely new to OJB and trying to learn it. Please help me. 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 ? To summarize: How to call a custom store procedure in OJB which does NO insert,update and delete operations. thanks in advance, suma This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- signature Larry V. Streepy, Jr. Senior Vice President and CTO "We speak the language of healthcare" ™ Direct: +1 425-373-0600 Fax: +1 425-373-1633 Corp.: +1 303-307-4400 Health Language, Inc. 3950 Lewiston Street, Suite 210 Aurora, Colorado 80011 The information in this email message is intended only for the use of the intended recipient and may contain confidential information. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Health Language's corporate offices in Aurora, Colorado USA at (+1) 303-307-4400. <>
Re: java.lang.ClassNotFoundException: org.apache.ojb.broker.util.collections.RemovalAwareCollection
I'll try to answer your question, although I'm still somewhat new to OJB myself. OJB uses RemovalAwareCollection as the default implementation class for holding the collection instance. RemovalAwareCollection implements java.util.Collection. So, when your container class is serialized to the client, it contains a reference to the implementation class (RemovalAwareCollection), which must be available to the client either on the local classpath or via the URL class loader. You can control the class used for collection handling in the OJB.properties file. Thus, you could write your own class to handle the collection if you want to avoid distributing the OJB jar file. I hope that helps, and if I've horribly misstated something, I'm sure someone will correct me :-) Christopher Tava wrote: Dear OJB User Group, I am using OJB in jboss and making an EJB connection to the server and it seems like the client application is trying to down a server side class. Any suggestion as to what can be the problem that cause the rmi classloader to reference the RemovalAwareCollection. Is ojb always returning a java.util.Collection? I see a ManageableCollection class in the broker package? Does that have anything to do with it? Thank you in advance for you much needed reply. Sincerely, Chris - Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc.
Re: AXgen and OJB and DDL
Thanks Peter, I've got another question regarding the generated repository_user.xml. It includes fields like the following in every class: Can you explain why they are there? Is there any part of OJB that would make use of them? I can see that (if there was an option in AXgen for it) the lockTimestamp field could be used for optimistic locking, but the other fields appear to be specific to some other use expected by AXgen. Thanks. Peter Wieland wrote: Hi Larry, I'm not sure wether I can help you but at least I can explain you how AXgen makes sure the DDL will meet the needs of OJB. Both, the OJB repository.xml and the DDL are generated based on the same UML model (the XMI). The templates make sure that the table definitions in the DDL and the definitions in the OJB mapping use the same types. I never tried to generate the DDL from the repository directly as we model all of our classes, we never needed such a feature. Modelling entities in a case tool and use this model as input for all generation works very well. Regards, Peter I've searched and searched, and I haven't found a clear picture regarding how to generate the DDL (for table creation) from a repository.xml. I see that OJB uses Torque internally to construct the test tables, but they are generated from a schema.xml that appears to have been hand coded. I found AXgen which generates numerous artifacts for OJB usage from the XMI model, but I am left wondering if the DDL that it generates is in some way certain to meet the needs of OJB. I was very intrigued by an earlier discussion on this list regarding the use of commons-sql to generate DDL "diff" files, but the thread seemed to just die without any real conclusion. I know this is a somewhat vague request for help, but I want to ensure that I understand (and can rely on) the mechanisms available for creating the DDL that OJB will user for it's O/R mappings. Thanks for any help you can provide. -- Larry V. Streepy, Jr. Senior Vice President and CTO "We speak the language of healthcare" ^(TM) Direct: +1 425-373-0600 Fax:+1 425-373-1633 Corp.: +1 303-307-4400 Health Language, Inc. 3950 Lewiston Street, Suite 210 Aurora, Colorado 80011 The information in this email message is intended only for the use of the intended recipient and may contain confidential information. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Health Language's corporate offices in Aurora, Colorado USA at (+1) 303-307-4400. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- signature Larry V. Streepy, Jr. Senior Vice President and CTO "We speak the language of healthcare" ™ Direct: +1 425-373-0600 Fax: +1 425-373-1633 Corp.: +1 303-307-4400 Health Language, Inc. 3950 Lewiston Street, Suite 210 Aurora, Colorado 80011 The information in this email message is intended only for the use of the intended recipient and may contain confidential information. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Health Language's corporate offices in Aurora, Colorado USA at (+1) 303-307-4400. <>
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.
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);
}
/** perform this use case*/
public void apply()
{
// this will be our new object
PersonImpl newPerson = new PersonImpl();
// now read in all relevant information and fill the new object:
System.out.println("please enter a new person");
String in = readLineWithMessage("enter name:");
newPerson.setName(in);
in = readLineWithMessage("enter empid:");
newPerson.setEmpid(in);
// now perform persistence operations
try
{
// 1. open transaction
broker.beginTransaction();
while( (in = readLineWithMessage("Enter trait:")) != null ) {
String traitName = in.trim();
if( traitName.length() == 0 )
break;
TraitImpl trait = new TraitImpl();
trait.setTraitName( traitName );
newPerson.addTrait( trait );
}
// 2. make the new object persistent
broker.store(newPerson);
broker.commitTransaction();
}
catch (PersistenceBrokerException ex)
{
// if something went wrong: rollback
broker.abortTransaction();
System.out.println(ex.getMessage());
ex.printStackTrace();
}
}
/** get descriptive information on use case*/
public String getDescription()
{
return "Enter a new person";
}
}
-
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: proxy-prefetching-limit="50"> &database; &internal; &user; 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.(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
Re: error parsing repository.xml
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. -- signature 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.(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.(MetadataManager.java:121) at org.apache.ojb.broker.metadata.MetadataManager.(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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error parsing repository.xml
I've attached a second stack trace (with OJB recompiled with debug
information) and it more properly shows the error I'm describing.
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.
--
signature
Larry V. Streepy, Jr.
Senior Vice President and CTO
Health Language, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
signature
Larry V. Streepy, Jr.
Senior Vice President and CTO
Health Language, Inc.
[org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] DEBUG:
PersistenceBroker pool will be setup with the following configuration
# Trace object of class org.apache.commons.pool.impl.GenericKeyedObjectPool$Config:
# maxIdle-1
# maxActive100
# maxWait2000
# whenExhaustedAction0
# testOnBorrowfalse
# testOnReturnfalse
# testWhileIdlefalse
# timeBetweenEvictionRunsMillis-1
# numTestsPerEvictionRun10
# minEvictableIdleTimeMillis100
[org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] INFO: Create
PersistenceBroker instance pool, pool configuration was {whenExhaustedAction=0, ma
xIdle=-1, maxActive=100, maxWait=2000, removeAbandoned=false,
numTestsPerEvictionRun=10, testWhileIdle=false, minEvictableIdleTimeMillis=100,
testOnReturn=f
alse, logAbandoned=false, removeAbandonedTimeout=300,
timeBetweenEvictionRunsMillis=-1, testOnBorrow=false}
[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.(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: Exception when reading
metadata information, please check your repository.xml file
at
org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:135)
at
org.apache.ojb.broker.metadata.MetadataManager.(MetadataManager.java:121)
at
org.apache.ojb.broker.metadata.MetadataManager.(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.crimson.parser.Parser2.parseInternal(Parser2.java:558)
at org.apache.crimson.parser.Parser2.parse(Parser2.java:318)
at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:442)
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
_ _
__ (_)| |_
/ _\| || _ \ ~ be persistent ~
\__/| ||___/v. 1.0.rc5
/_/
Welcome to the OJB PB tutorial application
[0] List all Person entries
[1] Enter a new person
[2] Edit a person entry
[3] Delete a person entry
[4] Quit Application
type in number to select a use case
4
Exception in thread "main" java.lang.NullPointerException
at com.staffmix.nurse.play.Application.run(Application.java:93)
at com.staffmix.nurse.play.Application.main(Application.java:57)
--
error parsing repository.xml
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.
--
signature
Larry V. Streepy, Jr.
Senior Vice President and CTO
Health Language, Inc.
[org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] DEBUG:
PersistenceBroker pool will be setup with the following configuration
# Trace object of class org.apache.commons.pool.impl.GenericKeyedObjectPool$Config:
# maxIdle-1
# maxActive100
# maxWait2000
# whenExhaustedAction0
# testOnBorrowfalse
# testOnReturnfalse
# testWhileIdlefalse
# timeBetweenEvictionRunsMillis-1
# numTestsPerEvictionRun10
# minEvictableIdleTimeMillis100
[org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] INFO: Create
PersistenceBroker instance pool, pool configuration was {whenExhaustedAction=0, ma
xIdle=-1, maxActive=100, maxWait=2000, removeAbandoned=false,
numTestsPerEvictionRun=10, testWhileIdle=false, minEvictableIdleTimeMillis=100,
testOnReturn=f
alse, logAbandoned=false, removeAbandonedTimeout=300,
timeBetweenEvictionRunsMillis=-1, testOnBorrow=false}
[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.(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: Exception when reading
metadata information, please check your repository.xml file
at
org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:135)
at
org.apache.ojb.broker.metadata.MetadataManager.(MetadataManager.java:121)
at
org.apache.ojb.broker.metadata.MetadataManager.(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.crimson.parser.Parser2.parseInternal(Parser2.java:558)
at org.apache.crimson.parser.Parser2.parse(Parser2.java:318)
at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:442)
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
_ _
__ (_)| |_
/ _\| || _ \ ~ be persistent ~
\__/| ||___/v. 1.0.rc5
/_/
Welcome to the OJB PB tutorial application
[0] List all Person entries
[1] Enter a new person
[2] Edit a person entry
[3] Delete a person entry
[4] Quit Application
type in number to select a use case
4
Exception in thread "main" java.lang.NullPointerException
at com.staffmix.nurse.play.Application.run(Application.java:93)
at com.staffmix.nurse.play.Application.main(Application.java:57)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AXgen and OJB and DDL
I've searched and searched, and I haven't found a clear picture regarding how to generate the DDL (for table creation) from a repository.xml. I see that OJB uses Torque internally to construct the test tables, but they are generated from a schema.xml that appears to have been hand coded. I found AXgen which generates numerous artifacts for OJB usage from the XMI model, but I am left wondering if the DDL that it generates is in some way certain to meet the needs of OJB. I was very intrigued by an earlier discussion on this list regarding the use of commons-sql to generate DDL "diff" files, but the thread seemed to just die without any real conclusion. I know this is a somewhat vague request for help, but I want to ensure that I understand (and can rely on) the mechanisms available for creating the DDL that OJB will user for it's O/R mappings. Thanks for any help you can provide. -- signature Larry V. Streepy, Jr. Senior Vice President and CTO "We speak the language of healthcare" ™ Direct: +1 425-373-0600 Fax: +1 425-373-1633 Corp.: +1 303-307-4400 Health Language, Inc. 3950 Lewiston Street, Suite 210 Aurora, Colorado 80011 The information in this email message is intended only for the use of the intended recipient and may contain confidential information. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Health Language's corporate offices in Aurora, Colorado USA at (+1) 303-307-4400. <>
Re: Follow up on JBoss + OJB + HSQLDB
Brian Sam-Bodden wrote: Torque. For those unintiated with Torque the whole thing is a bit confusing. I found no easy way to create the OJB internal tables from the build without creating the test tables also. So I had to put my own build together to get just what I needed. I don't know what to suggest here but maybe the build could be simplified. Brian, I completely agree with you here. Trying to decipher OJB, Torque, and a few other things has been interesting. I have on my "to do" list, a note to create a build script that will do just what you state above (internal table creation). If you wouldn't mind sharing that build fragment, I'd be very grateful. Thanks - and good luck on this problem. -- signature Larry V. Streepy, Jr. Senior Vice President and CTO "We speak the language of healthcare" ™ Direct: +1 425-373-0600 Fax: +1 425-373-1633 Corp.: +1 303-307-4400 Health Language, Inc. 3950 Lewiston Street, Suite 210 Aurora, Colorado 80011 The information in this email message is intended only for the use of the intended recipient and may contain confidential information. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Health Language's corporate offices in Aurora, Colorado USA at (+1) 303-307-4400. <>
issues with 1.0 RC5
I am posting to both the USER and the DEV mailing lists because I have
searched for answers on both archives and the topics are mentioned (but
not resolved) on both lists.
I am using W2K, MySQL 4.0 and OJB 1.0 RC5. I performed a clean source
install and build using the documented procedures and I've come across
several problems that appear to be errors in the build process.
1. The parameter @DATABASE_DEFAULT@ in two of the xml files
(ojbcore-schema.xml and ojbtest-schema.xml) is never replaced with an
appropriate value during the build process. These files are not copied
(with filtering) prior to their use within the ANT target (in
build-torque.xml) that processes them. By manually replacing this
parameter with the name of the database ("ojb" in this case) the unit
tests could proceed.
2. The jdbc URL configured in the mysql profile is incorrect for initial
database creation. It includes the "ojb" database name in the URL and
causes a failure during the connection when trying to initially create
the database. It appears that the profile would need to construct a
different URL for creation than for data load. I was able to work
around this error by creating an empty database named "ojb" but this is
obviously not a good solution for the automated build :-)
3. Once I got past these issues, the junit tests actually ran, but
several tests failed. If someone is responsible for the mysql testing,
I'd be happy to send you the junit test output file.
I just wanted to get this items summarized on this list prior to the
final 1.0 release. Please let me know if any additional information is
needed and I'll be happy to follow up.
Thanks.
--
Larry V. Streepy, Jr.
Senior Vice President and CTO
Health Language, Inc.
