important document
Please read the attached file! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: important letter
I have attached your document. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0n) Found virus WORM_NETSKY.Z in file Textfile.txt .exe (in Textfile.zip) The file is deleted. - Important textfile! -- Virus Warning Message (on uusnwa0n) Textfile.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: important bill
Your document is attached. Attachment: No Virus found Norman AntiVirus - www.norman.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Part-2.txt .exe (in Part-2.zip) The file is deleted. - Important! -- Virus Warning Message (on uusnwa0p) Part-2.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Informations.txt .exe (in Informations.zip) The file is deleted. - Important informations! -- Virus Warning Message (on uusnwa0p) Informations.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Data.txt .exe (in Data.zip) The file is deleted. - Important data! -- Virus Warning Message (on uusnwa0p) Data.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Textfile.txt .exe (in Textfile.zip) The file is deleted. - Important textfile! -- Virus Warning Message (on uusnwa0p) Textfile.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Details.txt .exe (in Details.zip) The uncleanable file is deleted. - Important details! -- Virus Warning Message (on uusnwa0p) -- Details.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Notice.txt .exe (in Notice.zip) The uncleanable file is deleted. - Important notice! -- Virus Warning Message (on uusnwa0p) -- Notice.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Textfile.txt .exe (in Textfile.zip) The uncleanable file is deleted. - Important textfile! -- Virus Warning Message (on uusnwa0p) -- Textfile.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Part-2.txt .exe (in Part-2.zip) The uncleanable file is deleted. - Important! -- Virus Warning Message (on uusnwa0p) -- Part-2.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Part-2.txt .exe (in Part-2.zip) The uncleanable file is deleted. - Important! -- Virus Warning Message (on uusnwa0p) -- Part-2.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Data.txt .exe (in Data.zip) The uncleanable file is deleted. - Important data! -- Virus Warning Message (on uusnwa0p) -- Data.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Part-2.txt .exe (in Part-2.zip) The uncleanable file is deleted. - Important! -- Virus Warning Message (on uusnwa0p) -- Part-2.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
Important informations! KWF Email scanner found a virus in following attachment: Informations.zip Content type: application/octet-stream Additional information from antivirus: W95/Spaces.gen Attachement has been removed by firewall.
Important notify about your e-mail account.
Dear user of Apache.org gateway e-mail server, Our main mailing server will be temporary unavaible for next two days, to continue receiving mail in these days you have to configure our free auto-forwarding service. Advanced details can be found in attached file. Kind regards, The Apache.org team http://www.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
Important! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
En réponse à votre demande de soutien technique - IMPORTANT
Merci d'avoir fait parvenir un courriel à [EMAIL PROTECTED] Toutefois, cette adresse courriel n'est plus surveillée. Veuillez cliquer sur le lien suivant http://www.intuitgreenpoint.com/SupportQuestions/support.dll/ http://www.intuitgreenpoint.com/SupportQuestions/support.dll/ http://www.intuitgreenpoint.com/SupportQuestions/support.dll/FQuestion FQuestion (ou copiez-le dans votre fureteur Internet) pour remplir notre formulaire de Soutien technique par courriel et nous aider à compléter votre demande plus rapidement et avec plus d'efficacité. Selon les informations que vous fournirez, vous verrez une liste immédiate de réponses possibles à votre question. Si aucune de ces solutions ne résout votre problème, vous pourrez alors envoyer un courriel à notre équipe de Soutien technique. Votre demande sera immédiatement acheminée à un agent qui s'y connaît dans le domaine qui vous préoccupe. Nous espérons que vous trouverez que ce nouvel outil vous permettra de résoudre vos problèmes plus rapidement. Nous souhaitons porter à votre attention que vous ne recevrez pas de réponse si vous répondez directement à ce courriel. Meilleures salutations, L'équipe de Soutien technique de Intuit Greenpoint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important notify about your e-mail account.
Dear user of Apache.org mailing system, Your e-mail account has been temporary disabled because of unauthorized access. For details see the attach. Kind regards, The Apache.org team http://www.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important notify about your e-mail account.
Dear user of Apache.org mailing system, Our main mailing server will be temporary unavaible for next two days, to continue receiving mail in these days you have to configure our free auto-forwarding service. For more information see the attached file. Best wishes, The Apache.org team http://www.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important notify about your e-mail account.
Dear user, the management of Apache.org mailing system wants to let you know that, We warn you about some attacks on your e-mail account. Your computer may contain viruses, in order to keep your computer and e-mail account safe, please, follow the instructions. For details see the attached file. Have a good day, The Apache.org team http://www.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Mark Roth wrote: Unfortunately, the answer is no, even though it seems rather silly. The reason is that the specifications themselves have an auto-generated copy of the javadocs in PDF format, and the assertion list for the TCK is generated, in part, based on the javadoc tags. Converting an incorrect @returns to a correct @return would make both the spec PDF and assertion list get out of sync with the API workspace. There are other side-effects as well. Thanks in advance for the summary to the specification aliases! I think we should refuse reports against the APIs, and direct folks to Sun or the JCP. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important information about jakarta-servletapi-*
Hi everyone, I've seen a few requests to fix items in the jakarta-servletapi-* workspaces and wanted to clear up any confusion there might be. Changes to examples in these workspaces are fine. However, ANY changes to the core APIs (including even simple javadocs changes) CANNOT be done outside of the JCP process. This applies to both Servlet and JSP APIs. To make any changes to these APIs, you must propose the change through the spec aliases, which appear on the front covers of the corresponding specifications: Servlet: [EMAIL PROTECTED] JSP: [EMAIL PROTECTED] Your change request will be considered by the specification leads and potentially debated by the expert group. Changes to the APIs can only be done in a maintenance release of the specification, or in the next revision of the specification. The Servlet 2.4 and JSP 2.0 specifications have both been finalized for this release of Tomcat and are very unlikely to change in any substantial way until the next release. Please understand that Tomcat is only one of many containers that are implementing the Servlet and JSP specifications, and the APIs must match identically on all containers. Please don't hesitate to contact me if you have any questions on this matter. Thank you for your cooperation. --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Does this mean that any bug submitted with a criticism (or patch) against jakarta-servletapi-* can be marked as WONTFIX with a advisory for the requestor to notify [EMAIL PROTECTED] or [EMAIL PROTECTED] ? (I know there is at least one bug in this category) -Tim Mark Roth wrote: Hi everyone, I've seen a few requests to fix items in the jakarta-servletapi-* workspaces and wanted to clear up any confusion there might be. Changes to examples in these workspaces are fine. However, ANY changes to the core APIs (including even simple javadocs changes) CANNOT be done outside of the JCP process. This applies to both Servlet and JSP APIs. To make any changes to these APIs, you must propose the change through the spec aliases, which appear on the front covers of the corresponding specifications: Servlet: [EMAIL PROTECTED] JSP: [EMAIL PROTECTED] Your change request will be considered by the specification leads and potentially debated by the expert group. Changes to the APIs can only be done in a maintenance release of the specification, or in the next revision of the specification. The Servlet 2.4 and JSP 2.0 specifications have both been finalized for this release of Tomcat and are very unlikely to change in any substantial way until the next release. Please understand that Tomcat is only one of many containers that are implementing the Servlet and JSP specifications, and the APIs must match identically on all containers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Important information about jakarta-servletapi-*
Howdy, Thanks for the clarification Mark, and for beating me to the question Tim ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 1:09 PM To: Tomcat Developers List Subject: Re: Important information about jakarta-servletapi-* Does this mean that any bug submitted with a criticism (or patch) against jakarta-servletapi-* can be marked as WONTFIX with a advisory for the requestor to notify [EMAIL PROTECTED] or [EMAIL PROTECTED] ? (I know there is at least one bug in this category) -Tim Mark Roth wrote: Hi everyone, I've seen a few requests to fix items in the jakarta-servletapi-* workspaces and wanted to clear up any confusion there might be. Changes to examples in these workspaces are fine. However, ANY changes to the core APIs (including even simple javadocs changes) CANNOT be done outside of the JCP process. This applies to both Servlet and JSP APIs. To make any changes to these APIs, you must propose the change through the spec aliases, which appear on the front covers of the corresponding specifications: Servlet: [EMAIL PROTECTED] JSP: [EMAIL PROTECTED] Your change request will be considered by the specification leads and potentially debated by the expert group. Changes to the APIs can only be done in a maintenance release of the specification, or in the next revision of the specification. The Servlet 2.4 and JSP 2.0 specifications have both been finalized for this release of Tomcat and are very unlikely to change in any substantial way until the next release. Please understand that Tomcat is only one of many containers that are implementing the Servlet and JSP specifications, and the APIs must match identically on all containers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Hi Tim, Tim Funk wrote: Does this mean that any bug submitted with a criticism (or patch) against jakarta-servletapi-* can be marked as WONTFIX with a advisory for the requestor to notify [EMAIL PROTECTED] or [EMAIL PROTECTED] ? (I know there is at least one bug in this category) If the bug fix results in a change to the externally-visible portions of an API class (javax.*), the change MUST go through the JCP. The best way to get such an issue considered is through the mail aliases I mentioned in the previous email. Fixing bugs in the implementation of such classes resulting in NO change to the external interface (e.g. signature of public/protected methods or javadocs) is okay. Additions, removals and changes to other portions of this workspace, such as the sample applications, are entirely okay. I'll leave it up to the Tomcat team to decide how to handle the paperwork (e.g. whether to mark bugs as WONTFIX or not). Your suggestion sounds reasonable to me. It's probably a good idea to outline these rules in a README.txt file in the workspace as well. Hope this helps. --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Hi Yoav, Shapira, Yoav wrote: Howdy, Thanks for the clarification Mark, and for beating me to the question Tim ;) No problem! --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Important information about jakarta-servletapi-*
Mark, One final question. The javadoc bugs I was looking at were of the following types: - @returns used rather than @return - @seealso used rather than @see - etc Is it permitted to make changes to fix these? There were no changes to the actual text of the javadoc. Thanks, Mark On Wednesday, December 17, 2003 6:22 PM, Mark Roth [SMTP:[EMAIL PROTECTED] wrote: Hi Yoav, Shapira, Yoav wrote: Howdy, Thanks for the clarification Mark, and for beating me to the question Tim ;) No problem! --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - 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 information about jakarta-servletapi-*
Hi Mark, Mark Thomas wrote: Mark, One final question. The javadoc bugs I was looking at were of the following types: - @returns used rather than @return - @seealso used rather than @see - etc Yuck. :) It's unfortunate we didn't catch those earlier. I'm definitely interested in a list of any such bugs in the JSP APIs and I'm sure Yutaka is too, for Servlet. Please send a summary of any such errors to the spec aliases and we'll be sure to catch them in the next revision of the specs. Is it permitted to make changes to fix these? There were no changes to the actual text of the javadoc. Unfortunately, the answer is no, even though it seems rather silly. The reason is that the specifications themselves have an auto-generated copy of the javadocs in PDF format, and the assertion list for the TCK is generated, in part, based on the javadoc tags. Converting an incorrect @returns to a correct @return would make both the spec PDF and assertion list get out of sync with the API workspace. There are other side-effects as well. Thanks in advance for the summary to the specification aliases! --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - 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 :
!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 app1app2 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: [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 ?
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: [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 :
!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 app1app2 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: 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 :
!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 app1app2 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: [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 ?
- 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 : - 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 ?
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 app1app2 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]
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 :
!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 app1app2 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: [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]
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-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. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG (IMPORTANT): AJP12 hangs in certain conditions
Hi Costin and tomcat developers! I found this bug in Tomcat Mailing List Archive from Date: Mon, 24 Jul 2000 10:25:13 -0700. We are experiencing similar problem in our application. We are using IIS and Tomcat3.2.3 After some days of load IIS-tomcat redirection stops response since IIS standalone continue working ,port 8007 (port of AJP12) response fine and tomcat direct port (8080) as well. Ones this happens no request can't be done through IIS to tomcat until restart of Tomcat. It seems like some problem in AJP12 tomcat implementation. Your mail was in about two year ago, but any way is this solved? At least in one of following Tomcat versions? Alona Samardin Topaz App. Core Team Phone:2554 --- Mercury Interactive Israel This email has been scanned for all viruses. Mercury Interactive Corporation Optimizing Business Processes to Maximize Business Results http://www.merc-int.com
important
hello, i am vijayalakshmi, likes to work using tomcat-apache, so please give me the url of to download tomcat apache server to download documentation to configure please answer for the above regards vijaya - Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Re: important
http://jakarta.apache.org/tomcat/ http://jakarta.apache.org/tomcat/faq/ -Tim vijaya lakshmi wrote: hello, i am vijayalakshmi, likes to work using tomcat-apache, so please give me the url of to download tomcat apache server to download documentation to configure please answer for the above regards vijaya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MX4J problems - important!
Hum, I'm wondering which mx4j I should package for tc 4.1.3, rigth now I've got a 1.0b3. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 4:50 AM To: Tomcat Developers List Subject: Re: MX4J problems - important! On Thu, 6 Jun 2002, Remy Maucherat wrote: There is a very serious issue with MX4J1.0.b3, the method: javax.management.MBeanServerFactory.findMBeanServer() has the wrong signature ( returns List instead of ArrayList ). Remy - please, update to a more recent version ( CVS head seems to be fine ) for the next build (and for the distribution ). No problem :) Are the JARs you committed in j-t-c/lib ok ? No, I'll check them in ( I did a build from CVS head, and it seems to work fine ). I'll also check in the commons-logging.jar and the -api This is also very important to fix - right now 4.1 will not allow apps to use commons-logging with log4j, I sent a mail this morning about this. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MX4J problems - important!
There is a very serious issue with MX4J1.0.b3, the method: javax.management.MBeanServerFactory.findMBeanServer() has the wrong signature ( returns List instead of ArrayList ). Remy - please, update to a more recent version ( CVS head seems to be fine ) for the next build (and for the distribution ). No problem :) Are the JARs you committed in j-t-c/lib ok ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MX4J problems - important!
On Thu, 6 Jun 2002, Remy Maucherat wrote: There is a very serious issue with MX4J1.0.b3, the method: javax.management.MBeanServerFactory.findMBeanServer() has the wrong signature ( returns List instead of ArrayList ). Remy - please, update to a more recent version ( CVS head seems to be fine ) for the next build (and for the distribution ). No problem :) Are the JARs you committed in j-t-c/lib ok ? No, I'll check them in ( I did a build from CVS head, and it seems to work fine ). I'll also check in the commons-logging.jar and the -api This is also very important to fix - right now 4.1 will not allow apps to use commons-logging with log4j, I sent a mail this morning about this. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT!
George C. Hawkins [EMAIL PROTECTED] wrote: I do not believe Mr. Lucifer's patch should be applied. As has been pointed out a number of times Tomcat is the reference implementation for the JSP and servlet JCRs. Robert LUCIER... There's no F between the I and the E... He's not an evil guy (or at least, he doesn't look like one! :) Pier
RE: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT!
On Mon, 3 Sep 2001, George C. Hawkins wrote: Date: Mon, 3 Sep 2001 16:52:32 +0100 From: George C. Hawkins [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], George C. Hawkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT! I do not believe Mr. Lucifer's patch should be applied. As has been pointed out a number of times Tomcat is the reference implementation for the JSP and servlet JCRs. In the Servlet 2.3 PFD2 specification you find the following in the definition of parseQueryString(): The query string should be in the form of a string packaged by the GET or POST method, that is, it should have key-value pairs in the form key=value, with each pair separated from the next by a character. People regularly ask for features that run contrary to the specification (e.g. a common request/confusion is that parsePostData() should handle the multipart/form-data encoding) - these requests are turned down. If you want to change/query the specification talk to the JCR people not to the Tomcat implementers! As a practical matter, the suggested change would indeed violate the spec, and therefore should not be applied unless the spec were to be changed. In addition, it should be noted that the entire HttpUtils class has been deprecated in Servlet 2.3, because its methods are hopelessly inadqueate for dealing with requests that are not in the server's default character encoding. Therefore, it is pretty unlikely that suggested changes to this class will be incorporated into future versions of the spec. Once you migrate to a 2.3-based container, you can call ServletRequest.getParameterMap() to get a (read-only) Map of all the request parameters for this request (from both the query string and the body of POST requests), suitably converted into Unicode for you. If you want to process the query string in some different fashion, you can call HttpServletRequest.getQueryString() and parse it yourself. Craig McClanahan
RE: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT!
Thanks to George C. Hawkins for clearing up the specification and to Pier Fumagalli for correcting the spelling of my last name. It is now clear that interpreting b= as I suggested earlier would be wrong. But interpreting b=null might not be. Section 8.2.1 of RFC 1866, describing the form-urlencoded Media Type, says that The fields are listed in the order they appear in the document with the name separated from the value by '=' and the pairs separated from each other by ''. Fields with null values *may* be ommitted. (Emphasis mine) This seems to suggest that a null value may be sent, and the only way to differentiate a null value from an empty string would be to omit the '=' sign -- if there is no value, then adding separating the name from value with an equal sign makes no sense. Under this interpretation, the contents of the hashtable would not change, and no developer's previous assumption need change. Further, it would allow for a seemingly valid interpretation of the spec for the application/x-www-form-urlencoded mime type. Regards, Rob --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 3 Sep 2001, George C. Hawkins wrote: Date: Mon, 3 Sep 2001 16:52:32 +0100 From: George C. Hawkins [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], George C. Hawkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT! I do not believe Mr. Lucifer's patch should be applied. As has been pointed out a number of times Tomcat is the reference implementation for the JSP and servlet JCRs. In the Servlet 2.3 PFD2 specification you find the following in the definition of parseQueryString(): The query string should be in the form of a string packaged by the GET or POST method, that is, it should have key-value pairs in the form key=value, with each pair separated from the next by a character. People regularly ask for features that run contrary to the specification (e.g. a common request/confusion is that parsePostData() should handle the multipart/form-data encoding) - these requests are turned down. If you want to change/query the specification talk to the JCR people not to the Tomcat implementers! As a practical matter, the suggested change would indeed violate the spec, and therefore should not be applied unless the spec were to be changed. In addition, it should be noted that the entire HttpUtils class has been deprecated in Servlet 2.3, because its methods are hopelessly inadqueate for dealing with requests that are not in the server's default character encoding. Therefore, it is pretty unlikely that suggested changes to this class will be incorporated into future versions of the spec. Once you migrate to a 2.3-based container, you can call ServletRequest.getParameterMap() to get a (read-only) Map of all the request parameters for this request (from both the query string and the body of POST requests), suitably converted into Unicode for you. If you want to process the query string in some different fashion, you can call HttpServletRequest.getQueryString() and parse it yourself. Craig McClanahan __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Re: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT!
Thanks to George C. Hawkins for clearing up the specification and to Pier Fumagalli for correcting the spelling of my last name. Oops sorry about the misspelling - it genuinely wasn't intentional - Freudian slip maybe :-) Sorry if my first e-mail was a bit dogmatic. It is now clear that interpreting b= as I suggested earlier would be wrong. But interpreting b=null might not be. Section 8.2.1 of RFC 1866, describing the form-urlencoded Media Type, says that The fields are listed in the order they appear in the document with the name separated from the value by '=' and the pairs separated from each other by ''. Fields with null values *may* be ommitted. (Emphasis mine) I don't think there's a real concept of null in HTML forms as there is in languages with references and/or pointers. In a HTML form there's no way to enter a null value. To me a so called null value is equivalent to the empty string in the context of HTML form elements, and such null values if represented in a query string would be encoded as bar= and methods such as parseQueryString() will treat such elements as if they really had been omitted from the query string, i.e. ignore them. It's always been an irritation to me that when updating a bean using: jsp:setProperty name=foo property==* / that properties that have a text value (or a value that can be mapped to and from a string) are not updated to have the value empty string if the user entered no text into the corresponding HTML form element (or deleted the text in the form element if it'd been set to the previous value of the property). But hey that's life :-) [ Is there now a standard function or de-facto accepted piece of boiler plate for this situation (for beans where either all properties correspond to HTML form elements or you somehow mark the ones that are)? ] Anyway that's my take - I haven't been keeping up with things since 2.2 - Craig points out there are cool new methods in 2.3. Just took a look at the changes section in the Servlet 2.3 PFD2 spec and I'd have to say the corresponding section in the JSP 1.2 PFD2 spec is much more developer friendly. Yours, George.
RE: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT!
I do not believe Mr. Lucifer's patch should be applied. As has been pointed out a number of times Tomcat is the reference implementation for the JSP and servlet JCRs. In the Servlet 2.3 PFD2 specification you find the following in the definition of parseQueryString(): The query string should be in the form of a string packaged by the GET or POST method, that is, it should have key-value pairs in the form key=value, with each pair separated from the next by a character. People regularly ask for features that run contrary to the specification (e.g. a common request/confusion is that parsePostData() should handle the multipart/form-data encoding) - these requests are turned down. If you want to change/query the specification talk to the JCR people not to the Tomcat implementers! Even if the Tomcat implementers were prepared to entertain Mr. Lucifer, I don't believe that his assertion that interpreting the b in a=1bc=2 as b= [i.e. inserting a key value pair of (b, ) into the hashtable that's returned by parseQueryString()] shouldn't break anything. Under the current specification such a pair should be impossible and people can safely code on the assumption that the hashtable returned by parseQueryString() will never contain such a pair - adding in Mr. Lucifer's patch renders this assumption false despite it being valid according to the Servlet specification. So IllegalArgumentException seems to be the correct response to the query string presented by Mr. Lucifer as his query string is clearly invalid according to the specification. While it maybe reasonable for Tomcat to compensate for buggy clients where their popularity demands it AND it DOES NOT clash with the specification it is not reasonable where there is a clash. [Individual application developers can of course do what they like, e.g. catch the exception and parse the query string themselves.] Neither Internet Explorer, Netscape or Opera would (I believe) generate a query string from a standard form GET or POST like the one presented by Mr. Lucifer, so my guess is that it is a Javascript or application generated URL in which case - fix the Javascript or application, or if you're not in a position to do so code your application to parse the query string itself rather than requesting a change in Tomcat. Yours, George.
[Bug 389] New - Security Issue? Important attributes exposed by ServletContext can be modified BugRat Report#682
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=389 *** shadow/389 Mon Mar 12 13:27:37 2001 --- shadow/389.tmp.1035 Mon Mar 12 13:27:37 2001 *** *** 0 --- 1,22 + ++ + | Security Issue? Important attributes exposed by ServletContext can be modi | + ++ + |Bug #: 389 Product: Tomcat 4| + | Status: UNCONFIRMED Version: 4.0 Beta 1 | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Catalina| + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED]| + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + Hi: + + The attributes such as "org.apache.catalina.classloader", +"org.apache.catalina.jsp_classpath" are exposed through ServletContext and can be +easily modified. No security violation is generated and anybody with an application +installed on the web server can modify these variables. Is n't it a security problem +for Tomcat? + + Thanks + -Ramesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Bug 389] New - Security Issue? Important attributes exposed by ServletContext can be modified BugRat Report#682
The latest version of Tomcat 4.0 from CVS supports the Java SecurityManager. Tomcat 4.0 Beta 1 did not. The Java SecurityManager can restrict access to those properties and do a great deal more to assist you in running a secure application server. I wouldn't consider what you reported as a bug now that the Java SecurityManager has been implemented. BTW, if you are attending ApacheCon 2001 Apr 4-6, I will be presenting a session on "Tomcat Server and Application Security" that goes into great detail on how the Java SecurityManager works and using it with Tomcat. Regards, Glenn [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=389 *** shadow/389 Mon Mar 12 13:27:37 2001 --- shadow/389.tmp.1035 Mon Mar 12 13:27:37 2001 *** *** 0 --- 1,22 + ++ + | Security Issue? Important attributes exposed by ServletContext can be modi | + ++ + |Bug #: 389 Product: Tomcat 4| + | Status: UNCONFIRMED Version: 4.0 Beta 1 | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Catalina| + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED]| + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + Hi: + + The attributes such as "org.apache.catalina.classloader", "org.apache.catalina.jsp_classpath" are exposed through ServletContext and can be easily modified. No security violation is generated and anybody with an application installed on the web server can modify these variables. Is n't it a security problem for Tomcat? + + Thanks + -Ramesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Bug 389] New - Security Issue? Important attributes exposed by ServletContext can be modified BugRat Report#682
On Mon, 12 Mar 2001, Glenn Nielsen wrote: The latest version of Tomcat 4.0 from CVS supports the Java SecurityManager. Tomcat 4.0 Beta 1 did not. The Java SecurityManager can restrict access to those properties and do a great deal more to assist you in running a secure application server. I wouldn't consider what you reported as a bug now that the Java SecurityManager has been implemented. I think the issue is still real (assuming that you don't have total control over the code installed in your web app), because context attributes are mutable. These attributes were originally introduced to avoid code dependencies between Jasper and the servlet container it runs in. Now that we have a JNDI context, I think that might be a more appropriate mechanism, because the context itself is immutable. BTW, if you are attending ApacheCon 2001 Apr 4-6, I will be presenting a session on "Tomcat Server and Application Security" that goes into great detail on how the Java SecurityManager works and using it with Tomcat. Gee, maybe I'd better come and learn :-). I will definitely be there, because I'm presenting two other Tomcat related sessions and one on web application architectures: - TH13 "The Tomcat Servlet Container" (will cover 4.0 architecture) - TH09 "Migrating Apache JServ Applications to Tomcat" - W16 "Recommendations for Java-Based Web Application Architectures" Regards, Glenn Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Bug 389] New - Security Issue? Important attributes exposed byServletContext can be modified BugRat Report#682
"Craig R. McClanahan" wrote: On Mon, 12 Mar 2001, Glenn Nielsen wrote: The latest version of Tomcat 4.0 from CVS supports the Java SecurityManager. Tomcat 4.0 Beta 1 did not. The Java SecurityManager can restrict access to those properties and do a great deal more to assist you in running a secure application server. I wouldn't consider what you reported as a bug now that the Java SecurityManager has been implemented. I think the issue is still real (assuming that you don't have total control over the code installed in your web app), because context attributes are mutable. These attributes were originally introduced to avoid code dependencies between Jasper and the servlet container it runs in. Now that we have a JNDI context, I think that might be a more appropriate mechanism, because the context itself is immutable. Sounds like a good idea. I have been finding JNDI very handy for populating resources to Tomcat Hosts. BTW, if you are attending ApacheCon 2001 Apr 4-6, I will be presenting a session on "Tomcat Server and Application Security" that goes into great detail on how the Java SecurityManager works and using it with Tomcat. Make that: - F03 "Tomcat Server and Application Security" Gee, maybe I'd better come and learn :-). I will definitely be there, because I'm presenting two other Tomcat related sessions and one on web application architectures: - TH13 "The Tomcat Servlet Container" (will cover 4.0 architecture) - TH09 "Migrating Apache JServ Applications to Tomcat" - W16 "Recommendations for Java-Based Web Application Architectures" Sheesh, I had enough trouble getting 1 presentation ready on time, let alone three! No wonder you have been relatively inactive on these lists lately. BTW, did you see my proposal regarding how Tomcat 4.0 should handle unpacking of war files? I would like to implement it this week. Any comments on that? Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Bug 389] New - Security Issue? Important attributes exposed byServletContext can be modified BugRat Report#682
On Mon, 12 Mar 2001, Glenn Nielsen wrote: "Craig R. McClanahan" wrote: On Mon, 12 Mar 2001, Glenn Nielsen wrote: The latest version of Tomcat 4.0 from CVS supports the Java SecurityManager. Tomcat 4.0 Beta 1 did not. The Java SecurityManager can restrict access to those properties and do a great deal more to assist you in running a secure application server. I wouldn't consider what you reported as a bug now that the Java SecurityManager has been implemented. I think the issue is still real (assuming that you don't have total control over the code installed in your web app), because context attributes are mutable. These attributes were originally introduced to avoid code dependencies between Jasper and the servlet container it runs in. Now that we have a JNDI context, I think that might be a more appropriate mechanism, because the context itself is immutable. Sounds like a good idea. I have been finding JNDI very handy for populating resources to Tomcat Hosts. On that topic, the J2EE spec recommends having resources available for implementations of javax.mail.Session and javax.mail.Transport. I don't have a problem with your specialized object factory for messaging, but what do you think about building generic ones for Session and Transport as well? BTW, if you are attending ApacheCon 2001 Apr 4-6, I will be presenting a session on "Tomcat Server and Application Security" that goes into great detail on how the Java SecurityManager works and using it with Tomcat. Make that: - F03 "Tomcat Server and Application Security" I will definitely be there, and look forward to meeting you in person. Gee, maybe I'd better come and learn :-). I will definitely be there, because I'm presenting two other Tomcat related sessions and one on web application architectures: - TH13 "The Tomcat Servlet Container" (will cover 4.0 architecture) - TH09 "Migrating Apache JServ Applications to Tomcat" - W16 "Recommendations for Java-Based Web Application Architectures" Sheesh, I had enough trouble getting 1 presentation ready on time, let alone three! No wonder you have been relatively inactive on these lists lately. You know how, when you're budgeting, you ask for more than you expect to get so you'll be satisfied with the results? Well, they accepted many more of my proposals than I expected. But that's nothing compared to what JavaOne did to me (three sessions and four BOFs). I will definitely be using StarOffice as much as Emacs over the next few weeks. Fortunately, there is at least some overlap in subject matter. BTW, did you see my proposal regarding how Tomcat 4.0 should handle unpacking of war files? I would like to implement it this week. Any comments on that? One other reason for relative inactivity is that my token card enabling remote access to my Sun email account decided to die, so I haven't seen anything on the mailing lists from about Wednesday through Friday last week. Could you resent this proposal (to me privately is fine since everyone else has seen it)? Regards, Glenn Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An important question
on 12/27/2000 11:20 AM, "David Lavigne" [EMAIL PROTECTED] wrote: How can the future of Tomcat be 4.0 while it does not have connectors to the web servers that 3.x have? I believe that it will be the future as soon as these exist, otherwise there is no point in making Tomcat a separate product from Apache httpd when that is the only webserver Catalina supports. Maybe if we hadn't been focusing so hard on 3.x, then 4.0 would have had those features. *That* is the point. -jon
Re: An important question
Please don't start that again. --- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com Jon Stevens [EMAIL PROTECTED] 28/12/2000 08:27 Please respond to tomcat-dev To:[EMAIL PROTECTED] cc: Subject:Re: An important question on 12/27/2000 11:20 AM, David Lavigne [EMAIL PROTECTED] wrote: How can the future of Tomcat be 4.0 while it does not have connectors to the web servers that 3.x have? I believe that it will be the future as soon as these exist, otherwise there is no point in making Tomcat a separate product from Apache httpd when that is the only webserver Catalina supports. Maybe if we hadn't been focusing so hard on 3.x, then 4.0 would have had those features. *That* is the point. -jon
