Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 12322 invoked from network); 18 Aug 2007 21:22:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Aug 2007 21:22:01 -0000 Received: (qmail 48434 invoked by uid 500); 18 Aug 2007 21:21:58 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 48391 invoked by uid 500); 18 Aug 2007 21:21:58 -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 48380 invoked by uid 99); 18 Aug 2007 21:21:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Aug 2007 14:21:58 -0700 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: local policy) Received: from [69.147.95.93] (HELO smtp130.plus.mail.sp1.yahoo.com) (69.147.95.93) by apache.org (qpsmtpd/0.29) with SMTP; Sat, 18 Aug 2007 21:21:56 +0000 Received: (qmail 74185 invoked from network); 18 Aug 2007 21:21:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:From:Subject:Date:To:X-Mailer; b=kdQjoHIwtPzdXKWErA1g7gx/79bxkrwQ/GUukNIV4PkIU27FwSNvw6whIBtmTxH5ZbNtP4XPlhGElhN/sFa/owaHSAx+b5viBPsQ83PX2jJcgAAzrlhPBAqQZwBOTpRyzvkAn7xJEkIlcW+hiAVpsnjnpSNQe3QmylvRLfZeMe8= ; Received: from unknown (HELO ?192.168.1.106?) (david_jencks@67.102.173.8 with plain) by smtp130.plus.mail.sp1.yahoo.com with SMTP; 18 Aug 2007 21:21:33 -0000 X-YMail-OSG: lmTMgYkVM1khf6LD7sprmCMK9kBxp4AlB2neSMjq0KdkGRbCZKAkkNFZevjduHiWT_sosXKNlw-- Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <22DD243E-FAEA-43E9-B5CB-2AA56AEB3C83@yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-20-858987449 Message-Id: From: David Jencks Subject: Re: Remove [Mutable]InterceptorConfiguration for 1.5.1? Also some thread-safety concerns Date: Sat, 18 Aug 2007 14:21:41 -0700 To: "Apache Directory Developers List" X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-20-858987449 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Aug 18, 2007, at 12:14 PM, Alex Karasulu wrote: > I glad to see you involved and thinking about these issues and aspects > of the server David. I know we're going to gain a lot from your > knowledge > in these areas. > > With respect to the Spring discussions I think we hit a stalemate a > few > weeks back. I know I've spoken to both you and Chris about this > who feel > Spring can do much of what we would like to do. As you know my stance > is to avoid being dependent on Spring. > > However I think we have some idea of how we can remain container > independent > while still leveraging Spring. We still need some discussions on > this but I don't > think they're going to happen in the next 3 days. So maybe we're in danger of confusing 2 issues: 1. spring vs some other container. On this I don't care very much but I haven't seen anything proposed that is as easy to use, flexible, and non-invasive as spring. In any case surely 1.5.1 is going out with spring as the container. (my xbean-spring proposal fits under this item). Designing components to be container agnostic is a really good goal.... leading to 2. reasonable component design. To me this includes not putting container functionality into the components. Currently at least the [Mutable]InterceptorConfiguration classes are definitely mostly doing stuff that should be done by the container, whatever it might end up being. One result is really ugly spring configuration. I'm proposing to work on (2) a bit, I think it would make the server.xml quite a bit more comprehensible both for plain spring and xbean-spring versions of server.xml > > Keep in mind 1.5.1 is a feature release where we're just releasing > to get feature > regardless of stability into the hands of our users. We can > release at any point > in time again thereafter so don't feel pressured to pump your > changes into this > release. well, I think the geronimo directory plugin will probably get released against 1.5.1 and the interceptor configuration is really bugging me and I have a couple extra hours.... so I thought I'd see what I could do here. thanks david jencks > > Alex > > On 8/18/07, David Jencks wrote: > A while back there was some discussion about just how much container > functionality apacheds needs to duplicate for spring, and IIUC there > was general agreement that [Mutable]InterceptorConfiguration could be > replaced by just letting the container create the interceptors > directly. > > I started looking at this issue this morning and think it would be > pretty easy to fix so I'm wondering if there's any chance it could > get into 1.5.1. > > I also see what looks to me like double-checked-locking problems with > InterceptorChain setting up the chain of Entry objects. IIUC there > are a bunch of methods to insert,remove, etc interceptors in the > running server but the actual code that traverses the interceptor > chain is not at all synchronized. This is a double-checked-locking > scenario and can lead to the live interceptor chain using > incompletely initialized interceptor objects. The usual fix nowadays > for such problems is to make the variables pointing to the possibly > incompletely initialized objects volatile. IIUC this would be the > InterceptorChain.Entry prevEntry and nextEntry fields. > > AFAICT the runtime change-the-chain methods are not called in the > apacheds code base at the moment, so I think an acceptable > alternative would be to remove those methods and rely on no one > starting to use the server until it's fully initialized. This would > involve removing the InterceptorChain addFirst, addLast, addBefore, > addAfter methods. > > > OK... back to the how-much-extra-wrapping question. > > I haven't started to code yet but I think the best solution for now > will be to: > > - In each interceptor class that actually uses an interceptor > configuration, replace that with individual attributes (I think only > the replication interceptor has any attributes at the moment) > - remove the InterceptorConfiguration cfg argument from > Interceptor.init > > At this point we won't need InterceptorConfiguration any more, the > container (spring) can create the interceptors itself, and > InterceptorChain will get a list of interceptors it needs to > initialize rather than a list of InterceptorConfigurations. > > thanks > david jencks > > > > --Apple-Mail-20-858987449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Aug 18, 2007, = at 12:14 PM, Alex Karasulu wrote:

