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...
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
