Hmmm - on second thought, maybe a ResultObjectFactory can't solve this
issue. But I really dislike the idea of changing iBATIS so that it, in
effect, ignores the interfaces you declare by remembering their
implementations. If there's an interface, there's always a possibility of
more than one
Jeff and Clinton,
Thanks for the responses! However, I am going to push this question a bit
more because I think it's not limited to immutability. Granted, your points
on the Immutable Pattern are good ones, but the topic is ancillary. If I did
make the interface mutable, the problem will still
I erred at the start of 4th paragraph:
It read:
iBATIS errs out on #4 because it invokes BImpl.setA(), but gets back only
the interface from BImpl.getA().
It should read:
iBATIS errs out on #4 because it invokes setName() from BImpl.getA(), but
the method doesn't exist at this level.
Paul
Hi Paul,
Did you actually try this? I did and had no trouble running it. I'd be
happy to send you the test case if you want, but I think it's exactly what
you described.
Jeff Butler
On 1/15/07, Paul Benedict [EMAIL PROTECTED] wrote:
I erred at the start of 4th paragraph:
It read:
Can you send the test case? That would be great. The example I did not
try per se, but it is a simplified example of what I've experienced for
a long time. The class and properties names aren't the same but the
concept is.
Paul
Jeff Butler wrote:
Hi Paul,
Did you actually try this? I did
I think I solved the problem. When I typed the problem out, I did not
realize I incorrectly stated the result map, which should be:
resultMap id=BResult class=BImpl
result property=a.name column=name /
/resultMap
Jeff, my original example and your example worked because it was done
I have this problem currently in iBATIS 2. I would prefer it be solved
in 2.4, but if it is more extensive in scope, then I wouldn't mind
seeing it pushed off to version 3.
Here are two classes which have two immutable interfaces:
interface A { class AImpl implements A {
String
First thought - ugh. I really don't care for domain classes being built
this way. We did it once and it really didn't solve anything. If a
programmer wants to break the immutability, it is a simple matter to cast
the interface to the mutable implementation. So it's just a lot of hassle
for no
Jeff,
Thanks for the reply. I know not everyone likes the immutable pattern,
but I have found it tremendously useful and cuts down on a lot of
synchronized behavior because it creates thread-safe access. I am not
promoting its use for everything, but because I have quite a few classes
which
