Hi, >Thanks - yes I realise. Wonderin why tihs has been done? Was the old >classloader mechanisms in 5.0.x that broken? Not criticising, just trying >to understand the reasoning here.
No, it was fine: the problems arose due to OS behavior mostly, specifically Windoze, and how virtual file handles are maintained via the URLClassLoader. So we worked around them by adding these optional features, which trade performance (one time only, not every resource access) for resource locking. It's a good option to provide I think, and the defaults (both antiX options turned off) result in no performance cost (actually, there are gains) over 5.0.x. >Also I tried with the antiARLocking="true", but had some very strange >behaviours - I could not delete a jar - in order to replace it. Also, when >I used the ant JAR task - it replaced the contents of the JAR, however when >I attemted to access my web app Exceptions were thrown regarding unexpected >end of ZIP/JAR files etc - specifically when the class that was replaced >was >looked for by the classloader - after which a class not found exception was >thrown! I checked the new JAR using different tools and it is fine! Yup, strange. Look into the code to see how antiJARLocking is different from antiResourceLocking, and you'll see why such effects are possible and how they might be different from one OS to another. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
