Jeremy (to clarify), Instead of having configuration data for an EJB living in only one namespace, why can't we create appropriate namespaces for the particular requirements for each EJB. Some examples would be:
geronimo.<AppName>.<EjbName>.jndi geronimo.<AppName>.<EjbName>.pool geronimo.<AppName>.<EjbName>.transaction geronimo.<AppName>.<EjbName>.security geronimo.<AppName>.<EjbName>.methods.<MethodIndex> (for Session & Entity) geronimo.<AppName>.<EjbName>.queue (for MDBs) geronimo.<AppName>.<EjbName>.timing (for Timed Beans) (Note if speed is an issue, we can create the following to obtain all configuration data in one call - generally used at startup) geronimo.<AppName>.<EjbName>.all This hopefully will give us the freedom to maintain easy configuration interfaces, rather than trying to come up with a generic inheritance model that will suit all. (Designed well, this should hopefully reduce code - due to reuse - not only in creating MBeans, but in creating behaviour on this model). The population of this information can be performed in any manor (sequential for SAX parsing), in EJB blocks (from binary storage) or randomly (from properties file / deployment tool). We are thus not locked into any configuration persistance model leaving flexibility to use any approach - the algorithm for loading configuration data, will also have an appropriate mechanism to persist the configuration data. Regards, Daniel Sagenschneider
