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.
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?
So, on with the requests:
1) some way of marking an entry as being "read only", so it doesn't require a setter. 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.
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
