On Jan 18, 2007, at 2:09 AM, David Blevins wrote:
On Jan 17, 2007, at 10:36 PM, David Blevins wrote:
On Jan 17, 2007, at 10:02 PM, Alan D. Cabrera wrote:
On Jan 16, 2007, at 11:51 PM, David Blevins wrote:
On Jan 16, 2007, at 1:48 PM, [EMAIL PROTECTED] wrote:
Author: adc
Date: Tue Jan 16 13:48:35 2007
New Revision: 496867
URL: http://svn.apache.org/viewvc?view=rev&rev=496867
Log:
First step at state based contexts and operation checking
Wow, the reworked CoreContext and subclasses are surprisingly
clean and simple.
Thanks. I wanted to consolidate all the allowed operations into
one place. All checks will go through this class.
I like it. I mean that chunk of code could go write on the
website as documentation. It leaves us with one set of rules for
each bean type, and all the real code is in one class only.
I see you're now removing some of the code I like :) I don't
think you need all the subclasses anymore, I think what you had was
teetering on perfection.
If you replaced your constants with enums and massaged your
comments into checks, you'd have some pretty sweet code that would
even throw extremely specific error messages like
"getCallerPrinciple cannot be called in ACTIVATE"
Here's what I mean: http://cwiki.apache.org/confluence/display/
OPENEJB/EjbContext+Whiteboard
I think that I understand your point but I don't think that I agree.
It seems to me a lot of work just to to get information in the
exception; this information can easily be obtained by the call
stack. It also seems, imho, to obfuscate what operations are
permissible and which are not. Using my current paradigm, the inner
classes map directly to the spec tables.
Regards,
Alan