[kepler-dev] Abort/Retry/Error Stacktrace window

[Kevin Ruland]

Hi all,

Christopher and I have been discussing application startup off-line --
mostly because it consisted of intermittant spurts of insight and lots
of carping and rambling about the design flaws of java.  Alas, he has
redirected the conversation back on track and so it should very likely
go back to the list.

[Note:  I've cut out the carping & rambling and promise I'll try real
hard to stay on topic!]

There are two issues we've been discussing.  First I wanted a nice
concise place to plunk down all the Kepler startup code - database
creation, working directory setup etc.  I find it rather disconcerting
that File.mkdir() is called in a large number of locations in order to
set up the .kepler hierarchy.  Also, I think as we move to leveraging
the database more, we should consolidate all the ddl code into a single
location (config.xml actually).  Towards that end, I asked Christopher
how best to set this up.  Right now, our best entry point is to slip
some extra calls into KSWLibraryBuilder which would work, but be rather
ugly.

The second issue we had been talking about is a way to indicate to the
VergilApplication that Kepler has failed to perform application startup
and it under no circumstances can continue.  Some examples of this
currently are:  Failure to create directory structure, Failure to access
database (two instances of Kepler), and probably some others.  There are
only a handful of these, but the current functionality is the
MessageHandler presents the little "stack trace?" window then allows the
application to appear to start up.  This is probably not expected.  I
would like to see something which presents the problem to the user (in a
window very likely) then offers only one option to 'abort'.

Christopher Brooks wrote:

>>From: Kevin Ruland <kruland at ku.edu>
>>To: Christopher Brooks <cxh at eecs.berkeley.edu>
>>Subject: Re: Abort/Retry/Error Stacktrace window
>>Date: Sun, 18 Dec 2005 12:11:39 -0600
>>    
>>
>>But back to option #3.  Maybe a special message handler during
>>application startup is a good idea.
>>    
>>
>
>Yep, see my other message.  Let me chew on this.
>
>  
>
>>Another question for you.  Kepler has a bunch of things it needs to do
>>during startup.  One one of which is the library builder stuff.  Others
>>are, create working directories, initialize (perhaps create) a database,
>>etc.  Where is the best place to put this kind of code?  I was thinking
>>about just putting it in Library Builder but there might be something
>>more appropriate.
>>    
>>
>
>Ok, I just looked at how kepler starts up.
>It runs ptolemy.vergil.VergilApplication, which invokes the 
>kepler configuration which loads
>kepler/configs/ptolemy/configs/kepler/configuration.xml
>which loads
>kepler/configs/ptolemy/configs/kepler/basicKeplerLibrary.xml
>
>basicKeplerLibrary.xml sets the _alternateLibraryBuilder attribute
>to org.kepler.moml.KSWLibraryBuilder.
>
>VergilApplication uses KSWLibraryBuilder as the library
>
>(Yah, I know this is all old news to you . . .)
>
>In principle, we could put more stuff in the KSWLibraryBuilder,
>but I think perhaps we need an application initialization
>class that does stuff like creating directories etc.
>There could be an attribute for this that if present
>would name a class that would have a particular method
>invoked.  
>
>As a straw person design, we could have a
>_applicationInitializer property that would be a string
>attribute that would name a class.  At some point
>in the start up, we would call the initialize() method
>of that class.
>
>I'm not sure where though.
>Possibly in
>ptolemy.vergil.VergilApplication._createDefaultConfiguration()
>
>An open question:
>Should we always do the Ptolemy specific initialization
>in _createDefaultConfiguration() such as reading in
>the vergilUserLibrary.xml file?  I say yes, though
>we could skip it by having that code in a separate
>method that was called by the initialize() method.
>
>  
>
I don't really have the experience to comment on this directly.

One thing did occur to me, we might be able to isolate all our "kepler
is catestropically dorked" exceptions into this startup class.  Would
isolating these to a specific part of application startup ease the
stress of having a pleasant and meaningful abort mechanism?


>An alternative to having the configuration set the
>initialization() class would be to pass in a property.
>The downside is that this makes the command line that
>much worse, which is bad for Eclipse users who are not
>using an ant call.  I think we should have some
>meaningful way of invoking Kepler by invoking a class
>without a lot of arguments.
>
>So, I think it should be in the configuration.
>
>  
>
I agree, it should be in the configuration.  Command line arguments are
fragile.

>If we are going to add this, we should probably open up
>the discussion to the group, feel free to respond and cc
>kepler-dev.
>
>  
>
Right-o!