From geronimo-dev-return-1136-apmail-incubator-geronimo-dev-archive=incubator.apache.org@incubator.apache.org Wed Aug 13 16:59:57 2003 Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 43681 invoked by uid 500); 13 Aug 2003 16:59:56 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 43571 invoked from network); 13 Aug 2003 16:59:55 -0000 Received: from saturn.opentools.org (HELO www.princetongames.org) (66.250.40.202) by daedalus.apache.org with SMTP; 13 Aug 2003 16:59:55 -0000 Received: from localhost (ammulder@localhost) by www.princetongames.org (8.11.6/8.11.6) with ESMTP id h7DIWbg31389 for ; Wed, 13 Aug 2003 14:32:37 -0400 X-Authentication-Warning: www.princetongames.org: ammulder owned process doing -bs Date: Wed, 13 Aug 2003 14:32:36 -0400 (EDT) From: Aaron Mulder X-X-Sender: ammulder@www.princetongames.org To: geronimo-dev@incubator.apache.org Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier) In-Reply-To: <20030813164909.47387.qmail@web41207.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N What spec are you talking about? There is no spec for a verifier to adhere to. The spec that a deployer could concievably adhere to says nothing about verification, or about the specific representation of server-specific information. I'm not sure how you can take these two components and "strictly adhere to the spec" for both of them. And for deployment, it isn't really an option to have a JSR-88 implementation that doesn't "strictly adhere to the spec" any more that we could have a non-compliant EJB container or web container. Aaron On Wed, 13 Aug 2003, Labeeb Syed wrote: > The primary issue I am concerned with is J2EE compliance. The Deploy > component should be able to delegate certain methods to the Verifier > component without a change in its own behavior. If we worry about the > deployment manager later, it will be a lot more troublesome and cause > some major confusion in terms of behaviour and responsibilty of the > various methods. Do you guys think we can get by and address such issues > later on? > > Secondly, there seems there will be an inherent overlapping of > responsibilities within the components. I have run into such issues > before and would like to avoid it altogether if possible. Sometimes you > end up re-coding and re-designing the whole component. Also in the > future someone else might be going through the code, it may make it more > difficult to enhance, test or debug the components. If we strictly > adhere to the spec, it will ensure better maintainability and longevity. > This my opinion in regards to the two components.