Peter, >Kool. So my wish of running Phoenix on a tank is looking better ;) > >I know of a few areas in which Phoenix memory / resource usage would need to >be improved before it could run comfortably in such an environment. In >particular the following could be big issues. >* threads >* classloader >* xml processing >* logging > >ClassLoader is probably the least of the worries but each of the others will >need triming. Tell us how first run goes and which parts cause the most pain >for you ;) > Maybe trimming is not the right term. Perhaps multiple implementations is the right way of curing the issue. If logging can be configured to do
a) expanding log file(s) as at present b) rolling log file(s). c) logging to null: d) logging mapped to System.out I'm not sure what is wrong with threads, classloading and xml processing..... Cornerstone now presents DOM & SAX parser factories to host apps through component manager. Is it that we could be having needless multiple instances in one phoenix VM? Or are you thinking just about general resource use? As for the breakthough moment with the iPAQ, it is some time away as I've no way at present of getting file to it *after* SavaJe has been installed. The only supported ways need extra hardware, PPP over serial cable not implemented yet. An alternate stategy could be to replace the jar file that is being burned in to eeprom with one of our making with Linux's mkcramfs tool. Regards, - Paul H -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
