You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <hg...@apache.org> on 2003/10/09 12:08:29 UTC
Important requirement : Re: [next] What's next ?
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-name>Servlet 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.
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Remy Maucherat <re...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
> 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
<Context ...>
<Parameter name="companyName" value="My Company, Incorporated"
override="false"/>
</Context>
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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.
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 :
>
> <!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).
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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 :
>>
>>
>> <!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).
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 :
<Context path="/myapp" docBase="c:\eclipse\workspace\customer\webapp"
debug="99" >
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
Posted by Jean-Francois Arcand <jf...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
Bill Barker a écrit :
> ----- Original Message -----
> From: "Henri Gomez" <hg...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Henri Gomez" <hg...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
Posted by Bill Barker <wb...@wilshire.com>.
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" <hg...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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 :
>
>
> <!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.
>
>
>
> 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/.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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.
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/.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
>> 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Jean-Francois Arcand <jf...@apache.org>.
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_part2 SYSTEM "app_part2.xml">
>>>> <!ENTITY ap_part3 SYSTEM "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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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_part2 SYSTEM "app_part2.xml">
>>> <!ENTITY ap_part3 SYSTEM "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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Remy Maucherat <re...@apache.org>.
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_part2 SYSTEM "app_part2.xml">
>> <!ENTITY ap_part3 SYSTEM "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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Glenn Nielsen <gl...@mail.more.net>.
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_part2 SYSTEM "app_part2.xml">
> <!ENTITY ap_part3 SYSTEM "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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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_part2 SYSTEM "app_part2.xml">
<!ENTITY ap_part3 SYSTEM "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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Remy Maucherat <re...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Important requirement : Re: [next] What's next ?
Posted by Henri Gomez <hg...@apache.org>.
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-name>Servlet 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org