On Tue, 22 Jun 2004 20:10:15 +0100, Gregory Block wrote:
>
>On 22 Jun 2004, at 19:39, Werner Guttmann wrote:
>
>> Thanks .. ;-). Btw, if you've got specific questions to code in HEAD,
>> let me know ...
>
>Actually, I've taken umbrage with some of the code in
>util.Configuration - I'll hand back a patch shortly and attach it to
>the bug that is listed in bugzilla already. We really need to *see* a
>SecurityException when it goes off because we haven't got access to
>bits and pieces; otherwise, they're nigh-on impossible to diagnose.
Great. I am looking forward to be informed about bug reports being created ... :-).
>Just changes to error handling, and some associated modifications to
>messages text to support that info.
>
>> No, not really .. ;-). Can you send me a small, self-contained example
>> that allowed me to reproduce what you are experiencing ? I know that
>> you
>> mentioned yourself that it looks like things are not really
>> reproducible, but if there's a small chance that it is ... ;-).
>
>I'll have a crack at it. If it is what I think it is, then all I
>should need to do is refer to a method which has a setter but no getter
>and takes an array type.
>
>> Well, there's a read-only attribute for the <sql> element, but afaik,
>> it only affects the generation of SQL elements. I'd have to
>> investigate whether it still
>> expects a setter to be in place.
>
>It'd be nice if it didn't - but that looked like a major hassle in the
>code when I was just looking at it. (Still trying to get my head
>around the way that works - that's an awful lot of "meta" coding)
Well, the code looks more complicated than it really is. Just top of my head, one
could add yet another attribute to the <field> element to specify
whether a setter should be relie upon or not. Just a thought, though .. ;-). And not
well thought-through, either.
>> Again, if you provided me with a small sample app, I could try to add
>> better exception handling, as from your description it clearly seems
>> like Castor is
>> failing in this area.
>
>I just had this gut feeling that when it went to create the mapping
>object, it reused a previous object that had the bad data in it, and
>instead of failing, continued on to the rest of the file because it had
>a getter and whatever was left over from the previous mapping operation
>of that kind.
>
>That's what it *looked* like. Dunno if it's true.
>
>
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
