Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 93451 invoked from network); 7 Oct 2004 05:16:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 7 Oct 2004 05:16:11 -0000 Received: (qmail 35974 invoked by uid 500); 7 Oct 2004 05:15:54 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 35931 invoked by uid 500); 7 Oct 2004 05:15:53 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 35911 invoked by uid 99); 7 Oct 2004 05:15:53 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 06 Oct 2004 22:15:50 -0700 Received: (qmail 646 invoked by uid 50); 7 Oct 2004 05:17:46 -0000 Date: 7 Oct 2004 05:17:46 -0000 Message-ID: <20041007051746.644.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3 X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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=4690 sessions not scoped according to spec section 7.3 ------- Additional Comments From ddewolf@apache.org 2004-10-07 05:17 ------- Can you provide some insight on why your interpretation is that this session is a mere shadow? What use would a session be if it can't be retrieved later on for use by subsequent requests? Can you provide any ideas on how we can meet the requirements of the portlet specification's Application Scoped attributes (15.3) with your interpretation. I'm not necessarily a fan of cross context apps either, however, our issue is that we're trying to implement a specification which *seems* to require a different interpretation of the servlet spec than yours. Any help would be greatly appreciated. --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org