not possible to specify the pooling parameter "cache-scheme" for Oracle connects

Martin, the second exception reported above definitely is genuine, and needs to
be addressed.

Please bear in mind that you won't be able to use an expression such as

cache-scheme="OracleConnectionCacheImpl.DYNAMIC_SCHEME"

at all, as we won't be able to access driver specific constants.

> Please bear in mind that you won't be able to use an expression such as
> cache-scheme="OracleConnectionCacheImpl.DYNAMIC_SCHEME"
> at all, as we won't be able to access driver specific constants.

OK, I also thought so. It was just a try since I found this expression in some
old mails to the topic.

Just added a dependency on bug 1628, as clearly this problem would be resolved
without any work if we committed bug 1628.

Martin, as bug 1628 has been committed yesterday, can you please verify whether
you are still seeing above problem? If not, this bug should be closed as a
duplicate of bug 1628.

Yes, it now works to add the "cache-scheme" parameter to the data-source
configuration.

• • • This bug has been marked as a duplicate of 1628 ***

Reopened the bug.

Using the "cache-scheme" parameter with classes12.jar as JDBC driver works
without problems. But using the newer "ojdbc14.jar" JDK 1.4 JDBC drivers results
in the exception talked about above. Both drivers are from Oracle 9 and export
the same interface: There are two methods setCacheSchema(int) and
setCacheSchema(String) in oracle.jdbc.pool.OracleConnectionCacheImpl.

The problem is:
org.exolab.castor.xml.descriptors.CoreDescriptors.generateClassDescriptor()
expects to find only ONE set method, not more. It does not look at the parameter
types to find the correct method to call. It is just luck if the one or the
other is chosen. (dependent on in which order the methods are enumerated from
Java Reflection)

Just added Keith to CC.

Keith, what do you think about allowing more than one set method in
FieldHandlerImpl and choosing between them in selectWriteMethod() based on the
parameter type given? This would allow to call the correct setter method and
solve the problem with overloaded functions.

Created an attachment (id=742)
first version of a patch

Hi,
this is my first version of a patch to solve the problems using the approach
described above. Any comments are appreciated. The "cache-scheme" parameter
works with this patch. But I am not quite sure, I got all completely right and
there are no side unpredicted effects. Should there also be the possibility for
more than one "add" method in addition to the multiple set methods?

Created an attachment (id=743)
new version of the patch, now supporting multiple add methods

Created an attachment (id=744)
fixed null pointer exceptions

Keith, can you please share your views with us wrt Martin's suggestion ?

I think it's a good idea, +1.

Iow, as long as we don't break the XML test suite, let's commit this change. And
let's amend the documentation to get across the message that element/attribute
order is relevant (once this patch has been committed). At least a FAQ entry
should be added ...

I did run the test suite using CTFRun.bat and can't see any problems. It
reports 159 test cases and no failures.

Well, in this case, let me try to get this into the codebase this weekend .. .

Martin, can you please attach a new patch, as the current one can not be applied
(easily) anymore as the code base has changed in places you are touching as well.

Created an attachment (id=821)
updated patch

OK, here is an up-to-date patch.

Martin, would you mind if I moved this to 0.9.7, i.e. post 0.9.6 ?

No problem. We are using our own version containing not yet commited patches
anyways.

Thanks. I'll commit this against head once the 0.9.6 release tag has been
created. And you guys really surprise me ... first Gregory, now you. Never heard
of stable and tested releases .. .

> Never heard of stable and tested releases .. .

Sure, I heared of this the one or the other time.
But running projects are always urgent and can't wait until release dates of
third party libraries, which seem always to move until sometime in the future.
g

Created an attachment (id=956)
updated import statements

Werner, you wanted to commit this after the 0.9.6 release.

Sure, will look into this .. well, this weekend .. .

Actually, why don't you re)assign this to yourself, and eventually commit this?

Martin, I am sure you have a ready-to-use test case for your patch. Do you mind
attaching it ... as I'd really like to commit this asap ?

Sorry for not answering faster. I will add my test case and commit the patch.

Created an attachment (id=982)
Test case in ZIP archive

Hi Martin, looks like you forgot to add your changes to src/etc/CHANGELOG.

What do you think, shouldn't we add your test to CTF test suit even if it is
only applicable for Oracle?

What are you missing in the CHANGELOG?

Sorry, I have overlooked your changes to CHANGELOG. It's all as it should be.

This patch has broken my ability to load XML files with a specific set-method="addMethod" configured on them; reverting this patch has returned the codebase to working order.

I'm guessing that there's something wrong with the dual-processing of information from Introspector's creation of the FieldHandlerImpl, but I'm not sure; to be honest, I'm not even sure where to start looking.

But before the patch, it's 100% ok, and after, it's 100% broken.

