Incidentally, if you use the latest bnd(tools) development builds, you can get
some of the nasty Require-Capability syntax generated from Java annotations.
For example, you can define your own annotation and add it to a class in your
bundle:
@JspTagLib(uri = “foo”)
public class MyTagLib extends …
Where the annotation is itself annotated as follows:
@Retention(RetentionPolicy.CLASS)
@RequireCapability(
ns = "osgi.extender",
filter = "(&(osgi.extender=jsp.taglib)(version>=1.0))”,
effective = "active")
public @interface JspTagLib {
String uri();
}
When bnd sees the annotated class in your bundle, it adds the following to the
generated manifest:
Require-Capability:
osgi.extender;uri=foo;filter:="(&(osgi.extender=jsp.taglib)(version>=1.0))";effective:=active
Regards
Neil
> On 19 Dec 2014, at 21:41, Raymond Auge <[email protected]> wrote:
>
>
>
> On Fri, Dec 19, 2014 at 1:37 PM, Tim Ward <[email protected]
> <mailto:[email protected]>> wrote:
> Hi Ray,
>
> Sent from my iPhone
>
> On 19 Dec 2014, at 21:23, Raymond Auge <[email protected]
> <mailto:[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]
>> <mailto:[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]
>> <mailto:[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
>>> <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]
>>> <mailto:[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
>>>> <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
>>>> <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
>>>> <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] <mailto:[email protected]>
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected] <mailto:[email protected]>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <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] <mailto:[email protected]>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> [email protected] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <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] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
