On 02/09/2005, at 1:35 PM, Chuck Hill wrote: Hi Ian,
On Sep 1, 2005, at 6:15 PM, Ian Joyner wrote:
Since I found the solution to my own problem, but could not find it documented in either the Omni list or here, I thought I'd write it up in case others hit the same several-hour wasting problem.
I created a new model in my project and most of the entities were subclasses of a generic entity, so I created in EOModeler the generic entity with abstract set and subclassed the entity. When I ran this, I got an exception on the server side:
[2005-09-02 10:20:44 EST] <WorkerThread5> Server exception: null [2005-09-02 10:20:44 EST] <WorkerThread5> java.lang.NullPointerException at com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecificationEditingContext(EODatabaseChannel.java:770) at com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecificationEditingContext(EODatabaseChannel.java:806)
What I found was that subclassing in EOModeler had not reset the abstract setting (a property that should not be preserved). This is strange because properties like client-side attribute are not preserved when subclassing.
I'm pretty sure that preserving the abstract setting is correct behavior. Losing the client-side attributes is the bug. It loses other things too at times.
I'd argue for resetting it on the grounds that it leads to this trap (purely selfish reason). But also, inheritance hierarchies in WO tend not to be more than one deep. Even if you are not in WO, OO classes do not inherit the abstract (deferred in Eiffel) property of a parent.
Perhaps this could be documented in the next WebObjects book,
Chapter 3: The Many Vexing Bugs in EOModeler :-)
Look forward to reading it ;-)
but I can think of three things Apple could do to improve WO in order to avoid this kind of (at worst project-killing) grief.
1) Fix EOModeler so that abstract is reset when subclassing and all the many little niggles with EOModeler like this.
The new Xcode plugin should make all this obsolete. Doubtless, it will replace them with new, different defects.
Yea!!!!.... Awwwww!!!!
2) Put a run time check at all the places like line 770 so that at line 770 (or earlier in the call chain) a fetch against an abstract entity is rejected. That is put much more DBC into WO (or just rewrite the whole thing in Eiffel!)
DBC is not meant to be in a deployed app so that is not really a solution. But EOAccess is far too optimistic about "this won't ever be null". Much better error condition checking and accurate error diagnosis is certainly needed.
Correct, but I was thinking perhaps how DBC affects how the rest of the code is written, ie the method containing line 770 might have:
require not entity.abstract
callers of this method would then write into their code a real runtime check that they are not passing abstract (because they have perhaps run the system and been caught by the development-time requires clause).
3) Integrate checks into the build process or into Interface Builder so that you are not allowed to do anything that might result in a fetch against an abstract entity in the first place (this is the difficult option).
That would require static Java analysis and probably more than a fair bit of intelligence. A RuntimeException seems like the more appropriate solution.
I wasn't thinking of Java analysis, but something like a check in IB that a display group was not getting its data source from an abstract entity. In other words better integration between EOM and IB and Xcode, but that would probably need a fair bit of reengineering.
I think if all these traps for the unwary/newbie that are documented in these groups made their way into Apple's code so that the traps did not exist in the first place, WO would be a much better development environment akin to type checking in languages.
Yep, just a question where Apple sees value in allocating its resources. And is _is_ a hardware company. I'm just happy that WO made it into Xcode and is getting a new EOModeler and WOBuilder.
I agree, it's good that Apple has now got a way forward for WO. You'd think with all these industry leading development tools that Apple's focus would become more development centric – that's the way into the corporate market where you have to have a good customer/vendor relationship. I'm not sure Apple is good at promoting hardware either. On TV this morning was a give away of a Windows XP system, "Media Centre Edition" – which is just what some MS marketer made up, because different editions of OSs is meaningless.
I don't know if you can categorize these kinds of issues as "bugs", so how does one get this message to Apple? Does anyone from Apple actually read these groups?
They do, at least on occasion. I don't know that they read each and every message. But this is not an appropriate or effective means of reporting bugs, wished for enhancements etc. Those need to be filed at http://bugreport.apple.com. Only things reported there will ever get changed.
I have a good list there already, but most have just been 'open' for months. I don't really want to hold them up fixing real defects by submitting wishlists. Oh well.
Ian |