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) then I would only put the extender requirement in the extendee (providing the tag lib) not the client. > >> 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é (@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 > > > -- > 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
