date:20040615

Hi,
> 14.06.2004 09:41:31 ch.eugster.pos.db.Table describeError
> SCHWERWIEGEND: Can not init Identity for given object
> [EMAIL PROTECTED]
ok, this means that the Identity object couldn't be created. You do an 
insert, thus I assume that the sequence manager has a problem in lookup 
the next sequence.
Is this the whole stack trace you get?
No other logging messages before that?

regards,
Armin
Christian Eugster wrote:
Hi Armin,

hmm difficult to say what's going wrong. I can't find metadata for
'ch.eugster.pos.db.DBResult' class or what does this entry mean?

DBResult is just an object that capsulate the information a transaction is
providing me. As following:
DBResult result = receipt.store();
if receipt.store() returns an errorcode, DBResult logs this to my logger.
The relevant metadata are those i provided in my mail.
The situation is, that some clients are - as a load-test - inserting
concurrently records in the same db over a network. all clients use ojb (as
i mentioned before rc5). Sometimes i get also the following error:
14.06.2004 09:41:31 ch.eugster.pos.db.Table describeError
SCHWERWIEGEND: Can not init Identity for given object
[EMAIL PROTECTED]
where ch.eugster.pos.db.Table is the abstract superclass of
ch.eugster.pos.db.Position.
Does this information help you?
Thank you and regards
Christian
-
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]

AW: Duplicate key error when inserting a new record

2004-06-15 Thread Christian Eugster

Hi Armin,

> hmm difficult to say what's going wrong. I can't find metadata for
> 'ch.eugster.pos.db.DBResult' class or what does this entry mean?

DBResult is just an object that capsulate the information a transaction is
providing me. As following:

DBResult result = receipt.store();

if receipt.store() returns an errorcode, DBResult logs this to my logger.
The relevant metadata are those i provided in my mail.

The situation is, that some clients are - as a load-test - inserting
concurrently records in the same db over a network. all clients use ojb (as
i mentioned before rc5). Sometimes i get also the following error:

14.06.2004 09:41:31 ch.eugster.pos.db.Table describeError
SCHWERWIEGEND: Can not init Identity for given object
[EMAIL PROTECTED]

where ch.eugster.pos.db.Table is the abstract superclass of
ch.eugster.pos.db.Position.

Does this information help you?

Thank you and regards

Christian


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

Re: New Warnings in Managed Environment with RC7

Gary wrote:
Armin:
Thanks for the quick reply. Do you guys have a
"contribute" site like SourceForge so I could buy you
a beer?
Think I should avoid to drink alcohol, because your problem seems really
sophisticated ;-)

No, I wasn't using the "Sync" factory. When I change
to it, I get a new error:
2004-06-15 15:19:29,798 ERROR [TCP
Connection(7)-172.24.54.129] Connection is in local
transaction, do a 'localCommit' or 'localRollback'
beforeperform the connection release - rollback the
connection now
(org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java))
hmm, do you close the PB instance within the used method or before the
tx demarcation ends?
I assume you don't.

regards,
Armin

It has the following stack trace:
System Thread [TCP Connection(7)-172.24.54.129]
(Suspended)
ConnectionManagerImpl.releaseConnection() line: 295
PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
line: 240
PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
line: 418
RegisteredSyncs.distributeBefore() line: 110
TransactionImpl.internalPrepare() line: 1211
TransactionImpl.commit() line: 960
TranManagerImpl.commit() line: 150
TranManagerSet.commit() line: 182
My OJB.properties is as follows:
#
# OJB.properties -- configuration of the OJB runtime
environment
# Version: 1.0
# (c) 2001, 2002, 2003 Apache Software Foundation
# Author: Thomas Mahler and many others
# @version $Id: OJB.properties,v 1.70 2004/06/03
23:46:08 arminw Exp $
#
#
# repository file settings
#
# The repositoryFile entry tells OJB to use this file
as as its standard mapping
# repository. The file is looked up from the
classpath.
#
repositoryFile=repository.xml
#
# If the useSerializedRepository entry is set to true,
OJB tries to load a
# serialized version of the repository for performance
reasons.
# if set to false, OJB always loads the xml file.
# Setting this flag to true will accelerate the
startup sequence of OJB.
# If set to true changes to the repository.xml file
will only be detected
# after maually deleting the repository.xml.serialized
file.
useSerializedRepository=false
#
# If Repository serialization is used the entry
serializedRepositoryPath defines the
# directory where the Repository is written to and
read from.
# this entry is used only when the
useSerializedRepository flag is set to true
#
serializedRepositoryPath=.
#
#
# PersistenceBrokerFactory / PersistenceBroker
#
# The PersistenceBrokerFactoryClass entry decides
which concrete
# PersistenceBrokerFactory implemention is to be used.
#PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
# If in managed environment *only* the PB-api was used
it's recommended to use this factory
# to enable the PersistenceBroker instances to
participate in the JTA transaction. This makes
# e.g. PBStateListener work properly in managed
environments.
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
#
#
# The PersistenceBrokerClass entry decides which
concrete PersistenceBroker
# implementation is to be served by the
PersistenceBrokerFactory.
# This is the singlevm implementation:
PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl
#PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
#
# This is an implementation that uses Prevayler
(prevayler.sf.net) as the persistent storage.
# Using this implementation OJB works as a simple
OODBMS
#PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
#
#
# PersistenceBroker pool
#
# PersistenceBroker pool configuration
# This pool uses the jakarta-commons-pool api.
# There you can find things described in detail.
#
# maximum number of brokers that can be borrowed from
the
# pool at one time. When non-positive, there is no
limit.
maxActive=100
#
# controls the maximum number of brokers that can sit
idle in the
# pool (per key) at any time. When non-positive, there
is no limit
maxIdle=-1
#
# max time block to get broker instance from pool,
after that exception is thrown.
# When non-positive, block till last judgement
maxWait=2000
#
# indicates how long the eviction thread should sleep
before "runs" of examining
# idle objects. When non-positive, no eviction thread
will be launched.
timeBetweenEvictionRunsMillis=-1
#
# specifies the minimum amount of time that an broke

