Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
As described above, you're trying to use an illegal URL, which goes above the top of the webapp's namespace. You'll need to use absolute "file:" or "http:" type URLs, or provide your own EntityResolver that does whatever you want it to do. 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/. Ok, it seems to works for external entities inside the webapp, I wonder what was damaged in my previous tests ? BTW, I think I could use the multiples configuration offered by TC 5 : $CATALINA_HOME/conf/[enginename]/[hostname]/ directory Did the server.xml could use external entities using the relative tweak and if so what the currentDir at server.xml parsing time ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
Jean-Francois Arcand a écrit :
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 :
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).
Nope, I'm using a standard TC 5.0.12 from inside my Eclipse IDE.
I double check another time today...
BTW, my webapp is not in c:/jakarta-tomcat-5.0.12/webapps but in
c:\eclipse\workspace\customer\webapp.
So in server.xml I've got :
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
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 :
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.
Henri,
I have great success using Digester inside a webapp and referencing
entities like this with relative references. If you still find you need
to do this, then something is either configured wrong, or the way that
Tomcat uses Digester has changed recently.
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 :
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).
XML parser resolution of entity references has ***nothing*** to do with
appBase or docBase. It has ***everything*** to do with making sure that
you specify a correct URL to the parser. You will find that the correct
URL for a web.xml file inside a webapp is (for Tomcat) something like
"jndi://localhost/myapp/WEB-INF/web.xml", so trying to use ".." type
references to go above the context's document root directory
("../../../etc/foo.xml") is not going to work, for the same reason that
the following operations on a Unix filesystem will fail:
cd /var
cat ../../etc/hosts
because you're trying to reference "above" the top of the filesystem.
Absolute "file:" URLs, as you've discovered, are the way to deal with
this issue.
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.
As described above, you're trying to use an illegal URL, which goes
above the top of the webapp's namespace. You'll need to use absolute
"file:" or "http:" type URLs, or provide your own EntityResolver that
does whatever you want it to do.
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/.
Craig (author of Digester, by the way :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
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 :
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 :
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]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
Bill Barker a écrit : - Original Message - From: "Henri Gomez" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, October 14, 2003 12:42 AM Subject: Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ? Bill Barker a écrit : You will probably get more traction by posting to commons-dev. While tomcat-dev still has a couple of commons committers (and, no, I'm not one of them) that hang out here, its not like the old days :(. Sure but Remy has written the Digester so it must still be commiter :-) Off of the top of my head, the following are both Tomcat committers and Commons committers: Remy,Costin,Craig(since, while announced as non-active, I assume that he hasn't removed himself),Mladin,Yoav I send a mail to the latest Digester commiter (rdonkin) and explained the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
- Original Message - From: "Henri Gomez" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, October 14, 2003 12:42 AM Subject: Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ? > Bill Barker a écrit : > > > You will probably get more traction by posting to commons-dev. While > > tomcat-dev still has a couple of commons committers (and, no, I'm not one of > > them) that hang out here, its not like the old days :(. > > Sure but Remy has written the Digester so it must still be commiter :-) Off of the top of my head, the following are both Tomcat committers and Commons committers: Remy,Costin,Craig(since, while announced as non-active, I assume that he hasn't removed himself),Mladin,Yoav > > BTW, I take a look at XmlMapper (the Digester ancestor) and it didn't > have problems with SYSTEM only entities > > > - > 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: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
Bill Barker a écrit : You will probably get more traction by posting to commons-dev. While tomcat-dev still has a couple of commons committers (and, no, I'm not one of them) that hang out here, its not like the old days :(. Sure but Remy has written the Digester so it must still be commiter :-) BTW, I take a look at XmlMapper (the Digester ancestor) and it didn't have problems with SYSTEM only entities - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
You will probably get more traction by posting to commons-dev. While
tomcat-dev still has a couple of commons committers (and, no, I'm not one of
them) that hang out here, its not like the old days :(.
- Original Message -
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 14, 2003 12:29 AM
Subject: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
> I traced TC 5.0 and Digester and suspect what could be the problem
> with external entities when only SYTEM is defined ie :
>
>
>
>
>
>
> 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.
>
>
>
> 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 :
>
>
>
>
> 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/.
>
>
>
>
>
> -
> 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]
Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
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.
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 :
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/.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
