Hey All,
I'm wondering about modelling an extender pattern using requirements &
capabilities header.
Hopefully I can explain this in a way that can be understood:
In order to implement the extender pattern we often define a new "custom"
header which declares the "opt-in" on the extender.
However, I'm wondering if instead of using a new "Custom header" if it
might not be better to define this "opt-in" using a Provide-Capability.
For instance, suppose I wanted to support dynamic provision of JSP taglibs.
I could model this using pure java jars with taglibs by adding a header to
the jar something like:
Provide-Capability:
jsp.taglib;
jsp.taglib.uri="http://my.uri.domain/cooltags_1_0";;
jsp.taglib.file="/META-INF/cooltags.tld";uses:=".....",
jsp.taglib;
jsp.taglib.uri="http://my.uri.domain/othertags_2_0";;
jsp.taglib.file="/META-INF/othertags.tld";uses:=".....",
Require-Capability: jsp.extender; filter:="(version=1.0)"
This way I don't have to invent a new syntax or header and this can easily
be resolved against in both directions.
The extender bundle would look for bundles providing jsp.taglib
capabilities and make the TLDs available to the JSP servlet it provides to
the clients using JSP.
A client bundle using both JSP and using the taglib would ask for them by
making a Require-Capability against both
Require-Capability: jsp.extender; filter:="(version=1.0)"
Require-Capability: jsp.taglib; filter:="(jsp.taglib.uri=
http://my.uri.domain/cooltags_1_0)"
Thoughts?
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