Re: New Warnings in Managed Environment with RC7

2004-06-15 Thread Gary

Armin:

Thanks for the quick reply. Do you guys have a
"contribute" site like SourceForge so I could buy you
a beer?

It has the following stack trace:
System Thread [TCP Connection(7)-172.24.54.129]
(Suspended)
ConnectionManagerImpl.releaseConnection() line: 295

PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
line: 240

PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
line: 418
RegisteredSyncs.distributeBefore() line: 110
TransactionImpl.internalPrepare() line: 1211
TransactionImpl.commit() line: 960
TranManagerImpl.commit() line: 150
TranManagerSet.commit() line: 182

My OJB.properties is as follows:
#
# OJB.properties -- configuration of the OJB runtime
environment
# Version: 1.0
# (c) 2001, 2002, 2003 Apache Software Foundation
# Author: Thomas Mahler and many others
# @version $Id: OJB.properties,v 1.70 2004/06/03
23:46:08 arminw Exp $
#
#
# repository file settings
#
# The repositoryFile entry tells OJB to use this file
as as its standard mapping
# repository. The file is looked up from the
classpath.
#
repositoryFile=repository.xml
#
# If the useSerializedRepository entry is set to true,
OJB tries to load a
# serialized version of the repository for performance
reasons.
# if set to false, OJB always loads the xml file.
# Setting this flag to true will accelerate the
startup sequence of OJB.
# If set to true changes to the repository.xml file
will only be detected
# after maually deleting the repository.xml.serialized
file.
useSerializedRepository=false
#
# If Repository serialization is used the entry
serializedRepositoryPath defines the
# directory where the Repository is written to and
read from.
# this entry is used only when the
useSerializedRepository flag is set to true
#
serializedRepositoryPath=.
#
#
# PersistenceBrokerFactory / PersistenceBroker
#
# The PersistenceBrokerFactoryClass entry decides
which concrete
# PersistenceBrokerFactory implemention is to be used.
#PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
# If in managed environment *only* the PB-api was used
it's recommended to use this factory
# to enable the PersistenceBroker instances to
participate in the JTA transaction. This makes
# e.g. PBStateListener work properly in managed
environments.
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
#
#
# The PersistenceBrokerClass entry decides which
concrete PersistenceBroker
# implementation is to be served by the
PersistenceBrokerFactory.
# This is the singlevm implementation:
PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl
#PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
#
# This is an implementation that uses Prevayler
(prevayler.sf.net) as the persistent storage.
# Using this implementation OJB works as a simple
OODBMS
#PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
#
#
# PersistenceBroker pool
#
# PersistenceBroker pool configuration
# This pool uses the jakarta-commons-pool api.
# There you can find things described in detail.
#
# maximum number of brokers that can be borrowed from
the
# pool at one time. When non-positive, there is no
limit.
maxActive=100
#
# controls the maximum number of brokers that can sit
idle in the
# pool (per key) at any time. When non-positive, there
is no limit
maxIdle=-1
#
# max time block to get broker instance from pool,
after that exception is thrown.
# When non-positive, block till last judgement
maxWait=2000
#
# indicates how long the eviction thread should sleep
before "runs" of examining
# idle objects. When non-positive, no eviction thread
will be launched.
timeBetweenEvictionRunsMillis=-1
#
# specifies the minimum amount of time that an broker
may sit idle
# in the pool before it is eligable for eviction due
to idle time.
# When non-positive, no object will be dropped from
the pool due
# to idle time alone (depends on
timeBetweenEvictionRunsMillis > 0)
minEvictableId

Re: New Warnings in Managed Environment with RC7

