Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 49278 invoked from network); 12 Mar 2008 17:46:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Mar 2008 17:46:03 -0000 Received: (qmail 15798 invoked by uid 500); 12 Mar 2008 17:45:59 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 15460 invoked by uid 500); 12 Mar 2008 17:45:58 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 15445 invoked by uid 99); 12 Mar 2008 17:45:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Mar 2008 10:45:58 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jgawor@gmail.com designates 209.85.162.183 as permitted sender) Received: from [209.85.162.183] (HELO el-out-1112.google.com) (209.85.162.183) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Mar 2008 17:45:21 +0000 Received: by el-out-1112.google.com with SMTP id y26so1657454ele.4 for ; Wed, 12 Mar 2008 10:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2Hm9pmlmR7sT60Yq7ib1RdhMngaQg8bsDc8aBf6fFrs=; b=oauYORy0OLz2CVAgNydRB3MPmRECbukae81aw+ympgAAgvfAj+45V20P228yJNp+betOwmm18u6X/sYucqyojzILuGyuS/IMPpiTvuA2NR4i94WjtDu9IF/Nhzye+GQHHWG1jFuJ74aQDvQ4fxAdc/EOzMxSLJX9MLC9wOCxaDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XPTyh09N1YupdquhNAYK3OBrC8qW3fIhwG2Oj+hv4vX2rn0Fb6P3QJXNl3vrmP0veuupwFCDk9auFpo6eseC8FC8ET1Pbk8AIXD2LksH9QM3cBBqkeOxoQD4GHF2SZrGYb0AdvIzAz1/6YOq6ZxteNWoNzI8Gm8blFQAqD11leE= Received: by 10.115.18.1 with SMTP id v1mr7529619wai.81.1205343903356; Wed, 12 Mar 2008 10:45:03 -0700 (PDT) Received: by 10.114.79.8 with HTTP; Wed, 12 Mar 2008 10:45:03 -0700 (PDT) Message-ID: <5eb405c70803121045v1387c2b0oc0c646ec32e5a512@mail.gmail.com> Date: Wed, 12 Mar 2008 13:45:03 -0400 From: "Jarek Gawor" To: dev@geronimo.apache.org Subject: Re: module builders/deployers in plugins In-Reply-To: <0AD7BB9A-2148-41CF-8B8E-C091AA996CD7@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5eb405c70802201212l7a938e1o12f390fac7e1fb98@mail.gmail.com> <5eb405c70803110915v6ddbb791j438a42697fb03328@mail.gmail.com> <0AD7BB9A-2148-41CF-8B8E-C091AA996CD7@yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org > >> 2) The AdminObjectRefBuilder is always trying to process _all_ > >> resource-env-ref entries (AdminObjectRefBuilder is just an > >> example in > >> this case). However, as things evolve (Java EE 5 -> 6) and new > >> resource env. types are added, it does not scale to keep updating > >> the > >> AdminObjectRefBuilder to handle these new types. So I think it would > >> be nice to install a new builder that would handle these new types > >> only. But that would require communicating with the > >> AdminObjectRefBuilder and somehow telling it to ignore the new > >> types. > >> The question is, what would be the best way of doing it? Or maybe we > >> need a different way of processing the DDs? > > This is kind of a tricky problem and I don't know the best way to > handle it. I doubt you want to get into rewriting the entire way we > resolve resource-env-refs at this point -- let me know if you do -- > so I would look into exactly what is keeping the current > AdminObjectRefBuilder from handling your new kinds of refs and > whether there is an easy way to exclude them. > > Some possibilities.... > - the AdminObjectRefBuilder.AdminObjectRefProcessor picks out the > annotations we will look at. If the new stuff can only be referred > to as @Resource you can have the AdminObjectRefProcessor skip the new > kinds. > - basically the AdminObjectRefBuilder works by finding a gbean that > corresponds to the name information and type information supplied, > around line 373. We could expand the choices for how we look for > target gbeans. > - we might be able to make the NamingBuilderCollection ordered and > have the builders not try to deal with questionable items that have > already been processed. I tried the last option. Specifically, I modified the AdminObjectRefBuilder to ignore elements that were already added to the jndi context map (assuming the NamingBuilderCollection would be ordered and that my builder would execute before the AdminObjectRefBuilder). However, since both Builders process the same type of elements in the DDs the NamingBuilderCollection did not like that and I got the following exception: 3:01:30,421 ERROR [ProxyCollection] Listener threw exception java.lang.IllegalArgumentException: Duplicate builderSpecQNames in builder set: QNameSet+(+resource-env-ref@http://java.sun.com/xml/ns/javaee, +resource-env-ref@http://java.sun.com/xml/ns/j2ee) and duplicate builderPlanQNames in builder set : QNameSet+(+resource-env-ref@http://geronimo.apache.org/xml/ns/naming-1.2) So this option would work only if I disabled this check or returned some other qnames for builderSpecQNames and builderPlanQNames in my builder. Also, I could create a new switching builder for processing the resource-env-ref elements and have it just basically redirect the calls to the AdminObjectRefBuilder and my builder (to avoid the above error) and combine it with the last option you described. Jarek