Refactoring the naming builder

[David Jencks <da...@yahoo.com>]

I've completed what I think is essential in my naming builder  
refactoring, http://issues.apache.org/jira/browse/GERONIMO-2383.  I  
think this or something similar is needed to get the jpa support in  
and probably for easy partial integration of jee5 features.

I've described whats going on in the jira issue, repeating it here:

Here's the idea: there's a lot of code changes, but the idea is  
pretty simple.

There's a new interface, NamingBuilder, with a bunch of phases like  
the ModuleBuilder interface.

     * buildEnvironment. The NamingBuilder can determine if it's  
needed and add to the modules environment. For instance, the openejb  
client ref builder can add openejb to an app client if there are ejb  
refs (and openejb is deployed)

     * initContext. This one is a little fishy, but seems to be  
needed to track message-destinations. I don't have any other uses for  
it yet.

     * buildNaming. Here the naming builder actually extracts the xml  
it is interested in from the specDD and the plan, constructs whatever  
it wants to put into jndi, and adds it to a map that will be  
serialized and used to build the jndi context when the app starts up.

In addition, there are two registration methods, where the builder  
reports which spec and plan qnames it intends to deal with. The  
builder is responsible for extracting only these elements itself, but  
the next class assures that well-behaved builders don't conflict.

So, there are lots and lots of these naming builders, for env  
entries, resource-refs, service-refs, etc etc. Generally the code in  
these is moved from ENCConfigBuilder, RefContext, and the module  
builders or old module-specific ref builders. There certainly aren't  
any new ideas in these builders.

The other new class is NamingBuilderCollection which has a collection  
of NamingBuilders and also implements NamingBuilder: when you call  
one of these methods it iterates through the collection in the  
obvious way. Also, it collects the qname sets from the builders and  
makes sure they don't conflict.

I've attempted to remove the changes in the jta11/jpa issue. There's  
a very high likelyhood this patch won't apply cleanly because it  
involves a lot of file moves.

This code is going to be very amenable to code rot so please don't  
waste my time updating for other changes and review and VOTE NOW.
[ Show » ]
David Jencks [09/Sep/06 01:16 PM] I think this is ready to commit.  
Please vote. Here's the idea: there's a lot of code changes, but the  
idea is pretty simple. There's a new interface, NamingBuilder, with a  
bunch of phases like the ModuleBuilder interface.

     * buildEnvironment. The NamingBuilder can determine if it's  
needed and add to the modules environment. For instance, the openejb  
client ref builder can add openejb to an app client if there are ejb  
refs (and openejb is deployed)

     * initContext. This one is a little fishy, but seems to be  
needed to track message-destinations. I don't have any other uses for  
it yet.

     * buildNaming. Here the naming builder actually extracts the xml  
it is interested in from the specDD and the plan, constructs whatever  
it wants to put into jndi, and adds it to a map that will be  
serialized and used to build the jndi context when the app starts up.

In addition, there are two registration methods, where the builder  
reports which spec and plan qnames it intends to deal with. The  
builder is responsible for extracting only these elements itself, but  
the next class assures that well-behaved builders don't conflict. So,  
there are lots and lots of these naming builders, for env entries,  
resource-refs, service-refs, etc etc. Generally the code in these is  
moved from ENCConfigBuilder, RefContext, and the module builders or  
old module-specific ref builders. There certainly aren't any new  
ideas in these builders. The other new class is  
NamingBuilderCollection which has a collection of NamingBuilders and  
also implements NamingBuilder: when you call one of these methods it  
iterates through the collection in the obvious way. Also, it collects  
the qname sets from the builders and makes sure they don't conflict.

I've attempted to remove the changes in the jta11/jpa issue. There's  
a very high likelyhood this patch won't apply cleanly because it  
involves a lot of file moves.

This code is going to be very amenable to code rot so please don't  
waste my time updating for other changes and review and VOTE NOW.

There are a couple of things I think might be improved:

- add a set of required qnames to the NamingBuilderCollection.  This  
could assure that a builder is registered for each jndi qname in the  
spec dd.  This basically requires writing a qname set property editor  
or xml attribute builder.  I'd like to do this as a bug fix after  
applying what I have so far.

- I'm a little worried about the initContext method since it is  
called with a different part of the specDD for ejbs than the other  
two methods to pick up the message-destinations from the assembly  
descriptor.  I don't think this is a blocker but I'd be interested in  
other ideas on how to handle this.

- I would like to figure out a better way to deal with the info  
processed into the ResourceEnvironementBuilder.  This would let us  
pretty much remove ENCConfigBuilder.  I'm not sure this needs to be  
part of this issue however.

many thanks for your prompt review and vote :-)

david jencks