svn commit: r541206 - /tomcat/trunk/bin/service.bat

[mturk]

Author: mturk
Date: Wed May 23 23:56:59 2007
New Revision: 541206

URL: http://svn.apache.org/viewvc?view=rev&rev=541206
Log:
Automatically detect CPU and 64-bit JVM version. This allows to install the 
proper service wrapper for the JVM and CPU used.

Modified:
tomcat/trunk/bin/service.bat

Modified: tomcat/trunk/bin/service.bat
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/bin/service.bat?view=diff&rev=541206&r1=541205&r2=541206
==
--- tomcat/trunk/bin/service.bat (original)
+++ tomcat/trunk/bin/service.bat Wed May 23 23:56:59 2007
@@ -15,30 +15,45 @@
 rem ---
 
 rem Guess CATALINA_HOME if not defined
+
+rem Make sure prerequisite environment variables are set
+if not "%JAVA_HOME%" == "" goto okJavaHome
+echo The JAVA_HOME environment variable is not defined
+echo This environment variable is needed to run this program
+goto end 
+
+:okJavaHome
+
+rem Detect Java Version and CPU
+set JVM_PLATFORM=%PROCESSOR_ARCHITEW6432%
+if "%JVM_PLATFORM%" == "" set JVM_PLATFORM=%PROCESSOR_ARCHITECTURE%
+
+set EXECUTABLE_CPU=
+java -version 2>&1 | findstr /I 64-bit > NUL
+if not ERRORLEVEL == 1 set EXECUTABLE_CPU=%JVM_PLATFORM%\
+
 set CURRENT_DIR=%cd%
 if not "%CATALINA_HOME%" == "" goto gotHome
-set CATALINA_HOME=%cd%
-if exist "%CATALINA_HOME%\bin\tomcat6.exe" goto okHome
-rem CD to the upper dir
-cd ..
-set CATALINA_HOME=%cd%
+set CURRENT_DIR=.\
+if "%OS%" == "Windows_NT" set CURRENT_DIR=%~dp0%
+
+pushd %CURRENT_DIR%..
+set CATALINA_HOME=%CD%
+popd
+
 :gotHome
-if exist "%CATALINA_HOME%\bin\tomcat6.exe" goto okHome
-echo The tomcat.exe was not found...
+if exist "%CATALINA_HOME%\bin\%EXECUTABLE_CPU%tomcat6.exe" goto okHome
+echo Tomcat6.exe for %JVM_PLATFORM% was not found...
 echo The CATALINA_HOME environment variable is not defined correctly.
 echo This environment variable is needed to run this program
 goto end
-rem Make sure prerequisite environment variables are set
-if not "%JAVA_HOME%" == "" goto okHome
-echo The JAVA_HOME environment variable is not defined
-echo This environment variable is needed to run this program
-goto end 
+
 :okHome
 if not "%CATALINA_BASE%" == "" goto gotBase
 set CATALINA_BASE=%CATALINA_HOME%
 :gotBase
- 
-set EXECUTABLE=%CATALINA_HOME%\bin\tomcat6.exe
+
+set EXECUTABLE=%CATALINA_HOME%\bin\%EXECUTABLE_CPU%tomcat6.exe
 
 rem Set default Service name
 set SERVICE_NAME=Tomcat6
@@ -61,15 +76,15 @@
 :doRemove
 rem Remove the service
 "%EXECUTABLE%" //DS//%SERVICE_NAME%
-echo The service '%SERVICE_NAME%' has been removed
+echo Service '%SERVICE_NAME%' has been removed
 goto end
 
 :doInstall
 rem Install the service
-echo Installing the service '%SERVICE_NAME%' ...
-echo Using CATALINA_HOME:%CATALINA_HOME%
-echo Using CATALINA_BASE:%CATALINA_BASE%
-echo Using JAVA_HOME:%JAVA_HOME%
+echo Installing service '%SERVICE_NAME%' ...
+echo Using CATALINA_HOME: %CATALINA_HOME%
+echo Using CATALINA_BASE: %CATALINA_BASE%
+echo Using JAVA_HOME: %JAVA_HOME%
 
 rem Use the environment variables as an example
 rem Each command line option is prefixed with PR_
@@ -86,7 +101,8 @@
 if exist "%PR_JVM%" goto foundJvm
 set PR_JVM=auto
 :foundJvm