I glad to = see you involved and thinking about these issues and aspects
of the = server David.=A0 I know we're going to gain a lot from your = knowledge
in these areas.

With respect to the Spring = discussions I think we hit a stalemate a few
weeks back.=A0 I know = I've spoken to both you and Chris about this who feel
Spring can do = much of what we would like to do.=A0 As you know my stance
is to = avoid being dependent on Spring.=A0

However I think we have some = idea of how we can remain container independent
while still = leveraging Spring.=A0 We still need some discussions on this but I = don't
think they're going to happen in the next 3 = days.

So = maybe we're in danger of confusing 2 issues:

1. spring vs some other = container.=A0 On this I don't care very much but I haven't seen anything = proposed that is as easy to use, flexible, and non-invasive as spring.=A0 = In any case surely 1.5.1 is going out with spring as the container. (my = xbean-spring proposal fits under this item).=A0 Designing components to = be container agnostic is a really good goal.... leading to

2. reasonable component = design.=A0 To me this includes not putting container functionality into = the components.=A0 Currently at least the = [Mutable]InterceptorConfiguration classes are definitely mostly doing = stuff that should be done by the container, whatever it might end up = being.=A0 One result is really ugly spring configuration.

I'm proposing to work on = (2) a bit, I think it would make the server.xml quite a bit more = comprehensible both for plain spring and xbean-spring versions of = server.xml

Keep in mind 1.5.1 is a = feature release where we're just releasing to get feature
regardless = of stability into the hands of our users.=A0 We can release at any = point
in time again thereafter so don't feel pressured to pump your = changes into this
release.=A0

well, I think the geronimo = directory plugin will probably get released against 1.5.1 and the = interceptor configuration is really bugging me and I have a couple extra = hours.... so I thought I'd see what I could do here.

thanks
david = jencks


Alex

On 8/18/07, David = Jencks <david_jencks@yahoo.com> = wrote:
A while back there was some discussion about just how much = container
functionality apacheds needs to duplicate for spring, and = IIUC there
was general agreement that = [Mutable]InterceptorConfiguration could be
replaced by just letting = the container create the interceptors directly.

I started = looking at this issue this morning and think it would be
pretty easy = to fix so I'm wondering if there's any chance it could
get into = 1.5.1.

I also see what looks to me like double-checked-locking = problems with
InterceptorChain setting up the chain of Entry = objects.=A0=A0IIUC there
are a bunch of methods to insert,remove, etc = interceptors in the
running server but the actual code that traverses = the interceptor
chain is not at all synchronized.=A0=A0This is a = double-checked-locking
scenario and can lead to the live interceptor = chain using
incompletely initialized interceptor objects.=A0=A0The = usual fix nowadays
for such problems is to make the variables = pointing to the possibly
incompletely initialized objects = volatile.=A0=A0IIUC this would be the
InterceptorChain.Entry = prevEntry and nextEntry fields.

AFAICT the runtime = change-the-chain methods are not called in the
apacheds code base at = the moment, so I think an acceptable
alternative would be to remove = those methods and rely on no one
starting to use the server until = it's fully initialized.=A0=A0This would
involve removing the = InterceptorChain addFirst, addLast, addBefore,
addAfter = methods.


OK... back to the how-much-extra-wrapping question. =

I haven't started to code yet but I think the best solution for = now
will be to:

- In each interceptor class that actually uses = an interceptor
configuration, replace that with individual attributes = (I think only
the replication interceptor has any attributes at the = moment)
- remove the InterceptorConfiguration cfg argument from = Interceptor.init

At this point we won't need = InterceptorConfiguration any more, the
container (spring) can create = the interceptors itself, and
InterceptorChain will get a list of = interceptors it needs to
initialize rather than a list of = InterceptorConfigurations.

thanks
david jencks

=



= --Apple-Mail-20-858987449--