Re: RE: SISC and JDK1.5?

Norman Gray <[email protected]>
Newsgroups gmane.comp.java.sisc.user
Message-ID <[email protected]>
Scott,

On 2006 Apr 11 , at 22.02, Scott G. Miller wrote:

> The heap jar, while more easily
> resolvable, isn't randomly accessable, so it must be fully loaded into
> memory at a cost in time and space.  Thats why its not in a jar by
> default.

My mistake.  I'd managed to convince myself that the sisc-heap.jar  
was new, which of course is not the case.

Omitting boring details, the reason I was looking at this was that  
the defaults-for-everything Context.execute() interface doesn't work  
quite so neatly as it might within Tomcat, where, as you imply, the  
location of the heap file isn't easily resolvable within findHeap().

To get round this requires locating the heap resource by some  
external means, then

     AppContext ctx  = new AppContext();
     ctx.addHeap(AppContext.openHeap(<heaplocation>));
     Context.setDefaultAppContext(ctx);

...which turns into a block of rather messy code once you catch all  
the possible errors, spoiling the simplicity of the Context.execute()  
interface.  Is there scope, instead, for giving AppContext a heap- 
finder function, which will substitute for findHeap() when necessary,  
thus letting SISC handle the possible errors.  For example:

     final URL heapLocation =  <whatever>;
     AppContext.setHeapFinder(new HeapFinder() {
         public URL findHeap() {
              return heapLocation;
         });
     ....
     Context.execute(...);

Obviously this findHeap() method could be more sophisticated than  
this if necessary. A simpler possibility is to add a simple static  
AppContext.setDefaultHeapLocation(URL) method, but there might be  
circumstances where the more flexible mechanism might be necessary,  
for example if there were some need to find the heap dynamically or  
conditionally.

I could draft such an implementation if you thought this reasonable.

All the best,

Norman


-- 
------------------------------------------------------------------------ 
----
Norman Gray  /  http://nxg.me.uk
eurovotech.org  /  University of Leicester, UK





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.