From geronimo-dev-return-3155-apmail-incubator-geronimo-dev-archive=incubator.apache.org@incubator.apache.org Fri Sep 05 07:38:27 2003 Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@www.apache.org Received: (qmail 20943 invoked from network); 5 Sep 2003 07:38:27 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 5 Sep 2003 07:38:27 -0000 Received: (qmail 3911 invoked by uid 500); 5 Sep 2003 07:37:31 -0000 Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 3844 invoked by uid 500); 5 Sep 2003 07:37:31 -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 3828 invoked from network); 5 Sep 2003 07:37:30 -0000 Received: from unknown (HELO public.coredevelopers.net) (209.233.18.245) by daedalus.apache.org with SMTP; 5 Sep 2003 07:37:30 -0000 Received: from coredevelopers.net (dsundstrom-host236.dsl.visi.com [208.42.65.236]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by public.coredevelopers.net (Postfix on SuSE Linux 8.0 (i386)) with ESMTP id 4CC187586 for ; Fri, 5 Sep 2003 00:29:54 -0700 (PDT) Date: Fri, 5 Sep 2003 02:36:51 -0500 Subject: Re: [XML Parsing] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Dain Sundstrom To: geronimo-dev@incubator.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N The reflective mapping is build inside the running container on the server side during startup and is private to the container. Clients never see it, so you have nothing to worry about. -dain On Friday, September 5, 2003, at 01:03 AM, Sagenschneider, Daniel A wrote: > Hi all, > > I've just joined the mailing list and have read the last few messages > relating to matching to target methods (I assume this to be the client > calls on the EJB interfaces to matching target methods of the EJBs - > please correct me if I'm wrong). > > To put a vote against reflective mapping, Sun specs indicate that the > EJBs are to be referenced via their interfaces for extended periods of > times (it indicates potentially years). If a reflective mapping were > to be utilised, it would allow the loose coupling to have the EJBs > upgraded on the server (with potentially changing interfaces) thus > allowing the client to continuously access the EJBs. > > The other potential is to formulate a naming system that can cater to > versioning of the EJB interfaces, which will ultimately require having > to uniquely identify overloaded methods (i.e. complete method > signatures) - this may be as expensive to decode as it would take the > lookup reflectively. > > NOTE: if tight coupling between Server EJB version and Client EJB > version is required then this will not be an issue. > > Regards, > Daniel Sagenschneider > > /************************* * Dain Sundstrom * Partner * Core Developers Network *************************/