Henri Gomez wrote:
I traced TC 5.0 and Digester and suspect what could be the problem with external entities when only SYTEM is defined ie :
<!ENTITY appset1 SYSTEM "appset1.xml"> <!ENTITY appset2 SYSTEM "appset2.xml">
In Digester.java, at least in the 1.5 release, resolveEntity return null if publicId is null even if systemId is set.
To make it works, I just replaced :
--
if (entityURL == null){ return (null);
by ---
if (entityURL == null){ if (systemId == null) return (null); else entityURL = systemId; }
FYI, in resolveEntity we got as parms for previous app1&app2 entities declaration:
systemid="jndi:/localhost/myapp/WEB-INF/appset1.xml" and publicid=null
systemid="jndi:/localhost/myapp/WEB-INF/appset2.xml" and publicid=null
This hack will solve the resolution of entities presents in WEB-INF.
That's strange since in Tomcat 5, the resolver is under o.a.c.u.SchemaResolver. Have you change something there? You should customize that class instead of the Digester one (will be easier and doesn't require commons-dev folks).
Now for entities located outside webapp / WEB-INF.
I know what the spec say about entities outside WAR but there is many case where you should serve the SAME application for many customers, and where specific settings for each customer MUST exist outside WAR.
Let see my case :
if the entity is defined like this :
<!ENTITY appset1 SYSTEM "file:../etc/appset1.xml"> <!ENTITY appset2 SYSTEM "file:/var/www/customer1/etc/appset2.xml">
resolveEntity got systemId="file:../etc/appset1.xml" and systemId="file:/var/www/customer1/etc/appset2.xml"
So if you have to specify a resource somewhere on your system, outside the webapp you should :
1) Know what the appBase and use .. trick to get it (relative). 2) Give an absolute reference on the file system, which is bad when you want to use the .war for many customers.
Let consider the following layout for an ISP/ASP provider wich use the same application for many clients (running their own TC 5).
/var/www/customer1/etc/appset1.xml /var/www/customer1/etc/appset2.xml /var/www/customer1/var/tomcat5/... /var/www/customer1/var/tomcat5/webapps/themainapp.war
/var/www/customer2/etc/appset1.xml /var/www/customer2/etc/appset2.xml /var/www/customer2/var/tomcat5/... /var/www/customer2/var/tomcat5/webapps/themainapp.war
You could use the file:.. trick to go from /var/www/customerx/var/tomcat5/, which is the appBase to /var/www/customerx/etc, where the customer specific settings are located.
Now consider another layout for an ISP/ASP provider wich use the same application for many clients but using a shared TC5.
/var/www/customer1/etc/appset1.xml /var/www/customer1/etc/appset2.xml /var/www/customer1/webapps/themainapp1.war /var/www/customer1/webapps/themainapp1/WEB-INF/...
/var/www/customer2/etc/appset1.xml /var/www/customer2/etc/appset2.xml /var/www/customer2/webapps/themainapp2.war /var/www/customer2/webapps/themainapp1/WEB-INF/...
themainapp1.war and themainapp2.war are copy of or symlink to the generic themainapp.war and are decompressed at startup time.
TC 5 is in shared mode, so it live outside customer layout :
/var/tomcat5/...
You couldn't use anymore the file:.. trick to go from /var/tomcat5/, which is the appBase to /var/www/customerx/etc, where the customer specific settings are located.
The only way to developpers and admins to have it works in both case is to set the current directory when web.xml is parsed to WEB-INF/.
So what about having something like CATALINA_HOME/common/xml where you can put your shared file. The change the SchemaResolver to look under that folder if it isn't able to resolve the publid/system id? I may have missed something.....
-- Jeanfrancois
--------------------------------------------------------------------- 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]