Here's the jist of what I'm guessing.

I've got a class called Cobrand; it has an addMember() method that adds and indexes values on the member object it loaded for later use. Member has a setParent(Cobrand cobrand) that appears to be getting nulled at some point, because the addMember() call is explicitly setting setParent() on it.

But when I run the tree's validate call (which is a part of its API) the Member reports that getParent() returns null - so setParent somehow gets called when it shouldn't.

Someone have any idea what's going on here?

What appears to be an associated patch by rjoachim to org.exolab.castor.persist.FieldMolder is having the same effect on add-methods for JDO once this patch is reverted, resulting in exceptions that look like...

24 Apr 2005 12:06:39 - org.apache.slide.common.XMLUnmarshaller - INFO - Loading object /roles
org.exolab.castor.jdo.DataObjectAccessException: Type conversion error: could not set value of Field
Molder of com.wow.framework.dao.UserSubscription.setservices(com.wow.framework.dao.UserSubscriptionS
ervice services) with value of type java.util.ArrayList
at org.exolab.castor.persist.FieldMolder.setValue(FieldMolder.java:356)
at org.exolab.castor.persist.CollectionProxy$ColProxy.close(ClassMolder.java:3174)
at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:812)
at org.exolab.castor.persist.LockEngine.load(LockEngine.java:366)
at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:701)
at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:582)
at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:810)
at org.exolab.castor.persist.LockEngine.load(LockEngine.java:366)
at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:701)
at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:582)
at org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:341)
at org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:331)
at com.wow.services.dao.AbstractJDOLoader.load(AbstractJDOLoader.java:100)
at com.wow.services.dao.AbstractJDOLoader$ParallelRetrievalTask.run(AbstractJDOLoader.java:4
00)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:552)

(again, the add-method didn't get recognized, and the set-method referenced doesn't even exist.)

Martin, I am about to back out this patch as it seems to be causing problems all over the place. I have got one problem, though: it's absolutely impossible to tell which patch to use. There's two patches submitted on March 21, 2005 at the same time (one with 23kb, one with 25 kb). Any idea which I should be using ?

Martin, just backed out the patch you just sent to committers@castor.codehaus.org .. . Gregory, can you please run your regression tests and come back to me with results ?

As we just backed out CASTOR-831, this should run successfully again.

As we just backed out CASTOR-831, this should run successfully again.

As we just backed out CASTOR-831, this should run successfully again.

> Thanks, Martin. I'll try to get this patch applied today or (at latest)
> tomorrow at work. I assume it will have dawned upon you that once I have
> checked this patch in, we are not going to support multiple set-methods
> (with different types) anymore. But with Greg's regression test, it
> should be straight forward for you to come up with a new patch that does
> not run into the problems we are currently seeing.

I tried this test case, but can't see any problems - neither with this patch not without it:

D:\Castor\CTF-Tests>ctfrun -text src\tests\xml\RegressionTestSuite\mapping\GSC_Regression
The system cannot find the file specified.
.\build\classes;.\build\tests;D:\java\j2sdk1.4.2_06\lib\tools.jar;lib\adaptx-0.9.13.jar;lib\ant-1.6-
launcher.jar;lib\ant-1.6.jar;lib\cglib-full-2.0.2.jar;lib\commons-logging.jar;lib\hsqldb.jar;lib\jak
arta-oro-2.0.5.jar;lib\jakarta-regexp-1.1.jar;lib\jdbc-se2.0.jar;lib\jndi_1.2.1.jar;lib\jta1.0.1.jar
;lib\jtf-0.1.jar;lib\junit_3.8.1.jar;lib\ldapjdk_4.1.jar;lib\log4j-1.2.8.jar;lib\mysql-connector-jav
a-3.0.15-ga-bin.jar;lib\mysql-connector-java-3.0.16-ga-bin.jar;lib\mysql-connector-java-3.1.6-bin.ja
r;lib\ojdbc14.jar;lib\postgresql.jar;lib\servlet.jar;lib\xerces-J_1.4.0.jar
arg: '-text'
Running in text mode.
arg: 'src\tests\xml\RegressionTestSuite\mapping\GSC_Regression'
Using '1116966177968' as seed for the initialization of the pseudo-random number generator
.
Time: 3,265

OK (1 test)

Patch has been reverted due to problem described at CASTOR-1147

While working at CASTOR-943 I needed to change setting of parameters on datasource fromusing Unmarshaller to java reflections. according to this change this patch doesn't apply any longer. Having said that with CASTOR-943 also setting cache-scheme is possible with the syntax:

cache-scheme=1

still the syntax with using the CACHE_SCHEME_DYNAMIC constant of the oracle driver is not possible but IMO not required. I'll therefore close this issue as duplicate.

Changed my opinon and resolve this one as 'Won't fix'