-
Notifications
You must be signed in to change notification settings - Fork 15
Extensibility
The Aggregator may be extended by third-parties to provide additional functionality not available with the base implementation. Extensions are implemented though the Eclipse extension registry by OSGi bundles providing extensions for the following Aggregator extension points:
This extension point allows third-parties to provide support for additional module builders. The Aggregator provides module builders for JavaScript files, i18n JavaScript resource files, CSS files, LESS files, and text resources. The following markup declaring the default modulebuilder extensions is from the Aggregator's plugin.xml:
<extension
id="default.modulebuilders"
point="com.ibm.jaggr.service.modulebuilder">
<builder extension="js"
class="com.ibm.jaggr.core.impl.modulebuilder.javascript.I18nModuleBuilder"/>
<builder extension="js"
class="com.ibm.jaggr.core.impl.modulebuilder.javascript.JavaScriptModuleBuilder"/>
<builder extension="less"
class="com.ibm.jaggr.core.impl.modulebuilder.less.LessModuleBuilder"/>
<builder extension="css"
class="com.ibm.jaggr.core.impl.modulebuilder.less.LessModuleBuilder"/>
<builder extension="*"
class="com.ibm.jaggr.core.impl.modulebuilder.text.TextModuleBuilder"/>
</extension>
The module type is determined by the file type of the module resource (e.g. css, js, html, etc.). The default module type of '*' is recognized as matching any module type that does not match another registered extension. If the same file type is specified more than once, then the module builders associated with the file type are invoked in the order that they are specified, and the first builder to indicate that it handles the module is used to build the module.
Applications specify the id(s) of module builder extension(s) used by the application using one or more modulebuilders servlet init-params. If no modulebuilders servlet init-param is specified, then the default.modulebuilders extension defined in the aggregator's plugin.xml is used.
Module builder extensions are required to provide an implementation of com.ibm.jaggr.core.modulebuilder.IModuleBuilder
This extension point allows third-parties to provide support for additional resource respository types as identified by the protocol, or scheme, portion of resource URIs. The Aggregator provides support for resources residing on the server's file system and in OSGi bundles. Extensions could provide additional support for resources residing in zip files or in databases. The following markup declaring the default resourcefactory extensions is from the Aggregator's plugin.xml:
<extension
id="default.resourcefactories"
point="com.ibm.jaggr.service.resourcefactory">
<factory scheme="file"
class="com.ibm.jaggr.core.impl.resource.FileResourceFactory"/>
<factory scheme="bundleentry"
class="com.ibm.jaggr.core.impl.resource.BundleResourceFactory"/>
<factory scheme="bundleresource"
class="com.ibm.jaggr.core.impl.resource.BundleResourceFactory"/>
<factory scheme="namedbundleresource"
class="com.ibm.jaggr.core.impl.resource.BundleResourceFactory"/>
</extension>
Applications specify the id(s) of resourcefactory extension(s) used by the application using one or more resourcefactories servlet init-params. If no resourcefactories servlet init-param is specified, then the default.resourcefactories extension defined in the aggregator's plugin.xml is used.
Resource factory extension are required to provide an implementation of com.ibm.jaggr.core.resource.IResourceFactory.
This extension point allows third-parties to provide support for resource converters. Resource converters are similar to module builders in that they both process resources in order to provide transformed output, but resource converters operate at a lower level. Module builders are invoked to provided built/minified content of a resource for inclusion in an aggregated layer response. Resource converters, on the other hand, are invoked whenever the content of the resource is read, including when the resource is requested by itself via a resource specific URL, and when resources are being scanned to build the dependency map. The intent of resource converters is to convert resources from one source type of content, which is not directly supported by the Aggregator, to another source type of content which is supported. The JSX Resource converter is an example implementation of a resource converter.
Resource converters are required to provide an implementation of com.ibm.jaggr.core.resource.IResouceConverter.
This extension point was introduced in version 1.3.
This extension point allows third-parties to register OSGi service providers. The service provider is registered with the OSGi service registry under the interface name specified by the extension's service attribute. The following markup declaring the configextension.bundleVersionsHash service provider is from the Aggregator's plugin.xml:
<extension
id="configextension.bundleVersionsHash"
point="com.ibm.jaggr.service.serviceprovider">
<serviceprovider
class="com.ibm.jaggr.service.impl.config.BundleVersionsHash"
service="com.ibm.jaggr.core.config.IConfigScopeModifier">
<init-param name="propName" value="getBundleVersionsHash"/>
</serviceprovider>
</extension>
Applications specify the id(s) of the serviceprovider extension(s) used by the application using the serviceproviders servlet init-param.
For the serviceproviders element, any name/value pairs specified using the init-param attribute are copied to the service registration properties for the service, in addtion to the name service registration property which specifies the name of the aggregator instance that is registering the service.
This extension point allows third-parties to provide support for additional HTTP Transports. The HTTP Transport is the Aggregator component that interfaces with the client-side AMD loader. It provides the implementation for the client-side AMD loader extension, which is responsible for composing the HTTP requests that the loader sends to the Aggregator, and it is responsible for parsing and interpreting the request on the server, converting URL request parameters into interface defined request attributes.
The following markup declaring the default HTTP transport is from the Aggregator's plugin.xml:
<extension
id="dojo.httptransport"
point="com.ibm.jaggr.service.httptransport">
<transport path="combo"
class="com.ibm.jaggr.core.impl.transport.DojoHttpTransport"/>
</extension>
Applications specify the id of the transport extension used by the application using the httptransport servlet init-param. If no httptransport servlet init-param is specified, then the dojo.httptransport extension defined in the aggregator's plugin.xml is used.
Transport extensions are required to provide an implementation of com.ibm.jaggr.core.transport.IHttpTransport.
For any extensions that accept initialization parameters specified using the init-params element, substitution variables of the form ${propertyname} may be used in the init-param value attribute. The substitution variables will be resolved using Java system properties, and/or any services implementing the com.ibm.jaggr.service.IVariableResolver interface that have been registered for the Aggregator. If the named property cannot be resolved, then the value string is not modified.