On Fri, Dec 19, 2014 at 1:37 PM, Tim Ward <[email protected]> wrote: > > Hi Ray, > > Sent from my iPhone > > On 19 Dec 2014, at 21:23, Raymond Auge <[email protected]> wrote: > > Thanks Tim, I can start with this. > > I just want to make it clear that there are 3 actors involved for this > scenario (perhaps that doesn't matter, let's see): > > 1) a JSP client bundle (has jsps) > Required-Capability: ...jsp.extender... > Required-Capability: ...jsp.taglib;filter:="(uri=foo)" > > 2) a taglib bundle (provides taglib) > Required-Capability: ...jsp.extender... > Provide-Capability: ... jsp.taglib;uri="foo"... > > 3) jsp extender (provides the JSP servlet to client bundles, ensures the > client's required taglibs are available to the servlet) > Provide-Capability: ...jsp.extender... > > > Between the three of these that would do the trick, although unless the > extender bundle directly interacts with the client bundle (which it may do > for this case) >
it does. > then I would only put the extender requirement in the extendee (providing > the tag lib) not the client. > Got it! Thanks you Tim. Happy Holidays! - Ray > > On Fri, Dec 19, 2014 at 1:11 PM, Tim Ward <[email protected]> wrote: >> >> 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é* <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 >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > -- > *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 > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *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
