It's not supposed to, but back in the day many levels of caching were added and I honestly was never sure what was cached and what was not.
The references to lzo's are _supposed_ to always be stored as whatever.lzx, and the compiler will look for and use whatever.lzo if it exists, otherwise fall back to the .lzx file. It seems possible a .lzo leaked into something that is not getting cleared out and that is why you are getting the error you see after deleteing the lzo. Note that the usual development mode is to do everything in tomcat as you prototype, but when you go to production to use the command-line compiler to make lzo's and SOLO apps. Mixing tomcat and lzos is not a well-trodden path. On 2011-11-15, at 07:02, Raju Bitter wrote: > Thanks, Tucker. I already tried that, but it doesn't help. Does the > compiler store any information on classes/class files from previous > compilation cycles? > > On Tue, Nov 15, 2011 at 2:46 PM, P T Withington <[email protected]> wrote: >> Probably some bad caching somewhere in tomcat. >> >> There is a query arg you can add to clear the caches. I think it is >> something like ?clearcache=true, but don't quote me on that. >> >> On 2011-11-15, at 02:40, Raju Bitter wrote: >> >>> When I generate an LZO for an app - using "lzc -c >>> --runtime=swf10,dhtml library.lzx" - and then delete the LZO, the app >>> won't compile any more, complaining that the classes included by >>> library.lzx are undefined, e.g. >>> >>> Compilation Errors >>> ../binary-libs/main-lzotest.lzx:11:55: Unknown tag <myclass> >>> >>> After restarting Tomcat, the compile works again as expected. Has >>> anyone else noticed this behavior? >> >>
