That would work. I had another idea on my way home. What if the constructRegistry threw an exception if there was any problem in the construction, that is after the registry is built? That way the application can decide what to do. What do you think about that?

-Harish

Howard M. Lewis Ship wrote:

Perhaps we should put a check in RegistryBuilder:

if (!LOG.isErrorEnabled())
 System.err.println("*** Logging not enabled for xxxx. Module parse and validation 
errors will not
be visible. ***");

In addition, an earlier version of the code had a brittle flag (that I used during 
testing). Turning
the flag on would make some errors turn into thrown exceptions. I only used it for 
testing, and
eventually discarded that and created a specialized Appended used to determine if 
certain messages
had been logged. It could be ressurected and tied to a JVM system property.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com



-----Original Message-----
From: Bill Lear [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 5:11 PM
To: Tapestry users
Cc: [EMAIL PROTECTED]
Subject: Re: [HiveMind] Re: Tapestry exception report incomplete?



On Thursday, October 2, 2003 at 17:04:20 (-0400) Harish Krishnaswamy writes:


...
Why not just toss the thing and let the app catch it?



My understanding is, from a microkernel standpoint, it is

not supposed


to crash just because one module or service had a problem,

you know like

the containers, they just report the problem and move on. But the containers have a console or a designated log file that one

can take a

look at, but HiveMind does not have either, that will be a

problem for

the uninformed, I think.


Hmm, not sure I agree with this --- if someone mis-configures a microkernel, I'd rather have it crash and tell me about it than sputter on and die later, pointing me elsewhere by a subsequently thrown exception. I'll have to think and bring pursue discussion on the hivemind list.


Bill


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Reply via email to