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 <[EMAIL PROTECTED]> 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
