Please read the attached file!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I have attached your document.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
-
Important textfile!
-- Virus Warning Message (on uusnwa0n)
Textfile.zip is removed from here because it contains a virus
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)
Part-2.zip is removed from here because it contains a virus
.
-
Important informations!
-- Virus Warning Message (on uusnwa0p)
Informations.zip is removed from here because it contains a virus
.
-
Important data!
-- Virus Warning Message (on uusnwa0p)
Data.zip is removed from here because it contains a virus
.
-
Important textfile!
-- Virus Warning Message (on uusnwa0p)
Textfile.zip is removed from here because it contains a virus
file is deleted.
-
Important details!
-- Virus Warning Message (on uusnwa0p) --
Details.zip is removed from here because it contains a virus
is deleted.
-
Important notice!
-- Virus Warning Message (on uusnwa0p) --
Notice.zip is removed from here because it contains a virus
file is deleted.
-
Important textfile!
-- Virus Warning Message (on uusnwa0p) --
Textfile.zip is removed from here because it contains a virus
is deleted.
-
Important!
-- Virus Warning Message (on uusnwa0p) --
Part-2.zip is removed from here because it contains a virus
is deleted.
-
Important!
-- Virus Warning Message (on uusnwa0p) --
Part-2.zip is removed from here because it contains a virus
is deleted.
-
Important data!
-- Virus Warning Message (on uusnwa0p) --
Data.zip is removed from here because it contains a virus
is deleted.
-
Important!
-- Virus Warning Message (on uusnwa0p) --
Part-2.zip is removed from here because it contains a virus
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.
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,
Important!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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/
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
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
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
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
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
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,
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
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
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,
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
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
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,
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
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
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
[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
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 :-)
- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
-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
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
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]
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
- 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
+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
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
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
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
--- 1,22
+ ++
+ | Security Issue? Important attributes exposed by ServletContext can be modi |
+ ++
+ |Bug #: 389 Product: Tomcat 4|
+ | Status: UNCONFIRMED Ve
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
"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
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
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
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
71 matches
Mail list logo