-echo Using JVM:  %PR_JVM%
+echo Using JVM  : %PR_JVM%
+echo Using JVM_PLATFORM : %JVM_PLATFORM%
 "%EXECUTABLE%" //IS//%SERVICE_NAME% --StartClass 
org.apache.catalina.startup.Bootstrap --StopClass 
org.apache.catalina.startup.Bootstrap --StartParams start --StopParams stop
 if not errorlevel 1 goto installed
 echo Failed installing '%SERVICE_NAME%' service
@@ -106,7 +122,7 @@
 set PR_STDOUTPUT=auto
 set PR_STDERROR=auto
 "%EXECUTABLE%" //US//%SERVICE_NAME% ++JvmOptions 
"-Djava.io.tmpdir=%CATALINA_BASE%\temp" --JvmMs 128 --JvmMx 256
-echo The service '%SERVICE_NAME%' has been installed.
+echo Service '%SERVICE_NAME%' has been installed.
 
 :end
 cd %CURRENT_DIR%



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541204 - /tomcat/trunk/dist.xml

[mturk]

Author: mturk
Date: Wed May 23 23:54:44 2007
New Revision: 541204

URL: http://svn.apache.org/viewvc?view=rev&rev=541204
Log:
Add windows service binaries to the .zip distribution.
The rule can be excluded by defining exclude.service.binaries in 
build.properties file.
Service binaries included are for all platforms WIN32 and WIN64.

Modified:
tomcat/trunk/dist.xml

Modified: tomcat/trunk/dist.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/dist.xml?view=diff&rev=541204&r1=541203&r2=541204
==
--- tomcat/trunk/dist.xml (original)
+++ tomcat/trunk/dist.xml Wed May 23 23:54:44 2007
@@ -418,7 +418,7 @@
 
   
   
+   description="Create Windows 32-bit installer" if="execute.installer">
 
 
   
@@ -426,10 +426,9 @@
 
 
 
-
-
+
+   
+
 
 
 
@@ -477,6 +476,15 @@
 
   
   
+
+   
+
+
+   
+
+
+   
+  
 
   
 
@@ -493,7 +501,15 @@
 
 
 
-
+
+
+
+
+
+
   
 
 
@@ -589,6 +605,14 @@
 
 
 
+
+
+
+
+ 
   
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41749] - Tomcat with APR using SSL spins CPU at 100%

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41749





--- Additional Comments From [EMAIL PROTECTED]  2007-05-23 23:40 ---
I have the same problem. i am using IIS6 with Tomcat 5.5.23 and JDK 1.5.0_11
Win2003 Server x64
When i debug the server remote i see ajp-polling-threads. one of them
is utilizing 100% CPU
when i suspend this polling-thread cpu-usage drops immediatelly.
i dont use ssl. bug seems to be in the poll-method of the ajp-connector.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42503] - ServletContext.getResourceAsStream returns stale data

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42503





--- Additional Comments From [EMAIL PROTECTED]  2007-05-23 17:00 ---
Created an attachment (id=20265)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20265&action=view)
Patch that updates the last modified time of the file when it is inserted into
the cache

The problem occurs because the last modified timestamp in the
FileResourceAttribute of CacheEntry isn't updated at the time the CacheEntry is
first inserted into the cache. The timestamp gets updated when
ProxyDirContext.revalidate() is executed. The window between when the
CacheEntry was inserted and when ProxyDirContext.revalidate() is called is
where the problem occurs.

The attached patch fixes this by updating the last modified (and creation)
timestamp at the time the resource is created (i.e. inserted into the cache). 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42503] - ServletContext.getResourceAsStream returns stale data

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42503





--- Additional Comments From [EMAIL PROTECTED]  2007-05-23 16:54 ---
Created an attachment (id=20264)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20264&action=view)
Test case

Put test.jsp in the ROOT web app.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42503] - ServletContext.getResourceAsStream returns stale data

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42503





--- Additional Comments From [EMAIL PROTECTED]  2007-05-23 16:53 ---
Created an attachment (id=20263)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20263&action=view)
Data file for the test case

