You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Hasan Kahraman <ha...@ericsson.com> on 2015/10/23 09:27:43 UTC
New Tag for: Dynamic OSGI service binding & Interception
Hi,
I've implemented a new tag library for my project. I thought this could be useful for Blueprint's roadmap.
Briefly: Enabling customization of an existing application with just deploying a bundle via OSGI services without changing the existing implementation.
I can share it with you (with unit tests) if you think it provides a contribution. Let me explain some functionality with examples:
1.) Proxy
Please see below blueprint layout.
In below sample my tag library creates a proxy class. So cdrFormatHandler is a proxy object instead of given class's object.
This proxy is capable of routing calls default implementation's (DefaultCdrFormatterImpl) methods by default.
Proxy listens OSGI container at the same time.
When bundle2 is deployed. It detects service (custom.cdr.formatter=bundle2.impl)is registered. Then sets this service as backing implementation. All calls are routed to bundle2's OSGI service's methods instead of default implementation.
Proxy is also capable of setting configuration property to incoming service. Like it did on default bean initialization. So registered service will also have cdrConfiguration bound.
init-method is called after properties are set.
When bundle2 is removed from system, again default implementation is being used. During removal destroy-method is called for the service before releasing.
Tag lib and proxy behaviour changes according to mode option.
'none': Proxy ignores any implementation, do nothing and returns default values to function calls.
'default': No proxy, no service, just a blueprint bean.
'filter': Waits for the required service to be provided (acts like referance). Any calls result with ServiceUnavailableException.
'filter-silent': Same as filter, but ServiceUnavailableException is not thrown.
Bundle1: config.properties
cdr_formatter.service=(custom.cdr.formatter=bundle2.impl)
cdr_formatter.mode=all
Bundle1: blueprint.xml
...
<bean id="cdrFormatHandler" class="com.example.DefaultCdrFormatterImpl"
init-method="init" destroy-method="destroy">
<es:proxy filter="${cdr_formatter.service}"
mode="${cdr_formatter.mode}"/>
<property name="configuration" ref="cdrConfiguration"/>
</bean>
....
Bundle2: blueprint.xml
....
<bean id="customCdrFormatter" class="com.example2.CustomCdrFormatterImpl"/>
<service ref="customCdrFormatter" interface="com.ericsson.sscm.common.ns.beans.TestBean">
<service-properties>
<entry key="custom.cdr.formatter" value="bundle2.impl"/>
</service-properties>
</service>
....
2.) Interceptor
Reuses your interceptor implementation, but this is just exposure to the blueprint.
In blow sample, proxy calls interceptor 1 & 2 preCall, postCallWithReturn and postCallWithException functions in given order.
Bundle1: blueprint.xml
...
<bean id="cdrFormatHandler" class="com.example.DefaultCdrFormatterImpl"
init-method="init" destroy-method="destroy">
<es:proxy filter="${cdr_formatter.service}"
mode="${cdr_formatter.mode}"/>
<es:intercept ref="interceptor_1" rank="1"/>
<es:intercept ref="interceptor_2" rank="2"/>
<property name="configuration" ref="cdrConfiguration"/>
</bean>
....
HASAN KAHRAMAN
Software Architect
SCC
Ericsson
ITU Teknokent ARI2
Maslak, Istanbul, Turkey
Phone +905304130491
Re: New Tag for: Dynamic OSGI service binding & Interception
Posted by Christian Schneider <ch...@die-schneider.net>.
Some comments
1) I think this is already possible using the service ranking.
You could have a default service with a low rank and replace it by
registering a service with a higher rank.
2) The intercept Element sounds interesting. Though I am not sure how
often you would use explicit interceptors.
Most times interceptors look over all beans and react on some of them.
Christian
On 23.10.2015 09:27, Hasan Kahraman wrote:
> Hi,
>
> I've implemented a new tag library for my project. I thought this could be useful for Blueprint's roadmap.
>
> Briefly: Enabling customization of an existing application with just deploying a bundle via OSGI services without changing the existing implementation.
>
> I can share it with you (with unit tests) if you think it provides a contribution. Let me explain some functionality with examples:
>
>
> 1.) Proxy
>
>
>
> Please see below blueprint layout.
>
>
> In below sample my tag library creates a proxy class. So cdrFormatHandler is a proxy object instead of given class's object.
>
> This proxy is capable of routing calls default implementation's (DefaultCdrFormatterImpl) methods by default.
>
> Proxy listens OSGI container at the same time.
>
> When bundle2 is deployed. It detects service (custom.cdr.formatter=bundle2.impl)is registered. Then sets this service as backing implementation. All calls are routed to bundle2's OSGI service's methods instead of default implementation.
>
> Proxy is also capable of setting configuration property to incoming service. Like it did on default bean initialization. So registered service will also have cdrConfiguration bound.
> init-method is called after properties are set.
>
> When bundle2 is removed from system, again default implementation is being used. During removal destroy-method is called for the service before releasing.
>
>
>
> Tag lib and proxy behaviour changes according to mode option.
>
> 'none': Proxy ignores any implementation, do nothing and returns default values to function calls.
>
> 'default': No proxy, no service, just a blueprint bean.
>
> 'filter': Waits for the required service to be provided (acts like referance). Any calls result with ServiceUnavailableException.
>
> 'filter-silent': Same as filter, but ServiceUnavailableException is not thrown.
>
>
>
>
>
> Bundle1: config.properties
>
> cdr_formatter.service=(custom.cdr.formatter=bundle2.impl)
>
> cdr_formatter.mode=all
>
>
>
> Bundle1: blueprint.xml
>
> ...
> <bean id="cdrFormatHandler" class="com.example.DefaultCdrFormatterImpl"
> init-method="init" destroy-method="destroy">
>
> <es:proxy filter="${cdr_formatter.service}"
> mode="${cdr_formatter.mode}"/>
>
> <property name="configuration" ref="cdrConfiguration"/>
>
>
> </bean>
>
> ....
>
>
>
> Bundle2: blueprint.xml
>
> ....
> <bean id="customCdrFormatter" class="com.example2.CustomCdrFormatterImpl"/>
>
> <service ref="customCdrFormatter" interface="com.ericsson.sscm.common.ns.beans.TestBean">
> <service-properties>
> <entry key="custom.cdr.formatter" value="bundle2.impl"/>
> </service-properties>
>
> </service>
>
> ....
>
>
>
>
>
>
>
> 2.) Interceptor
>
> Reuses your interceptor implementation, but this is just exposure to the blueprint.
> In blow sample, proxy calls interceptor 1 & 2 preCall, postCallWithReturn and postCallWithException functions in given order.
>
>
> Bundle1: blueprint.xml
>
> ...
> <bean id="cdrFormatHandler" class="com.example.DefaultCdrFormatterImpl"
> init-method="init" destroy-method="destroy">
>
> <es:proxy filter="${cdr_formatter.service}"
> mode="${cdr_formatter.mode}"/>
>
> <es:intercept ref="interceptor_1" rank="1"/>
> <es:intercept ref="interceptor_2" rank="2"/>
>
> <property name="configuration" ref="cdrConfiguration"/>
>
>
> </bean>
>
> ....
>
>
>
> HASAN KAHRAMAN
> Software Architect
> SCC
>
> Ericsson
> ITU Teknokent ARI2
> Maslak, Istanbul, Turkey
> Phone +905304130491
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com