Gregory,
please see inline ...
Werner
On Tue, 22 Jun 2004 09:48:23 +0100, Gregory Block wrote:
>
>I've just done a deploy of HEAD to our staging servers last week, and
>have been running it through its paces to see how it behaves.
>
>First, the good news - it looks very good. Haven't run into any
>operational issues - the things that worked then work now, and work
>predictably and reliably. No problems to report at this point in time.
Thanks .. ;-). Btw, if you've got specific questions to code in HEAD, let me know ...
>Now, the bad news. Something rather odd happened - and I'm not sure
>whether it's a problem in .3 release as well as HEAD or whether it's
>something new, and I'm not quite sure how reproducible it is...
>
>Basically, we have multiple mapping files here; we have one mapping
>file responsible for our core JDO object loading, and multiple mapping
>files for getting those JDO formats into several outbound feed formats.
>
>I had a problem with one of the JDO objects; I had written the getters
>for a specific set, but the setters were absent. As they are
>outbound-only representations, I had hoped that it wouldn't be bothered
>by methods that weren't used. Rather silly, I guess - would be nice to
>say "read-only"
>or something in order to not require a setter on the object; especially
>when it's implementation is going to do nothing except throw a not
>implemented exception.
>
>Anyways, aside from all that. In the mapping, early on, is a mapping
>to an ArrayList of EventDate objects; later on, there's a mapping to an
>array of EventCategory and EventLocation objects.
>
>When the mapping loaded, it reported that it failed to find the setter
>on eventCategory; however, when an object was produced using that
>failed mapping, it reported a class cast exception; inserting a debug
>statement made it clear that it was getting an EventDate object,
>essentially that in
>the progress of doing whatever it was looking to do, it had reused
>something from a previous run - a var didn't get cleared, or something,
>and it had built the mapping using the wrong methods. Somehow, a
>ListClassDescriptor ended up getting associated with it; that assumes
>that the
>value object is a (java.util.List), which threw a class cast exception.
> The in-memory mapping object was clearly in a very confused state -
>adding the required setter to the DAO in question caused it to all
>magically correct itself.
>
>Does that make any sense to anyone?
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 ... ;-).
>So, on with the requests:
>
>1) some way of marking an entry as being "read only", so it doesn't
>require a setter.
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.
>Preferrably applicable to individual methods as well
>as the whole class; if neither are easy, how's about being able to mark
>a whole mapping file as being 'read only' - for transforming into XML,
>but not from XML - so that I can lock down that API.
>
>2) Better failure for the above condition; rather than creating an
>improper mapping, either find a way to deal with the missing
>information and still produce a usable mapping that fails on method
>access, or just outright fail each time with an appropriate error. It
>threw me off that I was getting
>class cast exceptions instead of a mapping error, and it was only when
>I went digging through Catalina logs that I found that there was an
>error before what I was seeing which failed during the mapping
>processing.
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.
>
>
>
>-----------------------------------------------------------
>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
