Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
To see how "standard" and "legal" this usage is, you can try enabling the security manager (the only way to control writing to system properties - which are always JVM wide, so since Tomcat uses JAXP, Tomcat cannot avoid being affected to some extent when a webapp changes the parser factory - is to use the security manager) :) The other problem is that this by defeinition won't behave the same in different VMs (1.4, and same if you have a 5.0 VM with the compatibility pack for TC 5.5). Not allowing the application to modify this system property is not an option for me. You can send me a WAR to test however, I would be interested to look at this alleged difference in behavior. I've filled a bug report to which I attached a simple web app for reproducing the issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=41759 Etienne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
On 3/4/07, Etienne Giraudy <[EMAIL PROTECTED]> wrote: I guess that the point that is questionnable here is the way the API is designed: modifying the system property 'legal' and, AFAIK, it is the only way to choose the parser implementation we want to use (http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParser.html). From that point of view, shouldn't Tomcat protect itself against bad-designed standard APIs usage? To see how "standard" and "legal" this usage is, you can try enabling the security manager (the only way to control writing to system properties - which are always JVM wide, so since Tomcat uses JAXP, Tomcat cannot avoid being affected to some extent when a webapp changes the parser factory - is to use the security manager) :) The other problem is that this by defeinition won't behave the same in different VMs (1.4, and same if you have a 5.0 VM with the compatibility pack for TC 5.5). You can send me a WAR to test however, I would be interested to look at this alleged difference in behavior. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
On 3/3/07, Etienne Giraudy <[EMAIL PROTECTED]> wrote: Shall this be considered as a regression as in that case tomcat configuration is somehow altered by a web app? (in that case I'll fill a bug in bugzilla)) I don't think there can be a change of behavior in this sort of thing between TC 5.5 and 6.0. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
On 3/3/07, Caldarale, Charles R <[EMAIL PROTECTED]> wrote: > From: Etienne Giraudy [mailto:[EMAIL PROTECTED] > Subject: Migration from 5.5.20 to 6.0.10: parser issue on > application deployment > > One of the web app running on that server includes > xercesImpl.jar and use it through modifying the system > property javax.xml.parsers.SAXParserFactory. That behavior looks rather questionable to me. Having a webapp modify a global property that has the potential of affecting everything running in that JVM - including other webapps and the container - seems like a very risky strategy, raising serious compatibility and operability issues. The fact that it happened to work in one version of one container doesn't imply that it's an appropriate thing to do. I guess that the point that is questionnable here is the way the API is designed: modifying the system property 'legal' and, AFAIK, it is the only way to choose the parser implementation we want to use (http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParser.html). From that point of view, shouldn't Tomcat protect itself against bad-designed standard APIs usage? Etienne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
> From: Etienne Giraudy [mailto:[EMAIL PROTECTED] > Subject: Migration from 5.5.20 to 6.0.10: parser issue on > application deployment > > One of the web app running on that server includes > xercesImpl.jar and use it through modifying the system > property javax.xml.parsers.SAXParserFactory. That behavior looks rather questionable to me. Having a webapp modify a global property that has the potential of affecting everything running in that JVM - including other webapps and the container - seems like a very risky strategy, raising serious compatibility and operability issues. The fact that it happened to work in one version of one container doesn't imply that it's an appropriate thing to do. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
