Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:From:Subject:Date:To:X-Mailer;
  b=48/y/3nRLMDBrgMVe0kiKkyrXEqCj9NiVJyZl+jBunab/nhOQ06ObWMQByHiqCcFv0U9PlqDUF6w0hyZFVZJ1W0joYOqqw/vofcW0X8iKN2UJgWZmjfHvfx8BldNv9duzmWEHP34dIHxlzN+qJ64Hq6STm8RvrGvJalUgSu63uw=
  ;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <a32f6b020707152003t684f4a0ibb15d50d58d1556c@mail.gmail.com>
References: <a32f6b020707152003t684f4a0ibb15d50d58d1556c@mail.gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-12-255103615
Message-Id: <5F70BBD0-BC5F-46D2-B98D-D4CC23AF5C50@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: [ApacheDS] [CiDIT] Discussion
Date: Tue, 17 Jul 2007 18:05:33 -0700
To: "Apache Directory Developers List" <dev@directory.apache.org>


--Apple-Mail-12-255103615
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Jul 15, 2007, at 8:03 PM, Alex Karasulu wrote:

> Hi all,
>
> Here's that thread on discussing the CiDIT agenda. Let's take a  
> look at the following
> link before beginning:
>
>     http://directory.apache.org/apacheds/1.5/configuration-in-dit- 
> cidit.html
>
> Thoughts? Comments?

Yikes, I'm afraid this will take 6 months to a year to do, and unless  
you write "jdo for ldap", including an enhancer, I think its' going  
to be pretty painful to add new configuration elements.

Someone suggested a while back that we avoid the "jdo for ldap"  
problem by just storing server.xml in ldap as text.  IIUC this could  
be done in a couple of days.  Exactly how much really useful  
functionality would this lose compared to the fine grained approach?

What if each component/bean configuration were stored as xml text  
separately, each with a (unique) name, and the links were determined  
by the names?

BTW, unless you write a fancy dependency tracking system (i.e. the  
geronimo kernel) I think that any change basically requires stopping  
and restarting the server, so I'm not sure there is really much  
advantage to splitting up each bean separately.

And finally, why are there all these configuration objects that  
spring creates that then go and create the actual runtime objects,  
rather than having spring create the runtime object directly?  In  
particular, why is there an interceptor configuration object rather  
than just interceptors?

Are you finding that Spring has some limitations that you are running  
into?  Otherwise why eliminate it?

thanks
david jencks

>
> Alex
>


--Apple-Mail-12-255103615
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jul 15, 2007, =
at 8:03 PM, Alex Karasulu wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite">Hi =
all,<BR><BR>Here's that thread on discussing the CiDIT agenda. Let's =
take a look at the following<BR>link before beginning:<BR><BR>=A0=A0=A0 =
<A =
href=3D"http://directory.apache.org/apacheds/1.5/configuration-in-dit-cidi=
t.html"> =
http://directory.apache.org/apacheds/1.5/configuration-in-dit-cidit.html</=
A><BR><BR>Thoughts? Comments?<BR></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Yikes, I'm afraid this will =
take 6 months to a year to do, and unless you write "jdo for ldap", =
including an enhancer, I think its' going to be pretty painful to add =
new configuration elements.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Someone suggested a while =
back that we avoid the "jdo for ldap" problem by just storing server.xml =
in ldap as text.=A0 IIUC this could be done in a couple of days.=A0 =
Exactly how much really useful functionality would this lose compared to =
the fine grained approach?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>What if each component/bean =
configuration were stored as xml text separately, each with a (unique) =
name, and the links were determined by the names?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>BTW, unless you write a =
fancy dependency tracking system (i.e. the geronimo kernel) I think that =
any change basically requires stopping and restarting the server, so I'm =
not sure there is really much advantage to splitting up each bean =
separately.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>And=
 finally, why are there all these configuration objects that spring =
creates that then go and create the actual runtime objects, rather than =
having spring create the runtime object directly?=A0 In particular, why =
is there an interceptor configuration object rather than just =
interceptors?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Are you finding that Spring =
has some limitations that you are running into?=A0 Otherwise why =
eliminate it?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>thanks</DIV><DIV>david =
jencks</DIV><BR><BLOCKQUOTE =
type=3D"cite"><BR>Alex<BR><BR></BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-12-255103615--