Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v749.3)
In-Reply-To: <74e15baa0608290927x18f08ac0v2e56e92c6b8efa6d@mail.gmail.com>
References: <DFA35682-B8ED-46CF-9C4C-6F9D0D71F25D@yahoo.com>
 <74e15baa0608290927x18f08ac0v2e56e92c6b8efa6d@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9061886F-F681-4897-AA81-9738ED3A40C5@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Making the jndi context builder (ENCConfigBuilder) pluggable
Date: Tue, 29 Aug 2006 12:48:29 -0400
To: dev@geronimo.apache.org


On Aug 29, 2006, at 12:27 PM, Aaron Mulder wrote:

> On the conceptual level, it sounds like a builder will be invoked and
> given the opportunity to look through available elements and see if it
> should process any of them?  Are namespaces used or ignored?

About the same as the current NamespaceDrivenBuilder.... namespaces  
are used, it is xml after all, but as far as the framework goes you  
register for the QNames you intend to handle but no one checks that  
you only look at them.

> Specifically, will this increase in any way the number of places that
> namespaces are mandatory and our XML processors won't be able to
> automatically apply them if the user leaves them off?

I don't think so.  Are you aware of the mechanism for registering new  
automatic namespace conversions in SchemaConversionUtils?  You can  
have a builder for something register element converters for  
particular local element names.

>
> On the implementation level, it would be nice if the API for adding
> refs (GBean refs, EJB refs, etc.) had two options -- one plural where
> you give it XML objects for it to process (returning e.g. a Map), and
> one singular where you just give it a bunch of specific data elements
> (returning a ConfigurationAwareReference), and the first calls the
> second in a loop.  In using plugins, sometimes I use different
> elements than J2EE uses to achieve the same thing (e.g. combine the
> settings normally in J2EE plan and Geronimo plan into one place, or
> limit the mapping options).  It's also nice to be able to use this
> plumbing to generate a ConfigurationAwareReference even if you're not
> going to be putting it into JNDI (e.g. to give some GBean a convenient
> reference to a database connection pool).

I'll think about this.  Why don't you use a plain GBean reference to  
a ManagedConnectionFactoryWrapper for this particular case?

>
> Finally, I'm not thrilled by the number of deployer-specific objects
> required by the current ENCConfigBuilder -- RefContext,
> DeploymentContext, Configuration, and so on.  If this could be reduced
> to more elemental things like ClassLoader or specific data elements
> that would lessen the make-work for a plugin (where it currently needs
> to spend some time creating throwaway objects just to pass them to the
> ENCConfigBuilder).

I suspect the real pain here is generating psuedo-xml to pass into  
the builders.  I'll review, but I think the objects needed by my new  
code are actually reasonable.

I think what you'd actually like is a way to feed pojos in and get a  
Reference back out, although as mentioned above I tend to think a  
plain gbean reference is often a better approach.

thanks
david jencks

>
> Thanks,
>     Aaron
>
> On 8/29/06, David Jencks <david_jencks@yahoo.com> wrote:
>> in order to get the persistence contexts into jndi I'm working on a
>> way to restructure ENCConfigBuilder so it's like (not identical, but
>> similar in concept to) a NamespaceDrivenBuilderCollection + a bunch
>> of NamespaceDrivenBuilders, one registered for each kind of jndi
>> entry.  In particular I'm making the gbean-ref type into an abstract
>> element + substitution group, which is the particular part I need for
>> cm jpa.  When I get this part working I'm going to look into making
>> all the other bits (ejb refs etc) work the same way.  I hope to have
>> some code to look at in the next couple days, but I thought I'd tell
>> everyone where I'm headed.
>>
>> In a little more detail, this would involve a set of builders each
>> pulling the elements they wanted to look at from the spec dd and the
>> plan, and using them to add stuff to the jndi context.  I think I can
>> make sure that there's a builder registered for each spec type so we
>> can more or less assure that no spec env entries will be ignored.
>>
>> Does this seem like a good idea?
>>
>> thanks
>> david jencks
>>
>>