History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CASTOR-831
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Unassigned
Reporter: Martin Fuchs
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
castor

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

Created: 21/Jul/04 03:49 PM   Updated: 28/Aug/05 05:00 PM
Component/s: JDO
Affects Version/s: 0.9.5.3
Fix Version/s: 0.9.9 M1

Time Tracking:
Not Specified

File Attachments: 1. Text File 1691-updated.patch (23 kb)
2. Text File castor-1691-set-add.patch (25 kb)
3. Text File castor-1691-set-add.patch (25 kb)
4. Text File castor-1691-updated.patch (25 kb)
5. Text File castor-1691.patch (17 kb)
6. Zip Archive oraclejdotest.zip (2 kb)

Environment:
Operating System: Windows 2000
Platform: PC
Issue Links:
Related
 
dependent
 

Bugzilla Id: 1691


 Description  « Hide
To activate connection pooling using the Oracle JDBC driver, one has to use
the "data-source" form of configuration. This is a correct example for a
database configuration:

<database name="database" engine="oracle">
<data-source class-name="oracle.jdbc.pool.OracleConnectionCacheImpl">
<params URL="jdbc:oracle:thin: at localhost:1521:TEST" user="scott"
password="tiger" />
</data-source>
...
</database>

This activates Oracle connection pooling using the default parameters.

Optionally you can add additional parameters in <params> such as:

cache-time-to-live-timeout="30"
cache-fixed-wait-timeout="30"
max-limit="10"

What doesn't work is to specify an caching scheme using:

cache-scheme="OracleConnectionCacheImpl.DYNAMIC_SCHEME"

This results in an exception: (using Castor 0.9.5.3)
java.lang.NumberFormatException: For input
string: "OracleConnectionCacheImpl.FIXED_SCHEME"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.<init>(Unknown Source)
at org.exolab.castor.xml.UnmarshalHandler.toPrimitiveObject
(UnmarshalHandler.java:3303)
at org.exolab.castor.xml.UnmarshalHandler.processAttribute
(UnmarshalHandler.java:2770)
at org.exolab.castor.xml.UnmarshalHandler.processAttributes
(UnmarshalHandler.java:2479)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:2147)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:1292)
at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
at org.apache.xerces.validators.common.XMLValidator.callStartElement
(XMLValidator.java:1197)
at org.apache.xerces.framework.XMLDocumentScanner.scanElement
(XMLDocumentScanner.java:1862)
at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch
(XMLDocumentScanner.java:1238)
at org.apache.xerces.framework.XMLDocumentScanner.parseSome
(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1035)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:605)
at org.exolab.castor.jdo.engine.DatabaseRegistry.loadDatabase
(DatabaseRegistry.java:235)
at org.exolab.castor.jdo.JDO.getDatabase(JDO.java:603)
at ScottTest.run(ScottTest.java:63)
at ScottTest.main(ScottTest.java:23)

It seems, Castor doesn't translate the expression constant into a numeric value.

The following option to specify a caching scheme doesn't work either:
cache-scheme="1"

This results in another exception:
java.lang.IllegalArgumentException: Type conversion error: could not set value
of cacheScheme(java.lang.Integer) with value of type java.lang.Integer
at org.exolab.castor.mapping.loader.FieldHandlerImpl.setValue
(FieldHandlerImpl.java:474)
at org.exolab.castor.xml.UnmarshalHandler.processAttribute
(UnmarshalHandler.java:2779)
at org.exolab.castor.xml.UnmarshalHandler.processAttributes
(UnmarshalHandler.java:2479)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:2147)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:1292)
at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
at org.apache.xerces.validators.common.XMLValidator.callStartElement
(XMLValidator.java:1197)
at org.apache.xerces.framework.XMLDocumentScanner.scanElement
(XMLDocumentScanner.java:1862)
at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch
(XMLDocumentScanner.java:1238)
at org.apache.xerces.framework.XMLDocumentScanner.parseSome
(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1035)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:605)
at org.exolab.castor.jdo.engine.DatabaseRegistry.loadDatabase
(DatabaseRegistry.java:235)
at org.exolab.castor.jdo.JDO.getDatabase(JDO.java:603)
at ScottTest.run(ScottTest.java:63)
at ScottTest.main(ScottTest.java:23)

This error occures, because the function setCacheScheme() excpects a 'long'
parameter, not a parameter of type 'int'. And Castor doesn't convert it from
java.lang.Integer to long.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Werner Guttmann - 09/Aug/04 08:31 AM
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.