Put test.txt in the ROOT web app

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42503] New: - ServletContext.getResourceAsStream returns stale data

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42503

   Summary: ServletContext.getResourceAsStream returns stale data
   Product: Tomcat 6
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Under certain conditions, the resource cache implementation used by the
servlet/JSP engine (in org.apache.naming.resource) does not detect that a file
in its cache has been modified and therefore returns the previous contents of
the file.

This happens only 
 * when the file contents are modified but the file length doesn't change
 * until the time the first change in the file is detected after server startup
   
To reproduce the problem, put the attached test.jsp and test.txt into the ROOT
web app and then do the following. (I used Tomcat 6's trunk for the test)

% cat test.txt
abcd
% telnet . 9080 
Trying 0.0.0.0...
Connected to ..
Escape character is '^]'.
GET /test.jsp HTTP/1.0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=706D6FE8B06687509D42E79DBEE266EF; Path=/
Content-Type: text/html
Content-Length: 26
Date: Wed, 23 May 2007 23:03:05 GMT
Connection: close



File contents=[
abcd

]
Connection to . closed by foreign host.

% cat test.txt (change the contents but not the size)
efgh
 % telnet . 9080 
Trying 0.0.0.0...
Connected to ..
Escape character is '^]'.
GET /test.jsp HTTP/1.0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=2B144247B747F54184114FA82869DE14; Path=/
Content-Type: text/html
Content-Length: 26
Date: Wed, 23 May 2007 23:04:24 GMT
Connection: close



File contents=[
abcd

]

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Versioning in sources

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

aah, that makes sense.

Remember that the release manager is carrying his/her own 
build.properties, and if you build from source, you should too.
in there you override any properties needed. That is why all binary 
builds are correct, but your build isn't.


what you are asking for is that we update build.properties.default 
before tagging a release, correct?


Obviously, I am purposefully not doing that (I find those stupid 
commits, well, stupid ...).


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Versioning in sources

[William L. Thomson Jr.]

On Wed, 2007-05-23 at 19:46 +0200, Filip Hanik - Dev Lists wrote:
> aah, that makes sense.
> 
> Remember that the release manager is carrying his/her own 
> build.properties, and if you build from source, you should too.
> in there you override any properties needed. That is why all binary 
> builds are correct, but your build isn't.

Sure, and I can sed this in the build process, but prefer to not modify
upstreams stuff as much as possible.

> what you are asking for is that we update build.properties.default 
> before tagging a release, correct?

Yes, please. So that if one downloads versioned sources, and just builds
it by invoking ant with all defaults. The resulting build version will
match the sources it was built from.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

Re: Versioning in sources

[Filip Hanik - Dev Lists]

aah, that makes sense.

Remember that the release manager is carrying his/her own 
build.properties, and if you build from source, you should too.
in there you override any properties needed. That is why all binary 
builds are correct, but your build isn't.


what you are asking for is that we update build.properties.default 
before tagging a release, correct?


Filip

William L. Thomson Jr. wrote:

Filip,

On Wed, 2007-05-23 at 18:37 +0200, Filip Hanik - Dev Lists wrote:
  
hey William, what are you referring to? any specific .java files that 
need a version number?



Sorry should have been more specific, the problem lies in
build.properties.default

  
I was under the impression that we only tag each build, and then there 
is a small sucker in a property file that we swap out.



It's the prop file being neglected :)

  

ie, when you start 5.5.23 then you see

May 23, 2007 6:35:55 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.23



Not here, with 6.0.13 I get

May 23, 2007 1:15:58 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0-snapshot

With 5.5.23, I get

May 23, 2007 1:17:01 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5

Not sure what that's about with 5.5.23, since the prop file has 5.5.20,
so should reflect that version but does not.

404, and other error pages also reflect the versions as shown in the log
file and prop file.


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Versioning in sources

[William L. Thomson Jr.]

Filip,

On Wed, 2007-05-23 at 18:37 +0200, Filip Hanik - Dev Lists wrote:
> hey William, what are you referring to? any specific .java files that 
> need a version number?

Sorry should have been more specific, the problem lies in
build.properties.default

> I was under the impression that we only tag each build, and then there 
> is a small sucker in a property file that we swap out.

It's the prop file being neglected :)

> ie, when you start 5.5.23 then you see
> 
> May 23, 2007 6:35:55 PM org.apache.catalina.core.StandardEngine start
> INFO: Starting Servlet Engine: Apache Tomcat/5.5.23

Not here, with 6.0.13 I get

May 23, 2007 1:15:58 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0-snapshot

With 5.5.23, I get

May 23, 2007 1:17:01 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5

Not sure what that's about with 5.5.23, since the prop file has 5.5.20,
so should reflect that version but does not.

404, and other error pages also reflect the versions as shown in the log
file and prop file.


-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

Re: Announcing releases of tomcat native

[Mladen Turk]

William L. Thomson Jr. wrote:

On Wed, 2007-05-23 at 13:19 +0200, Mladen Turk wrote:

For 6.0.13 the required version is 1.1.8 and recommended
is 1.1.10 and that is clearly printed whenever Tomcat is started.
I'm not sure what more is needed.


According to the bug report, it required 1.1.10, and Tomcat failed to
start with 1.1.8.

http://bugs.gentoo.org/show_bug.cgi?id=179462



In that case this is the bug in Tomcat, cause required
version should be 1.1.10 not 1.1.8 then.

Anyhow, the point is to have Tomcat Native as part of
Tomcat release.
If for example we find a bug that would require a
new version of Tomcat native, then 5.5.x and 6.0.x
should be released as well with required version matching that.

That is why I'm not in favor of having separate releases
of the Tomcat Native, because we use the so called
releases *only* to be able to build with ant more easily.
Ideally the build.xml should build the binaries as well,
and that's not going to happen in the near future :)

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Versioning in sources

[Filip Hanik - Dev Lists]

hey William, what are you referring to? any specific .java files that 
need a version number?
I was under the impression that we only tag each build, and then there 
is a small sucker in a property file that we swap out.


ie, when you start 5.5.23 then you see

May 23, 2007 6:35:55 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.23

Filip


William L. Thomson Jr. wrote:

I could have swarn this was brought up recently but could not find
mention of it in archives. Guess I should file a bug on it, but it's
kinda a moot issue.

It seems the sources for 6.0.x have not really been versioned. I have
noticed it myself on occasion, but never cared enough to comment or etc.
A user commented recently, which motivated me to act :)

