Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 84528 invoked from network); 2 Nov 2004 00:07:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 2 Nov 2004 00:07:00 -0000 Received: (qmail 83024 invoked by uid 500); 2 Nov 2004 00:06:53 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 82981 invoked by uid 500); 2 Nov 2004 00:06:52 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@geronimo.apache.org Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 82967 invoked by uid 99); 2 Nov 2004 00:06:52 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [66.250.40.202] (HELO saturn.opentools.org) (66.250.40.202) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 01 Nov 2004 16:06:52 -0800 Received: by saturn.opentools.org (Postfix, from userid 500) id 337FD3ED5; Mon, 1 Nov 2004 19:09:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by saturn.opentools.org (Postfix) with ESMTP id 2C328F5C1 for ; Mon, 1 Nov 2004 19:09:38 -0500 (EST) Date: Mon, 1 Nov 2004 19:09:38 -0500 (EST) From: Aaron Mulder X-X-Sender: ammulder@saturn.opentools.org To: dev@geronimo.apache.org Subject: Re: Jetty Security Realms In-Reply-To: <6ABF7002-2BB8-11D9-A78B-000D93361CAA@gluecode.com> Message-ID: References: <6ABF7002-2BB8-11D9-A78B-000D93361CAA@gluecode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Sun, 31 Oct 2004, David Jencks wrote: > This is somewhat beyond my knowledge, but... > > 1. If its easier, we could deploy an additional gbean for the realm > along with the JettyWebAppContext: the configuration would be generated > by the JettyModuleBuilder. Basically I'm thinking that you should deploy one GBean to make the realm exist. Then any other stuff should be handled by the JettyModuleBuilder. > 2. We're going to need to do something so we are deploying gbeans for > servlets, and do this fairly soon. This is going to involve fairly > extensive changes to how we deploy web apps. What is your guess on the > impact of this on your proposal? I don't think this will impact my proposal. I'm suggesting that we add some functionality to override the defaults in the JettyWebAppContext. You're suggesting that we add some functionality to override the default servlet construction for servlets in the JettyWebAppContext. I think these proposals are similar. The only possible problem I see is that I will still be depending on the default Jetty authentication process (just changing how it picks the realm to authenticate against). If the servlet changes are so extensive that they alter how servlet invocations perform authentication, then we'd have to make sure the "new authentication process" identifies the correct realm to use. But at that point we'd be talking about Geronimo code to Geronimo code, so it shouldn't be a big deal. Aaron