Re: Important requirement : Re: [next] What's next ?
Craig R. McClanahan a écrit : Henri Gomez wrote: CF w3c.org ... relative URIs are relative to the location of the resource within which the entity declaration occurs. http://www.w3.org/TR/REC-xml#sec-external-ent As long as Tomcat uses the Digester.parse() entry point that takes an InputSource, and properly specifies the system URL of the web.xml resource, the parser will be able to resolve relative URLs like this correctly. If Tomcat is doing that (it did in 4.1, haven't checked 5.0) and relative resolution doesn't work, then its an XML parser bug. Well just take a look at my post and you'll see there may be a problem in Digester. BTW, I'm using latest xerces but it was the case with previous release - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez a écrit : Remy Maucherat a écrit : Henri Gomez wrote: Henri Gomez a écrit : Note: I really love Xerces' error messages. Great it seems to works with : ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; [ !ENTITY % appconf SYSTEM file:../etc/webapp/appconf.xml %appconf; ] web-app display-nameServlet 2.4 Examples/display-name description Servlet 2.4 Examples. /description . So should I assume that the current directory is webapps ? Most stuff during webapp deployment is relative to the host appBase, so I'm not surprised. I don't really know how this particular path is resolved, though. Could it be possible to add an attribute in Context to make Tomcat use the docBase location instead of appBase for a particular context ? I made extensive tests with TC 5.0.12 and my currents applications, where tomcat could live somewhere on the system (following Linux FHS recommandation), and the webapps elsewhere. With such very current settings, I couldn't determine from the webapp area where is the 'current workdir' and my relative links are broken !!! Also it will help ease translation from TC 3.3.x for 5.0.x since the current workdir for TC 3.3.x while parsing web.xml is the WEB-INF where the web.xml is located. Thanks to take a look at this or at least told me if I could works on it to add such feature. No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). I don't care, sorry. The question to ask: is it the right thing to do or not. - Hosts are based on separate directories - Hosts should be independent Based on that, the choice of using appBase is the right one. Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. Webapps, and even more, hosts, should be independent. Anything else seems a hack which may or may not work. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). I don't care, sorry. The question to ask: is it the right thing to do or not. - Hosts are based on separate directories - Hosts should be independent Sorry, but I care about TC 3.2/3.3 users base, since I'm one of them. I've got not less than 50 clients using TC 3.3.1a and they use the described layout. Also sometimes ago we speak about security manager and stuff which shouldn't be get OUTSIDE the web application. When you have web.xml and its external entities in the same war, why couldn't we get them directly ? A webapp in a WAR doesn't have to know about specific appBase, or I missed a whole episode ? Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. Webapps, and even more, hosts, should be independent. Anything else seems a hack which may or may not work. Sure and since a webapp should be independant, the external entities SHOULD be searched by default in the WAR or exploded WAR... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Glenn Nielsen wrote: Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? I think I have misunderstood stuff. It is ok to base resolution on the webapp docBase (but not on the server home directory). As Glenn says, it seems more logical to base it on the location of web.xml. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Remy Maucherat a écrit : Glenn Nielsen wrote: Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? I think I have misunderstood stuff. It is ok to base resolution on the webapp docBase (but not on the server home directory). As Glenn says, it seems more logical to base it on the location of web.xml. Allelouia, we agree ;) The base should be the location of web.xml (la prochaine fois j'envoie un mail en français :---) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
CF w3c.org ... relative URIs are relative to the location of the resource within which the entity declaration occurs. http://www.w3.org/TR/REC-xml#sec-external-ent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: Remy Maucherat a écrit : Glenn Nielsen wrote: Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? I think I have misunderstood stuff. It is ok to base resolution on the webapp docBase (but not on the server home directory). As Glenn says, it seems more logical to base it on the location of web.xml. Allelouia, we agree ;) The base should be the location of web.xml (la prochaine fois j'envoie un mail en français :---) +1 ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
The base should be the location of web.xml (la prochaine fois j'envoie un mail en français :---) +1 ;-) Time for a Tomcat Dev French Forum, to fix these language problems ? ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: CF w3c.org ... relative URIs are relative to the location of the resource within which the entity declaration occurs. http://www.w3.org/TR/REC-xml#sec-external-ent As long as Tomcat uses the Digester.parse() entry point that takes an InputSource, and properly specifies the system URL of the web.xml resource, the parser will be able to resolve relative URLs like this correctly. If Tomcat is doing that (it did in 4.1, haven't checked 5.0) and relative resolution doesn't work, then its an XML parser bug. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
