Having just noticed a couple of omissions... To actually match the filter in my previous email the extender would need to specify:
Provide-Capability: osgi.extender;osgi.extender=jsp.taglib;version=1.0.0 Also, unless the extendee should be prevented from resolving in the absence of the extender then it should specify effective:=active (as opposed to the default of resolve) And now I'm done - speak to you all next year! Tim Sent from my iPhone > On 19 Dec 2014, at 20:55, Tim Ward <[email protected]> wrote: > > Hi Ray, > > There is already an osgi.extender namespace declared for this sort of > dependency. The extender provides a capability in the osgi.extender > namespace, which is required by the extendee. There's a blueprint example in > the spec, but this would work for your JSPs. Time for a JSP extender in > Enrerprise R7? > > Apologies for phone-based syntax issues! > > Extender: > > Provide-Capability: osgi.extender;osgi.extender=jsp.taglib > > Extendee: > > Require-Capability: > filter:=(&(osgi.extender=jsp.taglib)(version>=1.0.0)(!(version>=2.0.0))); > jsp.taglib.uri="http://my.uri.domain/cooltags_1_0";; > jsp.taglib.file="/META-INF/cooltags.tld";uses:="..... > > Regards, > > Tim > > Sent from my iPhone > >> On 19 Dec 2014, at 19:38, Raymond Auge <[email protected]> wrote: >> >> 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é (@rotty3000) >> Senior Software Architect Liferay, Inc. (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