Anyway 6.0.x stuff is all 6.0.0-snapshot. Or something like that.
Looking at latest 5.5.23 sources, they are versioned as 5.5.20 :(

Now I can totally sed this stuff on compile/install/merge but would be
nice if it could be addressed upstream. I am sure others downloading
sources would prefer the default to match the version of the sources :)

Minor issue, but kinda annoying just the same. Thanks much, and let me
know if you would prefer I file a bug.

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Versioning in sources

[William L. Thomson Jr.]

I could have swarn this was brought up recently but could not find
mention of it in archives. Guess I should file a bug on it, but it's
kinda a moot issue.

It seems the sources for 6.0.x have not really been versioned. I have
noticed it myself on occasion, but never cared enough to comment or etc.
A user commented recently, which motivated me to act :)

Anyway 6.0.x stuff is all 6.0.0-snapshot. Or something like that.
Looking at latest 5.5.23 sources, they are versioned as 5.5.20 :(

Now I can totally sed this stuff on compile/install/merge but would be
nice if it could be addressed upstream. I am sure others downloading
sources would prefer the default to match the version of the sources :)

Minor issue, but kinda annoying just the same. Thanks much, and let me
know if you would prefer I file a bug.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

Re: Publishing JAR's to Maven

[Filip Hanik - Dev Lists]

Niall Pemberton wrote:

On 5/23/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:

Hi,

Just wanted to say thanks. :-)


+1 - this is great.
I think the ant tasks have different naming conventions, I believe the 
jars get renamed on the way up.

just an fyi
Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42497] - 304 response should consistently include ETag header

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42497





--- Additional Comments From [EMAIL PROTECTED]  2007-05-23 09:03 ---
Created an attachment (id=20251)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20251&action=view)
Request and response headers showing the problem

I have attached a log file from Firefix LiveHTTPHeaders showing the problem.
A static file is requested twice. The first response is a 200 with an ETag
header,
the second response is a 304 without an ETag header.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42497] New: - 304 response should consistently include ETag header

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42497

   Summary: 304 response should consistently include ETag header
   Product: Tomcat 5
   Version: 5.5.23
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According to the HTTP spec, if a server includes an ETag header when it sends a
file, it must also include the ETag when it sends a 304 (not-modified) response
for that file. Tomcat does not do this for static files - if you request a
static file and get a 200 response, the response has an ETag header; but if you
get a 304 resopnse, the ETag is omitted.

