Add-on components contexts from jar modules

[Feature]

• Automatic add-on component assembly from a jar files located in an HST-2 application.

a) A jar module in HST-2 application may have a module descriptor file, classpath:META-INF/hst-assembly/addon/module.xml.

Here's a simple example:

<module xmlns="http://www.onehippo.org/schema/hst/hst-addon-module_1_0.xsd">
<name>org.example.analytics</name>
<config-locations>
<config-location>classpath*:META-INF/hst-assembly/addon/org.example.analytics/*.xml</config-location>
</config-locations>
</module>

Then, HST-2 container will create a module instance with the information specified by the descriptor.
And all the components defined in config-location xml files will be loaded into a dedicated spring applicationContext.

b) A bean in a module can get access to beans in the default HST-2 container applicationContext.

Because the dedicated spring applicationContext is a child of the default HST-2 container applicationContext,
its components may get access to any beans in the parent applicationContext (the default HST-2 container applicationContext).

For example,
<bean id="aBeanInChildContext" ...>
<property name="somethingFromParent" ref="somethingFromParent" />
</bean>

, where "somethingFromParent" bean can be found in either its child
applicationContext or its parent applicationContext.

c) ComponentManager#getComponent(componentName) should be extended to:

• #getComponent(componentName); and
• #getComponent(componentName, String ... addonModuleNames);

So, a child bean can be retrieved only by using the second method with ComponentManager.
With the first operation, you can retrieve beans defined in the HST-2 default parent applicationContext only.

d) Modules can be hierarchically structured.

Here's an example:

<module xmlns="http://www.onehippo.org/schema/hst/hst-addon-module_1_0.xsd">
<name>org.example.analytics</name>
<config-locations>
<config-location>classpath*:META-INF/hst-assembly/addon/org.example.analytics/*.xml</config-location>
</config-locations>
<modules>
<module>
<name>reports</name>
<config-locations>
<config-location>classpath*:META-INF/hst-assembly/addon/org.example.analytics/reports/*.xml</config-location>
</config-locations>
</module>
<module>
<name>statistics</name>
<config-locations>
<config-location>classpath*:META-INF/hst-assembly/addon/org.example.analytics/statistics/*.xml</config-location>
</config-locations>
</module>
</modules>
</module>

Then, HST-2 container will create three child applicationContexts for this module.
The contextName of each is, "org.example.analytics", "reports" or "statistics".
The applicationContexts of child modules ("reports" and "statistics") are child applicationContexts of "org.example.analytics" applicationContext.
So, beans in either "reports" or "statistics" are able to get access to beans in either "org.example.analytics" or HST-2 default applicationContext.

However, beans in sibling module applicationContexts cannot refer to the beans of other sibling module applicationContexts.

e) API changes

• ComponentManager#getComponent(beanName); // as it is
• ComponentManager#getComponent(beanName, String ... contextNames); // new

So, with the above example, you may use #getComponent("someAnalyticReportBean", "org.example.analytics", "reports").
Or, you may use #getComponent("someAnalyticBean", "org.example.analytics"), for instance.

f) Module descriptor XML namespace: "http://www.onehippo.org/schema/hst/hst-addon-module_1_0.xsd"
And, its XSD will be provided in hst-core-x.x.x.jar!META-INF/schemas/hst-addon-module_1_0.xsd (and possibly on the web, too.)