Re: 1:m-relation
Yes, exactly what I do. But see, to B instances be stored in database, you
must put auto-update='true' in your collection descriptor.
In real, I use a collection class RemovalAwareCollection (or a specialized
RemovalAwareList that I've created) to auto-delete. So, if I
a.getCol().remove( 0 );
broker.store(a);
the item in 0 is deleted from database, as expected. This is a must for my
app.
Best regards,
Edson Richter
- Original Message -
From: James Nyika [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 4:46 PM
Subject: Re: 1:m-relation
Edson,
Can i ask you to give an example of how you add more B objects the the
collection you described below
do you do something like this :
//get broker
broker = brokerfactory.defaultInstance();
//fetch an A object that has say 3 B objects in the collection.
...
//create a new B object
B newB = new B();
//add to the collection
A.getCol().add(newB);
//persist the A
broker.beginTransaction();
broker.store(A);
broker.commitTransaction();
?
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/8/2003 12:24:28 PM
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try to
give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
class-descriptor
class=A
table=TB_A
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
collection-descriptor
name=col
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
/class-descriptor
class-descriptor
class=B
table=TB_B
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
field-descriptor
name=idA
column=ID_A
jdbc-type=INTEGER
primarykey=true /
reference-descriptor
name=a
class-ref=A
foreignkey field-ref=idA/
/reference-descriptor
/class-descriptor
And this should work. You don't need to specify auto-retrieve, because
by
default it's true. Auto-update and auto-delete are false by default.
Some
people like to work with specialized collection classes. In particular,
I
work always with RemovalAwareList (a collection that know how to
persists
deletes in the collection). To archieve this, your should be more
specific
in collection descriptor like this:
collection-descriptor
name=col
collection-class=org.apache.ojb.broker.util.collections.RemovalAwareList
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
Of course, you could mixes the several other options that OJB offers to
you,
like auto-increment, proxies and so on. In this case, I'll recomendly
you to
use cvs HEAD that has several fixes for these options over rc3.
Best regards,
Edson Richter
- Original Message -
From: Christian Eugster [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 07, 2003 11:31 AM
Subject: 1:m-relation
i am working on a mysql-database and ojb rc3. i have an 1:m-relation
with
the following setting in the collection-desriptor of the parent
object:
auto-retrieve=true
when i try to retrieve an parent-object i get the error-message as
follows:
(setting auto-retrieve to false there is no error). what am i doing
wrong?
java.lang.IllegalArgumentException
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.
java:63)
at java.lang.reflect.Field.set(Field.java:519)
at
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un
known Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
Re: DateTime conversion problem again
What your GMT? In my case, all date/time are stored in database with -3 hours, because I'm on GMT-3. I'm using SapDB. I think that is this you getting, and it's a internationalization Java feature... Can someone else confirm this? Edson Richter - Original Message - From: Mykola Ostapchuk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 9:23 PM Subject: DateTime conversion problem again Sorry to post this question again, I still can't solve the problem. Any help will be very appreciated! Can anybody tell me how to map DateTime MySql field in OJB? My realization is the next: field-descriptor id=13 name=userDateInserted column=US_date_inserted jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlTimest ampFieldConversion/ userDateInserted - of type java.util.Date. After setting the Date, OJB inserts right date. But time is 1 hour minus of the actual time (minutes and seconds are right). Interesting, the userDateInserted has right Date value, but after passing it thru OJB, Date is decreased for 1 hour... Is it some kind of a bug? Am I doing something wrong? Any suggestions? Regards, Mykola Ostapchuk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.497 / Virus Database: 296 - Release Date: 4/7/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Can you try to change from log.error to e.printStackTrace() so we can have
more info about line/stack trace?
The code you are using to obtain the broker is exatly same I'm using, so
it's right.
What about .xml and .dtd? You remembered to updated too?
Edson
- Original Message -
From: Mykola Ostapchuk [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 9:14 PM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Hello,
I've spent 2 days trying to migrate my application from OJB 0.9.7 to OJB
1.0.rc3, and still no success.
The problem is - I can't instantiate broker with the next line:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
I'm using default OJB.properties from 1.0 rc3. I have db-ojb-1.0.rc3.jar and
all additional *.jar files in /lib folder.
I debug RepositoryXmlHandler and it seems there're no problems (see code
snap from pevious message below).
Line:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
generates some error I don't know how to cach.
log.error in cach statement doesn't print anything.
try {
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
usersVO.setUsername(username);
usersVO.setPassword(password);
Query query = new QueryByCriteria(usersVO);
usersVO = (UsersVO) broker.getObjectByQuery(query);
} catch (Exception e) {
log.error(PersistenceBrokerException thrown in UsersDAO.findByUP():
+ e.toString());
}
With OJB 0.9.7 everything works fine.
I'll very appreciate any help!
Regards,
Mykola Ostapchuk
- Original Message -
From: Mykola Ostapchuk [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 11:52 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Sorry for the previous message. Here's the log:
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - startDoc
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler -
descriptor-repository
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - documentation
15DEBUG [Thread-5] metadata.RepositoryXmlHandler -
class-descriptor
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
isolation-level:
read-uncommitted
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - class:
com.iprs.web.users.UsersVO
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - proxy: null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - table: users
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - row-reader:
null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - extends: null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - accept-locks:
true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - accept-locks:
true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
initialization-method: null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - refresh: true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
field-descriptor
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - name: userId
46DEBUG [Thread-5] metadata.RepositoryXmlHandler - column: US_id
46DEBUG [Thread-5] metadata.RepositoryXmlHandler - jdbc-type:
BIGINT
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: endDoc
- Original Message -
From: Thomas Mahler [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 1:57 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
this is most likely a problem during the parsing of the repository.
please set the debug level for XmlRepositoryHandler to DEBUG to see
where the repository problems are.
cheers,
Thomas
Mykola Ostapchuk wrote:
Hello,
I have a problem with migrating from OJB 0.9.7 to OJB 1.0.rc3.
What I did:
- replaced db-ojb-0.9.7.jar with db-ojb-1.0.rc3.jar.
- built new OJB internal DB tables.
- replaced old OJB.properties with a new one.
- replaced repository.dtd with a new one.
- modified repository.xml for a new version.
I can't instantiate broker. I see no error messages:
try {
log.info(Can see this message***);
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
log.info(Can not see this
message***);
} catch (Exception e) {
log.info(Can not see this
message***);
}
Is there something I've missed?
Regards,
Mykola Ostapchuk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Re: Help in store function call in PersistenceBroker
I had this (exactly) stack trace when I made some reference (foreign key)
with two fields mapping for a table that has only one field in primary key.
I think OJB must check if fkfields[].length == pkfield[].lenght, and throw a
better explanatory exception. The code in PersistenceBrokerImpl should be
similar to
// MBAIRD: we have 'disassociated' this object from the referenced
object,
// the object representing the ord is now null, so set the fk to
null.
if (ref == null)
{
refPkValues = new Object[objFkFields.length];
}
else
{
// BRJ: ref may be Proxy
Class refClass = ProxyHelper.getRealClass(ref);
ClassDescriptor refCld =
descriptorRepository.getDescriptorFor(refClass);
refPkValues = brokerHelper.getKeyValues(refCld, ref, false);
}
if( ojbFkFields.lenght != refPkValues.lenght )
throw new PersistenceBrokerException(The number of fields in
foreign key doesn't match the number of fields in primary key ( +
realObj.getClass().getName() + ));
for (int i = 0; i objFkFields.length; i++)
{
objFkFields[i].getPersistentField().set(realObj,
refPkValues[i]);
}
Jakob, Armin, Thomas can someone confirm this?
Edson Richter
- Original Message -
From: Chiah Tong Kiat [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 11:38 PM
Subject: Help in store function call in PersistenceBroker
Hi
I'm having some problem when I attempt to store the database.
It's throwing the stack trace following stack trace
com.fedex.cih.jp.JPShipmentImpl.setMDEDetails(JPShipmentImpl.java:424)
2003-07-0
9 02:03:00,843 ERROR [ExecuteThread: '8' for queue: 'default']
jp.JPShipmentImpl
(JPShipmentImpl.java:424) -
org.apache.ojb.broker.PersistenceBrokerException: C
ould not generate primary key values for given Identity
com.fedex.data.ShipmentCoreClearanceImpl{2057001}, exception was
java.lang.Array
IndexOutOfBoundsException
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:263)
at
org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:204)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.assertFkAssignment(Persiste
nceBrokerImpl.java:730)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.assignReferenceFKs(Persiste
nceBrokerImpl.java:2104)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBroker
Impl.java:1935)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl
.java:1874)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl
.java:660)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersi
stenceBroker.java:158)
at
com.fedex.cih.jp.JPShipmentImpl.setMDEDetails(JPShipmentImpl.java:370)
at
com.fedex.cih.ejb.ShipmentBean.setMDEDetails(ShipmentBean.java:159)
at
com.fedex.cih.ejb.ShipmentBean_6ssy2e_EOImpl.setMDEDetails(ShipmentBean_6ssy
2e_EOImpl.java:202)
at
com.fedex.cih.ejb.ShipmentBean_6ssy2e_EOImpl_WLSkel.invoke(Unknown Source)
at
weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at
weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at
weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManage
r.java:821)
at
weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308)
at
weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:3
0)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
rethrown as org.apache.ojb.broker.PersistenceBrokerException: Could not
generate
primary key values for given Identity
com.fedex.data.ShipmentCoreClearanceImpl{2057001}, exception was
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:275)
at
org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:204)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.assertFkAssignment(Persiste
nceBrokerImpl.java:730)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.assignReferenceFKs(Persiste
nceBrokerImpl.java:2104)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBroker
Impl.java:1935)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl
.java:1874)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl
.java:660)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersi
stenceBroker.java:158)
at
com.fedex.cih.jp.JPShipmentImpl.setMDEDetails(JPShipmentImpl.java:370)
Re: transaction in JBoss with MySQL Datasource
Hi, try to use JTA UserTransaction or container-managed tx and do not use ODMG tx-declaration. UserTransaction utx = ... utx.begin() db.deletePersistent(toBeDeleted); /* here it crashes */ utx.commit() HTH regards, Armin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 3:25 PM Subject: transaction in JBoss with MySQL Datasource Hello! I' using JBoss 3.0.6, OJB rc3 and a MySQL Database, which is configured as a Datasource for Local Transaction. I'm trying to delete an object but I'm having some problems with the transaction. I have tried several things with the following results: - 1. Use only of org.odmg.Transaction: Transaction tx = odmg.currentTransaction(); if ( !tx.isOpen()) tx.begin(); db.deletePersistent(toBeDeleted); /* here it crashes */ tx.commit(); Result: org.odmg.TransactionNotInProgressException: No external transaction found at org.apache.ojb.odmg.JTATxManager.registerTx(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.begin(Unknown Source) at org.apache.ojb.odmg.OJBJ2EE_2.beginInternTransaction(Unknown Source) at org.apache.ojb.odmg.OJBJ2EE_2.currentTransaction(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete(S erve rOjbDAO.java:227) --- 2. Use only of UserTranscation: UserTransaction userTx = (UserTransaction) context.lookup(java:/comp/UserTransaction); userTx.begin(); db.deletePersistent(toBeDeleted); /* here it crashes */ userTx.commit(); Result: org.odmg.TransactionNotInProgressException: No transaction in progress, cannot delete persistent at org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete (ServerOjbDAO.java:230) - 3. Use of both (Transaction and UserTransaction combined): UserTransaction userTx = (UserTransaction) context.lookup(java:/comp/UserTransaction); userTx.begin(); Transaction tx = odmg.currentTransaction(); if ( !tx.isOpen()) tx.begin(); db.deletePersistent(toBeDeleted); tx.commit(); /* here it crashes */ userTx.commit(); Result: java.lang.UnsupportedOperationException: Not supported operation at org.apache.ojb.odmg.NarrowTransaction.commit(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete(S erve rOjbDAO.java:232) - 4. like 3 but I uncomment tx.commit(). No exceptions but the object is not deleted. No SQL statement is generated by OJB. I know it is a lot to read but maybe somebody can take some time to read my code. Where is my problem and which transactions should I use? Or is the configuration of my Datasource wrong? Thanks, Julia. - 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: transaction in JBoss with MySQL Datasource
Hello Armin, I tried this alread. This will give me an: org.odmg.TransactionNotInProgressException: No transaction in progress, cannot delete persistent at org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete(Serve rOjbDAO.java:230) The Operation on the database crashes. Other suggestions? Julia. -Ursprüngliche Nachricht- Von: Armin Waibel [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 9. Juli 2003 15:38 An: OJB Users List Betreff: Re: transaction in JBoss with MySQL Datasource Hi, try to use JTA UserTransaction or container-managed tx and do not use ODMG tx-declaration. UserTransaction utx = ... utx.begin() db.deletePersistent(toBeDeleted); /* here it crashes */ utx.commit() HTH regards, Armin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 3:25 PM Subject: transaction in JBoss with MySQL Datasource Hello! I' using JBoss 3.0.6, OJB rc3 and a MySQL Database, which is configured as a Datasource for Local Transaction. I'm trying to delete an object but I'm having some problems with the transaction. I have tried several things with the following results: - 1. Use only of org.odmg.Transaction: Transaction tx = odmg.currentTransaction(); if ( !tx.isOpen()) tx.begin(); db.deletePersistent(toBeDeleted); /* here it crashes */ tx.commit(); Result: org.odmg.TransactionNotInProgressException: No external transaction found at org.apache.ojb.odmg.JTATxManager.registerTx(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.begin(Unknown Source) at org.apache.ojb.odmg.OJBJ2EE_2.beginInternTransaction(Unknown Source) at org.apache.ojb.odmg.OJBJ2EE_2.currentTransaction(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete(S erve rOjbDAO.java:227) --- 2. Use only of UserTranscation: UserTransaction userTx = (UserTransaction) context.lookup(java:/comp/UserTransaction); userTx.begin(); db.deletePersistent(toBeDeleted); /* here it crashes */ userTx.commit(); Result: org.odmg.TransactionNotInProgressException: No transaction in progress, cannot delete persistent at org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete (ServerOjbDAO.java:230) - 3. Use of both (Transaction and UserTransaction combined): UserTransaction userTx = (UserTransaction) context.lookup(java:/comp/UserTransaction); userTx.begin(); Transaction tx = odmg.currentTransaction(); if ( !tx.isOpen()) tx.begin(); db.deletePersistent(toBeDeleted); tx.commit(); /* here it crashes */ userTx.commit(); Result: java.lang.UnsupportedOperationException: Not supported operation at org.apache.ojb.odmg.NarrowTransaction.commit(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete(S erve rOjbDAO.java:232) - 4. like 3 but I uncomment tx.commit(). No exceptions but the object is not deleted. No SQL statement is generated by OJB. I know it is a lot to read but maybe somebody can take some time to read my code. Where is my problem and which transactions should I use? Or is the configuration of my Datasource wrong? Thanks, Julia. - 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]
Shut off Logging?
I can't quite figure out how to shut off the connection logging, the
one that looks like:
[org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl] INFO:
Create new connection
pool:[EMAIL PROTECTED]
jcd-alias=oraclesl
default-connection=false
dbms=Oracle
jdbc-level=2.0
driver=oracle.jdbc.driver.OracleDriver
protocol=jdbc
sub-protocol=oracle
db-alias=thin:@xxx.x.xxx:PORT:FOO
user=
password=*
eager-release=false
ConnectionPoolDescriptor={whenExhaustedAction=0, maxIdle=-1,
maxActive=21, maxWait=5000, removeAbandoned=false,
numTestsPerEvictionRun=10, testWhileIdle=false, minEvictable\
IdleTimeMillis=60, testOnReturn=false, logAbandoned=false,
removeAbandonedTimeout=300, timeBetweenEvictionRunsMillis=-1,
testOnBorrow=true}
batchMode=false
useAutoCommit=AUTO_COMMIT_IGNORE_STATE
ignoreAutoCommitExceptions=false
sequenceDescriptor=null
]
I generally like this, it's helped out quite a bit when trying to
figure out if I'm setting it up correctly, but now I want it shut off
(running a cron job and it greatly messes up the output). Which
logging config controls this?
Thanks!
cdh
--
Chris D. Halverson http://www.halverson.org/
YIM/AIM: chrisdhal MSN: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:m-relation
Edson,
see this is very interesting because i do not use any special
collection class. I use a simple
vector. When i do the stuff you are describing below, my new B object
is not being created in
the database, EVEN with my auto-update set to true. If i change
anything on the A object, the change
is recognized and saved. However, if i add or remove any objects from
the collection of B objects, it is as through
the change is not recognized. Should i start using the
RemovalAwareCollection in order to make sure that any additions
or deletions to the vector ?
Note: the difference between what i showed below and the examples that
come with OJB is that OJB examples always show the
changes being made in the context of a broker transaction. I am not
sure if this matters, but the way i am writing my interface to the
persistence broker, i would like to be able to read objects out of the
database, update them at will outside of broker transaction contexts,
then
bring the same references back and save the altered objects back to
the database.
any help you can provide would be helpful
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/9/2003 6:31:08 AM
Yes, exactly what I do. But see, to B instances be stored in database,
you
must put auto-update='true' in your collection descriptor.
In real, I use a collection class RemovalAwareCollection (or a
specialized
RemovalAwareList that I've created) to auto-delete. So, if I
a.getCol().remove( 0 );
broker.store(a);
the item in 0 is deleted from database, as expected. This is a must for
my
app.
Best regards,
Edson Richter
- Original Message -
From: James Nyika [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 4:46 PM
Subject: Re: 1:m-relation
Edson,
Can i ask you to give an example of how you add more B objects the
the
collection you described below
do you do something like this :
//get broker
broker = brokerfactory.defaultInstance();
//fetch an A object that has say 3 B objects in the collection.
...
//create a new B object
B newB = new B();
//add to the collection
A.getCol().add(newB);
//persist the A
broker.beginTransaction();
broker.store(A);
broker.commitTransaction();
?
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/8/2003 12:24:28 PM
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try
to
give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
class-descriptor
class=A
table=TB_A
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
collection-descriptor
name=col
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
/class-descriptor
class-descriptor
class=B
table=TB_B
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
field-descriptor
name=idA
column=ID_A
jdbc-type=INTEGER
primarykey=true /
reference-descriptor
name=a
class-ref=A
foreignkey field-ref=idA/
/reference-descriptor
/class-descriptor
And this should work. You don't need to specify auto-retrieve, because
by
default it's true. Auto-update and auto-delete are false by default.
Some
people like to work with specialized collection classes. In
particular,
I
work always with RemovalAwareList (a collection that know how to
persists
deletes in the collection). To archieve this, your should be more
specific
in collection descriptor like this:
collection-descriptor
name=col
collection-class=org.apache.ojb.broker.util.collections.RemovalAwareList
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
Of course, you could mixes the several other options that OJB offers
to
you,
like auto-increment, proxies and so on. In this case, I'll recomendly
you to
use cvs HEAD that has several fixes for these options over rc3.
Best regards,
Edson Richter
- Original Message -
From: Christian
RE: Weblogic, threads, and startup errors
Hi, I was out yesterday, so I just read this. This is an excellent explanation. When I encountered the problem, I very much suspected it was something like you were describing. But I was not sure, and in particular, I was not sure what the right fix might be. Thanks! Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED] -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 10:29 AM To: 'OJB Users List' Subject: RE: Weblogic, threads, and startup errors Hi Bonnie, Well classloaders, especially in servlet containers, are not always the most predictable things. I am not sure if the classloader of threads started from a web application is even really covered in any length in the servlet specification. So let's look at the javadocs of Thread.getContextClassLoader() for an idea of how this classloader craziness is supposed to work: Returns the context ClassLoader for this Thread. The context ClassLoader is provided by the creator of the thread for use by code running in this thread when loading classes and resources. If not set, the default is the ClassLoader context of the parent Thread. The context ClassLoader of the primordial thread is typically set to the class loader used to load the application. First, if there is a security manager, and the caller's class loader is not null and the caller's class loader is not the same as or an ancestor of the context class loader for the thread whose context class loader is being requested, then the security manager's checkPermission method is called with a RuntimePermission(getClassLoader) permission to see if it's ok to get the context ClassLoader. If not set, the default is the ClassLoader context of the parent Thread. Based on this statement on starting a new thread, you would expect it's classloader to be the same as the parent classloader of the thread it was started from. However, this is obviously not the case within Weblogic. You would expect, (hope), the a new thread started from a servlet would use the webapp's classloader, i.e. the parent classloader that the servlet is using. However, it is obvious that the classloader given to new threads started within Weblogic is not the same classloader as the one possessed by the servlet. My guess is that new threads are using either the system of the container or the primordial classloader rather than the webapp's classloader. So, based on the statement The context ClassLoader is provided by the creator of the thread for use by code running in this thread when loading classes and resources. It is probably a best practice to make sure you always set the classloader of a new thread before starting. By using this process you have guaranteed the behavior of the new thread's classloader. In closing, my guess on what is currently happening is that new threads are either using the system classloader of the container or the primordial classloader rather than the webapp's classloader. *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 5:27 PM To: OJB Users List Subject: RE: Weblogic, threads, and startup errors This did the trick. Thank you! Now I just have to understand WHY it did the trick :-) Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED] -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 5:23 PM To: 'OJB Users List' Subject: RE: Weblogic, threads, and startup errors Actually, it should look like thisL ClassLoader cl = Thread.currentThread().getContextClassLoader(); AccountUpdater myNewThread = new AccountUpdater(); myNewThread.setContextClassLoader(cl); myNewThreadStart.start(); *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 5:21 PM To: 'OJB Users List' Subject: RE: Weblogic, threads, and startup errors Some simple questions: 1. Where do you have the OJB resources (OJB.properties, repository.xml, etc.)? To make things easy, they should be in the default package of your webapp's WEB-INF/classes directory. 2. Where is your OJB jar? For the most predictable results, it should be in your webapp's WEB-INF/lib directory. I would discourage loading OJB from shared or common lib locations within your
RE: Partial collection problem
Rob, I have had this problem to, and posted all the info that I could to try to diagnose the issue, to no avail. I ended up just coding a work around to get what I needed. I noticed that when I ran a query to get the count of expected objects, the count I got back was right, but the collection was always n+1 (just as you described). For the workaround I first get an enumeration of primary keys (because that works as expected), then go through each of the referenced tables, and build a hashmap of the rest of the objects that I need. Then I piece them together at the end, and return a collection of 'Whole' objects. I think its actually faster than the OJB code would have been, because its fewer trips to the DB. I had to do this workaround, even though it is a little clunky, because we are going to production soon, and I wasn't able to solve the original Collection problem. I only have one class with a collection, so I only had to do the workaround once. I am hoping that the issue gets resolved, because I don't want to have to code any more OJB workarounds, and I don't want to abandon OJB when we move to the next project. Are you able to determine what the issue is? Previous postings pointed to JBoss issues, but I have websphere and DB2 (my issue could be my JDBC driver, I haven't tried any others). It seemed to me that a resultSet was being closed early. please post if you resolve the issue -John -Original Message- From: Rob Kischuk [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 7:09 AM To: 'OJB Users List' Subject: RE: Partial collection problem Thanks for the suggestion. I built from the latest code in CVS last night, and still had the same problem. -Rob -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 7:23 PM To: OJB Users List Subject: Re: Partial collection problem Hi Rob, I think this is an known issue, please try latest CVS. regards, Armin - Original Message - From: Rob Kischuk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 07, 2003 3:31 PM Subject: RE: Partial collection problem This is a big problem - we have a collection of 200 items that we are retrieving, and the first query only retrieves a single item, with each subsequent query retrieving one more item (e.g. - the fifth query result has 5 items). This seems to be either a very nasty error on my part, or a major bug. Can anyone shed some additional light on this? Is it a bug? Is there a workaround? This is a major showstopper for OJB on an application we're working on, and could require some major rework. -Rob -Original Message- From: Rob Kischuk Sent: Thursday, July 03, 2003 9:43 AM To: '[EMAIL PROTECTED]' Subject: Partial collection problem I saw a discussion cross this list a while back regarding this same problem, but with no solution. The problem is this: when I run a query to load a collection of objects that contain other objects, the first call retrieves only the first item in the collection. The second call retrieves a total of 2 items, the third, a total of 3 items, and so on. Obviously, the correct functionality would be to have all of the items in the collection retrieved on the first call. I described the issue in great detail as a part of Defect OJB172: http://scarab.werken.com/issues/curmodule/120/tqk/0/template/ViewIssue.v m/id /OJB172/issuelist/-1/issuelist/1/issuelist/OJB172 http://scarab.werken.com/issues/curmodule/120/tqk/0/template/ViewIssue. vm/i d/OJB172/issuelist/-1/issuelist/1/issuelist/OJB172 But it appears that the defect hasn't been touched since I entered it. Is there a known fix or workaround for it? Thanks! Rob - 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: Partial collection problem
I've had this problem too. The issue is that the result set is being closed prematurely because the eager-release attribute in the connection descriptor was set to true; if you can try setting this to false. I was able to do this without any probs because I'nm using tomcat, the problem appeared because i tried to port to jboss and changed the eager release setting. cheers Jin - Original Message - From: McCaffrey, John G. [EMAIL PROTECTED] To: 'OJB Users List' [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 3:46 PM Subject: RE: Partial collection problem Rob, I have had this problem to, and posted all the info that I could to try to diagnose the issue, to no avail. I ended up just coding a work around to get what I needed. I noticed that when I ran a query to get the count of expected objects, the count I got back was right, but the collection was always n+1 (just as you described). For the workaround I first get an enumeration of primary keys (because that works as expected), then go through each of the referenced tables, and build a hashmap of the rest of the objects that I need. Then I piece them together at the end, and return a collection of 'Whole' objects. I think its actually faster than the OJB code would have been, because its fewer trips to the DB. I had to do this workaround, even though it is a little clunky, because we are going to production soon, and I wasn't able to solve the original Collection problem. I only have one class with a collection, so I only had to do the workaround once. I am hoping that the issue gets resolved, because I don't want to have to code any more OJB workarounds, and I don't want to abandon OJB when we move to the next project. Are you able to determine what the issue is? Previous postings pointed to JBoss issues, but I have websphere and DB2 (my issue could be my JDBC driver, I haven't tried any others). It seemed to me that a resultSet was being closed early. please post if you resolve the issue -John -Original Message- From: Rob Kischuk [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 7:09 AM To: 'OJB Users List' Subject: RE: Partial collection problem Thanks for the suggestion. I built from the latest code in CVS last night, and still had the same problem. -Rob -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 7:23 PM To: OJB Users List Subject: Re: Partial collection problem Hi Rob, I think this is an known issue, please try latest CVS. regards, Armin - Original Message - From: Rob Kischuk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 07, 2003 3:31 PM Subject: RE: Partial collection problem This is a big problem - we have a collection of 200 items that we are retrieving, and the first query only retrieves a single item, with each subsequent query retrieving one more item (e.g. - the fifth query result has 5 items). This seems to be either a very nasty error on my part, or a major bug. Can anyone shed some additional light on this? Is it a bug? Is there a workaround? This is a major showstopper for OJB on an application we're working on, and could require some major rework. -Rob -Original Message- From: Rob Kischuk Sent: Thursday, July 03, 2003 9:43 AM To: '[EMAIL PROTECTED]' Subject: Partial collection problem I saw a discussion cross this list a while back regarding this same problem, but with no solution. The problem is this: when I run a query to load a collection of objects that contain other objects, the first call retrieves only the first item in the collection. The second call retrieves a total of 2 items, the third, a total of 3 items, and so on. Obviously, the correct functionality would be to have all of the items in the collection retrieved on the first call. I described the issue in great detail as a part of Defect OJB172: http://scarab.werken.com/issues/curmodule/120/tqk/0/template/ViewIssue.v m/id /OJB172/issuelist/-1/issuelist/1/issuelist/OJB172 http://scarab.werken.com/issues/curmodule/120/tqk/0/template/ViewIssue. vm/i d/OJB172/issuelist/-1/issuelist/1/issuelist/OJB172 But it appears that the defect hasn't been touched since I entered it. Is there a known fix or workaround for it? Thanks! Rob - 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: Rollback not happening
I do call persistanceBroker.abortTransaction(); when I catch an exception, and I call persistanceBroker.close(); in the finally of the method I am not sure if I understand your suggestion about which transaction logic to use. I am not using EJBs, I am using websphere datasource, with DB2 pooled database driver. Is there a known issue? thanks for your help -John -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 6:13 PM To: OJB Users List Subject: Re: Rollback not happening Hi, I am using WebSphere transaction manager factory, and ConnectionFactoryManagedImpl. if you are running in an managed environment use declarative or programmatic transaction of your appServer (don't use the OJB tx demarcation e.g beginTransaction(), ...). How do you use OJB - within session beans? If you don't run in a managed environment and you want to use OJB tx-demarcation, don't set 'ConnectionFactoryManagedImpl'. regards, Armin - Original Message - From: McCaffrey, John G. [EMAIL PROTECTED] To: 'OJB Users List' [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 12:12 AM Subject: Rollback not happening hmmm. I must be missing something, but I thought if I called persistanceBroker.beginTransaction(); persistanceBroker.store(brokerVO); and if there was an exception and persistanceBroker.commitTransaction(); never gets called, then the data should not be in the database. I am storing a BrokerVO that has N BusinessContact objects, and if one of the businesContacts fails to insert, I want the whole transaction to rollback. I am not sure what I am doing wrong here. If any part of the transaction fails (I am inserting into three tables), I want all of the data to rollback. snip class-descriptor class=com.kraft.esi.msf.common.db.dsna.BrokerVO schema=schema; table=brkr field-descriptor id=1 name=brkrNbr column=BP_NBR jdbc-type=DECIMAL primarykey=true/ field-descriptor id=2 name=vendNbr column=AP_VNDR_NBR jdbc-type=VARCHAR / field-descriptor id=3 name=brkrEffStrtDate column=EFCT_STRT_DT jdbc-type=DATE conversion=org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDa teFi eldConversion/ field-descriptor id=4 name=brkrEffEndDate column=EFCT_END_DT jdbc-type=DATE conversion=org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDa teFi eldConversion/ field-descriptor id=5 name=brkrComment column=CMNT jdbc-type=VARCHAR/ reference-descriptor name=busnPtnrVO class-ref=com.kraft.esi.msf.common.db.dsna.BusnPtnrVO auto-retrieve=true auto-update=true auto-delete=true foreignkey field-id-ref=1/ /reference-descriptor reference-descriptor name=apVndrVO class-ref=com.kraft.esi.msf.common.db.dsna.ApVndrVO auto-retrieve=true auto-update=false auto-delete=false foreignkey field-id-ref=2/ /reference-descriptor !-- -- collection-descriptor name=businessContacts element-class-ref=com.kraft.esi.msf.common.db.dsna.BpCntctVO auto-retrieve=true auto-update=true auto-delete=true orderby=cntctTypeCode sort=ASC proxy=false inverse-foreignkey field-id-ref=1/ /collection-descriptor /class-descriptor snip I am using WebSphere transaction manager factory, and ConnectionFactoryManagedImpl. any help would be greatly appreciated. -John - 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: transaction in JBoss with MySQL Datasource
I tried this alread. This will give me an: sorry, overlooked that! org.odmg.TransactionNotInProgressException: No external transaction found Seems OJB is not associated with JTA transaction. Can you try UserTransaction utx = ... utx.begin() odmg.currentTransaction(); db.deletePersistent(toBeDeleted); /* here it crashes */ utx.commit() What's the result now? regards, Armin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 3:46 PM Subject: AW: transaction in JBoss with MySQL Datasource Hello Armin, I tried this alread. This will give me an: org.odmg.TransactionNotInProgressException: No transaction in progress, cannot delete persistent at org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete(S erve rOjbDAO.java:230) The Operation on the database crashes. Other suggestions? Julia. -Ursprüngliche Nachricht- Von: Armin Waibel [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 9. Juli 2003 15:38 An: OJB Users List Betreff: Re: transaction in JBoss with MySQL Datasource Hi, try to use JTA UserTransaction or container-managed tx and do not use ODMG tx-declaration. UserTransaction utx = ... utx.begin() db.deletePersistent(toBeDeleted); /* here it crashes */ utx.commit() HTH regards, Armin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 3:25 PM Subject: transaction in JBoss with MySQL Datasource Hello! I' using JBoss 3.0.6, OJB rc3 and a MySQL Database, which is configured as a Datasource for Local Transaction. I'm trying to delete an object but I'm having some problems with the transaction. I have tried several things with the following results: - 1. Use only of org.odmg.Transaction: Transaction tx = odmg.currentTransaction(); if ( !tx.isOpen()) tx.begin(); db.deletePersistent(toBeDeleted); /* here it crashes */ tx.commit(); Result: org.odmg.TransactionNotInProgressException: No external transaction found at org.apache.ojb.odmg.JTATxManager.registerTx(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.begin(Unknown Source) at org.apache.ojb.odmg.OJBJ2EE_2.beginInternTransaction(Unknown Source) at org.apache.ojb.odmg.OJBJ2EE_2.currentTransaction(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete(S erve rOjbDAO.java:227) --- 2. Use only of UserTranscation: UserTransaction userTx = (UserTransaction) context.lookup(java:/comp/UserTransaction); userTx.begin(); db.deletePersistent(toBeDeleted); /* here it crashes */ userTx.commit(); Result: org.odmg.TransactionNotInProgressException: No transaction in progress, cannot delete persistent at org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete (ServerOjbDAO.java:230) - 3. Use of both (Transaction and UserTransaction combined): UserTransaction userTx = (UserTransaction) context.lookup(java:/comp/UserTransaction); userTx.begin(); Transaction tx = odmg.currentTransaction(); if ( !tx.isOpen()) tx.begin(); db.deletePersistent(toBeDeleted); tx.commit(); /* here it crashes */ userTx.commit(); Result: java.lang.UnsupportedOperationException: Not supported operation at org.apache.ojb.odmg.NarrowTransaction.commit(Unknown Source) at de.arvatosystems.monitoring.integration.dao.server.ServerOjbDAO.delete(S erve rOjbDAO.java:232) - 4. like 3 but I uncomment tx.commit(). No exceptions but the object is not deleted. No SQL statement is generated by OJB. I know it is a lot to read but maybe somebody can take some time to read my code. Where is my problem and which transactions should I use? Or is the configuration of my Datasource wrong? Thanks, Julia. - 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: 1:m-relation
Hi!
The persistence should occur automatically when auto-update=true, even using
Vectors.
Are you working with OJB Api, ODBC or JDO?
The samples I've shown uses OJB Api. And of course, I use transactions...
(or I store A and all instances of B, or don't store anything. This is a
must when working with large apps).
Maybe someone else can point you with more information... All that I can
tell you is that this work. When I started with OJB I've used the samples,
and they work. Maybe you have missing something in configuration.
About the RemovalAwareCollection, you should use only if you need the
instances of B being removed when you store A... Nothing about auto-update
inserting objects.
[]s
Edson Richter
- Original Message -
From: James Nyika [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 11:03 AM
Subject: Re: 1:m-relation
Edson,
see this is very interesting because i do not use any special
collection class. I use a simple
vector. When i do the stuff you are describing below, my new B object
is not being created in
the database, EVEN with my auto-update set to true. If i change
anything on the A object, the change
is recognized and saved. However, if i add or remove any objects from
the collection of B objects, it is as through
the change is not recognized. Should i start using the
RemovalAwareCollection in order to make sure that any additions
or deletions to the vector ?
Note: the difference between what i showed below and the examples that
come with OJB is that OJB examples always show the
changes being made in the context of a broker transaction. I am not
sure if this matters, but the way i am writing my interface to the
persistence broker, i would like to be able to read objects out of the
database, update them at will outside of broker transaction contexts,
then
bring the same references back and save the altered objects back to
the database.
any help you can provide would be helpful
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/9/2003 6:31:08 AM
Yes, exactly what I do. But see, to B instances be stored in database,
you
must put auto-update='true' in your collection descriptor.
In real, I use a collection class RemovalAwareCollection (or a
specialized
RemovalAwareList that I've created) to auto-delete. So, if I
a.getCol().remove( 0 );
broker.store(a);
the item in 0 is deleted from database, as expected. This is a must for
my
app.
Best regards,
Edson Richter
- Original Message -
From: James Nyika [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 4:46 PM
Subject: Re: 1:m-relation
Edson,
Can i ask you to give an example of how you add more B objects the
the
collection you described below
do you do something like this :
//get broker
broker = brokerfactory.defaultInstance();
//fetch an A object that has say 3 B objects in the collection.
...
//create a new B object
B newB = new B();
//add to the collection
A.getCol().add(newB);
//persist the A
broker.beginTransaction();
broker.store(A);
broker.commitTransaction();
?
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/8/2003 12:24:28 PM
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try
to
give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
class-descriptor
class=A
table=TB_A
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
collection-descriptor
name=col
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
/class-descriptor
class-descriptor
class=B
table=TB_B
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
field-descriptor
name=idA
column=ID_A
jdbc-type=INTEGER
primarykey=true /
reference-descriptor
name=a
class-ref=A
foreignkey field-ref=idA/
/reference-descriptor
/class-descriptor
And this should work. You don't need to specify auto-retrieve,
Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
I've tried e.printStackTrace() , log.error, simple System.out - none of them
prints anything.
I've configured log4j.properties to DEBUG everything - the same result.
I found the problem - jcd-alias=default was missing in repository.xml.
OJB 0.9.7 doesn't require it, but OJB 1.0.rc3 does.
Regards,
Mykola
- Original Message -
From: Edson Carlos Ericksson Richter [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]; Mykola Ostapchuk
[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 6:36 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Can you try to change from log.error to e.printStackTrace() so we can have
more info about line/stack trace?
The code you are using to obtain the broker is exatly same I'm using, so
it's right.
What about .xml and .dtd? You remembered to updated too?
Edson
- Original Message -
From: Mykola Ostapchuk [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 9:14 PM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Hello,
I've spent 2 days trying to migrate my application from OJB 0.9.7 to OJB
1.0.rc3, and still no success.
The problem is - I can't instantiate broker with the next line:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
I'm using default OJB.properties from 1.0 rc3. I have db-ojb-1.0.rc3.jar
and
all additional *.jar files in /lib folder.
I debug RepositoryXmlHandler and it seems there're no problems (see code
snap from pevious message below).
Line:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
generates some error I don't know how to cach.
log.error in cach statement doesn't print anything.
try {
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
usersVO.setUsername(username);
usersVO.setPassword(password);
Query query = new QueryByCriteria(usersVO);
usersVO = (UsersVO) broker.getObjectByQuery(query);
} catch (Exception e) {
log.error(PersistenceBrokerException thrown in UsersDAO.findByUP():
+ e.toString());
}
With OJB 0.9.7 everything works fine.
I'll very appreciate any help!
Regards,
Mykola Ostapchuk
- Original Message -
From: Mykola Ostapchuk [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 11:52 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Sorry for the previous message. Here's the log:
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - startDoc
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler -
descriptor-repository
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler -
documentation
15DEBUG [Thread-5] metadata.RepositoryXmlHandler -
class-descriptor
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
isolation-level:
read-uncommitted
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - class:
com.iprs.web.users.UsersVO
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - proxy: null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - table: users
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - row-reader:
null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - extends:
null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
accept-locks:
true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
accept-locks:
true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
initialization-method: null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - refresh:
true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
field-descriptor
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - name: userId
46DEBUG [Thread-5] metadata.RepositoryXmlHandler - column:
US_id
46DEBUG [Thread-5] metadata.RepositoryXmlHandler - jdbc-type:
BIGINT
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: endDoc
- Original Message -
From: Thomas Mahler [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 1:57 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
this is most likely a problem during the parsing of the repository.
please set the debug level for XmlRepositoryHandler to DEBUG to see
where the repository problems are.
cheers,
Thomas
Mykola Ostapchuk wrote:
Hello,
I have a problem with migrating from OJB 0.9.7 to OJB 1.0.rc3.
What I did:
- replaced db-ojb-0.9.7.jar with db-ojb-1.0.rc3.jar.
- built new OJB internal DB tables.
- replaced old OJB.properties with a new one.
- replaced repository.dtd with a new one.
- modified repository.xml
RE: Migrating from OJB 0.9.7 to OJB 1.0.rc3
urk, that should definitely be handled in a nice way.
-Original Message-
From: Mykola Ostapchuk [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 10:05 AM
To: [EMAIL PROTECTED]
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
I've tried e.printStackTrace() , log.error, simple System.out - none of them
prints anything.
I've configured log4j.properties to DEBUG everything - the same result.
I found the problem - jcd-alias=default was missing in repository.xml.
OJB 0.9.7 doesn't require it, but OJB 1.0.rc3 does.
Regards,
Mykola
- Original Message -
From: Edson Carlos Ericksson Richter [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]; Mykola Ostapchuk
[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 6:36 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Can you try to change from log.error to e.printStackTrace() so we can have
more info about line/stack trace?
The code you are using to obtain the broker is exatly same I'm using, so
it's right.
What about .xml and .dtd? You remembered to updated too?
Edson
- Original Message -
From: Mykola Ostapchuk [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 9:14 PM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Hello,
I've spent 2 days trying to migrate my application from OJB 0.9.7 to OJB
1.0.rc3, and still no success.
The problem is - I can't instantiate broker with the next line:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
I'm using default OJB.properties from 1.0 rc3. I have db-ojb-1.0.rc3.jar
and
all additional *.jar files in /lib folder.
I debug RepositoryXmlHandler and it seems there're no problems (see code
snap from pevious message below).
Line:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
generates some error I don't know how to cach.
log.error in cach statement doesn't print anything.
try {
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
usersVO.setUsername(username);
usersVO.setPassword(password);
Query query = new QueryByCriteria(usersVO);
usersVO = (UsersVO) broker.getObjectByQuery(query);
} catch (Exception e) {
log.error(PersistenceBrokerException thrown in UsersDAO.findByUP():
+ e.toString());
}
With OJB 0.9.7 everything works fine.
I'll very appreciate any help!
Regards,
Mykola Ostapchuk
- Original Message -
From: Mykola Ostapchuk [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 11:52 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
Sorry for the previous message. Here's the log:
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler - startDoc
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler -
descriptor-repository
0 DEBUG [Thread-5] metadata.RepositoryXmlHandler -
documentation
15DEBUG [Thread-5] metadata.RepositoryXmlHandler -
class-descriptor
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
isolation-level:
read-uncommitted
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - class:
com.iprs.web.users.UsersVO
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - proxy: null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - table: users
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - row-reader:
null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - extends:
null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
accept-locks:
true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
accept-locks:
true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
initialization-method: null
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - refresh:
true
31DEBUG [Thread-5] metadata.RepositoryXmlHandler -
field-descriptor
31DEBUG [Thread-5] metadata.RepositoryXmlHandler - name: userId
46DEBUG [Thread-5] metadata.RepositoryXmlHandler - column:
US_id
46DEBUG [Thread-5] metadata.RepositoryXmlHandler - jdbc-type:
BIGINT
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG: endDoc
- Original Message -
From: Thomas Mahler [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 1:57 AM
Subject: Re: Migrating from OJB 0.9.7 to OJB 1.0.rc3
this is most likely a problem during the parsing of the repository.
please set the debug level for XmlRepositoryHandler to DEBUG to see
where the repository problems are.
cheers,
Thomas
Mykola Ostapchuk wrote:
Hello,
I have a problem with migrating from OJB 0.9.7 to OJB 1.0.rc3.
Can't instantiate query
Hi,
I can't instantiate query with the next line:
Query query = QueryFactory.newQuery(CountriesVO.class, criteria);
It generates error and method returns null.
The method worked well with OJB 0.9.7, now I'm using OJB 1.0.rc3.
Does anybody have any idea what can be wrong?
One more question: I don't understand why catch (Exception e) doesn't
actually cach an Exception?
I've System.out and log.error in catch statement - none of them prints
nothing.
Here's my method:
public Vector allCountries() throws DataAccessException {
log.info(Entering the
CountriesDAO.allCountries()***);
PersistenceBroker broker = null;
Vector results = null;
try{
Criteria criteria = new Criteria();
criteria.addOrderBy(CO_name);
Query query = QueryFactory.newQuery(CountriesVO.class,
criteria);
query.setStartAtIndex(1);
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
results = (Vector) broker.getCollectionByQuery(query);
}
catch (Exception e) {
System.out.println(Error: +e.toString());
log.error(Exception thrown in CountriesDAO.allCountries(): +
e.toString());
}
finally {
if (broker != null) broker.close();
}
log.info(Done with
CountriesDAO.allCountries()***);
return results;
}
Please, help!
Regards,
Mykola
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: newbie question
Thank you. -Original Message- From: Thomas Mahler [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 2:35 PM To: OJB Users List Subject: Re: FW: newbie question I assume you are talking about Jakarta Slide? Jakarta Slide is a CMS engine which provides it's own abstraction of JDBC backends. OJB is an Object/Relational mapping tool. SLIDE and OJB have nothing to do with each other. Of course it could make sense to replace the Slide persistence mechanism by OJB. Currently Jakarta Jetspeed is already migrating to OJB. But I don't know of such plans for Slide. You should asked the Slide team about their plans! cheers, Thomas Kevin Ritter wrote: Try again -Original Message- From: Kevin Ritter Sent: Wednesday, July 09, 2003 1:22 PM To: '[EMAIL PROTECTED]' Subject: newbie question How does this technology work with an implementation of SLIDE running on TOMCAT 4.1.x? Does it replace SLIDE, coexist with SLIDE, or has nothing to do with SLIDE? With kind regards, Kevin Ritter - 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: Can't instantiate query
I solved the problem by using
Query query = new QueryByCriteria(CountriesVO.class, criteria);
I'm wandering why
Query query = QueryFactory.newQuery(CountriesVO.class,criteria);
doesn't work in OJB 1.0.rc3?..
Regards,
Mykola
- Original Message -
From: Mykola Ostapchuk [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 1:22 PM
Subject: Can't instantiate query
Hi,
I can't instantiate query with the next line:
Query query = QueryFactory.newQuery(CountriesVO.class, criteria);
It generates error and method returns null.
The method worked well with OJB 0.9.7, now I'm using OJB 1.0.rc3.
Does anybody have any idea what can be wrong?
One more question: I don't understand why catch (Exception e) doesn't
actually cach an Exception?
I've System.out and log.error in catch statement - none of them prints
nothing.
Here's my method:
public Vector allCountries() throws DataAccessException {
log.info(Entering the
CountriesDAO.allCountries()***);
PersistenceBroker broker = null;
Vector results = null;
try{
Criteria criteria = new Criteria();
criteria.addOrderBy(CO_name);
Query query = QueryFactory.newQuery(CountriesVO.class,
criteria);
query.setStartAtIndex(1);
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
results = (Vector) broker.getCollectionByQuery(query);
}
catch (Exception e) {
System.out.println(Error: +e.toString());
log.error(Exception thrown in CountriesDAO.allCountries():
+
e.toString());
}
finally {
if (broker != null) broker.close();
}
log.info(Done with
CountriesDAO.allCountries()***);
return results;
}
Please, help!
Regards,
Mykola
-
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: DateTime conversion problem again
Hi Edson, After migration to OJB 1.0.rc3 I don't have this problem anymore. Can anybody confirm it was a bug in OJB 0.9.7? Regards, Mykola Ostapchuk What your GMT? In my case, all date/time are stored in database with -3 hours, because I'm on GMT-3. I'm using SapDB. I think that is this you getting, and it's a internationalization Java feature... Can someone else confirm this? Edson Richter - Original Message - From: Mykola Ostapchuk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 9:23 PM Subject: DateTime conversion problem again Sorry to post this question again, I still can't solve the problem. Any help will be very appreciated! Can anybody tell me how to map DateTime MySql field in OJB? My realization is the next: field-descriptor id=13 name=userDateInserted column=US_date_inserted jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlTimest ampFieldConversion/ userDateInserted - of type java.util.Date. After setting the Date, OJB inserts right date. But time is 1 hour minus of the actual time (minutes and seconds are right). Interesting, the userDateInserted has right Date value, but after passing it thru OJB, Date is decreased for 1 hour... Is it some kind of a bug? Am I doing something wrong? Any suggestions? Regards, Mykola Ostapchuk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.497 / Virus Database: 296 - Release Date: 4/7/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebSphere and Class Reloading
After version 0.97 (I believe) of OJB, WebSphere started to require full server resert in order to get OJB to catch up on the reloaded classes. I sent a note to IBM tech support and here's what they came up with. I hope this information is usable to you guys. Following is the update from our L3 team: Action taken: Has been gathering logs/traces to investigate the problem. So far, have narrowed the problem arises at place where there's a programmatically class loading using forname in ConfigurationAbstractImpl.java which behave differently after class change and web module reloading. Action plan: Will check to see if that's caused by the WAS classloader and work on a patch to fix the problem if necessary. After looking this problem for awhile, I have found out 2 Class.forName() call are causing the problem in the Apache OJB library db-ojb-1.0.rc1.jar. I've got the application working after making 2 changes: (1) ConfigurationAbstractImpl.java in org/apache/ojb/broker/util/configuration/impl change the forName call to like: clazz = Thread.currentThread().getContextClassLoader().loadClass(className); (2) ClassHelper.java in org/apache/ojb/broker/util change the forName call to like: return Thread.currentThread().getContextClassLoader().loadClass(className); However, since that function in ClassHelper.java is also used to load the Oracle JDBC driver too, you will need to make a special case to let it still use forName() when loading the JDBC driver. By the way, this approach of loading JDBC driver yourself is not recommended on WebSphere. First, you are on your own to handling all the low level JDBC connection details and skipping the nice pooling and datasource DB connection features available and managed by WebSphere. Also, this approach could pose a scalability issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using null value with FK
Hi, I've read somewhere in this ML that, since the latest releases, OJB uses null values for FK when the referenced object is null. But it doesn't, it uses the default 0 value instead (the FK is a int). Note that my FK field descriptor is defined with the nullable attribute. This is really annoying since it isn't compatible with the FK constraint of my DB (PostgreSQL). So I guess I've misunderstood a basic concept.. Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Repository || File not found
Where do the repository** files need to be located so that my compiled classes can recognize and make use of them? Thanks in advance, ~ Matthew -- Met @ Uber [EMAIL PROTECTED] Uberstats - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repository || File not found
In your classpath. Cheers Shane -Original Message- From: Met @ Uber [mailto:[EMAIL PROTECTED] Sent: Thursday, 10 July 2003 12:57 p.m. To: OJB User Subject: Repository || File not found Where do the repository** files need to be located so that my compiled classes can recognize and make use of them? Thanks in advance, ~ Matthew -- Met @ Uber [EMAIL PROTECTED] Uberstats - 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]
jdbc-connection-descriptor Tag Error.
Does anyone see whats wrong with the following XML file? Also, what tool on a Linux machine might I use to compare XML files to a DTD? All the help is greatly appreciated. === repository_database.xml === jdbc-connection-descriptor jcd-alias=default default-connection=true platform=PostgreSQL jdbc-level=2.0 driver=org.postgresql.Driver protocol=jdbc subprotocol=postgresql dbalias=ccw_java username=mimetnet password=patribus eager-release=false batch-mode=false useAutoCommit=1 ignoreAutoCommitExceptions=false connection-pool maxActive=21 validationQuery= / sequence-manager className=org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl attribute attribute-name=grabSize attribute-value=20 / attribute attribute-name=autoNaming attribute-value=true / attribute attribute-name=globalSequenceId attribute-value=false / attribute attribute-name=globalSequenceStart attribute-value=1 / /sequence-manager /jdbc-connection-descriptor === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jdbc-connection-descriptor Tag Error.
Met @ Uber wrote: Does anyone see whats wrong with the following XML file? Also, what tool on a Linux machine might I use to compare XML files to a DTD? You seem to be missing a closing quote with the driver attribute: jdbc-connection-descriptor jcd-alias=default default-connection=true platform=PostgreSQL jdbc-level=2.0 driver=org.postgresql.Driver protocol=jdbc subprotocol=postgresql dbalias=ccw_java username=mimetnet password=patribus eager-release=false batch-mode=false useAutoCommit=1 ignoreAutoCommitExceptions=false If that is the problem, then you really should be using an editor that supports syntax highlighting (vim, etc) - an issue like this shouldn't be something that you need to contact a mailing list about. Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
