On 13/01/15 16:27, Raymond Auge wrote:
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();
String value();
String ns() default "osgi.extender";
String version default "${@version}";
or something like that, check the bnd annotations source code
}
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]
<mailto:[email protected]>> wrote:
On Fri, Dec 19, 2014 at 1:59 PM, Neil Bartlett <[email protected]
<mailto:[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] <mailto:[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";;
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";;
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] <mailto:[email protected]>
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
--
*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
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[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] <mailto:[email protected]>
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
--
*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
--
Ferry Huberts
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
