Re: Tomcat supporting PHP

[Endre Stølsvik]

Sorry for posting on this old thread, and then even to my own post..

However, in the name of the archives and anyone interested:

It is GPL, and it is a native Resin feature, and both of those things 
are very sad. But it is a very interesting project, and it is definitly 
open source, though very business unfriendly.


This thing is apparently rather standards compliant, implementing the 
javax.scripting API. The PHP part of Resin resides in one single 
portable servlet.


Here's a blog entry describing the approx. one-and-a-half easy step to 
get "Quercus PHP engine running in GlassFish Java EE 5 Application Server":

  http://weblogs.java.net/blog/ludo/archive/2007/03/100_java_quercu.html

Kind regards,
Endre.

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

DO NOT REPLY [Bug 43335] New: - Are pathname & docBase mandatory fields for a Context in server.xml

[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=43335

   Summary: Are pathname & docBase mandatory fields for a Context in
server.xml
   Product: Tomcat 5
   Version: 5.5.20
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:HTTP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On Solaris we have a WAR application in $CATALINA_BASE/webapps/app1.war defined
in server.xml

...

...

works without problems

On Windows we have app1.war in $CATALINA_HOME, but we got an exception with
MBeans and must use

...

...

The docu says, docBase is mandatory, but path is optional, so I'm confused now. 

What would be the correct settings ?

-- 
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 43338] New: - Setting '*' as the servlet-name in filter-mapping causes IllegalArgumentException.

[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=43338

   Summary: Setting '*' as the servlet-name in filter-mapping causes
IllegalArgumentException.
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


SRV 6.2.5 says supporting for '*' as the servlet-name in filter-mapping.
I set following filter-mapping.

SampleFilter
*


However, InvocationTargetException occurred in Digester. 
It is as follows.

Sep 10, 2007 7:16:56 PM org.apache.tomcat.util.digester.Digester endElement
SEVERE: End event threw exception
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.tomcat.util.IntrospectionUtils.callMethod1
(IntrospectionUtils.java:899)
at org.apache.tomcat.util.digester.SetNextRule.end
(SetNextRule.java:193)
at org.apache.tomcat.util.digester.Rule.end(Rule.java:229)
at org.apache.tomcat.util.digester.Digester.endElement
(Digester.java:1058)
omit...
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: java.lang.IllegalArgumentException: Filter mapping must specify 
either a  or a 
at org.apache.catalina.core.StandardContext.addFilterMap
(StandardContext.java:2160)
... 44 more
   omit...


I made a StandardContext's patch.

Index:/tomcat6-trunk/java/org/apache/catalina/core/StandardContext.java
===
--- /tomcat6-trunk/java/org/apache/catalina/core/StandardContext.java
(revision 574195)
+++ /tomcat6-trunk/java/org/apache/catalina/core/StandardContext.java
(working copy)
@@ -2156,7 +2156,9 @@
 if (findFilterDef(filterName) == null)
 throw new IllegalArgumentException
 (sm.getString("standardContext.filterMap.name", filterName));
-if ((servletNames.length == 0) && (urlPatterns.length == 0))
+if (!filterMap.getMatchAllServletNames() && 
+   !filterMap.getMatchAllUrlPatterns() && 
+(servletNames.length == 0) && (urlPatterns.length == 0))
 throw new IllegalArgumentException
 (sm.getString("standardContext.filterMap.either"));
 // FIXME: Older spec revisions may still check this

I made a StandardContext's patch.

Regards.

-- 
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 43335] - Are pathname & docBase mandatory fields for a Context in server.xml

