From dev-return-24094-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Fri Mar 07 18:11:51 2008 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 43434 invoked from network); 7 Mar 2008 18:11:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Mar 2008 18:11:51 -0000 Received: (qmail 96322 invoked by uid 500); 7 Mar 2008 18:11:47 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 96116 invoked by uid 500); 7 Mar 2008 18:11:47 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 96105 invoked by uid 99); 7 Mar 2008 18:11:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Mar 2008 10:11:46 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 64.233.184.233 as permitted sender) Received: from [64.233.184.233] (HELO wr-out-0506.google.com) (64.233.184.233) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Mar 2008 18:11:11 +0000 Received: by wr-out-0506.google.com with SMTP id c48so232910wra.1 for ; Fri, 07 Mar 2008 10:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=HS0NbrBN4ALU+eHzoVlBN0eMpyxwGIUTE+HzI/Q6eBI=; b=W1QlbxIfNaiynmdiNO/bRzyod1Oq35V2Y6k/p38aHJBODhgBbCFA+ZhGSEFIw3dSIZjjfInu27jPPhZvgIjGoDJiw7ullF0zlsYqjBR70DIiDIFO5kqZ1Katqu96bg+sNr3QPBUSjJqO+7HvnsE5JCklNgoaOkUHiXgQjdgKQuk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=hBNCiJtA/TFvk7Tp9XPpMwUgvbUzoeoK0fz3M6LBOAerQjLf/zXtcFfTSCQNubC1RbRMLJTqxIbrWutJl1X4nUbMrl/nnDiSZUB/Oz/d5fKdYKKbij8aEIZsV5bbQAmFN+Y9D7SdSPV+AXdbyFe7xZBpxghJcmBU62nyh2iHNiY= Received: by 10.140.171.4 with SMTP id t4mr765374rve.230.1204913480069; Fri, 07 Mar 2008 10:11:20 -0800 (PST) Received: by 10.115.76.4 with HTTP; Fri, 7 Mar 2008 10:11:20 -0800 (PST) Message-ID: Date: Fri, 7 Mar 2008 13:11:20 -0500 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: Re: [Configuration] Suppose EMF is Used... In-Reply-To: <47D0C577.3040501@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_38371_13962848.1204913480073" References: <47D0C577.3040501@gmail.com> X-Google-Sender-Auth: c268238281d81f26 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_38371_13962848.1204913480073 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is acceptable as long as we can separate it as another way to wire the server together. It cannot impose specifics on the components themselves. This way there is no direct dependence on the wiring technology be it Spring, EMF or OSGi. Alex On Thu, Mar 6, 2008 at 11:32 PM, Ole Ersoy wrote: > Hey Guys, > > One thing that needs to be voted on is whether it is acceptable for > components to receive configuration data from a general context object. > WIth a EMF based approach the server would first load server.xml, > instantiating all the Beans modeled in apacheds-xbean-spring.xsd. If you > follow the tutorial / trace I sent out earlier, you'll see how there are > generated. As EMF loads server.xml it creates and binds server.xml to > instances of these classes. These instances would then have to be made > available to other components via a server context object. So the server > startup process would be something like this: > > - Load server.xml > - Get root configuration object from EMF Resource > (Metaphor for server.xml) > and place it on the server context > - Create all other server components, providing them with a reference > to the server context > > So the question is "Is this acceptable?". > > Thanks, > - Ole > > ------=_Part_38371_13962848.1204913480073 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is acceptable as long as we can separate it as another way to wire the server together.  It cannot impose specifics on the components themselves.  This way there is no direct dependence on the wiring technology be it Spring, EMF or OSGi.

Alex

On Thu, Mar 6, 2008 at 11:32 PM, Ole Ersoy <ole.ersoy@gmail.com> wrote:
Hey Guys,

One thing that needs to be voted on is whether it is acceptable for components to receive configuration data from a general context object.  WIth a EMF based approach the server would first load server.xml, instantiating all the Beans modeled in apacheds-xbean-spring.xsd.  If you follow the tutorial / trace I sent out earlier, you'll see how there are generated.  As EMF loads server.xml it creates and binds server.xml to instances of these classes.  These instances would then have to be made available to other components via a server context object.  So the server startup process would be something like this:

- Load server.xml
- Get root configuration object from EMF Resource
 (Metaphor for server.xml)
 and place it on the server context
- Create all other server components, providing them with a reference
 to the server context

So the question is "Is this acceptable?".

Thanks,
- Ole


------=_Part_38371_13962848.1204913480073--