Re: filtering of features at automatic features loading over osgi service

[Christian Schneider]

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 :

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

[Aki Yoshida]

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 :
> 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
>

Fediz Tomcat plug-in and Shibboleth IdP

[Abba Yadav]

I am trying to integrate Fediz Tomcat plug-in to talk to our Shibboleth IdP. 
The Fediz tomcat plug-in on the Service Provider talks SAML 1.0.



Sample Fediz configuration file looks like this:














https://localhost:8443/fedizhelloworld/https://localhost:8443/fedizhelloworld/%3C/audienceItem>>



















1000

http://www.w3.org/2001/XMLSchema-instance";


xsi:type="federationProtocolType" version="1.0.0">




https://localhost:9443/fedizidp/https://localhost:9443/fedizidp/%3C/issuer>>

,


http://schemas.xmlsoap.org/ws/2005/05/identity/claims/rolehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/role%3C/roleURI>>




























I am trying to map the different values required by fediz plugin to talk to our 
Shibboleth IdP. Any help is much appreciated.



Thanks,

Abba