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 16:27:54 GMT
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?
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?

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).

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).

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