On the topic of @ProvideCapability, I was not able to create
a parameterized annotation such as:
@Retention(RetentionPolicy.CLASS)
@ProvideCapability(
name="jsp.taglib", ns = "osgi.extender", version = "${@version}"
)
public @interface JspTagLib {
String value();
}
Such that I could then apply it as:
@JspTagLib("http://alloy.liferay.com/tld/aui";)
class Foo {}
Rather I had to use this
@ProvideCapability(
ns = "osgi.extender", version = "${@version}",
value = "uri=http://alloy.liferay.com/tld/aui";
)
class Foo {}
Is this because I'm using at bnd 2.3?
Is it possible to make a parameterized extensions of @ProviderCapability?
- Ray
On Fri, Dec 19, 2014 at 5:06 PM, Raymond Auge <[email protected]>
wrote:
>
>
> On Fri, Dec 19, 2014 at 1:59 PM, Neil Bartlett <[email protected]>
> wrote:
>>
>> 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
>>
>
> Yes this is brilliant stuff that Peter has already submitted as a RFC for
> R7.
>
>
> https://github.com/osgi/design/blob/master/rfps/rfp-0167-Manifest-Annotations.pdf
>
> This brings an exciting ease of use to the req&cap model!
>
> - Ray
>
>
>>
>> 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]> 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
>>
>>
>>
>> _______________________________________________
>> 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)
>
--
*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
