-------- Original Message --------
Subject: OJB Framework: Bugs and Questions
Date: Sun, 17 Nov 2002 21:34:38 -0000
From: "Werner Schulz" <[EMAIL PROTECTED]>
Reply-To: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Dear Thomas,
Sorry to write in english, but in technical matters like this one, it
just flows easier.
We have started to use the OJB framework for a big J2EE application
since it fits our needs best (not too complicated but with sufficient
SQL-like features like programmatic queries) which other OR frameworks
seem to lack. So I am quite happy about using OJB.
However, I have come across some problems, mainly due to my (lack
of)understanding of
OJB, but in a few cases due to bugs.
On a more fundamental level, I would like to understand the
implications
J2EE has on the use of OJB. The docs are still somewhat thin here.
>From what you will see below, I've got J2EE and OJB running for some
very simple stuff. But I haven't yet tested the core elements of J2EE
(concurrency->threads and transactions) and OJB's behaviour.
Just answers to some basic questions would help me a great deal:
a) We are using the PersistenceBrokerFactory straight as in
aBroker = PersistenceBrokerFactory
.createPersistenceBroker( new PBKey("repository.xml") );
since I can't seem to see a way to initiate it otherwise using Oracle's
J2EE (EJB 1.1) 9iAS server. (The suggested Jboss setup just doesn't
apply
for us.)
Any experience/reasons why this approach may be incorrect?
b) If I call the broker factory several times in methods that are
part of a J2EE transaction, will the rollback work correctly? I.e.,
if I avoid any call to transactions via OJB, will my J2EE transactions
work as expected?
Two cases which I think are bugs:
a) (can't find the class but somewhere) the OJB properties file is
called in from
the classpath and the string ".properties" is attached, then the
resource
is called in. I think the file extension must not be used when using a
ResourceBundle to read properties since this is automatically attached.
b) a more fundamental error occurs when handling 1:N associations.
I am using my own class for primary/foreign keys. When a contained
object
in a collection is assigned the id of the containing object, OJB uses
the
type since it has converted the primary key(s) of the containing object
already into the SQL type.
Example: I have a List (id:PK,name:String) where PK is my own
PrimaryKey class (I have also written a converter for this,
it maps PK to BIGINT and vice versa).
List contains entries, where an entry has the fields
(id:PK, parentid:PK, name:String, ...)
When storing the List object, I get an exception since OJB tries to
set the parentid with a java.lang.Long value.
I have identified the lines of code that are causing this:
(OJB 0.9.7)
In class
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl (version 1.58)
in method "assertFkAssignment" (line 653) there is a call:
fld.getPersistentField().set(obj, refPkValues[i]);
Here the PK object "refPkValues[i]" has the wrong type (Long instead of
PK).
This is due to the keys returned from class
org.apache.ojb.broker.metadata.ClassDescriptor (version 1.30)
in method "getKeyValues"
where values are converted to their SQL types in line 841.
Since values here are set on the Java level, it is obviously wrong
to use key values that have been converted to SQL-compatible values
(ie. my PK is now a Long, etc.)
I have not checked whether M:N associations are also affected by this.
(I will soon find out since they coming soon.)
A Suggestion beyond current OJB:
I would like to see a more sophisticated approach when setting values.
I don't like to expose default constructors when a proper object model
would use constructor arguments when creating an object. Hence I would
like to replace the setters with constructors that take arguments.
One could place constructor instructions into the mapping file:
<class-descriptor ...>
<constructor>
<field refid="1"/>
<field refid="3"/>
<field refid="4"/>
<constructor>
<field ..../>
</class-descriptor>
which means that field 1,3,4 should be set in the constructor but not
necessarily later via setters. (Getters are required since one needs
to store the fields somehow!)
I am looking forward to hearing from you.
Best regards,
Werner
Werner Schulz
Cambridge, UK
work: [EMAIL PROTECTED]
home: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
