geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Making the jndi context builder (ENCConfigBuilder) pluggable
Date Tue, 29 Aug 2006 17:11:23 GMT
On the subject of data source reference strategies.  Let's say this is
the JPA plugin, and whatever it lists in the non-jta-data-source
element I will assume is the name of a database connection pool.  I
want to configure a GBean with a reference to this pool.

What I'm looking for is something like this:

String poolName = something.getNonJtaDataSource();
ConfigurationAwareReference ref =
ENCConfigBuilder.createResourceReference(configuration, poolName);
gbeanData.setAttribute("datasource", ref);

You seem to be suggesting that instead of the data source attribute, I
should create a reference to a ManagedConnectionFactory.  To do this,
I think I'd have to repeat all the code in ENCConfigBuilder to locate
the ManagedConnectionFactory in the current or parent Configurations,
then take apart whatever it gives me back on order to create an
AbstractNameQuery, then call setReference on the GBeanData with the
AbstractNameQuery.  That sounds more complicated to me compared to the
code above.  Plus, the using GBean has to call the method named
$getResource, which to me, is very unfortunate -- I take anything with
$ in the name as "I'm an internal, touch me at your own peril".

I would be a lot more comfortable with your approach if every
connector generated a GBean that implemented the connection factory
interface (e.g. DataSource) and I could map to that directly.  This
doesn't seem undoable.  :)

Thanks,
     Aaron

On 8/29/06, David Jencks <david_jencks@yahoo.com> wrote:
>
> 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
> >>
> >>
>
>

Mime
View raw message