Hi Gary,
Gary wrote:
I am now getting the following warnings in a JTA
environment (this worked fine, no messages, before
RC7):
2004-06-15 13:32:26,728 WARN 
[Servlet.Engine.Transports : 0] No running tx found,
please only delete objects in context of an
PB-transaction, to avoid side-effects - e.g. when
rollback of complex objects
(org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java))

Looking into the code, it appears as though I am now
required to do a pb.beginTransaction() in even a
managed environment.  Am I missing something?
I assume you use PB-api in managed environment and when deleting an 
object you use a JTA-tx?

Did you set
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
in OJB.properties (introduced in rc6)?
regards,
Armin
Thanks for all your hard work, Gary

__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
-
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]

New Warnings in Managed Environment with RC7

2004-06-15 Thread Gary

I am now getting the following warnings in a JTA
environment (this worked fine, no messages, before
RC7):

2004-06-15 13:32:26,728 WARN 
[Servlet.Engine.Transports : 0] No running tx found,
please only delete objects in context of an
PB-transaction, to avoid side-effects - e.g. when
rollback of complex objects
(org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java))


Looking into the code, it appears as though I am now
required to do a pb.beginTransaction() in even a
managed environment.  Am I missing something?

Thanks for all your hard work, Gary



__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

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

Re: RE : OJB and RMI

No, we didnt see any error messages relating to this, probably because the 
logging configuration is set in OJB.properties.


Did you get a log message about that ? If not, then I should add one to 
make this easier for the next person with the same problem.


No problem!
Just for the record: do you have to use ClassHelper#setClassLoader to make 
it work with RMI ?
No, we did not need to do that.  All we needed to do was make sure 
OJB.properties, spy.properties, and the various repository.xml files could 
be found.  There wasn't any RMI specific steps that needed to be taken 
beyond granting permission in the RMI.policy file. We didnt even need to 
add ojb.jar to the codebase list.

Brad

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

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

Re: RE : OJB and RMI

Bradford Pielech wrote:
No, we didnt see any error messages relating to this, probably because 
the logging configuration is set in OJB.properties.
Well not exactly for two reasons: in rc7 and newer, logging settings can 
(and should) be specified in a separate file OJB-logging.properties. 
Also, a missing OJB.properties file should be noted in the boot log 
which does not need to be configured (it simply prints to stdout; e.g. 
the error message that you got is probably from the boot logger). I'll 
check the handling of a missing properties file.

No, we did not need to do that.  All we needed to do was make sure 
OJB.properties, spy.properties, and the various repository.xml files 
could be found.  There wasn't any RMI specific steps that needed to be 
taken beyond granting permission in the RMI.policy file. We didnt even 
need to add ojb.jar to the codebase list.
That's nice then, no need to configure OJB to make it work with RMI :-)
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE : OJB and RMI

Bradford Pielech wrote:
Tom:
Thanks for all your help.  Sometimes a fresh set of eyes can 
really help.  The problem was a misspelled path on the OJB.properties 
location.
Did you get a log message about that ? If not, then I should add one to 
make this easier for the next person with the same problem.

Now you can get back to your usual task of helping solve real 
OJB problems.

thanks again.
No problem!
Just for the record: do you have to use ClassHelper#setClassLoader to 
make it work with RMI ?

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

Re: RE : OJB and RMI

Tom:
Thanks for all your help.  Sometimes a fresh set of eyes can 
really help.  The problem was a misspelled path on the OJB.properties location.

Now you can get back to your usual task of helping solve real OJB 
problems.

thanks again.
Brad
At 06:31 PM 6/15/2004 +0200, you wrote:
Bradford Pielech wrote:
Tom:
Thanks for the pointer, but it still isn't working.  Here is 
some sample code inside the RMI server that illustrates the failure:

  String s = 
RMIClassLoader.getClassAnnotation(PersistenceBrokerFactory.class);
  ClassLoader cl = RMIClassLoader.getClassLoader(s);
  org.apache.ojb.broker.util.ClassHelper.setClassLoader(cl);
  PersistenceBroker pbroker = 
PersistenceBrokerFactory.defaultPersistenceBroker();
  System.out.println("PBroker: " + pbroker.toString());

