Project: springxd
Issue XD-2469: Parent Modules
Thinking about the UBS(?) scenario that MP described. They want all their Cassandra modules to share a connection, leading to the need for a parent context for those modules. We could introduce a parent module for this purpose. The module declares a parent in its properties which likely ends up as a parent module definition in the module definition. When the child module is deployed, its parent must be deployed first if it is not already (i.e., parent is a singleton per container). The module sets that as it's parent context. We would have to make sure things happen in the correct order so the global context is the parent of the parent (ad infinitum). The alternative is to add a module parent context to the XD hierarchy which is extensible, but this is more elegant IMHO. Also, in cases that don't require singleton bean definitions, the parent could package and provide common jars to children, e.g., we set the parent module's classloader as the parent classloader, eliminating the need to install common jars in an HDFS path (basically the approach I described https://jira.spring.io/browse/XD-2420) MP : >> Also, in cases that don't require singleton bean definitions, the parent could package and provide common jars to children, e.g., we set the parent module's classloader as the parent classloader This approach does not offer some of the advantages offered by a central yaml config noted in the JIRA . But it is simpler in many ways. The developer just installs a parent module containing dependent jars and sets that as a parent in the child modules. This requires no additional infrastructure. To address the hadoop scenario we discussed, we would need another level of indirection so the parent of the hdfs modules is bound to the configured hadoop distro. e.g. something like parent = ${xd.hadoop.distro} in module properties MF: Possibly the parent modules could go in the "common" directory? They should be considered "abstract" also - in the same sense as abstract bean definitions in a Spring context (and they should only be started on demand when needed by at least one concrete child module - then destroyed when the last child module is destroyed). Maybe this would also allow us to wrap up those xml files that currently live in "common" so that they are treated as parent modules? MF: Yea, that sounds good wrt to common. Also it might be a good idea to enable spring to throw an error if it finds more than one bean of the same name in the application context - i think that applies to searching in parent contexts as well. this would avoid the 'last one wins' rule and give more deterministic behavior.
Story points: 8