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