[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=43335


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 04:15 ---
Bugzilla is not a support forum. Please use the users mailing list for questions
like this.

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

Two keystore, invalid password

[István Viczián]

Hello,

I hope this is the right forum to take my question.
I found a very interesting problem with Tomcat 5.5.23, that not
appears in Tomcat 5.5.17 (boundled with NetBeans 5.5.1).
Imagine, that your web application acts as web-service server, and web
service client, too. You need SSL client certificate authentication
both for server and cliens side. So, you need two keys, one for the
SSL connector, and one for the web-service client. Put the case that
you cannot package two keys in one keystore.
The tomcat.keystore.jks contains the server key for the server side,
configured in server.xml in the SSL HTTP/1.1 Connector section, like
this:



The keystore.jks contains the client key for the client side,
configured with command line parameters:

-Djavax.net.ssl.keyStore=keystore.jks
-Djavax.net.ssl.keyStorePassword=keystore.pass

In this case, the Tomcat cannot open the tomcat.keystore.jks file, the
error message is:
java.io.IOException: Keystore was tampered with, or password was incorrect

So lets see the Bug 38774
(http://issues.apache.org/bugzilla/show_bug.cgi?id=38774), and the
source code of the the
org.apache.tomcat.util.net.jsse.JSSESocketFactory class and the
getKeystorePassword() method.

protected String getKeystorePassword() {
String keyPass = (String)attributes.get("keypass");
if (keyPass == null) {
keyPass = defaultKeyPass;
}
String keystorePass = (String)attributes.get("keystorePass");
if (keystorePass == null) {
// Bugzilla 38774:
http://issues.apache.org/bugzilla/show_bug.cgi?id=38774
keystorePass = System.getProperty("javax.net.ssl.keyStorePassword");
if (keystorePass == null ) {
keystorePass = keyPass;
}
}
return keystorePass;
}

It tries to get the keystorePass attribute (this is null, because the
keystorePass attribute come from the server.xml as "keypass"
property), then tries to get the system property. And if both are
null, gets the keypass property - this is the good one.

So, the Tomcat tries to open the tomcat.keystore.jks file with
keystore.pass password, which is the password (set as command line
parameter) of the keystore.jks file.

So I think the right way to check the system property in the last
step, when the keystorePass and the keyPass are both null.

protected String getKeystorePassword() {
String keyPass = (String)attributes.get("keypass");
if (keyPass == null) {
keyPass = defaultKeyPass;
}
String keystorePass = (String)attributes.get("keystorePass");
if (keystorePass == null) {
keystorePass = keyPass;
if (keystorePass == null ) {
// Bugzilla 38774:
http://issues.apache.org/bugzilla/show_bug.cgi?id=38774
keystorePass =
System.getProperty("javax.net.ssl.keyStorePassword");
}
}
return keystorePass;
}

My application works with this patch.

Istvan Viczian

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

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Mladen Turk wrote:

Remy Maucherat wrote:


To give an idea, "tis" could mean:
- API changing patches (any protected or above signature change)
- code changes in the critical path (for example, code which gets 
executed on each HTTP request)


Fine.

- any other commit for which a committer asks for the RTC procedure 
should be rollbacked if it hinders concurrent work, and go through the 
RTC procedure




This looks like a conditional veto that can be voted over. Perfect!
IIUC it means that instead veto one asks for a vote (+3 votes), right?
Looks like RTC on demand, that would require some sort of lazy consensus.


This could get clarified a little bit more. I don't think asking for 
review is vetoing a patch, as there's no need to revert in most cases 
(one case would be a pending tag, or if it somehow causes immediate 
development conflicts). However, if a patch doesn't attract enough 
votes, or doesn't pass the +3 margin (if that's what gets accepted), it 
is considered vetoed and needs to be reverted.


Rémy

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

DO NOT REPLY [Bug 43339] New: - Special characters like german umlauts in server.xml comments cause server to stop working

[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=43339

   Summary: Special characters like german umlauts in server.xml
comments cause server to stop working
   Product: Tomcat 4
   Version: 4.1.31
  Platform: PC
OS/Version: Windows Server 2003
Status: NEW
  Severity: minor
  Priority: P3
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A comment placed in the section

of the server.xml config file contained a german Umlaut (like in "Diese
Änderungen können"). This caused the server to refuse to start up - the service
was stopped as soon as it was started, reporting "The Java Virtual Machine has
exited with a code of 1, the service is being stopped." to the Windows event
log. The comment was inserted just before
 (dash dash greater
than)

This bug is very annoying, as the user gets no information about what causes the
 error, not even something like "error in config".

-- 
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 43339] - Special characters like german umlauts in server.xml comments cause server to stop working

[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=43339


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 07:13 ---
server.xml is an XML file. If you break it by adding characters to it not
encoded in the default UTF-8 encoding without declaring the encoding used, every
standards-compliant XML-parser will refuse to process it. So does Tomcat's XML
parser.
If there's any error on Tomcat's side, it's the missing XML-declaration at the
start of server.xml. But that isn't of relevance here (and I didn't bother to
check whether this has changed with the current version of the 4.1.x branch).

So, the "fix" is to have an UTF-8-encoded server.xml or to declare the encoding
used if it's different from UTF-8 (the default for an XML file without an
explicit declaration of the encoding).

-- 
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 40668] - MailSessionFactory is missing in Tomcat 5.5.23

