Quick comment inline...
-Nick
-------Original Message-----
--From: Gregory Block [mailto:[EMAIL PROTECTED]
--Sent: Tuesday, June 22, 2004 3:10 PM
--To: Castor Developers
--Subject: Re: [castor-dev] Current CVS head...
--
--
--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.
--
--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.
Doesn't it make sense that a read-only sql field would still need a set
method? I mean you need to get the field value into the object somehow
so that people can actually "read" it from the object. I'm gathering
that what is really needed is a "write-only" field. Sounds kinda strange
but I think it would apply to this case, and kind of makes sense. Anyone
else think this would be a useful ability to have? This way we can only
specify get-methods with no need for sets.
--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)
--
--> 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