This produces the error:
---
[BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, 
can't get PBF class object
--

Any other ideas?
Hmm, I'm by no means an RMI expert (at least in environments where 
performance is not an issue, I'd rather use XML-RPC), but I wonder whether 
the RMI classloader is correctly initialized to find OJB classes, or 
whether OJB is correctly configured.
Have a look into your OJB.properties file to see what the persistence 
broker factory class is that would used (property 
PersistenceBrokerFactoryClass). If this property is not defined, then the 
above error results (there is no default value for this property). If it 
is defined, then either the OJB.properties file could not be loaded (you 
should see this in the same log where the above error message was output), 
or the class could not be loaded.
In the first case, the OJB.properties file could probably not loaded (you 
can set its path manually using the system property "OJB.properties" prior 
to using *any* OJB class).
In the latter case, please try to load the class directly using the RMI 
classloader:

Class.forName(classname, true, cl);
and see what happens then.
Tom
-
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: [ANN] OJB 1.0rc7 Released

2004-06-15 Thread Edson Carlos Ericksson Richter

To me, default doesn't matters... Just be really clear in DOCS that the 
changes are made, because I've a near to 265000 loc here that uses 
either RemovalAware and Non-RemovalAware behaviour...

Best regards,
Edson Richter
Armin Waibel wrote:
Steve Clark wrote:
Armin Waibel writes:


Armin> ooh, seems I made a mistake in the test cases repository I
Armin> don't specified a "non-removeaware" collection-class. Maybe
Armin> I should read the docs before I start writing the next test
Armin> cases ;-).
Not to beat a dead horse, but I think this is yet another very clear
demonstration that the default behavior is counterintuitive.  It
really seems that it would be better for non-RemovalAwareCollection to
be the default, with RemovalAwareCollection available as an option for
those who want that behavior.

I agree with you, but some time ago the argument for using 
RemovalAwareCollections as default collection-class was to make PB-api 
delete collection objects behaviour similar to the ODMG-api. I don't 
know when we change collection-class, but originally 
non-RemovalAwareCollection was used as default one.

If most OJB user vote for an rollback to non-RAC, we can switch back 
again (hopefully the last time ;-)).
As an alternative I will have a look in source and try to make default 
collection-class pluggable via OJB.properties file. If it will be 
possible, we can satisfy both strategies.

regards,
Armin

-
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: Duplicate key error when inserting a new record

Hi Christian,
hmm difficult to say what's going wrong. I can't find metadata for 
'ch.eugster.pos.db.DBResult' class or what does this entry mean?

regards,
Armin
Christian Eugster wrote:
Hi!
I use OJB-1.0rc5 with a mysql (innodb) as backend. When we insert
concurrently objects that have two 1:n-relations into the same table
pos_receipt from e.g. 4 clients, we get the following
duplicate-primary-key-message:
14.06.2004 09:40:47 ch.eugster.pos.db.DBResult log
SCHWERWIEGEND: 23000: Duplicate key or integrity constraint violation,
message from server: "Duplicate entry '1822' for key 1"
ojb increments the primarykey (Long).
Has anybody an idea, what I am doing wrong?
Thank your!
Christian
the repository connection-descriptor looks like this:
---
...



 


...
---
the class-descriptors look like this:
XXX
pos_receipt



primarykey="true" indexed="true" access="readwrite" autoincrement="true"
nullable="true" locking="false" update-lock="true" default-fetch="false" />

jdbc-type="TIMESTAMP" primarykey="false" nullable="true" indexed="false"
autoincrement="false" locking="false" update-lock="true"
default-fetch="false" access="readwrite" />




































XXX































XXX




















XXX

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

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

Re: RE : OJB and RMI

Bradford Pielech wrote:
Tom:
Thanks for the pointer, but it still isn't working.  Here is 
some sample code inside the RMI server that illustrates the failure:

  String s = 
RMIClassLoader.getClassAnnotation(PersistenceBrokerFactory.class);
  ClassLoader cl = RMIClassLoader.getClassLoader(s);
  org.apache.ojb.broker.util.ClassHelper.setClassLoader(cl);
  PersistenceBroker pbroker = 
PersistenceBrokerFactory.defaultPersistenceBroker();
  System.out.println("PBroker: " + pbroker.toString());

