Re: common/endorsed classLoader
Costin Manolache wrote: To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what endorsed really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Xerces would certainly load. Do you really need Xerces' JAXP rather than that in 1.4? -- Jess Holle
Re: common/endorsed classLoader
Jess Holle wrote: Costin Manolache wrote: To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what endorsed really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Xerces would certainly load. Do you really need Xerces' JAXP rather than that in 1.4? Yes, because in 1.4, Crimson is used and doesn't support XML schema. That's the only good reason we have to use Xerces when validating a web.xml. Note thatn in 1.5, Xerces packages have been renamed to com.sun.org.apache.xerces.*, which will resolve a lot of problem (ex: you should be able to bundle any xerces version in your war). I didn't test it yet -- Jeanfrancois -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed classLoader
Jeanfrancois Arcand wrote: Jess Holle wrote: Costin Manolache wrote: To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what endorsed really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Xerces would certainly load. Do you really need Xerces' JAXP rather than that in 1.4? Yes, because in 1.4, Crimson is used and doesn't support XML schema. That's the only good reason we have to use Xerces when validating a web.xml. Note thatn in 1.5, Xerces packages have been renamed to com.sun.org.apache.xerces.*, which will resolve a lot of problem (ex: you should be able to bundle any xerces version in your war). I didn't test it yet Xerces does not have to be endorsed or even be *the* endorsed JAXP XML implementation to be used for purposes like validating XML schema. One can simply directly use the given JAXP factory class -- or better yet use a loader that first tries for the 1.5 repackaged JAXP factory and then reverts to the standard Xerces class naming or some such. If this is not feasible (e.g. if the digester, etc, code involved simply grabs the currently defined JAXP implementation), one could always just have a given classloader force Xerces to be the JAXP implementation for everything within it (by redirecting request for the given meta-inf/services entries to define Xerces as the XML implementation). Such a classloader could also have the smarts not to do this in Java 1.5 Now if the 1.5 JAXP interfaces themselves render the current Xerces inoperable that is a bigger issue -- and one which I would have to chalk up as a serious design flaw in JAXP, i.e. one should not grow interfaces in such a way as to break all existing implementations -- rather one should add a sub-interface and provide APIs to request the sub-interface, etc. I sincerely hope Sun has not mis-stepped in such a major way with something as central as JAXP... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed classLoader
Bill Barker wrote: Are endorsed jars getting loaded somewhere else other than Bootstrap? Using the default startup scripts, they are loaded into the System CL (the only way a delegating CL can find them :). You mean -Djava.endorsed.dirs in catalina scripts, correct? Yup. BTW, why do they need to be loaded into the System CL in the scripts on top of commonLoader in Bootstrap using common.loader property in org/apache/catalina/startup/catalina.properties? CLFactory sets delegate=true on the StandardCL instances, so they are delegating loaders (This is in 5.0.x; in 5.5 StandardCL is pretty much just a URLCL, which delegates). As a result, they will always find the xml classes in the System CL (for JVM = 1.4). Thus if you want to change your xml classes from the JVM default, that's where you have to have them. It doesn't really matter if they are in the common.loader property or not (except, of course, for JVM 1.4 :). To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what endorsed really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed classLoader
Are endorsed jars getting loaded somewhere else other than Bootstrap? Using the default startup scripts, they are loaded into the System CL (the only way a delegating CL can find them :). You mean -Djava.endorsed.dirs in catalina scripts, correct? BTW, why do they need to be loaded into the System CL in the scripts on top of commonLoader in Bootstrap using common.loader property in org/apache/catalina/startup/catalina.properties? Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed classLoader
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, August 18, 2004 6:01 PM Subject: Re: common/endorsed classLoader Are endorsed jars getting loaded somewhere else other than Bootstrap? Using the default startup scripts, they are loaded into the System CL (the only way a delegating CL can find them :). You mean -Djava.endorsed.dirs in catalina scripts, correct? Yup. BTW, why do they need to be loaded into the System CL in the scripts on top of commonLoader in Bootstrap using common.loader property in org/apache/catalina/startup/catalina.properties? CLFactory sets delegate=true on the StandardCL instances, so they are delegating loaders (This is in 5.0.x; in 5.5 StandardCL is pretty much just a URLCL, which delegates). As a result, they will always find the xml classes in the System CL (for JVM = 1.4). Thus if you want to change your xml classes from the JVM default, that's where you have to have them. It doesn't really matter if they are in the common.loader property or not (except, of course, for JVM 1.4 :). Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed classLoader
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 17, 2004 12:57 PM Subject: common/endorsed classLoader I wrote up some code in Bootstrap/ClassLoaderFactory to not load xml api jars in common/endorsed if JDK 1.5 is used. I see that the jars don't get loaded when I check the StandardClassLoader but still the jars conflict somehow resulting an error when used JDK1.5 unless endorsed directory is physically removed. Are endorsed jars getting loaded somewhere else other than Bootstrap? Using the default startup scripts, they are loaded into the System CL (the only way a delegating CL can find them :). Of course, TC 5.5 no longer copies Xerces to endorsed by default. Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
