Re: Abstract causes server exception
Re: Abstract causes server exception
- Subject: Re: Abstract causes server exception
- From: Chuck Hill <email@hidden>
- Date: Thu, 1 Sep 2005 20:35:56 -0700
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._selectWithFetchSpecificatio
nEditingContext(EODatabaseChannel.java:770)
at
com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecificatio
nEditingContext(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.
Perhaps this could be documented in the next WebObjects book,
Chapter 3: The Many Vexing Bugs in EOModeler
:-)
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.
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.
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 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 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.
Chuck
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden