You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Aki Yoshida <el...@gmail.com> on 2013/03/15 00:32:47 UTC
filtering of features at automatic features loading over osgi service
Hi,
Currently, I think there is no filtering option in automatic feature
loading over osgi services.
I think it's nicer and safer to have some kind of filtering mechanism.
I am thinking of not just the enable/disable boolean flag, but a regex
filter to match against the service-publishing bundle's symbolic names
and feature names.
Cocretely, we define bus properties that look something like,
bus.feature.osgi.load.allowFeatures
bus.feature.osgi.load.denyFeatures
bus.feature.osgi.load.allowBundles
bus.feature.osgi.load.denyBundles
each taking a regex string.
and writing in a pseudo-code,
given
f = feature
bsn = bundleSymbolicName
fn = featureName
we use the condition
if (match(allowBundles, bn) && !match(allowBundles, bn)
&& match(allowFeatures, fn) && !match(denyFeatures, fn)) {
add(f)
}
or use a simpler rule with only the bundle name check part.
Do you have comments or preferences?
Thanks.
regards, aki
Re: filtering of features at automatic features loading over osgi service
Posted by Daniel Kulp <dk...@apache.org>.
I kind of chatted with Aki a bit about this today. To follow up on list:
I basically have no problem with doing this as long as the defaults remain as today (unfiltered). However, if we start pursuing this, it may also be good to make it also apply to the other things that can be pulled in such as BusLifecycleListeners, ServerLifecycleListeners, and ClientLifecycleListeners.
Also, it's likely also useful to allow the "reverse" where a bundle could register a *LifecycleListener with some OSGi properties that specify which buses and services to apply it to.
Anyway, mostly just a bunch of potentially cool feature requests. :-)
Dan
On Mar 14, 2013, at 7:32 PM, Aki Yoshida <el...@gmail.com> wrote:
> Hi,
> Currently, I think there is no filtering option in automatic feature
> loading over osgi services.
> I think it's nicer and safer to have some kind of filtering mechanism.
>
> I am thinking of not just the enable/disable boolean flag, but a regex
> filter to match against the service-publishing bundle's symbolic names
> and feature names.
>
> Cocretely, we define bus properties that look something like,
> bus.feature.osgi.load.allowFeatures
> bus.feature.osgi.load.denyFeatures
> bus.feature.osgi.load.allowBundles
> bus.feature.osgi.load.denyBundles
>
> each taking a regex string.
>
> and writing in a pseudo-code,
> given
> f = feature
> bsn = bundleSymbolicName
> fn = featureName
>
> we use the condition
> if (match(allowBundles, bn) && !match(allowBundles, bn)
> && match(allowFeatures, fn) && !match(denyFeatures, fn)) {
> add(f)
> }
>
> or use a simpler rule with only the bundle name check part.
>
> Do you have comments or preferences?
>
> Thanks.
> regards, aki
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: filtering of features at automatic features loading over
osgi service
Posted by Willem jiang <wi...@gmail.com>.
Yes, we could use the Client/ServerLifecycleListener to do that kind of job.
But now I have some trouble to do the same configuration on the WebClient which is created by JAXRSClientFactoryBean.
It looks like the ClientLifecycleListener doesn't work for the WebClient, I had to using the patch in CXF-4953 (https://issues.apache.org/jira/browse/CXF-4953) to work around it.
We need implement the same interface in jaxrs front end.
[1]https://issues.apache.org/jira/browse/CXF-4953
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, April 9, 2013 at 7:33 PM, Daniel Kulp wrote:
>
> On Apr 9, 2013, at 4:53 AM, Willem.Jiang <willem.jiang@gmail.com (mailto:willem.jiang@gmail.com)> wrote:
>
> > Hi,
> > I'm sorry my reply may not relate to this discussion directly, but I think
> > it could be interesting to for us to discuss that if the bus aware the
> > exported feature, how the ClientFactoryBeans can use it. As you know the
> > feature could not just be used to setup the interceptors.
>
>
>
> No, features applied to a Bus should only be applied to the Bus as they may only be designed for that scenario. If you have something that needs to be applied to a client or server, they should be registering the Client/ServerLifcycleListeners and apply things at that point.
>
> Dan
>
>
> >
> > I create a JIRA CXF-4953[1] for it.
> > Any thought?
> >
> > [1]https://issues.apache.org/jira/browse/CXF-4953
> >
> > Willem
> >
> >
> >
> > --
> > View this message in context: http://cxf.547215.n5.nabble.com/filtering-of-features-at-automatic-features-loading-over-osgi-service-tp5724596p5726029.html
> > Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: filtering of features at automatic features loading over osgi service
Posted by Daniel Kulp <dk...@apache.org>.
On Apr 9, 2013, at 4:53 AM, Willem.Jiang <wi...@gmail.com> wrote:
> Hi,
> I'm sorry my reply may not relate to this discussion directly, but I think
> it could be interesting to for us to discuss that if the bus aware the
> exported feature, how the ClientFactoryBeans can use it. As you know the
> feature could not just be used to setup the interceptors.
No, features applied to a Bus should only be applied to the Bus as they may only be designed for that scenario. If you have something that needs to be applied to a client or server, they should be registering the Client/ServerLifcycleListeners and apply things at that point.
Dan
>
> I create a JIRA CXF-4953[1] for it.
> Any thought?
>
> [1]https://issues.apache.org/jira/browse/CXF-4953
>
> Willem
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/filtering-of-features-at-automatic-features-loading-over-osgi-service-tp5724596p5726029.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: filtering of features at automatic features loading over osgi
service
Posted by "Willem.Jiang" <wi...@gmail.com>.
Hi,
I'm sorry my reply may not relate to this discussion directly, but I think
it could be interesting to for us to discuss that if the bus aware the
exported feature, how the ClientFactoryBeans can use it. As you know the
feature could not just be used to setup the interceptors.
I create a JIRA CXF-4953[1] for it.
Any thought?
[1]https://issues.apache.org/jira/browse/CXF-4953
Willem
--
View this message in context: http://cxf.547215.n5.nabble.com/filtering-of-features-at-automatic-features-loading-over-osgi-service-tp5724596p5726029.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: filtering of features at automatic features loading over osgi
service
Posted by Christian Schneider <ch...@die-schneider.net>.
I am also not sure which aproach is more suitable.
Basically intents are only a more loosely coupled form of adding
features to a service.
The instrumentation case even applies when the service has no clue of
the features you want to add to it.
Btw. in dosgi there is also such a case. Adding the dosgi properties to
services that do not yet have them. There
of course intents can not help.
Probably both aproaches are importent. So the question is how to make
them both work together.
Christian
On 19.03.2013 15:46, Aki Yoshida wrote:
> Okay. I see what you mean. It is a bit different but more related than
> I initially thought :-)
>
> This "intent" approach is useful when your scenario app knows which
> features to use or at least knows which features it intends to use and
> tries to find them in osgi services.
>
> The use case that I had in mind was to influence the behavior of some
> scenarios from outside, something like instrumentation. And for this
> mechanism, I was thinking of providing an option at the service-side
> to restrict its applicability to some specific scenarios-apps and also
> at the scenario-app-side to exclude the engagement of listeners or
> features from some specific services.
>
> I though this use case is somewhat complementary to the "intent" use
> case but I am not really sure. I was thinking of introducing a pair of
> regex properties to control the behavior of such external
> features/listener engagement (which I added in CXF-4900). But I wonder
> if it could be better replaced with the intent-based approach of some
> forms (e.g. allowing some pseudo intentions like "no-intention" to
> mean excluding everything and "any-intention" for including
> everything, other concrete intentions to choose specifically)? Not
> sure if it's simpler to separate them or unify them.
>
> regards, aki
>
>
>
> 2013/3/18 Christian Schneider <ch...@die-schneider.net>:
>> That is true, it is a bit different. I think were both aproaches meet is
>> that we should be able to control which extensions and features are loaded.
>> Simply loading everything is too coarse grained. For extensions the default
>> of loading every extension may make sense as they are often things like
>> transports or data formats.
>> These are simply available and are activated by settings in the service.
>>
>> At least for features this is different though. Outside of OSGi features are
>> only activated if they are listed in the service endpoint or proxy. So
>> simply loading them all in OSGi is not enough.
>> A simple aproach may be to do it like in dOSGi. There you can list named
>> "intents" in an endpoint and include features this way. So a feature could
>> be published as an OSGi service and be given a name in an OSGi property.
>> Then you could list the features you want in the properties of an endpoint
>> or proxy and so filter the loading.
>>
>> Even better would be to have a plugable mechansim that decides which
>> features to load. My policy manager would then be such an implementation.
>> The simple activation by name would be another.
>>
>> Btw. one big advantage of naming the required features is that you can wait
>> for them. I implemented this for intents in the current dosgi version. The
>> advantage is that you do not have to start features in a lower start level
>> than the user bundle that needs them.
>>
>> Christian
>>
>> Am 18.03.2013 10:28, schrieb Aki Yoshida:
>>
>>> Hi Christian,
>>> your use case seems like creating some kind of automatic policy
>>> derivation mechanism based on other properties of the scenario. It's
>>> an interesting approach that makes some scenarios more flexible as
>>> they don't need to explicitly use policies but could make the thing
>>> complex as we don't see policies explicitly?
>>>
>>> But in any case, I think this use case has a different aspect than
>>> simply controlling/restricting the automatic engagement of the
>>> published features or lifecycle listeners from somewhere else into the
>>> bus.
>>>
>>> regards, aki
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: filtering of features at automatic features loading over osgi service
Posted by Aki Yoshida <el...@gmail.com>.
Okay. I see what you mean. It is a bit different but more related than
I initially thought :-)
This "intent" approach is useful when your scenario app knows which
features to use or at least knows which features it intends to use and
tries to find them in osgi services.
The use case that I had in mind was to influence the behavior of some
scenarios from outside, something like instrumentation. And for this
mechanism, I was thinking of providing an option at the service-side
to restrict its applicability to some specific scenarios-apps and also
at the scenario-app-side to exclude the engagement of listeners or
features from some specific services.
I though this use case is somewhat complementary to the "intent" use
case but I am not really sure. I was thinking of introducing a pair of
regex properties to control the behavior of such external
features/listener engagement (which I added in CXF-4900). But I wonder
if it could be better replaced with the intent-based approach of some
forms (e.g. allowing some pseudo intentions like "no-intention" to
mean excluding everything and "any-intention" for including
everything, other concrete intentions to choose specifically)? Not
sure if it's simpler to separate them or unify them.
regards, aki
2013/3/18 Christian Schneider <ch...@die-schneider.net>:
> That is true, it is a bit different. I think were both aproaches meet is
> that we should be able to control which extensions and features are loaded.
> Simply loading everything is too coarse grained. For extensions the default
> of loading every extension may make sense as they are often things like
> transports or data formats.
> These are simply available and are activated by settings in the service.
>
> At least for features this is different though. Outside of OSGi features are
> only activated if they are listed in the service endpoint or proxy. So
> simply loading them all in OSGi is not enough.
> A simple aproach may be to do it like in dOSGi. There you can list named
> "intents" in an endpoint and include features this way. So a feature could
> be published as an OSGi service and be given a name in an OSGi property.
> Then you could list the features you want in the properties of an endpoint
> or proxy and so filter the loading.
>
> Even better would be to have a plugable mechansim that decides which
> features to load. My policy manager would then be such an implementation.
> The simple activation by name would be another.
>
> Btw. one big advantage of naming the required features is that you can wait
> for them. I implemented this for intents in the current dosgi version. The
> advantage is that you do not have to start features in a lower start level
> than the user bundle that needs them.
>
> Christian
>
> Am 18.03.2013 10:28, schrieb Aki Yoshida:
>
>> Hi Christian,
>> your use case seems like creating some kind of automatic policy
>> derivation mechanism based on other properties of the scenario. It's
>> an interesting approach that makes some scenarios more flexible as
>> they don't need to explicitly use policies but could make the thing
>> complex as we don't see policies explicitly?
>>
>> But in any case, I think this use case has a different aspect than
>> simply controlling/restricting the automatic engagement of the
>> published features or lifecycle listeners from somewhere else into the
>> bus.
>>
>> regards, aki
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: filtering of features at automatic features loading over osgi
service
Posted by Christian Schneider <ch...@die-schneider.net>.
That is true, it is a bit different. I think were both aproaches meet is
that we should be able to control which extensions and features are loaded.
Simply loading everything is too coarse grained. For extensions the
default of loading every extension may make sense as they are often
things like transports or data formats.
These are simply available and are activated by settings in the service.
At least for features this is different though. Outside of OSGi features
are only activated if they are listed in the service endpoint or proxy.
So simply loading them all in OSGi is not enough.
A simple aproach may be to do it like in dOSGi. There you can list named
"intents" in an endpoint and include features this way. So a feature
could be published as an OSGi service and be given a name in an OSGi
property.
Then you could list the features you want in the properties of an
endpoint or proxy and so filter the loading.
Even better would be to have a plugable mechansim that decides which
features to load. My policy manager would then be such an
implementation. The simple activation by name would be another.
Btw. one big advantage of naming the required features is that you can
wait for them. I implemented this for intents in the current dosgi
version. The advantage is that you do not have to start features in a
lower start level
than the user bundle that needs them.
Christian
Am 18.03.2013 10:28, schrieb Aki Yoshida:
> Hi Christian,
> your use case seems like creating some kind of automatic policy
> derivation mechanism based on other properties of the scenario. It's
> an interesting approach that makes some scenarios more flexible as
> they don't need to explicitly use policies but could make the thing
> complex as we don't see policies explicitly?
>
> But in any case, I think this use case has a different aspect than
> simply controlling/restricting the automatic engagement of the
> published features or lifecycle listeners from somewhere else into the
> bus.
>
> regards, aki
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: filtering of features at automatic features loading over osgi service
Posted by Aki Yoshida <el...@gmail.com>.
Hi Christian,
your use case seems like creating some kind of automatic policy
derivation mechanism based on other properties of the scenario. It's
an interesting approach that makes some scenarios more flexible as
they don't need to explicitly use policies but could make the thing
complex as we don't see policies explicitly?
But in any case, I think this use case has a different aspect than
simply controlling/restricting the automatic engagement of the
published features or lifecycle listeners from somewhere else into the
bus.
regards, aki
2013/3/15 Christian Schneider <ch...@die-schneider.net>:
> Hi Aki,
>
> I also experimented with something similar some time ago.
> The idea was like in your case to have some control over which features are
> activated. I called the project policy manager.
>
> I extracted some meta data about each endpoint or client into a simple data
> structure. Then I used jxpath to allow users to create filters based on the
> extracted
> data. So a rule consisted of a jxpath expression and one or more feature
> names to enable.
>
> One thing that is very interesting to pursue is to also use jaxws:properties
> for the filtering. This allows the user to define custom meta data in an
> endpoint definition that you can then
> use in the rules.
>
> Christian
>
> Am 15.03.2013 00:32, schrieb Aki Yoshida:
>
>> Hi,
>> Currently, I think there is no filtering option in automatic feature
>> loading over osgi services.
>> I think it's nicer and safer to have some kind of filtering mechanism.
>>
>> I am thinking of not just the enable/disable boolean flag, but a regex
>> filter to match against the service-publishing bundle's symbolic names
>> and feature names.
>>
>> Cocretely, we define bus properties that look something like,
>> bus.feature.osgi.load.allowFeatures
>> bus.feature.osgi.load.denyFeatures
>> bus.feature.osgi.load.allowBundles
>> bus.feature.osgi.load.denyBundles
>>
>> each taking a regex string.
>>
>> and writing in a pseudo-code,
>> given
>> f = feature
>> bsn = bundleSymbolicName
>> fn = featureName
>>
>> we use the condition
>> if (match(allowBundles, bn) && !match(allowBundles, bn)
>> && match(allowFeatures, fn) && !match(denyFeatures, fn)) {
>> add(f)
>> }
>>
>> or use a simpler rule with only the bundle name check part.
>>
>> Do you have comments or preferences?
>>
>> Thanks.
>> regards, aki
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: filtering of features at automatic features loading over osgi
service
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Aki,
I also experimented with something similar some time ago.
The idea was like in your case to have some control over which features
are activated. I called the project policy manager.
I extracted some meta data about each endpoint or client into a simple
data structure. Then I used jxpath to allow users to create filters
based on the extracted
data. So a rule consisted of a jxpath expression and one or more feature
names to enable.
One thing that is very interesting to pursue is to also use
jaxws:properties for the filtering. This allows the user to define
custom meta data in an endpoint definition that you can then
use in the rules.
Christian
Am 15.03.2013 00:32, schrieb Aki Yoshida:
> Hi,
> Currently, I think there is no filtering option in automatic feature
> loading over osgi services.
> I think it's nicer and safer to have some kind of filtering mechanism.
>
> I am thinking of not just the enable/disable boolean flag, but a regex
> filter to match against the service-publishing bundle's symbolic names
> and feature names.
>
> Cocretely, we define bus properties that look something like,
> bus.feature.osgi.load.allowFeatures
> bus.feature.osgi.load.denyFeatures
> bus.feature.osgi.load.allowBundles
> bus.feature.osgi.load.denyBundles
>
> each taking a regex string.
>
> and writing in a pseudo-code,
> given
> f = feature
> bsn = bundleSymbolicName
> fn = featureName
>
> we use the condition
> if (match(allowBundles, bn) && !match(allowBundles, bn)
> && match(allowFeatures, fn) && !match(denyFeatures, fn)) {
> add(f)
> }
>
> or use a simpler rule with only the bundle name check part.
>
> Do you have comments or preferences?
>
> Thanks.
> regards, aki
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com