|
|
|
> 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 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.
Reopened the bug.
Using the "cache-scheme" parameter with classes12.jar as JDBC driver works The problem is: 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 ?
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. 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 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 (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 at castor dot codehaus dot org ..
![]() As we just backed out
As we just backed out
As we just backed out
> 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 OK (1 test) Patch has been reverted due to problem described at CASTOR-1147
While working at
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'
|
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.