This produces the error:
---
[BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance 
failed, can't get PBF class object
--

Any other ideas?
Hmm, I'm by no means an RMI expert (at least in environments where 
performance is not an issue, I'd rather use XML-RPC), but I wonder 
whether the RMI classloader is correctly initialized to find OJB 
classes, or whether OJB is correctly configured.
Have a look into your OJB.properties file to see what the persistence 
broker factory class is that would used (property 
PersistenceBrokerFactoryClass). If this property is not defined, then 
the above error results (there is no default value for this property). 
If it is defined, then either the OJB.properties file could not be 
loaded (you should see this in the same log where the above error 
message was output), or the class could not be loaded.
In the first case, the OJB.properties file could probably not loaded 
(you can set its path manually using the system property 
"OJB.properties" prior to using *any* OJB class).
In the latter case, please try to load the class directly using the RMI 
classloader:

Class.forName(classname, true, cl);
and see what happens then.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE : OJB and RMI

Tom:
Thanks for the pointer, but it still isn't working.  Here is some 
sample code inside the RMI server that illustrates the failure:

  String s = 
RMIClassLoader.getClassAnnotation(PersistenceBrokerFactory.class);
  ClassLoader cl = RMIClassLoader.getClassLoader(s);
  org.apache.ojb.broker.util.ClassHelper.setClassLoader(cl);
  PersistenceBroker pbroker = 
PersistenceBrokerFactory.defaultPersistenceBroker();
  System.out.println("PBroker: " + pbroker.toString());

This produces the error:
---
[BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, 
can't get PBF class object
--

Any other ideas?
Brad
At 04:54 PM 6/15/2004 +0200, you wrote:
Bradford Pielech wrote:
The problem occurs the very first time we call anything to do with 
PersistenceBroker. Another thing of note is that the RMI server and OJB / 
MySQL libraries are all on the same machine.
This seems to be a classloader problem, perhaps the thread's context 
classloader is the RMI classloader (which does not find OJB's classes) ? 
If you're using a fresh version of OJB (rc7 or CVS), then you can put 
breakpoints into the org.apache.ojb.broker.util.ClassHelper#getClass and 
#newInstance methods to see which classloader is used (the 
PersistenceBrokerFactory is present otherwise you'd get a different error, 
so this occurs within OJB). Using the ClassHelper class, you can also 
define which classloader OJB uses.

Tom
-
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: Three level inheritance problem - Null data from the mostly nested table

Hi Mariusz,
did you try latest release (rc7)? Jakob fix a problem with inheritance 
between rc6 and rc7.

regards,
Armin
Mariusz Wójcik wrote:
Hi
I try to realize three level of inheritance in OJB. My Class C extends 
Class B extends Class A each data are stored
in separate tables (Table A, Table B, Table C) . I've implemented it.
Inserts work fine. Inheritance is OK, all data are stored in tables.All 
references are OK.

I have problems with quering objects.
I try to get all C Class object. In each object I can't get access to 
data which are stored in A Table (they are null).
But when I try to list A Class Objects, their data are complete.

I noticed very strange thing.
When I try to list object in this order, both methods works fine 
(Collection returned by method getCClassObject is OK, all object,s data 
are complete):
...

Collection AClassObjects=getAClassObjects(); //getting A Class objects
Collection CClassObjects=getCClassObjects(); //getting C Class objects
...
But my problems start when I try to invoke only one method:
..
Collection CClassObjects=getCClassObjects(); //getting C Class object
..
Object of CClassObjects collection haven't data stored in A table (the 
mostly nested)...

I have to use the other solution... but it doesn't work Please help 
me ...

Best regards
mario
-
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: [ANN] OJB 1.0rc7 Released

Hi Gary,
Gary wrote:
Can someone please clarify exactly what property
changed in OJB.properties as mentioned below?  Thanks.
OJB.properties file new properties:
-ListProxyClass
-IndirectionHandlerClass
-SetProxyClass
-RowReaderDefaultClass
odmg specific
-ImplementationClass
The logging properties moved to a separate file.
regards,
Armin


- OJB.properties file has changed, don't forget to
replace on update! 
One new property
to set in managed environments.

--- Brian McCallister
<[EMAIL PROTECTED]> wrote:
The OJB team would like to announce the release of
Apache 
Object/Relational Bridge (OJB) 1.0rc7.

This release will hopefully be the final release
candidate before 
version 1.0. If no major problems
are discovered, OJB 1.0 will be released in one
week.

DOWNLOADS
http://db.apache.org/builds/ojb/
CHANGES:
- New Apache Forrest generated web site.
- OJB.properties file has changed, don't forget to
replace on update! 
One new property
to set in managed environments.

- Logging settings have moved to separate
OJB-logging.properties file
- Logging initialization is now decoupled form OJB
initialization; this 
is
described in the new reference guide for logging

- It is no longer necessary to provide an empty
repository.xml file 
when starting
without repository and connection descriptors

- rename/move internal package
org.apache.ojb.odmg.transaction to 
org.apache.ojb.broker.transaction.tm
In managed environments each (top-level) API use
transaction manager 
access, thus the TM related
classes are moved to the PB kernel and
OJB.properties entries change.

- Base class for ODMG api access within non- or
managed environments is 
now
org.apache.ojb.odmg.OJB. The used
org.odmg.Implementation interface 
implementation
is specified in OJB.properties.

- ConnectionManager is more strict on
CM.releaseConnection() method 
calls. Now an
exception is thrown when CM is in a "local
transaction" status when try 
to release
the connection. The local tx status of
ConnectionManager and 
PersistenceBroker implementation
is now decoupled, useful in managed environments
allows to "close the 
connection" without
change the PB tx-state.

- the indirection handler (for reference proxies),
and the list and set 
proxy classes
can now be configured in the OJB.properties file

- new CollectionProxy interface introduced to allow
the ODMG api to 
make use of alternate collection
proxy implementations.

KNOWN ISSUES:
- odmg-api: It is not possible to exchange objects
in 1:n references.
- odmg-api: Creation of m:n relation only works when
objects created 
step by step (or use PB-api
as workaround), persist a whole object graph doesn't
work. On delete of 
collection objects from a m:n relation
objects will be deleted from the indirection table
and (unexpected 
behaviour) from the referenced
table too.

- A count on ReportQueries containing groupBy does
not deliver a 
correct result.

- Batch handling doesn't work properly with
optimistic locking.
- ReportQueries should not be used with columns
referencing Classes 
with extents.



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




__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
-
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: [ANN] OJB 1.0rc7 Released

Steve Clark wrote:
Armin Waibel writes:

Armin> ooh, seems I made a mistake in the test cases repository I
Armin> don't specified a "non-removeaware" collection-class. Maybe
Armin> I should read the docs before I start writing the next test
Armin> cases ;-).
Not to beat a dead horse, but I think this is yet another very clear
demonstration that the default behavior is counterintuitive.  It
really seems that it would be better for non-RemovalAwareCollection to
be the default, with RemovalAwareCollection available as an option for
those who want that behavior.
I agree with you, but some time ago the argument for using 
RemovalAwareCollections as default collection-class was to make PB-api 
delete collection objects behaviour similar to the ODMG-api. I don't 
know when we change collection-class, but originally 
non-RemovalAwareCollection was used as default one.