To reproduce:
- In a browser, request a static file from Tomcat (e.g. 
http://localhost/tomcat.gif)
- Make sure you get a 200 response (force reload or clear browser cache)
- Examine the response headers (using a browser plugin or whatever) - note that
there is an ETag header
- Request the same file again, getting a 304 (not-modified) response from Tomcat
- Examine the response headers - note there is no ETag
The 304 response should include an ETag header, because the 200 response had 
one.

Spec reference: RFC 2616 section 10.3.5 says:
"304 Not Modified
[...]
The response MUST include the following header fields:
[...]
  - ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request"

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r540981 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/CometEvent.java catalina/connector/CometEventImpl.java coyote/ActionCode.java coyote/http11/Http11AprProcessor.java

[remm]

Author: remm
Date: Wed May 23 08:49:36 2007
New Revision: 540981

URL: http://svn.apache.org/viewvc?view=rev&rev=540981
Log:
- Revert the API changes in the 6.0.x branch.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CometEventImpl.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ActionCode.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java?view=diff&rev=540981&r1=540980&r2=540981
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java Wed May 23 
08:49:36 2007
@@ -66,14 +66,8 @@
  *  been initialized in the begin method should be reset. After this event 
has
  *  been processed, the request and response objects, as well as all their 
dependent
  *  objects will be recycled and used to process other requests.
- * CALLBACK - Callback will be called by the container after the comet 
processor
- *  has registered for the OP_CALLBACK operation.
- *  This allows you get an event instantly, and you can perform IO actions
- *  or close the Comet connection.
- * WRITE - Write is called, only if the Comet processor has registered for 
the OP_WRITE
- *  event. This means that connection is ready to receive data to be 
written out.
  */
-public enum EventType {BEGIN, READ, END, ERROR, WRITE, CALLBACK}
+public enum EventType {BEGIN, READ, END, ERROR}
 
 
 /**
@@ -85,7 +79,6 @@
  * WEBAPP_RELOAD - the webapplication is being reloaded (sub type of END)
  * SERVER_SHUTDOWN - the server is shutting down (sub type of END)
  * SESSION_END - the servlet ended the session (sub type of END)
-
  */
 public enum EventSubType { TIMEOUT, CLIENT_DISCONNECT, IOEXCEPTION, 
WEBAPP_RELOAD, SERVER_SHUTDOWN, SESSION_END }
 
@@ -108,7 +101,6 @@
  * Returns the event type.
  * 
  * @return EventType
- * @see #EventType
  */
 public EventType getEventType();
 
@@ -116,7 +108,6 @@
  * Returns the sub type of this event.
  * 
  * @return EventSubType
- * @see #EventSubType
  */
 public EventSubType getEventSubType();
 
@@ -152,92 +143,5 @@
  */
 public void setTimeout(int timeout)
 throws IOException, ServletException, UnsupportedOperationException;
-
-
-
-/**
- * COMET_NON_BLOCKING
- * Option bit set for allowing non blocking IO
- * when reading from the request or writing to the response
- * COMET_NO_IO
- * Option bit set to not register for any IO events
- * Connections can be reregistered for IO events using the 
- * @see #configure(int)
- */
-public enum CometConfiguration {COMET_NON_BLOCKING,COMET_NO_IO};
-
-/**
- * Configures the connection for desired IO options.
- * By default a Comet connection is configured for 
- * a) Blocking IO - standard servlet usage
- * b) Register for READ events when data arrives
- * Tomcat Comet allows you to configure for additional options:
- * the COMET_NON_BLOCKING bit signals whether writing and 
reading from the request 
- * or writing to the response will be non blocking.
- * the COMET_NO_IO bit signals the container that you are not 
interested in 
- * receiving any IO events from the container.
- * @param cometOptions int - the option bit set, see #COMET_NON_BLOCKING 
and #COMET_NO_IO
- * @throws IOException -
- * @throws IllegalStateException - if this method is invoked outside of 
the BEGIN event
- */
-public void configure(CometConfiguration... options)
-throws IOException, IllegalStateException;
-
-/**
- * Returns the configuration for this Comet connection
- * @return CometConfiguration[]
- * @see #configure(CometConfiguration...)
- */
-public CometConfiguration[] getConfiguration();
-
-/**
- * OP_CALLBACK - receive a CALLBACK event from the container
- * OP_READ - receive a READ event when the connection has data to be read
- * OP_WRITE - receive a WRITE event when the connection is able to receive 
data to be written
- * @see #register(CometOperations)
- */
-public enum CometOperation {OP_CALLBACK, OP_READ, OP_WRITE};
-
-/**
- * Registers the Comet connection with the container for IO notifications.
- * These could be notifications 
- * @param operations
- * @throws IOException
- * @throws IllegalStateException - if you are trying to register with a 
socket that already is registered
- * or if the operation you are trying to register is invalid.
- */
-public void

svn commit: r540979 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java

[remm]

Author: remm
Date: Wed May 23 08:44:33 2007
New Revision: 540979

URL: http://svn.apache.org/viewvc?view=rev&rev=540979
Log:
- NPE check (when using JMX, if I remember correctly).

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java?view=diff&rev=540979&r1=540978&r2=540979
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java Wed 
May 23 08:44:33 2007
@@ -1875,6 +1875,9 @@
  * @return The work path
  */ 
 public String getWorkPath() {
+if (getWorkDir() == null) {
+return null;
+}
 File workDir = new File(getWorkDir());
 if (!workDir.isAbsolute()) {
 File catalinaHome = engineBase();



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Announcing releases of tomcat native

[William L. Thomson Jr.]

On Wed, 2007-05-23 at 15:18 +0200, Rainer Jung wrote:
>
> I think he's trying to provide packages for a distro. So he wants to 
> provide 1.1.8, 1.1.9, 1.1.10, ... whenever they are released (available).

100% Correct :)

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

Re: Announcing releases of tomcat native

[William L. Thomson Jr.]

On Wed, 2007-05-23 at 13:19 +0200, Mladen Turk wrote:
>
> For 6.0.13 the required version is 1.1.8 and recommended
> is 1.1.10 and that is clearly printed whenever Tomcat is started.
> I'm not sure what more is needed.

According to the bug report, it required 1.1.10, and Tomcat failed to
start with 1.1.8.

http://bugs.gentoo.org/show_bug.cgi?id=179462

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

Re: Announcing releases of tomcat native

[Jess Holle]

In general it is not very easy to even notice when new stable tcnative 
versions become available.


For instance, discovering that 1.1.10 is out, what changed since 1.1.8, 
and verifying that it is intended to work with 5.5.23 are not very 
trivial from the web site currently...


Rainer Jung wrote:

Mladen Turk wrote:

It is part of Tomcat release and that shouldn't change.
Each tomcat release has a detection of the Tomcat native, and
it prints out the suggested version compared with the one user is
running.

For 6.0.13 the required version is 1.1.8 and recommended
is 1.1.10 and that is clearly printed whenever Tomcat is started.
I'm not sure what more is needed.


I think he's trying to provide packages for a distro. So he wants to 
provide 1.1.8, 1.1.9, 1.1.10, ... whenever they are released (available).


At the moment, the only way to learn about the releases for him is 
looking into a tomcat download, unpacking the included tcnative source 
and checking, if it is new and he needs to provide a new package. This 
is not very robust and furthermore that way he only will recognize 
tcnative versions bundled with a Tomcat download.


Regards,

Rainer

-
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: Publishing JAR's to Maven

[Niall Pemberton]

On 5/23/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:

Hi,

Just wanted to say thanks. :-)


+1 - this is great.

Niall


Regards,
Sebastiaan

Filip Hanik - Dev Lists wrote:
> Ok, I think I'm done, just need to document the very messy way of
> setting this up.
>
> BTW, I published 6.0.13 to the staging and the main repository.
> I built the extras from the trunk, as I don't think there were any
> changes since 6.0.13
>
> Filip
>
> Filip Hanik - Dev Lists wrote:
>> I'm gonna take a new stab at this, to get it over with.
>> this time using the Maven ant-tasks,
>>
>> Any work already done on this, kindly let me know
>>
>> Filip
>>
>> -
>> 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]
>