[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=40668





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 07:49 ---
A more accurate description of the cause of this bug is probably that the tomcat
binary build process is not done in a repeatable fashion. The person creating
the builds is probably not even aware their build environment is creating broken
tomcat binaries.

One of the key purposes of Maven is to create repeatable builds that will
produce the exact same artifact, regardless of who ran the build. I suggest that
to permanently solve this problem, Maven be used in the Tomcat build.

-- 
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 43339] - Special characters like german umlauts in server.xml comments cause server to stop working

[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=43339





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 07:51 ---
OK, I thought that inside comments ANYTHING (including binary garbage) is to be
ignored until the comment end tag. This seems not to be the case, so it is ok
that the config was not accepted (although it would probably be more
user-friendly to just skip wrong comment content even if it is not required).

But there is still the problem that no senseful error message is given to the
user (at least I did not find any). I am leaving this bug at "resolved invalid"
because I am not sure if this is considered a bug and if it is, probably a new
bug report should be opened. 

-- 
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 43339] - Special characters like german umlauts in server.xml comments cause server to stop working

[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=43339





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 08:25 ---
> OK, I thought that inside comments ANYTHING (including binary garbage) is to
> be
> ignored until the comment end tag. This seems not to be the case, so it is ok
> that the config was not accepted (although it would probably be more
> user-friendly to just skip wrong comment content even if it is not required).

You still didn't get the point: it's a *requirement* for a XML-parser to abort
processing when an error (including what you call "binary garbage") is
encountered. Whether or not the error is inside a comment or not is completely
irrelevant. The fact that you added non-UTF-8 characters without declaring the
encoding used, broke server.xml. In fact, it isn't even an XML file anymore,
after that change.
Again: this is a matter of how XML and XML-parsers work, not a matter of a
choice made by Tomcat. If you want to find out more, read the XML specs.

> But there is still the problem that no senseful error message is given to the
> user (at least I did not find any). I am leaving this bug at "resolved
> invalid" because I am not sure if this is considered a bug and if it is,
> probably a new bug report should be opened.

I do get a senseful error message right on the console if I start Tomcat by
catalina.bat run
Chances are, you'll also find a message if you look into Tomcat's logs.

-- 
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 43341] New: - Abbility to define recovery test for lb worker

[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=43341

   Summary: Abbility to define recovery test for lb worker
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Connector:AJP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It would be handy to be able to explicitly define a "test request" and result to
be executed to test the availability of an lb worker in mod_jk before taking it
out of an error state.

-- 
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 43343] New: - Loss of data and concurrency issue with Catalina session persistent storage