If most OJB user vote for an rollback to non-RAC, we can switch back 
again (hopefully the last time ;-)).
As an alternative I will have a look in source and try to make default 
collection-class pluggable via OJB.properties file. If it will be 
possible, we can satisfy both strategies.

regards,
Armin

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

Re: [ANN] OJB 1.0rc7 Released

2004-06-15 Thread Steve Clark

> Armin Waibel writes:

Armin> ooh, seems I made a mistake in the test cases repository I
Armin> don't specified a "non-removeaware" collection-class. Maybe
Armin> I should read the docs before I start writing the next test
Armin> cases ;-).

Not to beat a dead horse, but I think this is yet another very clear
demonstration that the default behavior is counterintuitive.  It
really seems that it would be better for non-RemovalAwareCollection to
be the default, with RemovalAwareCollection available as an option for
those who want that behavior.

-- 
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291


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

Re: RE : OJB and RMI

Bradford Pielech wrote:
The problem occurs the very first time we call anything to do with 
PersistenceBroker. Another thing of note is that the RMI server and 
OJB / MySQL libraries are all on the same machine.
This seems to be a classloader problem, perhaps the thread's context 
classloader is the RMI classloader (which does not find OJB's classes) ? 
If you're using a fresh version of OJB (rc7 or CVS), then you can put 
breakpoints into the org.apache.ojb.broker.util.ClassHelper#getClass and 
#newInstance methods to see which classloader is used (the 
PersistenceBrokerFactory is present otherwise you'd get a different 
error, so this occurs within OJB). Using the ClassHelper class, you can 
also define which classloader OJB uses.

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

Pb on jdo.getCol and Delete

2004-06-15 Thread Emmanuel DUPONT

All,

 

I retrieve a jdo collection with the jdo.getCol method. I'm using dynamic
proxy. OJB RC7 same pb in RC6 

I'm using an iterator on this col and delete each object retrieve.

 

Later (not all time but 50% time) I commit and I have an Unmaterialized
proxy error !!

 

It seems that after a while (undefined time) the proxy is unmaterialized and
the commit could not order to delete the object ..

 

Database db = impl.getDatabase(product);
Collection col = jdo.getCol();
Iterator iter = col.iterator();
 
While (iter.hasNext()) {
   Jdoxx myxx = iter.next();
   db.deletePersistent(myxx);
}

 

 

blablablablablablabla.later on

 

commit();

 

 

What wrong in my logic ???

 

Any help would be appreciated! Tx !!

RE : OJB and RMI

The problem occurs the very first time we call anything to do with 
PersistenceBroker. Another thing of note is that the RMI server and OJB / 
MySQL libraries are all on the same machine.

Brad

At 04:36 PM 6/15/2004 +0200, you wrote:
A thread problem ?
Does your problem occurs the first call or only next one ?

Jean-Baptiste BRIAUD  SYSDEO
  www.sysdeo.com
