OJB behavior question

[Larry V. Streepy, Jr.]

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: Problem with reading records having a PK with value 0 (not null)

[Armin Waibel]

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






//
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:

 



 


 


 


...


  



 

  

 

 

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, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to program against the ODMG personality correctly?

[Sean Dockery]

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);
> configu

OJB and DBMS\'s that don\'t support column aliases

[gbu]

Hi,

I would like to know whether OJB support DBMS's (like IBM's DB2/VSE VM) that
don't allow column aliases in SQL-select statements?

E.g. "Select TB_EMP as employee, ..."  doesn't work, it should be "Select
TB_EMP, ...".

I wonder if this will work with OJB and more particularly with JDO?  





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Real world OJB applications

[Ilkka Priha]

Here is one other, a web interface to the Microsoft Northwind sample 
database based on Apache Velocity and OJB:

http://ptuuli.myapp.info/ (username = "vieras", password = "vieras")

Its not a real application itself, but we've applied the same technology 
and framework to more complicated databases that are already in 
production use or will soon be after OJB 1.0 final has been released.

The Tammi framework is also a source forge project:

http://tammi.sourceforge.net

-- Ilkka

Sean Dockery wrote:
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]
.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Real world OJB applications

[Sean Dockery]

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: error parsing repository.xml

[Larry V. Streepy, Jr.]

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 repository:
repository_user.xml
  
    at
org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:13

Re: Fwd: Using a non-existent collection inside a query

[edson . richter]

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: Fwd: Using a non-existent collection inside a query

[Jakob Braeuchi]

hi edson,

[EMAIL PROTECTED] wrote:

i do not see where this happens ?


i meant i do not see where the keys in referenced objects are set...
btw. there have been changes in storeCollection recently
jakob


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]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fwd: Using a non-existent collection inside a query

[edson . richter]

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

[edson . richter]

> 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

[Jakob Braeuchi]

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

[edson . richter]

>
> 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: FW: NetBeans and OJB

[edson . richter]

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.

Re: Fwd: Using a non-existent collection inside a query

[Jakob Braeuchi]

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

[Armin Waibel]

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.(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:


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

RE: join and retrieve single object?

[Ron Gallagher]

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: ODMG Update Collection Problem

[Ralf Geiger]

- 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]

ODMG Update Collection Problem

[Ralf Geiger]

Hi,

According to the mailing list I know that lots of people have similar problems. 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)

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

Re: error parsing repository.xml

[Armin Waibel]

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:



&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 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)
  

Re: error parsing repository.xml

[Armin Waibel]

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 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


-

[Fwd: How to call a select store procedure in OJB]

[Thomas Mahler]

 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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FW: NetBeans and OJB

[Muhammad Aamir]

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.(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:



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 - 
  From: Muhammad Aamir 
  To: OJB Users List 
  Sent: Friday, January 09, 2004 9:38 AM
  Subject: RE: FW: Ne