[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=43343

   Summary: Loss of data and concurrency issue with Catalina session
persistent storage
   Product: Tomcat 6
   Version: 6.0.9
  Platform: Other
OS/Version: other
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A user was asking questions on the tomcat users mailing list about TC and how it
handled concurrency in sessions and session passivation/object caching of
sessions when they are inactive etc. I thought, surely this is using locks etc,
so had responded as such. Then I got curious. I started looking in the code and
found that indeed TC has a concurrency issue when the session is to pushed to
disk if it is inactive or the max number of live sessions is too high.

The problem is a user could have a session getting ready to become inactive. The
server is beginning to write the session out to disk. The user then comes in on
a request and gets the current session. They set an attribute. The web
application and the user think all is OK. But in reality the data they just put
into the session will be lost. The server just dumped their session to disk
containing the old data as they updated the copy. So, the next time they come in
the session will be pulled from disk with the old values and anything they put
into it will have been lost. Depending on the application this could be very 
bad.

To see the issue go to the file:
java/org/apache/catalina/session/PersistentManagerBase.java

methods:
swapIn
swapOut
writeSession
findSession
(other related)
then the different stores load and save methods. There is nothing keeping this
from happening.

If a lock is on a per session level this should keep it snappy for all other
requests etc. Either the session could be used as the lock or an object instance
variable on the session instance.

I noticed there is a comment in the source code for
PersistentManagerBase.processMaxIdleSwaps which reads:
// Swap out all sessions idle longer than maxIdleSwap
// FIXME: What's preventing us from mangling a session during
// a request?

So, apparently someone thought of this. Nothing is keeping it from mangling a
session currently.

What might be a fix is a session is given an instance variable which can be used
for a synchronization lock at the session level. In
PersistentManagerBase.findSession, this lock would be used before the session
can be returned. After the session map is accessed it should then return null if
the session had been passivating before it was asked to be found. The session
would then be loaded from storage again before it was ever given back to be
accessed had it been passivating. It would also be used in
PersistentManagerBase.* which call swapOut.

The code would look like this (might explain it better):

StandardSession:

/**
 Used for locking the session during persistence operations.
**/
Integer persistence_locker = new Integer(0);

PersistentManagerBase:

/**
 * Return the active Session, associated with this Manager, with the
 * specified session id (if any); otherwise return null.
 * This method checks the persistence store if persistence is enabled,
 * otherwise just uses the functionality from ManagerBase.
 *
 * @param id The session id for the session to be returned
 *
 * @exception IllegalStateException if a new session cannot be
 *  instantiated for any reason
 * @exception IOException if an input/output error occurs while
 *  processing this request
 */
public Session findSession(String id) throws IOException {

Session session = super.findSession(id);
//OK, at this point, we're not sure if another thread is trying to
//remove the session or not so the only way around this is to lock
//it (or attempt to) and then try to get it by this session id again.
//If the other code ran swapOut, then we should get a null back during
//this run, and if not, then by doing this we lock it out and then can
//access the session safely and will call access on it to update the
//access time and hopefully keep the processes from running swapOut
//so, we're adding two accesses to the hashmap instead of one for
//each request. But, we know we get the session or null back after
//the other process has had a chance to remove it or not.
if(session!=null{
synchronized(session.persistence_locker){
session = 
super.findSession(session.getIdInternal());
 

DO NOT REPLY [Bug 43343] - Loss of data and concurrency issue with Catalina session persistent storage

[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=43343





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 10:56 ---
I thought about marking this as a P1 as it could cause some very hard to track
down data loss in a web application. What is the difference between P1 and P2
for the Tomcat project?

-- 
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 43343] - Loss of data and concurrency issue with Catalina session persistent storage

[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=43343





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 11:09 ---
Using a plain Object to synchronize on rather than an Integer(0) would be very
slightly more efficient.


-- 
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 43344] New: - Misspelling in if.jsp example

[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=43344

   Summary: Misspelling in if.jsp example
   Product: Tomcat 6
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Examples
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/webapps/examples/jsp/tagplugin/if.jsp

--- if.jsp  (revision 574320)
+++ if.jsp  (working copy)
@@ -25,7 +25,7 @@
 
 Plugin Introductory Notes
 
-Brief Instructions for Wrieting Plugins
+Brief Instructions for Writing Plugins
  
 

-- 
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 42950] - ConcurrentModificationException on Shutdown

[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=42950





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 11:52 ---

We recently started using some axis2 services and started getting this issue on
shutdown.  It is not always repeatable by starting up tomcat (catalina.sh start)
then stopping tomcat (catalina.sh stop) - depends on thread timing.  Note that
when this exception is thrown, tomcat does not shutdown.

There appears to be some ThreadPoolExecutor.shutdown activity during shutdown of
axis2 that causes class loading.  This class loading activity happens while
tomcat is attempting to call WebappClassLoader.clearReferences.  In
clearReferences, resourceEntries.clone is called which causes the
ConcurrentModificationException to occur because of the conflicting call to
resourceEntries.put on line 2134.

The following patch to WebappClassLoader.java (of tomcat 5.5.23) worked for us:

@@ -1589,7 +1589,12 @@

 // Null out any static or final fields from loaded classes,
 // as a workaround for apparent garbage collection bugs
-Iterator loadedClasses = ((HashMap)
resourceEntries.clone()).values().iterator();
+HashMap resourceEntriesClone = null;
+synchronized(resourceEntries)
+{
+resourceEntriesClone = (HashMap) resourceEntries.clone();
+}
+Iterator loadedClasses = resourceEntriesClone.values().iterator();
 while (loadedClasses.hasNext()) {
 ResourceEntry entry = (ResourceEntry) loadedClasses.next();
 if (entry.loadedClass != null) {



-- 
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 42950] - ConcurrentModificationException on Shutdown

[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=42950


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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: [VOTE] Make released versions RTC

[Jim Jagielski]

How about:

   o CTR on trunk

   o Various release branches are made (ala httpd, apr, etc...).
 These include a STATUS file.

   o All code applied to the release branch is under
 lazy consensus but *must* be specified in STATUS.
 (eg: "I plan on applying rev786987 in 3 days under
 lazy consensus").

Not as stringent as RTC, but also provides a good level
of oversight with a minimum of overhead... RTC can be
maintained for older, stable releases.

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

Re: [VOTE] Make released versions RTC

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Mladen Turk wrote:
  

Remy Maucherat wrote:


To give an idea, "tis" could mean:
- API changing patches (any protected or above signature change)
- code changes in the critical path (for example, code which gets 
executed on each HTTP request)
  

Fine.


- any other commit for which a committer asks for the RTC procedure 
should be rollbacked if it hinders concurrent work, and go through the 
RTC procedure


  

This looks like a conditional veto that can be voted over. Perfect!
IIUC it means that instead veto one asks for a vote (+3 votes), right?
Looks like RTC on demand, that would require some sort of lazy consensus.


Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

This could get clarified a little bit more. I don't think asking for 
review is vetoing a patch, as there's no need to revert in most cases 
(one case would be a pending tag, or if it somehow causes immediate 
development conflicts). However, if a patch doesn't attract enough 
votes, or doesn't pass the +3 margin (if that's what gets accepted), it 
is considered vetoed and needs to be reverted.
  
this wouldn't work, the community is simply too small, we barely get 
enough vote to get a 5.5 release out the door as it is.

Filip

Rémy

-
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: [VOTE] Make released versions RTC

[Filip Hanik - Dev Lists]

Jim Jagielski wrote:

How about:

   o CTR on trunk

   o Various release branches are made (ala httpd, apr, etc...).
 These include a STATUS file.

   o All code applied to the release branch is under
 lazy consensus but *must* be specified in STATUS.
 (eg: "I plan on applying rev786987 in 3 days under
 lazy consensus").

Not as stringent as RTC, but also provides a good level
of oversight with a minimum of overhead... RTC can be
maintained for older, stable releases.
this is pretty much how tomcat development has worked, but with less 
obstacles to go around, ie the status file. instead folks applied the 
patch, updated the changelog and if anyone vetoed or objected, we'd 
revise it or pull it out.
We're pretty good about patches to release branches. I think all the -1 
in this voting thread are based on that, please correct me if I am wrong.


And as for CTR on trunk, that used to be the case, but we no longer have 
a trunk for reasons still unclear to me, other than personal.


Filip

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

Re: [VOTE] Make released versions RTC

[Yoav Shapira]

Hey,

On 9/10/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> How about:
>
> o CTR on trunk
>
> o Various release branches are made (ala httpd, apr, etc...).
>   These include a STATUS file.
>
> o All code applied to the release branch is under
>   lazy consensus but *must* be specified in STATUS.
>   (eg: "I plan on applying rev786987 in 3 days under
>   lazy consensus").
>
> Not as stringent as RTC, but also provides a good level
> of oversight with a minimum of overhead... RTC can be
> maintained for older, stable releases.

+1, fine by me.  As long as trunk is CTR, i.e. I can work fast on the
next release, it's fine by me.

Yoav

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

DO NOT REPLY [Bug 43343] - Loss of data and concurrency issue with Catalina session persistent storage

[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=43343





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 13:51 ---
Any reason not to use the Session object itself as the monitor?


-- 
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: [VOTE] Make released versions RTC

[Remy Maucherat]

Jim Jagielski wrote:

How about:

   o CTR on trunk

   o Various release branches are made (ala httpd, apr, etc...).
 These include a STATUS file.

   o All code applied to the release branch is under
 lazy consensus but *must* be specified in STATUS.
 (eg: "I plan on applying rev786987 in 3 days under
 lazy consensus").

Not as stringent as RTC, but also provides a good level
of oversight with a minimum of overhead... RTC can be
maintained for older, stable releases.


I don't see any difference with what happens at the moment, so since I 
think the current model has issues, it seems difficult for me to 
compromise on something even less than the ideas I just brought forward. 
I'll post a second vote eventually, and if it fails again, I think the 
Tomcat project should continue using the current model rather than come 
up with useless rules.


The main idea is that since there's only one trunk branch, there should 
be agreement on APIs and important topics to proceed, everything else 
should be in separate proposals. The mechanism also would work fine for 
release branches.


Rémy

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

DO NOT REPLY [Bug 43343] - Loss of data and concurrency issue with Catalina session persistent storage

[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=43343





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 14:23 ---
No real reason I can find. We might want to use an instance variable as the lock
just in case there are ever any other synchronized methods or sections added to
the session where the entire session is locked. That would help if those
synchronized session methods would need to be used by other threads and could be
accessed even during passivation. I only find one place where the session itself
is locked and that is in the expires method where a synchronized (this) is used.
 So, using the session itself would be OK for now, and it may logically work out
to be the case that no other action should ever be able to actually be made or
ever wanted on the session while it is being cached/passivated. I mentioned it
could be used as the lock in the my description some where. So, at least for
now, or always if deemed to always be wanted, I don't see any reason why it
itself can not be the lock.

-- 
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 40668] - MailSessionFactory is missing in Tomcat 5.5.23

[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=40668


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 16:51 ---
The recently released 5.5.25 contains the missing class files.

-- 
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: [VOTE] Make released versions RTC

[Mark Thomas]

Jim Jagielski wrote:
> How about:
> 
>o CTR on trunk
> 
>o Various release branches are made (ala httpd, apr, etc...).
>  These include a STATUS file.
> 
>o All code applied to the release branch is under
>  lazy consensus but *must* be specified in STATUS.
>  (eg: "I plan on applying rev786987 in 3 days under
>  lazy consensus").
> 
> Not as stringent as RTC, but also provides a good level
> of oversight with a minimum of overhead... RTC can be
> maintained for older, stable releases.

Still -1.

It provides no more oversight than RTC and adds the overhead of having
to update the status file 3 days before you can do anything. The
contents of the status file can be generated retrospectively from svn
if anyone finds it useful.

Mark


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

svn commit: r574429 - in /tomcat/site/trunk: docs/security-5.html xdocs/security-5.xml

[markt]

Author: markt
Date: Mon Sep 10 19:03:39 2007
New Revision: 574429

URL: http://svn.apache.org/viewvc?rev=574429&view=rev
Log:
Update fix in now 5.5.25 has been released

Modified:
tomcat/site/trunk/docs/security-5.html
tomcat/site/trunk/xdocs/security-5.xml

Modified: tomcat/site/trunk/docs/security-5.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-5.html?rev=574429&r1=574428&r2=574429&view=diff
==
--- tomcat/site/trunk/docs/security-5.html (original)
+++ tomcat/site/trunk/docs/security-5.html Mon Sep 10 19:03:39 2007
@@ -214,8 +214,8 @@
 
 
 
-
-Fixed in Apache Tomcat 5.5.HEAD, 5.0.HEAD
+
+Fixed in Apache Tomcat 5.5.25, 5.0.HEAD
 
 
 

Modified: tomcat/site/trunk/xdocs/security-5.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-5.xml?rev=574429&r1=574428&r2=574429&view=diff
==
--- tomcat/site/trunk/xdocs/security-5.xml (original)
+++ tomcat/site/trunk/xdocs/security-5.xml Mon Sep 10 19:03:39 2007
@@ -24,7 +24,7 @@
 
   
 
-  
+  
 low: Cross-site scripting
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2449";>
CVE-2007-2449



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

DO NOT REPLY [Bug 43350] New: - typo in "Web Application Compilation"

[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=43350

   Summary: typo in "Web Application Compilation"
   Product: Tomcat 6
   Version: 6.0.13
  Platform: Other
   URL: http://tomcat.apache.org/tomcat-6.0-doc/jasper-
howto.html#Web%20Application%20Compilation
OS/Version: other
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


There seems to be a copy paste error from tomcat5:



directory no longer exists.

-- 
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 43350] - typo in "Web Application Compilation"

[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=43350





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 21:14 ---
Furthermore, I noticed that my jspc target was missing some libraries.

I was able to fix this with


since the "jasper" task doesn't allow for nested classpath elements.

I defined the classpath of  stand-alone as this
"jspc.classpath"

-- 
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 43350] - typo in "Web Application Compilation"

[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=43350





--- Additional Comments From [EMAIL PROTECTED]  2007-09-10 21:20 ---
I furthermore got

  java.lang.NoClassDefFoundError: org/apache/commons/el/ExpressionEvaluatorImpl

until I copied commons-el.jar
  to ${tomcat.home}/lib
  

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