software engineer  www.eclipsetotale.com
> -Message d'origine-
> De : Bradford Pielech [mailto:[EMAIL PROTECTED]
> Envoyé : mardi 15 juin 2004 16:34
> À : OJB Users List
> Objet : OJB and RMI
>
> Hello all:
>
> I am having running into a problem. I have an RMI server which intends to
> make calls to MySQL, using PersistencBroker. It fails when I call:
>
> 
> PersistenceBroker pbroker =
> PersistenceBrokerFactory.defaultPersistenceBroker();
> 
>
> with:
> -
> [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed,
> can't get PBF class object
> ---
>
> If I remove RMI from the equation, everything works fine, i.e. the
> PersistenceBroker calls succeed.  With RMI, the Remote Server gets a
> "NoClassDefFoundError" For the PersistenceBrokerFactory.
>
> Is there possibly anything in the OJB configuration that might affect this
> environment?  Has anyone else been able to get OJB to work in this
> scenario?
>
> Thanks,
> Brad
>
>
>
> -
> 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 : OJB and RMI

2004-06-15 Thread Jean-Baptiste BRIAUD

A thread problem ?
Does your problem occurs the first call or only next one ?


Jean-Baptiste BRIAUD  SYSDEO
  www.sysdeo.com
software engineer  www.eclipsetotale.com

> -Message d'origine-
> De : Bradford Pielech [mailto:[EMAIL PROTECTED]
> Envoyé : mardi 15 juin 2004 16:34
> À : OJB Users List
> Objet : OJB and RMI
> 
> Hello all:
> 
> I am having running into a problem. I have an RMI server which intends to
> make calls to MySQL, using PersistencBroker. It fails when I call:
> 
> 
> PersistenceBroker pbroker =
> PersistenceBrokerFactory.defaultPersistenceBroker();
> 
> 
> with:
> -
> [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed,
> can't get PBF class object
> ---
> 
> If I remove RMI from the equation, everything works fine, i.e. the
> PersistenceBroker calls succeed.  With RMI, the Remote Server gets a
> "NoClassDefFoundError" For the PersistenceBrokerFactory.
> 
> Is there possibly anything in the OJB configuration that might affect this
> environment?  Has anyone else been able to get OJB to work in this
> scenario?
> 
> Thanks,
> Brad
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




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

OJB and RMI

Hello all:
I am having running into a problem. I have an RMI server which intends to 
make calls to MySQL, using PersistencBroker. It fails when I call:


PersistenceBroker pbroker = 
PersistenceBrokerFactory.defaultPersistenceBroker();


with:
-
[BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, 
can't get PBF class object
---

If I remove RMI from the equation, everything works fine, i.e. the 
PersistenceBroker calls succeed.  With RMI, the Remote Server gets a 
"NoClassDefFoundError" For the PersistenceBrokerFactory.

Is there possibly anything in the OJB configuration that might affect this 
environment?  Has anyone else been able to get OJB to work in this scenario?

Thanks,
Brad

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

Re: [ANN] OJB 1.0rc7 Released

2004-06-15 Thread Gary

Can someone please clarify exactly what property
changed in OJB.properties as mentioned below?  Thanks.

> - OJB.properties file has changed, don't forget to
> replace on update! 
> One new property
> to set in managed environments.

--- Brian McCallister
<[EMAIL PROTECTED]> wrote:
> The OJB team would like to announce the release of
> Apache 
> Object/Relational Bridge (OJB) 1.0rc7.
> 
> This release will hopefully be the final release
> candidate before 
> version 1.0. If no major problems
> are discovered, OJB 1.0 will be released in one
> week.
> 
> 
> DOWNLOADS
> 
> http://db.apache.org/builds/ojb/
> 
> 
> CHANGES:
> 
> - New Apache Forrest generated web site.
> 
> - OJB.properties file has changed, don't forget to
> replace on update! 
> One new property
> to set in managed environments.
> 
> - Logging settings have moved to separate
> OJB-logging.properties file
> 
> - Logging initialization is now decoupled form OJB
> initialization; this 
> is
> described in the new reference guide for logging
> 
> - It is no longer necessary to provide an empty
> repository.xml file 
> when starting
> without repository and connection descriptors
> 
> - rename/move internal package
> org.apache.ojb.odmg.transaction to 
> org.apache.ojb.broker.transaction.tm
> In managed environments each (top-level) API use
> transaction manager 
> access, thus the TM related
> classes are moved to the PB kernel and
> OJB.properties entries change.
> 
> - Base class for ODMG api access within non- or
> managed environments is 
> now
> org.apache.ojb.odmg.OJB. The used
> org.odmg.Implementation interface 
> implementation
> is specified in OJB.properties.
> 
> - ConnectionManager is more strict on
> CM.releaseConnection() method 
> calls. Now an
> exception is thrown when CM is in a "local
> transaction" status when try 
> to release
> the connection. The local tx status of
> ConnectionManager and 
> PersistenceBroker implementation
> is now decoupled, useful in managed environments
> allows to "close the 
> connection" without
> change the PB tx-state.
> 
> - the indirection handler (for reference proxies),
> and the list and set 
> proxy classes
> can now be configured in the OJB.properties file
> 
> - new CollectionProxy interface introduced to allow
> the ODMG api to 
> make use of alternate collection
> proxy implementations.
> 
> 
> KNOWN ISSUES:
> 
> - odmg-api: It is not possible to exchange objects
> in 1:n references.
> 
> - odmg-api: Creation of m:n relation only works when
> objects created 
> step by step (or use PB-api
> as workaround), persist a whole object graph doesn't
> work. On delete of 
> collection objects from a m:n relation
> objects will be deleted from the indirection table
> and (unexpected 
> behaviour) from the referenced
> table too.
> 
> - A count on ReportQueries containing groupBy does
> not deliver a 
> correct result.
> 
> - Batch handling doesn't work properly with
> optimistic locking.
> 
> - ReportQueries should not be used with columns
> referencing Classes 
> with extents.
> 
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

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

Re: [ANN] OJB 1.0rc7 Released

Hi Steve,
Steve Clark wrote:
Brian> - odmg-api: Creation of m:n relation only works when
Brian> objects created step by step (or use PB-api as workaround),
Brian> persist a whole object graph doesn't work. On delete of
Brian> collection objects from a m:n relation objects will be
Brian> deleted from the indirection table and (unexpected
Brian> behaviour) from the referenced table too.
me> Also unsure about the deletion piece: Does this mean that
me> auto-delete="link" doesn't work with ODMG any more (it's been
me> working ok in RC6)?
Armin> hmm, at all times the top-level api need the default values
Armin> for auto-xxx settings:
Armin> auto-retrieve true
Armin> auto-update false
Armin> auto-delete false
Armin> But except for auto-delete on 1:1 relation, 'false' is
Armin> equals with 'link'.
Oops.  I shouldn't have brought in auto-delete.  It sounds from the
release notes like there's a new behavior where removing an object
from an m:n relation removes the object from the db, as well.  Is this
only with RemovalAwareCollection (in which case I think it's
expected?), or is this with all collection classes (in which case I
think it's a new behavior and very seriously broken)?
ooh, seems I made a mistake in the test cases repository I don't 
specified a "non-removeaware" collection-class. Maybe I should read the 
docs before I start writing the next test cases ;-).

Will check this and remove the entry in the release notes if I have success.
Steve, thank you very much!
regards,
Armin
thanks,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cascading anonymous keys

Hi Brian,
Brian Latimer wrote:
Armin,
I have tried my code with rc7 and I still have the problem I described.
Looking at the test case you have written, it seems to produce the 
results I would like.  That is, your code does not return null objects 
for objects that should be retrieved via anonymous foreign keys 
contained within nested objects.

The only major difference I have seen between your test case and my code 
thus far is that you have a reference to a "Person" within the 
PersonDetail.
This shouldn't be a problem. In the test I set auto-retrieve to false 
for this reference. But I will try to run the test without the reference 
to be sure.


public static class PersonDetail implements PersonDetailIF
{
Integer id;
String profile;
Person person;   // <-  I don't have 
this reference
GenderIF gender;
...

I tried adding a reference like you have but ended up with the same 
results that I had without such a reference.

My code looks very much like your test case, but I still get nulls on my 
nested objects if I use anonymous keys and turn proxies off.
While I think you have shown that the problems must be with my code 
somewhere, I'm certainly baffled as to what might be wrong.

I am using PersistentFieldIntrospectorImpl and most of my properties are 
private, do you suppose that would cause a problem on nested objects?

I run PrimaryKeyForeignKeyTest.java with PersistentFieldIntrospectorImpl 
 but all tests pass, thus it seems that this isn't the problem.

A difference between your test and PrimaryKeyForeignKeyTest is that you 
using another SequenceManager to generate the PK values (assume you are 
using SequenceManagerNativeImpl, because PK was set to 'readonly'). I 
don't know if this could be a problem, maybe you try to run your test 
with another SequenceManager (e.g. SequenceManagerInMemoryImpl and non 
Identity column for PK).

regards,
Armin

Thank you very much for looking into this for me.
Brian
At 08:58 AM 06/12/2004, Armin Waibel wrote:
Hi Brian,
I tried to reproduce your problem (with latest from CVS) without 
success. A new test case was added to test suite 
([db-ojb]/src/test/org/...) called PrimaryKeyForeignKeyTest.java, the 
mapping is declared in repository_junit_reference.
Please have a look at this test, does it reproduce your problem?

regards,
Armin


-
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: Launching a statement SQL fom OJB

Hi Paolo,
Paolo Salvan wrote:
Hi!
Suppose I've to do something in the DB launching directly an SQL statement, 
bypassing OJB how can I do it?
Please see
http://db.apache.org/ojb/docu/faq.html#performSQL
http://db.apache.org/ojb/docu/connection.html#obtain-connection
And how to prevent problems with the object cache of OJB?
Currently the only way is to clear the cache.
broker.clearCache();
regards,
Armin
ie: if a launch "UPDATE costs_table SET cost = cost + 10", but some record has 
already been loaded in memory by OJB...how can I get them updated?

(same problems for inserts and updates...)
Thanks and bye!
Paolo
-
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: RC7 contains JBoss TX fix? was Re: [ANN] OJB 1.0rc7 Released