Re: org.apache.ojb.broker.PersistenceBrokerSQLException
I reproduced the exeption by stopping and restarting the sql server. the probleme is that OJB dont auto-Reconnect in spite of putting in my repository.xml in the connection declaration dbalias=//localhost/MyDB?autoReconnect=true How can i tell to OJb to auto reconnect? - Original Message - From: Noureddine BEKRAR [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Friday, August 13, 2004 9:57 AM Subject: org.apache.ojb.broker.PersistenceBrokerSQLException Hi all, I have a SQL probleme, it seems like the connection died after some time, it happen only for the OJB connection, because I have another connection that use classic java connection managed with a connection pool, this kind of connection dont throw any exception at the same time the ojb connection throws that exception. Did anyone had the same problem? org.apache.ojb.broker.PersistenceBrokerSQLException: java.sql.SQLException: Communication link failure: java.io.EOFException, underlying cause: null ** BEGIN NESTED EXCEPTION ** java.io.EOFException STACKTRACE: java.io.EOFException at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1388) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1532) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1923) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1163) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1272) at com.mysql.jdbc.Connection.execSQL(Connection.java:2236) at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1555) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.materializeObject(JdbcAcces sImpl.java:557) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(PersistenceBrok erImpl.java:1232) at org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(Persi stenceBrokerImpl.java:1355) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity(Persist enceBrokerImpl.java:1334) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(D elegatingPersistenceBroker.java:306) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(D elegatingPersistenceBroker.java:306) at jouve.extradim.backoffice.entity.dao.ProjectDAO.retrieve(ProjectDAO.java:37) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti nuationInterpreter.java:1134) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti nuationInterpreter.java:190) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti nuationInterpreter.java:138) at org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(Interprete dFunctionImpl.java:121) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:159 1) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.h andleContinuation(FOM_JavaScriptInterpreter.java:788) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(C allFunctionNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo keNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectN ode.java:97) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo keNodes(AbstractParentProcessingNode.java:49) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok e(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo keNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel ineNode.java:126) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo keNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe linesNode.java:101) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess or.java:336) at org.apache.cocoon.components.treeprocessor.TreeProcessor.buildPipeline(TreeP rocessor.java:295) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod e.java:94) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo keNodes(AbstractParentProcessingNode.java:49) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok e(PreparableMatchNode.java:130) at
Re: XDoclet problems after rc6 to 1.0.0 update
Thomas Dudziak wrote: The fix should be a simple change of the compile-classpath at the beginning of the build.xml of the ojb-blank project to: [..] That works for me, thanks. -- Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: org.apache.ojb.broker.PersistenceBrokerSQLException
Hi, never used mysql (so take this with a pinch of salt ;-)), but it seems that by default reconnected connections set to 'read-only' mode. Did you try to set failOverReadOnly=false http://dev.mysql.com/doc/connector/j/en/index.html#id2423002 In jdbc-connection-descriptor you should set useAutoCommit=1, this guarantee that all connections returned to pool set with autoCommit 'true'. Only in this case autoReconnect seems to work in mysql. http://db.apache.org/ojb/docu/guides/repository.html#useAutoCommit If you don't have succeed in doing so, you can specify a 'validatioQuery' to check connection before delivered by the connection-pool http://db.apache.org/ojb/docu/guides/repository.html#connection-pool-N10230 regards, Armin Noureddine BEKRAR wrote: I reproduced the exeption by stopping and restarting the sql server. the probleme is that OJB dont auto-Reconnect in spite of putting in my repository.xml in the connection declaration dbalias=//localhost/MyDB?autoReconnect=true How can i tell to OJb to auto reconnect? - Original Message - From: Noureddine BEKRAR [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Friday, August 13, 2004 9:57 AM Subject: org.apache.ojb.broker.PersistenceBrokerSQLException Hi all, I have a SQL probleme, it seems like the connection died after some time, it happen only for the OJB connection, because I have another connection that use classic java connection managed with a connection pool, this kind of connection dont throw any exception at the same time the ojb connection throws that exception. Did anyone had the same problem? org.apache.ojb.broker.PersistenceBrokerSQLException: java.sql.SQLException: Communication link failure: java.io.EOFException, underlying cause: null ** BEGIN NESTED EXCEPTION ** java.io.EOFException STACKTRACE: java.io.EOFException at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1388) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1532) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1923) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1163) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1272) at com.mysql.jdbc.Connection.execSQL(Connection.java:2236) at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1555) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.materializeObject(JdbcAcces sImpl.java:557) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(PersistenceBrok erImpl.java:1232) at org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(Persi stenceBrokerImpl.java:1355) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity(Persist enceBrokerImpl.java:1334) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(D elegatingPersistenceBroker.java:306) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(D elegatingPersistenceBroker.java:306) at jouve.extradim.backoffice.entity.dao.ProjectDAO.retrieve(ProjectDAO.java:37) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti nuationInterpreter.java:1134) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti nuationInterpreter.java:190) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti nuationInterpreter.java:138) at org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(Interprete dFunctionImpl.java:121) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:159 1) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.h andleContinuation(FOM_JavaScriptInterpreter.java:788) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(C allFunctionNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo keNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectN ode.java:97) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo keNodes(AbstractParentProcessingNode.java:49) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok e(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo keNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel ineNode.java:126) at
Re: Cache problems in mutlithreaded environment
Hi,
I there a problem with my mail ? Did i forget something ? I am not clear ?
Please, tell me, i really need this info.
Cyril Ledru wrote:
Hi all,
This is my problem : I have an application which launch several threads.
In each thread, there is a call to getCollectionByQuery.
Here is the code of my thread class :
public class LoadThread extends Thread {
public void run() {
PBKey pbkey = new PBKey(...,...,...);
PersistenceBroker pb = null;
try {
pb
=PersistenceBrokerFactory.createPersistenceBroker(pbkey);
Collection c = pb.getCollectionByQuery(new
QueryByCriteria( Employee.class));
} finally {
if (null != pb) {
pb.close();
}
}
}
}
Then i launch this threads :
LoadThread[] ts = new LoadThread[10];
for (int i = 0; i ts.length; i++) {
ts[i] = new LoadThread();
}
for (int i = 0; i ts.length; i++) {
ts[i].start();
}
This is quite simple. The problem is the response time are abnormally
high. Usually, only the first call is time consuming because ojb mount
the objects in cache and the next calls should take a lot less time.
But here all the calls are time consuming.
If i launch the same series of threads a second time, the calls take 2
or 3 less time. Same if i put a second call to getCollectionByQuery in
my run method.
So it seems that ojb has a cache for each thread and not a general cache.
Am i using ojb incorrectly or is ojb incapable of caching datas for all
the threads ?
In the second case, is someone knows a way of caching for all the threads ?
Thanks in advance ,
Cyril.
-
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: Cache problems in mutlithreaded environment
Hi Cyril,
I think your test case has a few drawbacks and do not reflect a
production scenario.
First time PBF was used OJB parse and create all metadata objects (OJB
startup phase), this is time consuming and only occur one time in OJB
runtime. So before you start the LoadThread classes you should do a
dummy operation on OJB to force OJB startup.
If i launch the same series of threads a second time, the calls take 2
or 3 less time. Same if i put a second call to getCollectionByQuery in
my run method.
So it seems that ojb has a cache for each thread and not a general
cache.
This depends on the used ObjectCache implementation
http://db.apache.org/ojb/docu/guides/objectcache.html#Shipped+cache+implementations
The object you try to materialize will be put to cache when it is fully
materialized (e.g. if you set autoRetrieve 'true' to reference
descriptors they will be load too). So if multiple concurrent threads
try to lookup the same object (and you use the default cache), they may
materialize the object several times because none of the threads has put
a fully materialized object to cache.
By the way, if you use OJB source distribution you can run a
multi-threaded performance test against (hsql by default) with 'ant
perf-test'
http://db.apache.org/ojb/docu/guides/performance.html#OJB+performance+in+multi-threaded+environments
regards,
Armin
Cyril Ledru wrote:
Hi,
I there a problem with my mail ? Did i forget something ? I am not clear ?
Please, tell me, i really need this info.
Cyril Ledru wrote:
Hi all,
This is my problem : I have an application which launch several
threads. In each thread, there is a call to getCollectionByQuery.
Here is the code of my thread class :
public class LoadThread extends Thread {
public void run() {
PBKey pbkey = new PBKey(...,...,...);
PersistenceBroker pb = null;
try {
pb
=PersistenceBrokerFactory.createPersistenceBroker(pbkey);
Collection c = pb.getCollectionByQuery(new
QueryByCriteria( Employee.class));
} finally {
if (null != pb) {
pb.close();
}
}
}
}
Then i launch this threads :
LoadThread[] ts = new LoadThread[10];
for (int i = 0; i ts.length; i++) {
ts[i] = new LoadThread();
}
for (int i = 0; i ts.length; i++) {
ts[i].start();
}
This is quite simple. The problem is the response time are abnormally
high. Usually, only the first call is time consuming because ojb mount
the objects in cache and the next calls should take a lot less time.
But here all the calls are time consuming.
If i launch the same series of threads a second time, the calls take 2
or 3 less time. Same if i put a second call to getCollectionByQuery in
my run method.
So it seems that ojb has a cache for each thread and not a general cache.
Am i using ojb incorrectly or is ojb incapable of caching datas for
all the threads ?
In the second case, is someone knows a way of caching for all the
threads ?
Thanks in advance ,
Cyril.
-
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: Cache problems in mutlithreaded environment
Thanks for you answer.
I think your test case has a few drawbacks and do not reflect a
production scenario.
Our clients are asking our datas every 3 sec through a web service. So
this case'll occure a lot i think.
I tried to launch a first dummy call before the others. It reduce a
little the response time but not to much.
If i send my requests in a for loop, each request takes 200 ms and if i
do the same but in threads instead of the loop , it takes up to 3 seconds !
This depends on the used ObjectCache implementation
I tried all the objectcache but the performance are almost the same.
The object you try to materialize will be put to cache when it is fully
materialized (e.g. if you set autoRetrieve 'true' to reference
descriptors they will be load too). So if multiple concurrent threads
try to lookup the same object (and you use the default cache), they may
materialize the object several times because none of the threads has put
a fully materialized object to cache.
My first dummy call is in fact the same call to getCollectionByQuery.
So normally all my object should already be in cache and the next
queries sould take a lot less time, aren't they ?
Armin Waibel wrote:
Hi Cyril,
I think your test case has a few drawbacks and do not reflect a
production scenario.
First time PBF was used OJB parse and create all metadata objects (OJB
startup phase), this is time consuming and only occur one time in OJB
runtime. So before you start the LoadThread classes you should do a
dummy operation on OJB to force OJB startup.
If i launch the same series of threads a second time, the calls take 2
or 3 less time. Same if i put a second call to getCollectionByQuery in
my run method.
So it seems that ojb has a cache for each thread and not a general
cache.
This depends on the used ObjectCache implementation
http://db.apache.org/ojb/docu/guides/objectcache.html#Shipped+cache+implementations
The object you try to materialize will be put to cache when it is fully
materialized (e.g. if you set autoRetrieve 'true' to reference
descriptors they will be load too). So if multiple concurrent threads
try to lookup the same object (and you use the default cache), they may
materialize the object several times because none of the threads has put
a fully materialized object to cache.
By the way, if you use OJB source distribution you can run a
multi-threaded performance test against (hsql by default) with 'ant
perf-test'
http://db.apache.org/ojb/docu/guides/performance.html#OJB+performance+in+multi-threaded+environments
regards,
Armin
Cyril Ledru wrote:
Hi,
I there a problem with my mail ? Did i forget something ? I am not
clear ?
Please, tell me, i really need this info.
Cyril Ledru wrote:
Hi all,
This is my problem : I have an application which launch several
threads. In each thread, there is a call to getCollectionByQuery.
Here is the code of my thread class :
public class LoadThread extends Thread {
public void run() {
PBKey pbkey = new PBKey(...,...,...);
PersistenceBroker pb = null;
try {
pb
=PersistenceBrokerFactory.createPersistenceBroker(pbkey);
Collection c = pb.getCollectionByQuery(new
QueryByCriteria( Employee.class));
} finally {
if (null != pb) {
pb.close();
}
}
}
}
Then i launch this threads :
LoadThread[] ts = new LoadThread[10];
for (int i = 0; i ts.length; i++) {
ts[i] = new LoadThread();
}
for (int i = 0; i ts.length; i++) {
ts[i].start();
}
This is quite simple. The problem is the response time are abnormally
high. Usually, only the first call is time consuming because ojb
mount the objects in cache and the next calls should take a lot less
time.
But here all the calls are time consuming.
If i launch the same series of threads a second time, the calls take
2 or 3 less time. Same if i put a second call to getCollectionByQuery
in my run method.
So it seems that ojb has a cache for each thread and not a general
cache.
Am i using ojb incorrectly or is ojb incapable of caching datas for
all the threads ?
In the second case, is someone knows a way of caching for all the
threads ?
Thanks in advance ,
Cyril.
-
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: Cache problems in mutlithreaded environment
Cyril Ledru wrote:
Thanks for you answer.
I think your test case has a few drawbacks and do not reflect a
production scenario.
Our clients are asking our datas every 3 sec through a web service. So
this case'll occure a lot i think.
ok, but your test doesn't reflect this. Your test starts ten threads and
they all access OJB/DB at the same time. So I think the problem is your
DB, because OJB always perform the query to the DB and then check the
ResultSet for already cached objects. So I think the test tests the
performance of parallel queries against your DB (by query all Employee
in DB).
I tried to launch a first dummy call before the others. It reduce a
little the response time but not to much.
ok, first improvement is made ;-)
If i send my requests in a for loop, each request takes 200 ms and if i
do the same but in threads instead of the loop , it takes up to 3 seconds !
hmm, I don't know the size of the returned ResultSet (and the mapping
Employee class) so I can't estimate if 200ms is slow. In your test 10
threads access at the same time your DB, so 10x200ms will be the best
expected result.
A more realistic scenario will be
public void run()
{
// each thread obtains objects in a loop e.g 10 times
// and use a random timeout (e.g. 10-200ms)
for(..)
{
try{Thread.sleep(timeout);}catch()...
PBKey pbkey = new PBKey(...,...,...);
PersistenceBroker pb = null;
try
{
pb = PersistenceBrokerFactory.createPersistenceBroker(pbkey);
Collection c =
pb.getCollectionByQuery(new QueryByCriteria(Employee.class));
}
finally
{
if (null != pb) pb.close();
}
}
}
In this case only a few threads will access the DB at the same time.
This depends on the used ObjectCache implementation
I tried all the objectcache but the performance are almost the same.
This prove my theory that your DB is the bottleneck.
Some days ago I checked in a query performence improvement you can try
to replace your local files with these classes
/home/cvs/db-ojb/src/java/org/apache/ojb/broker/accesslayer/RowReaderDefaultImpl.java,v
revision 1.30.2.1
/home/cvs/db-ojb/src/java/org/apache/ojb/broker/accesslayer/RsIterator.java,v
revision 1.63.2.2
This will be part of the upcomming 1.0.1 maintenance release.
regards,
Armin
The object you try to materialize will be put to cache when it is fully
materialized (e.g. if you set autoRetrieve 'true' to reference
descriptors they will be load too). So if multiple concurrent threads
try to lookup the same object (and you use the default cache), they may
materialize the object several times because none of the threads has put
a fully materialized object to cache.
My first dummy call is in fact the same call to getCollectionByQuery.
So normally all my object should already be in cache and the next
queries sould take a lot less time, aren't they ?
Armin Waibel wrote:
Hi Cyril,
I think your test case has a few drawbacks and do not reflect a
production scenario.
First time PBF was used OJB parse and create all metadata objects (OJB
startup phase), this is time consuming and only occur one time in OJB
runtime. So before you start the LoadThread classes you should do a
dummy operation on OJB to force OJB startup.
If i launch the same series of threads a second time, the calls
take 2
or 3 less time. Same if i put a second call to
getCollectionByQuery in
my run method.
So it seems that ojb has a cache for each thread and not a general
cache.
This depends on the used ObjectCache implementation
http://db.apache.org/ojb/docu/guides/objectcache.html#Shipped+cache+implementations
The object you try to materialize will be put to cache when it is
fully materialized (e.g. if you set autoRetrieve 'true' to reference
descriptors they will be load too). So if multiple concurrent threads
try to lookup the same object (and you use the default cache), they
may materialize the object several times because none of the threads
has put a fully materialized object to cache.
By the way, if you use OJB source distribution you can run a
multi-threaded performance test against (hsql by default) with 'ant
perf-test'
http://db.apache.org/ojb/docu/guides/performance.html#OJB+performance+in+multi-threaded+environments
regards,
Armin
Cyril Ledru wrote:
Hi,
I there a problem with my mail ? Did i forget something ? I am not
clear ?
Please, tell me, i really need this info.
Cyril Ledru wrote:
Hi all,
This is my problem : I have an application which launch several
threads. In each thread, there is a call to getCollectionByQuery.
Here is the code of my thread class :
public class LoadThread extends Thread {
public void run() {
PBKey pbkey = new PBKey(...,...,...);
PersistenceBroker pb = null;
try {
pb
=PersistenceBrokerFactory.createPersistenceBroker(pbkey);
Collection c = pb.getCollectionByQuery(new
QueryByCriteria(
Re: extent problem
You have to specify the extent-class as the first sub-tag of class-descriptor (see http://db.apache.org/ojb/docu/guides/repository.html#class-descriptor for details). Also, you have to duplicate all fields/references/collections from Child in SuperChild, currently they are not automatically 'inherited' in the descriptor of the sub class. I did this and it did not work. I get this: java.lang.NullPointerException ... java.lang.VerifyError: Class net.vettenranta.super.Child overrides final method jdoReplaceFlags.()V at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:256) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:30) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:98) at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(Reposit oryXmlHandler.java:199) . using: 1.0rc6 I would recommend that you use the OJB and JDO Xdoclet modules (OJB module is part of OJB, the JDO module can be downloaded from http://xdoclet.sourceforge.net/xdoclet/index.html) to generate these two files, they will make things a lot easier for you. Have to look into it. - Joose -- Always remember that you are unique, just like everyone else! * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote: I did this and it did not work. I get this: java.lang.NullPointerException ... java.lang.VerifyError: Class net.vettenranta.super.Child overrides final method jdoReplaceFlags.()V at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:256) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:30) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:98) at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(Reposit oryXmlHandler.java:199) . using: 1.0rc6 Hmm, can't help you with the JDO stuff. You should post this error again (with the URL to your doc/tutorial) in a new thread with JDO in the message label (to attract the JDO experts). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cache problems in mutlithreaded environment
Cyril Ledru wrote:
Thanks again for your answer.
I tried to delay the threads but the result are almost the same.
Do you use different delay times for each thread? If all threads wait
e.g 100ms it doesn't change anything, because they will access at same
time again.
When i told you about the 200ms it the average time took to retreive
all employees in the db when the datas are in the cache.
Here, it seems like the datas aren't in a cache...
Do you know which classes i need to log in order to know if a query
takes its data in the cache or in the db ?
Most cache implementations don't use logging, so you have to change the
source and put an output in ObjectCache#lookup(...) method, e.g.
ObjectCacheDefaultImpl#lookup(...):
...
if(result != null) System.out.println(match: + oid);
return result;
}
Again, the query is never performed against the cache. First the query
was performed against the DB and then the ResultSet was performed
against the cache. See RsIterator.java.
regards,
Armin
Armin Waibel wrote:
Cyril Ledru wrote:
Thanks for you answer.
I think your test case has a few drawbacks and do not reflect a
production scenario.
Our clients are asking our datas every 3 sec through a web service.
So this case'll occure a lot i think.
ok, but your test doesn't reflect this. Your test starts ten threads
and they all access OJB/DB at the same time. So I think the problem is
your DB, because OJB always perform the query to the DB and then check
the ResultSet for already cached objects. So I think the test tests
the performance of parallel queries against your DB (by query all
Employee in DB).
I tried to launch a first dummy call before the others. It reduce a
little the response time but not to much.
ok, first improvement is made ;-)
If i send my requests in a for loop, each request takes 200 ms and if
i do the same but in threads instead of the loop , it takes up to 3
seconds !
hmm, I don't know the size of the returned ResultSet (and the mapping
Employee class) so I can't estimate if 200ms is slow. In your test 10
threads access at the same time your DB, so 10x200ms will be the best
expected result.
A more realistic scenario will be
public void run()
{
// each thread obtains objects in a loop e.g 10 times
// and use a random timeout (e.g. 10-200ms)
for(..)
{
try{Thread.sleep(timeout);}catch()...
PBKey pbkey = new PBKey(...,...,...);
PersistenceBroker pb = null;
try
{
pb = PersistenceBrokerFactory.createPersistenceBroker(pbkey);
Collection c =
pb.getCollectionByQuery(new QueryByCriteria(Employee.class));
}
finally
{
if (null != pb) pb.close();
}
}
}
In this case only a few threads will access the DB at the same time.
This depends on the used ObjectCache implementation
I tried all the objectcache but the performance are almost the same.
This prove my theory that your DB is the bottleneck.
Some days ago I checked in a query performence improvement you can try
to replace your local files with these classes
/home/cvs/db-ojb/src/java/org/apache/ojb/broker/accesslayer/RowReaderDefaultImpl.java,v
revision 1.30.2.1
/home/cvs/db-ojb/src/java/org/apache/ojb/broker/accesslayer/RsIterator.java,v
revision 1.63.2.2
This will be part of the upcomming 1.0.1 maintenance release.
regards,
Armin
The object you try to materialize will be put to cache when it is
fully
materialized (e.g. if you set autoRetrieve 'true' to reference
descriptors they will be load too). So if multiple concurrent threads
try to lookup the same object (and you use the default cache),
they may
materialize the object several times because none of the threads
has put
a fully materialized object to cache.
My first dummy call is in fact the same call to
getCollectionByQuery. So normally all my object should already be in
cache and the next queries sould take a lot less time, aren't they ?
Armin Waibel wrote:
Hi Cyril,
I think your test case has a few drawbacks and do not reflect a
production scenario.
First time PBF was used OJB parse and create all metadata objects
(OJB startup phase), this is time consuming and only occur one time
in OJB runtime. So before you start the LoadThread classes you
should do a dummy operation on OJB to force OJB startup.
If i launch the same series of threads a second time, the calls
take 2
or 3 less time. Same if i put a second call to
getCollectionByQuery in
my run method.
So it seems that ojb has a cache for each thread and not a
general cache.
This depends on the used ObjectCache implementation
http://db.apache.org/ojb/docu/guides/objectcache.html#Shipped+cache+implementations
The object you try to materialize will be put to cache when it is
fully materialized (e.g. if you set autoRetrieve 'true' to reference
descriptors they will be load too). So if multiple concurrent
threads try to lookup the same object (and you use the default
cache), they may
Re: extent problem
Hi, it seems that when I try to get Child it also get's SuperChild.. even though I haven't said that it should get superchild. All I want is to get just Child not superCHild.. Perhaps it's not possible to get like this? How about if I do Child interface and SuperChild implements Child and ChildImpl implements Child could it work then? - Joose 13.8.2004 kello 16:50, Thomas Dudziak kirjoitti: Joose Vettenranta wrote: I did this and it did not work. I get this: java.lang.NullPointerException ... java.lang.VerifyError: Class net.vettenranta.super.Child overrides final method jdoReplaceFlags.()V at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:256) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:30) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:98) at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(Repos it oryXmlHandler.java:199) . using: 1.0rc6 Hmm, can't help you with the JDO stuff. You should post this error again (with the URL to your doc/tutorial) in a new thread with JDO in the message label (to attract the JDO experts). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Always remember that you are unique, just like everyone else! * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote: Hi, it seems that when I try to get Child it also get's SuperChild.. even though I haven't said that it should get superchild. All I want is to get just Child not superCHild.. Perhaps it's not possible to get like this? You'll need to add a field called 'ojbConcreteClass' so that OJB knows which class to instantiate. Or you can super-references (in which case you don't need to duplicate the fields from Child in SuperChild in the repository file). See here for details on these strategies: http://db.apache.org/ojb/docu/guides/advanced-technique.html#Mapping+Inheritance+Hierarchies Also I don't know whether two connections on the same database works. You might run into problems with the cache. You should definitly have a look at the different cache implementations provided with OJB: http://db.apache.org/ojb/docu/guides/objectcache.html Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Hi, it seems that when I try to get Child it also get's SuperChild.. even though I haven't said that it should get superchild. All I want is to get just Child not superCHild.. Perhaps it's not possible to get like this? You'll need to add a field called 'ojbConcreteClass' so that OJB knows which class to instantiate. Or you can super-references (in which case you don't need to duplicate the fields from Child in SuperChild in the repository file). See here for details on these strategies: http://db.apache.org/ojb/docu/guides/advanced- technique.html#Mapping+Inheritance+Hierarchies I solved it so, that I made 3 classes abstarct A B extends A C extends A and in code I call B or C not A. But still, B and C can't use same table name. Oh well, can't have everything. Problem is that now I have to change every class to use C instead of using A or B. What I would like to do like this: A B extends A and use B where B's extra stuff is needed and A where it's not needed. This way I can change just few files to use B and use A elsewhere. Now I have to change everything to use B. Also I don't know whether two connections on the same database works. You might run into problems with the cache. You should definitly have a look at the different cache implementations provided with OJB: Yes, this was a problem and solved in CVS. - Joose -- Always remember that you are unique, just like everyone else! * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+file regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException: java.lang.ClassCastException at org.apache.ojb.broker.metadata.MetadataManager.buildDefaultKey(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.getInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefaultKe y(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersi stenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker( Unknown Source) at org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSessio nPBImpl.java:79) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+fil e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException: java.lang.ClassCastException at org.apache.ojb.broker.metadata.MetadataManager.buildDefaultKey(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.getInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefault Ke y(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPer si stenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroke r( Unknown Source) at org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSess io nPBImpl.java:79) - 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: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+fil e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException: java.lang.ClassCastException at org.apache.ojb.broker.metadata.MetadataManager.buildDefaultKey(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.getInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefault Ke y(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPer si stenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroke r( Unknown Source) at org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSess io nPBImpl.java:79) - 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: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. Are you saying that dependencies were removed that rc6 had that 1.0 doesn't need? My Class-Path entry from my EJB jar file contains the following entries: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.1 Created-By: 1.4.2-b28 (Sun Microsystems Inc.) Built-By: andrew.clute Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi -1.5.1.jar p6spy.jar Are you thinking that there are unnesscary entries in it? I guess am not sure what the cause or solution would be based on your statement to look for. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+f il e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException: java.lang.ClassCastException at org.apache.ojb.broker.metadata.MetadataManager.buildDefaultKey(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.getInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefault Ke y(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPer si stenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroke r( Unknown Source) at org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSess io nPBImpl.java:79) - 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: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote: Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. sorry, my bad English ;-) I mean the names of some jars are changed, e.g. commons-collections-2.1.1.jar instead of commons-collections.jar. Maybe you have a jar in classpath that doesn't match the Class-Path setting. regards Armin Are you saying that dependencies were removed that rc6 had that 1.0 doesn't need? My Class-Path entry from my EJB jar file contains the following entries: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.1 Created-By: 1.4.2-b28 (Sun Microsystems Inc.) Built-By: andrew.clute Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi -1.5.1.jar p6spy.jar Are you thinking that there are unnesscary entries in it? I guess am not sure what the cause or solution would be based on your statement to look for. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+f il e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException: java.lang.ClassCastException at org.apache.ojb.broker.metadata.MetadataManager.buildDefaultKey(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.getInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefault Ke y(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPer si stenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroke r( Unknown Source) at org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSess io nPBImpl.java:79) - 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: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Ahh, I don't think that is the case, since my Class-Path setting is dynamically generated when I produce the EAR by taking all of the jars in my lib directory and adding it to that setting. Now, I did not update my commons-* jar file for 1.0 -- and you are saying that there was some upgrades? I wonder if that could be the issue. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:48 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. sorry, my bad English ;-) I mean the names of some jars are changed, e.g. commons-collections-2.1.1.jar instead of commons-collections.jar. Maybe you have a jar in classpath that doesn't match the Class-Path setting. regards Armin Are you saying that dependencies were removed that rc6 had that 1.0 doesn't need? My Class-Path entry from my EJB jar file contains the following entries: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.1 Created-By: 1.4.2-b28 (Sun Microsystems Inc.) Built-By: andrew.clute Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi -1.5.1.jar p6spy.jar Are you thinking that there are unnesscary entries in it? I guess am not sure what the cause or solution would be based on your statement to look for. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+f il e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException: java.lang.ClassCastException at org.apache.ojb.broker.metadata.MetadataManager.buildDefaultKey(Unknow n Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at org.apache.ojb.broker.metadata.MetadataManager.getInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefaul t Ke y(Unknown Source) at
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Upgrading to the newest versions of the lib files for OJB did not fix the problem. I wish there was someway I could figure out what was keeping the reference to the previous classes around that would conflict with the new classloader. Ugh! -Andrew -Original Message- From: Clute, Andrew [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:50 PM To: OJB Users List Subject: RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Ahh, I don't think that is the case, since my Class-Path setting is dynamically generated when I produce the EAR by taking all of the jars in my lib directory and adding it to that setting. Now, I did not update my commons-* jar file for 1.0 -- and you are saying that there was some upgrades? I wonder if that could be the issue. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:48 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. sorry, my bad English ;-) I mean the names of some jars are changed, e.g. commons-collections-2.1.1.jar instead of commons-collections.jar. Maybe you have a jar in classpath that doesn't match the Class-Path setting. regards Armin Are you saying that dependencies were removed that rc6 had that 1.0 doesn't need? My Class-Path entry from my EJB jar file contains the following entries: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.1 Created-By: 1.4.2-b28 (Sun Microsystems Inc.) Built-By: andrew.clute Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi -1.5.1.jar p6spy.jar Are you thinking that there are unnesscary entries in it? I guess am not sure what the cause or solution would be based on your statement to look for. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+f il e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor]
Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote: Ahh, I don't think that is the case, since my Class-Path setting is dynamically generated when I produce the EAR by taking all of the jars in my lib directory and adding it to that setting. Now, I did not update my commons-* jar file for 1.0 -- and you are saying that there was some upgrades? I wonder if that could be the issue. Agree, think 'old' libraries can't cause the issue. Between rc6 and 1.0 many changes are made in source (e.g. OJB startup behavior), but again I can't believe that these changes are responsible for your issue. Do my best, but now I'm stumped. Good luck in bug-hunting! Armin Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:48 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. sorry, my bad English ;-) I mean the names of some jars are changed, e.g. commons-collections-2.1.1.jar instead of commons-collections.jar. Maybe you have a jar in classpath that doesn't match the Class-Path setting. regards Armin Are you saying that dependencies were removed that rc6 had that 1.0 doesn't need? My Class-Path entry from my EJB jar file contains the following entries: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.1 Created-By: 1.4.2-b28 (Sun Microsystems Inc.) Built-By: andrew.clute Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi -1.5.1.jar p6spy.jar Are you thinking that there are unnesscary entries in it? I guess am not sure what the cause or solution would be based on your statement to look for. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+f il e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException: java.lang.ClassCastException at org.apache.ojb.broker.metadata.MetadataManager.buildDefaultKey(Unknow n Source) at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown Source) at
Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote: Upgrading to the newest versions of the lib files for OJB did not fix the problem. I wish there was someway I could figure out what was keeping the reference to the previous classes around that would conflict with the new classloader. Ugh! last-ditch attempt ;-) Did you check the entries in application.xml too? Or was this file auto-generated too? Armin -Andrew -Original Message- From: Clute, Andrew [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:50 PM To: OJB Users List Subject: RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Ahh, I don't think that is the case, since my Class-Path setting is dynamically generated when I produce the EAR by taking all of the jars in my lib directory and adding it to that setting. Now, I did not update my commons-* jar file for 1.0 -- and you are saying that there was some upgrades? I wonder if that could be the issue. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:48 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. sorry, my bad English ;-) I mean the names of some jars are changed, e.g. commons-collections-2.1.1.jar instead of commons-collections.jar. Maybe you have a jar in classpath that doesn't match the Class-Path setting. regards Armin Are you saying that dependencies were removed that rc6 had that 1.0 doesn't need? My Class-Path entry from my EJB jar file contains the following entries: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.1 Created-By: 1.4.2-b28 (Sun Microsystems Inc.) Built-By: andrew.clute Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi -1.5.1.jar p6spy.jar Are you thinking that there are unnesscary entries in it? I guess am not sure what the cause or solution would be based on your statement to look for. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+f il e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to be casted in to the same class type in a new class loader. I have taken a quick look at MetadataManager, and don't see anything terribly obvious as to the cause -- which I would assume is a static instance to the Collection of JdbcConnectionsDescriptors. There is a a ThreadLocal variable, but I don't think that is the cause. So, my question is: has anyone else seen this? Can anyone think of why on a undeployment that not all of the OJB classes are removed from the VM? Thanks! Here is the stacktrace: 2004-08-11
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
I don't fill out the application.xml entries, since I Thought it was an either-or situation (either Class-Path in the manifest file, or entries in Application.xml) -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 3:18 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: Upgrading to the newest versions of the lib files for OJB did not fix the problem. I wish there was someway I could figure out what was keeping the reference to the previous classes around that would conflict with the new classloader. Ugh! last-ditch attempt ;-) Did you check the entries in application.xml too? Or was this file auto-generated too? Armin -Andrew -Original Message- From: Clute, Andrew [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:50 PM To: OJB Users List Subject: RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Ahh, I don't think that is the case, since my Class-Path setting is dynamically generated when I produce the EAR by taking all of the jars in my lib directory and adding it to that setting. Now, I did not update my commons-* jar file for 1.0 -- and you are saying that there was some upgrades? I wonder if that could be the issue. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:48 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. sorry, my bad English ;-) I mean the names of some jars are changed, e.g. commons-collections-2.1.1.jar instead of commons-collections.jar. Maybe you have a jar in classpath that doesn't match the Class-Path setting. regards Armin Are you saying that dependencies were removed that rc6 had that 1.0 doesn't need? My Class-Path entry from my EJB jar file contains the following entries: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.1 Created-By: 1.4.2-b28 (Sun Microsystems Inc.) Built-By: andrew.clute Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi -1.5.1.jar p6spy.jar Are you thinking that there are unnesscary entries in it? I guess am not sure what the cause or solution would be based on your statement to look for. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+ f il e regards, Armin Clute, Andrew wrote: I am running OJB 1.0 with JBoss 3.2.5. On *occasional* redeployments of my EAR file (with nested Jars and Wars) I will get a nasty ClassCastException that is only fixable by restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. The top part of the stack trace is posted below. From what I can tell, the exception stems from not that it is the wrong class attempting to be casted, but it is an instance of a class that is from a previous deployment (and thus classloader) that is trying to
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Just for giggles, I changed my EAR to use the Application.xml file to denote the dependant jar files, and took it out of the Manifest file for my Ejb jar, and it still is causing the issue! Ughh. Might be time to post this to the Jboss forums -- but they are not nearly as helpful! :) -Andrew -Original Message- From: Clute, Andrew [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 3:22 PM To: OJB Users List Subject: RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? I don't fill out the application.xml entries, since I Thought it was an either-or situation (either Class-Path in the manifest file, or entries in Application.xml) -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 3:18 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: Upgrading to the newest versions of the lib files for OJB did not fix the problem. I wish there was someway I could figure out what was keeping the reference to the previous classes around that would conflict with the new classloader. Ugh! last-ditch attempt ;-) Did you check the entries in application.xml too? Or was this file auto-generated too? Armin -Andrew -Original Message- From: Clute, Andrew [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:50 PM To: OJB Users List Subject: RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Ahh, I don't think that is the case, since my Class-Path setting is dynamically generated when I produce the EAR by taking all of the jars in my lib directory and adding it to that setting. Now, I did not update my commons-* jar file for 1.0 -- and you are saying that there was some upgrades? I wonder if that could be the issue. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:48 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. sorry, my bad English ;-) I mean the names of some jars are changed, e.g. commons-collections-2.1.1.jar instead of commons-collections.jar. Maybe you have a jar in classpath that doesn't match the Class-Path setting. regards Armin Are you saying that dependencies were removed that rc6 had that 1.0 doesn't need? My Class-Path entry from my EJB jar file contains the following entries: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.1 Created-By: 1.4.2-b28 (Sun Microsystems Inc.) Built-By: andrew.clute Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi -1.5.1.jar p6spy.jar Are you thinking that there are unnesscary entries in it? I guess am not sure what the cause or solution would be based on your statement to look for. Thanks! -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine). Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? As far as I know the ClassLoader take care of static instances too. Did you check all jar names and Class-Path entries in your config files? I think that some jar files changed between rc6 and 1.0 Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+ f il e regards, Armin Clute,
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Well, I have narrowed the issue down further, but still do not have a
solution yet. In ConnectionRepository.getAllDescriptor(), the
JdbcConnectionDescriptor's that are in the current repository are cloned
(seralized) into another list and returned. I made the guess (and I was
right) that when this error is exposed, the JdbcConnectionDescriptor's
that are returned from the Serilization are loaded in a different
classloader than the ones that OJB creates!
To prove this, I changed the code for that method from:
[code]
public List getAllDescriptor()
{
return (List) SerializationUtils.clone(new
ArrayList(jcdMap.values()));
}
[/code]
To:
[code]
public List getAllDescriptor()
{
Iterator it = jcdMap.values().iterator();
while (it.hasNext()){
Object o = it.next();
System.out.println(ClassLoader for +
o.getClass().getName() + before Serialization:
+o.getClass().getClassLoader());
}
List returnList = (List) SerializationUtils.clone(new
ArrayList(jcdMap.values()));
it = returnList.iterator();
while (it.hasNext()){
Object o = it.next();
System.out.println(ClassLoader for +
o.getClass().getName() + after Serialization:
+o.getClass().getClassLoader());
}
return returnList;
}
[/code]
And as I assumed, the first time my application is deployed, the
classloader for the Connection is the same for both what OJB uses, and
what SerilizationUtils uses:
17:02:09,592 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
,addedOrder=37}
17:02:18,811 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
,addedOrder=37}
But, after redeploying it, the classloader for OJB changes (as I would
assume is correct), but the classloader for SerilizationUtils stays the
same as the previous version! Oops!
17:03:04,780 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56537OSNCore.ear
,addedOrder=38}
17:03:11,280 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
Serialization: [EMAIL PROTECTED]
url=null ,addedOrder=37}
So, now I need to figure out why this is happening. Something thing
looks weird for the after-serilization version after redploying, since
the url for that class is null. Not sure where it is loading it from, or
why it has a stored copy of it.
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 3:53 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
Just for giggles, I changed my EAR to use the Application.xml file to
denote the dependant jar files, and took it out of the Manifest file for
my Ejb jar, and it still is causing the issue!
Ughh. Might be time to post this to the Jboss forums -- but they are not
nearly as helpful! :)
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 3:22 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
I don't fill out the application.xml entries, since I Thought it was an
either-or situation (either Class-Path in the manifest file, or entries
in Application.xml)
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 3:18 PM
To: OJB Users List
Subject: Re: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote:
Upgrading to the newest versions of the lib files for OJB did not fix
the problem.
I wish there was someway I could figure out what was keeping the
reference to the previous classes around that would conflict with the
new classloader. Ugh!
last-ditch attempt ;-)
Did you check the entries in application.xml too? Or was this file
auto-generated too?
Armin
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 2:50 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
Ahh, I don't think that is the case, since my Class-Path setting is
dynamically generated when I produce the EAR by taking all of the jars
in my lib directory and adding it to that setting.
Now, I did not update my commons-* jar file for 1.0 --
Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
So, now I need to figure out why this is happening. Something thing
looks weird for the after-serilization version after redploying, since
the url for that class is null. Not sure where it is loading it from, or
why it has a stored copy of it.
I must admit that I don't have a clue...
Did you checked commons-lang.jar? SerializationUtils is part of
commons-lang and if this jar wasn't redeployed it will use the 'old'
class-loader. Or is commons-lang duplicated in classpath?
regards,
Armin
Clute, Andrew wrote:
Well, I have narrowed the issue down further, but still do not have a
solution yet. In ConnectionRepository.getAllDescriptor(), the
JdbcConnectionDescriptor's that are in the current repository are cloned
(seralized) into another list and returned. I made the guess (and I was
right) that when this error is exposed, the JdbcConnectionDescriptor's
that are returned from the Serilization are loaded in a different
classloader than the ones that OJB creates!
To prove this, I changed the code for that method from:
[code]
public List getAllDescriptor()
{
return (List) SerializationUtils.clone(new
ArrayList(jcdMap.values()));
}
[/code]
To:
[code]
public List getAllDescriptor()
{
Iterator it = jcdMap.values().iterator();
while (it.hasNext()){
Object o = it.next();
System.out.println(ClassLoader for +
o.getClass().getName() + before Serialization:
+o.getClass().getClassLoader());
}
List returnList = (List) SerializationUtils.clone(new
ArrayList(jcdMap.values()));
it = returnList.iterator();
while (it.hasNext()){
Object o = it.next();
System.out.println(ClassLoader for +
o.getClass().getName() + after Serialization:
+o.getClass().getClassLoader());
}
return returnList;
}
[/code]
And as I assumed, the first time my application is deployed, the
classloader for the Connection is the same for both what OJB uses, and
what SerilizationUtils uses:
17:02:09,592 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
,addedOrder=37}
17:02:18,811 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
,addedOrder=37}
But, after redeploying it, the classloader for OJB changes (as I would
assume is correct), but the classloader for SerilizationUtils stays the
same as the previous version! Oops!
17:03:04,780 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56537OSNCore.ear
,addedOrder=38}
17:03:11,280 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
Serialization: [EMAIL PROTECTED]
url=null ,addedOrder=37}
So, now I need to figure out why this is happening. Something thing
looks weird for the after-serilization version after redploying, since
the url for that class is null. Not sure where it is loading it from, or
why it has a stored copy of it.
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 3:53 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
Just for giggles, I changed my EAR to use the Application.xml file to
denote the dependant jar files, and took it out of the Manifest file for
my Ejb jar, and it still is causing the issue!
Ughh. Might be time to post this to the Jboss forums -- but they are not
nearly as helpful! :)
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 3:22 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
I don't fill out the application.xml entries, since I Thought it was an
either-or situation (either Class-Path in the manifest file, or entries
in Application.xml)
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 3:18 PM
To: OJB Users List
Subject: Re: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote:
Upgrading to the newest versions of the lib files for OJB did not fix
the problem.
I wish there was someway I could figure out what was keeping the
reference to the previous classes around that would conflict with the
new classloader. Ugh!
last-ditch attempt ;-)
Did you check the entries in application.xml too? Or was this file
auto-generated too?
Armin
-Andrew
-Original
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
I am wondering if it has something to do with the fact that
SerilizationUtils uses ObjectInputStream to serialize/desearlize the
objects, and ObjectInputStream on the deserialization does a
Class.forName() to create the new object -- which in the J2EE
classloader world can cause problems. I think that would explain why it
would use the previous versions. I am posting a message to the Jboss
group to see if my hypothesis is correct.
-Andrew
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 5:25 PM
To: OJB Users List
Subject: Re: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
So, now I need to figure out why this is happening. Something thing
looks weird for the after-serilization version after redploying, since
the url for that class is null. Not sure where it is loading it from,
or why it has a stored copy of it.
I must admit that I don't have a clue...
Did you checked commons-lang.jar? SerializationUtils is part of
commons-lang and if this jar wasn't redeployed it will use the 'old'
class-loader. Or is commons-lang duplicated in classpath?
regards,
Armin
Clute, Andrew wrote:
Well, I have narrowed the issue down further, but still do not have a
solution yet. In ConnectionRepository.getAllDescriptor(), the
JdbcConnectionDescriptor's that are in the current repository are
cloned
(seralized) into another list and returned. I made the guess (and I
was
right) that when this error is exposed, the JdbcConnectionDescriptor's
that are returned from the Serilization are loaded in a different
classloader than the ones that OJB creates!
To prove this, I changed the code for that method from:
[code]
public List getAllDescriptor()
{
return (List) SerializationUtils.clone(new
ArrayList(jcdMap.values()));
}
[/code]
To:
[code]
public List getAllDescriptor()
{
Iterator it = jcdMap.values().iterator();
while (it.hasNext()){
Object o = it.next();
System.out.println(ClassLoader for +
o.getClass().getName() + before Serialization:
+o.getClass().getClassLoader());
}
List returnList = (List) SerializationUtils.clone(new
ArrayList(jcdMap.values()));
it = returnList.iterator();
while (it.hasNext()){
Object o = it.next();
System.out.println(ClassLoader for +
o.getClass().getName() + after Serialization:
+o.getClass().getClassLoader());
}
return returnList;
}
[/code]
And as I assumed, the first time my application is deployed, the
classloader for the Connection is the same for both what OJB uses, and
what SerilizationUtils uses:
17:02:09,592 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
,addedOrder=37}
17:02:18,811 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
,addedOrder=37}
But, after redeploying it, the classloader for OJB changes (as I would
assume is correct), but the classloader for SerilizationUtils stays
the same as the previous version! Oops!
17:03:04,780 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56537OSNCore.ear
,addedOrder=38}
17:03:11,280 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
Serialization: [EMAIL PROTECTED]
url=null ,addedOrder=37}
So, now I need to figure out why this is happening. Something thing
looks weird for the after-serilization version after redploying, since
the url for that class is null. Not sure where it is loading it from,
or why it has a stored copy of it.
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 3:53 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
Just for giggles, I changed my EAR to use the Application.xml file to
denote the dependant jar files, and took it out of the Manifest file
for my Ejb jar, and it still is causing the issue!
Ughh. Might be time to post this to the Jboss forums -- but they are
not nearly as helpful! :)
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 3:22 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote: I am wondering if it has something to do with the fact that SerilizationUtils uses ObjectInputStream to serialize/desearlize the objects, and ObjectInputStream on the deserialization does a Class.forName() to create the new object -- which in the J2EE classloader world can cause problems. I think that would explain why it would use the previous versions. I am posting a message to the Jboss group to see if my hypothesis is correct. Hope you don't mind if I hop in :-) A couple of weeks ago we unified class and resource loading in OJB into the ClassHelper class, which per default uses the class loader of the current thread. So perhaps the problem here is that the SerializationUtils class does not use this class loader (it is known to happen that the classloader that class.forName uses is not the same as the one of the current thread, e.g. when writing Ant tasks). However in OJB we cannot change this, so perhaps you could create a modified version of commons-lang to verify this, and if this is true, then you probably should file a feature request with the commons-lang folks ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with storing / retrieving and automatic deleting
Any ideas on this? I tried implementing all my transactin in ODMG and had the same problem... Thanks -Clay Clay Mitchell wrote: Ok, maybe I don't understand exactly how this all works, but here is what's going on. I've posted the 3 relevant class-descriptors below. There are two source tables (ACCOUNT and SECURITY) and one that links the two (ACCOUNT_SECURITY). The initial load of an object works perfectly. All references are loaded perfectly, even cascading through dozens of tables. I create a new object / array representing ACCOUNT_SECURITY, populating the accountId and securityId fields, and then add it to the account object. I don't populate the SECURITY object. And then I store that account. New ACCOUNT_SECURITY entries work great, no problem with inserts. Here's where the problem starts: 1) Removing ACCOUNT_SECURITY entries that don't exist doesn't happen. 2) When I try to reload the account object, it stores the exact copy I stored, (I'm assuming the cache is taking over) while I need it to reload the entire object. Can I force this without turning off caching? Here's the three entries in my repository: class-descriptor class=com.exigentic.swls.AccountSecurity table=ACCOUNT_SECURITY field-descriptor name=securityId indexed=true primarykey=true default-fetch=true column=SECURITY_ID jdbc-type=INTEGER/ field-descriptor name=accountId indexed=true primarykey=true default-fetch=true column=ACCOUNT_ID jdbc-type=INTEGER/ reference-descriptor name=security class-ref=com.exigentic.swls.Security auto-update=false auto-delete=false foreignkey field-ref=securityId/ /reference-descriptor reference-descriptor name=account class-ref=com.exigentic.swls.Account auto-update=false auto-delete=false foreignkey field-ref=accountId/ /reference-descriptor /class-descriptor class-descriptor class=com.exigentic.swls.Security table=SECURITY field-descriptor name=id primarykey=true default-fetch=true autoincrement=true sequence-name=SEQ_SECURITY_ID column=SECURITY_ID jdbc-type=INTEGER/ collection-descriptor name=accountSecurities element-class-ref=com.exigentic.swls.AccountSecurity auto-update=false auto-delete=false inverse-foreignkey field-ref=securityId/ /collection-descriptor /class-descriptor class-descriptor class=com.exigentic.swls.Account table=ACCOUNT field-descriptor name=id indexed=true primarykey=true default-fetch=true autoincrement=true sequence-name=SEQ_ACCOUNT_ID column=ACCOUNT_ID jdbc-type=INTEGER/ collection-descriptor name=security element-class-ref=com.exigentic.swls.AccountSecurity auto-update=true auto-delete=true inverse-foreignkey field-ref=accountId/ /collection-descriptor /class-descriptor Thanks, -Clay Mitchell - 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: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
That's a good idea about trying a modified version of commons-lang. However, I am not sure what they will be able to do about it since they are using ObjectInputStream to do the serialization, and that is Sun's code. Either way, I will see if there is a workaround. On the other hand -- why is OJB using this method to do what looks like is a simple clone routine? If commons-lang method is known to be non-complaint with J2EE (especially JBoss) classloading, wouldn't OJB want to change the way it clones those descriptors? -Andrew -Original Message- From: Thomas Dudziak [mailto:[EMAIL PROTECTED] Sent: Fri 8/13/2004 6:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: I am wondering if it has something to do with the fact that SerilizationUtils uses ObjectInputStream to serialize/desearlize the objects, and ObjectInputStream on the deserialization does a Class.forName() to create the new object -- which in the J2EE classloader world can cause problems. I think that would explain why it would use the previous versions. I am posting a message to the Jboss group to see if my hypothesis is correct. Hope you don't mind if I hop in :-) A couple of weeks ago we unified class and resource loading in OJB into the ClassHelper class, which per default uses the class loader of the current thread. So perhaps the problem here is that the SerializationUtils class does not use this class loader (it is known to happen that the classloader that class.forName uses is not the same as the one of the current thread, e.g. when writing Ant tasks). However in OJB we cannot change this, so perhaps you could create a modified version of commons-lang to verify this, and if this is true, then you probably should file a feature request with the commons-lang folks ? 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]