-
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: Announcing releases of tomcat native

[Rainer Jung]

Mladen Turk wrote:

It is part of Tomcat release and that shouldn't change.
Each tomcat release has a detection of the Tomcat native, and
it prints out the suggested version compared with the one user is
running.

For 6.0.13 the required version is 1.1.8 and recommended
is 1.1.10 and that is clearly printed whenever Tomcat is started.
I'm not sure what more is needed.


I think he's trying to provide packages for a distro. So he wants to 
provide 1.1.8, 1.1.9, 1.1.10, ... whenever they are released (available).


At the moment, the only way to learn about the releases for him is 
looking into a tomcat download, unpacking the included tcnative source 
and checking, if it is new and he needs to provide a new package. This 
is not very robust and furthermore that way he only will recognize 
tcnative versions bundled with a Tomcat download.


Regards,

Rainer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42494] - local JNDI context indefinitely caches objects from custom object factories

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42494





--- Additional Comments From [EMAIL PROTECTED]  2007-05-23 05:47 ---
I repeat:

"Every time your web application calls lookup() on a context entry that is bound
to this factory, the getObjectInstance() method is called, ..." (quoted from
JNDI resources howto, Adding custom resource factories)

How can I programmatically reload an application from the application itself, in
a J2EE-conformant manner?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42494] - local JNDI context indefinitely caches objects from custom object factories

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42494


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-05-23 05:14 ---
Factories are indeed resolved once. You should reload the application.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42494] New: - local JNDI context indefinitely caches objects from custom object factories

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42494

   Summary: local JNDI context indefinitely caches objects from