Martin Fuchs - 09/Aug/04 10:49 AM
> 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.


Werner Guttmann - 11/Aug/04 03:19 AM
Just added a dependency on bug 1628, as clearly this problem would be resolved
without any work if we committed bug 1628.

Werner Guttmann - 07/Oct/04 04:44 AM
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.

Martin Fuchs - 07/Oct/04 07:42 AM
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 ***

Martin Fuchs - 20/Oct/04 12:56 PM
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)


Werner Guttmann - 20/Oct/04 12:59 PM
Just added Keith to CC.

Martin Fuchs - 20/Oct/04 01:12 PM
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.

Martin Fuchs - 21/Oct/04 04:19 PM
Created an attachment (id=742)
first version of a patch

Martin Fuchs - 21/Oct/04 04:24 PM
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?

Martin Fuchs - 22/Oct/04 02:49 PM
Created an attachment (id=743)
new version of the patch, now supporting multiple add methods

Martin Fuchs - 23/Oct/04 04:37 AM
Created an attachment (id=744)
fixed null pointer exceptions

Werner Guttmann - 07/Dec/04 05:21 AM
Keith, can you please share your views with us wrt Martin's suggestion ?

Keith Visco - 07/Dec/04 09:14 AM
I think it's a good idea, +1.

Werner Guttmann - 08/Dec/04 02:47 AM
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 ...

Martin Fuchs - 10/Dec/04 11:37 AM
I did run the test suite using CTFRun.bat and can't see any problems. It
reports 159 test cases and no failures.

Werner Guttmann - 11/Dec/04 02:01 AM
Well, in this case, let me try to get this into the codebase this weekend .. .

Werner Guttmann - 14/Dec/04 07:29 AM
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.

Martin Fuchs - 14/Dec/04 11:14 AM
Created an attachment (id=821)
updated patch

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


Werner Guttmann - 14/Dec/04 11:39 AM
Martin, would you mind if I moved this to 0.9.7, i.e. post 0.9.6 ?

Martin Fuchs - 14/Dec/04 12:02 PM
No problem. We are using our own version containing not yet commited patches
anyways.

Werner Guttmann - 14/Dec/04 12:09 PM
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 .. .

Martin Fuchs - 03/Jan/05 05:49 AM
> 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


Martin Fuchs - 05/Mar/05 10:21 AM
Created an attachment (id=956)
updated import statements

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


Werner Guttmann - 05/Mar/05 12:28 PM
Sure, will look into this .. well, this weekend .. .

Werner Guttmann - 08/Mar/05 08:21 AM
Actually, why don't you re)assign this to yourself, and eventually commit this?

Werner Guttmann - 15/Mar/05 07:04 AM
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 ?

Martin Fuchs - 20/Mar/05 03:41 AM
Sorry for not answering faster. I will add my test case and commit the patch.

Martin Fuchs - 20/Mar/05 04:39 AM
Created an attachment (id=982)
Test case in ZIP archive

Ralf Joachim - 20/Mar/05 06:13 AM
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?


Martin Fuchs - 24/Mar/05 01:40 AM
What are you missing in the CHANGELOG?

Ralf Joachim - 24/Mar/05 05:57 AM
Sorry, I have overlooked your changes to CHANGELOG. It's all as it should be.

Gregory Block - 24/Apr/05 05:56 AM
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?


Gregory Block - 24/Apr/05 06:13 AM
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.)


Werner Guttmann - 22/May/05 04:39 AM
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 ?

Werner Guttmann - 22/May/05 09:25 AM
Martin, just backed out the patch you just sent to committers at castor dot codehaus dot org .. . Gregory, can you please run your regression tests and come back to me with results ?

Werner Guttmann - 22/May/05 09:26 AM
As we just backed out CASTOR-831, this should run successfully again.

Werner Guttmann - 22/May/05 09:27 AM
As we just backed out CASTOR-831, this should run successfully again.

Werner Guttmann - 22/May/05 09:27 AM
As we just backed out CASTOR-831, this should run successfully again.

Martin Onis - 24/May/05 03:25 PM
> 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)


Ralf Joachim - 03/Aug/05 04:39 PM
Patch has been reverted due to problem described at CASTOR-1147

Ralf Joachim - 23/Aug/05 04:15 PM
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.


Ralf Joachim - 23/Aug/05 04:17 PM
Changed my opinon and resolve this one as 'Won't fix'