custom object factories
   Product: Tomcat 5
   Version: 5.5.17
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Currently, if I locate a resource (e.g. EJB Home) from Tomcat's JNDI Context,
and I have configured a custom Object Factory for that location, the factory is
only exactly queried once.

This is very problematic in the EJB case because if the connection to the server
has been broken (for example by an application server restart), as this renders
the handle invalid and there is no way to get another handle on the same bean
again (apart from restarting Tomcat).

This is on Tomcat 5.5.17, but is most likely broken on 5.5.23, too.

Please note that Tomcats behaviour is also conflicting with the docs:

"Every time your web application calls lookup() on a context entry that is bound
to this factory, the getObjectInstance() method is called, ..." (quoted from
JNDI resources howto, Adding custom resource factories)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Announcing releases of tomcat native

[Mladen Turk]

Yoav Shapira wrote:

Hi,

On 5/22/07, William L. Thomson Jr. <[EMAIL PROTECTED]> wrote:

If possible when new versions of Tomcat native be announced on list?
Seems Tomcat 6.0.13 requires 1.1.10. First I became aware of it, was
when user reported the problem. Granted I should have discovered it
before them when packaging and testing Tomcat 6.0.13 release.

Either way would be easier to follow and be aware of if new releases
were announced. Like is done for Tomcat and mod_jk. Granted I understand
both of those require vote and etc before release. So more of an
official release process there. Just not ideal to have to check download
area for new releases.

Thanks much :)


You're right, we should be better about them.

If the tcnative releases are not part of another voted-upon package,
such as Tomcat itself or the Connectors, then they need to be voted
upon separately.  The PMC has to ratify them as releases, like all the
other code we release.

On the other hand, if they are included in Tomcat as bundles and not
distributed separately, we don't need another vote.  Just a note in
the release notes about the tcnative version change.



It is part of Tomcat release and that shouldn't change.
Each tomcat release has a detection of the Tomcat native, and
it prints out the suggested version compared with the one user is
running.

For 6.0.13 the required version is 1.1.8 and recommended
is 1.1.10 and that is clearly printed whenever Tomcat is started.
I'm not sure what more is needed.

Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Publishing JAR's to Maven

[Sebastiaan van Erk]

Hi,

Just wanted to say thanks. :-)

Regards,
Sebastiaan



Filip Hanik - Dev Lists wrote:
Ok, I think I'm done, just need to document the very messy way of 
setting this up.


BTW, I published 6.0.13 to the staging and the main repository.
I built the extras from the trunk, as I don't think there were any 
changes since 6.0.13


Filip

Filip Hanik - Dev Lists wrote:

I'm gonna take a new stab at this, to get it over with.
this time using the Maven ant-tasks,

Any work already done on this, kindly let me know

Filip

-
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]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]