Reference to a service declared in the same bundle

[Nico]

Hi,

I was wondering if references declaration to services declared in the same ApplicationContext (same bundle) are supported.
In fact I've got the following bean declaration:

	<bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
		<property name="corePoolSize" value="5" />
		<property name="maxPoolSize" value="10" />
		<property name="queueCapacity" value="25" />
	</bean>

	<bean id="ServerEventPublisherServiceBean" class="org.escapek.server.core.internal.ServerEventPublisherService">
		<property name="taskExecutor" ref="taskExecutor"></property>
		<property name="listeners" ref="ServerEventListeners"></property>
	</bean>

and this osgi context:

	<list id="ServerEventListeners" cardinality="0..N" 
			interface="org.escapek.server.core.event.IServerEventListener">
	</list>
	<list id="RepInitTasks" cardinality="0..N" 
			interface="org.escapek.server.core.IRepInitTask">
		<comparator>
			<natural basis="service-reference" />
		</comparator>
	</list>

	<service ref="ServerEventPublisherServiceBean"
		interface="org.escapek.server.core.event.IServerEventPublisher" />

When starting the bundle I get:

2008-07-29 18:01:53,295 [OSGi Console] INFO  o.s.o.e.s.DefaultOsgiApplicationContextCreator:67 - Discovered configurations {osgibundle:/META-INF/spring/*.xml} in bundle [org.escapek.server.core (org.escapek.server.core;singleton:=true)]

osgi> 2008-07-29 18:01:53,575 [SpringOsgiExtenderThread-17] INFO  o.s.o.c.support.OsgiBundleXmlApplicationContext:412 - Refreshing org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext@1370ce9: display name [OsgiBundleXmlApplicationContext(bundle=org.escapek.server.core, config=osgibundle:/META-INF/spring/*.xml)]; startup date [Tue Jul 29 18:01:53 CEST 2008]; root of context hierarchy
2008-07-29 18:01:53,575 [SpringOsgiExtenderThread-17] INFO  o.s.beans.factory.xml.XmlBeanDefinitionReader:323 - Loading XML bean definitions from URL [bundleentry://1403/META-INF/spring/bundle-context-osgi.xml]
2008-07-29 18:01:53,645 [SpringOsgiExtenderThread-17] INFO  o.s.beans.factory.xml.XmlBeanDefinitionReader:323 - Loading XML bean definitions from URL [bundleentry://1403/META-INF/spring/bundle-context.xml]
2008-07-29 18:01:53,745 [SpringOsgiExtenderThread-17] INFO  o.s.o.c.support.OsgiBundleXmlApplicationContext:427 - Bean factory for application context [org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext@1370ce9]: org.springframework.beans.factory.support.DefaultListableBeanFactory@13b8f62
2008-07-29 18:01:53,766 [SpringOsgiExtenderThread-17] INFO  o.s.o.e.i.d.s.DependencyWaiterApplicationContextExecutor:252 - No outstanding OSGi service dependencies, completing initialization for OsgiBundleXmlApplicationContext(bundle=org.escapek.server.core, config=osgibundle:/META-INF/spring/*.xml)
2008-07-29 18:01:53,786 [SpringOsgiExtenderThread-18] INFO  o.s.b.factory.support.DefaultListableBeanFactory:414 - Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@13b8f62: defining beans [ServerEventListeners,RepInitTasks,org.springframework.osgi.service.exporter.support.OsgiServiceFactoryBean#0,org.springframework.osgi.service.exporter.support.OsgiServiceFactoryBean#1,org.springframework.osgi.service.exporter.support.OsgiServiceFactoryBean#2,taskExecutor,syncTaskExecutor,ServerEventPublisherServiceBean,ServerEventLoggingListenerBean,ServerStateController]; root of factory hierarchy
2008-07-29 18:01:53,786 [SpringOsgiExtenderThread-18] INFO  o.s.scheduling.concurrent.ThreadPoolTaskExecutor:250 - Initializing ThreadPoolExecutor 'taskExecutor'
2008-07-29 18:01:53,796 [SpringOsgiExtenderThread-18] INFO  o.s.o.s.exporter.support.OsgiServiceFactoryBean:394 - Publishing service under classes [{org.escapek.server.core.event.IServerEventPublisher}]
2008-07-29 18:01:53,796 [SpringOsgiExtenderThread-18] INFO  o.s.o.s.exporter.support.OsgiServiceFactoryBean:394 - Publishing service under classes [{org.escapek.server.core.event.IServerEventListener}]
2008-07-29 18:01:53,816 [SpringOsgiExtenderThread-18] INFO  o.s.o.s.exporter.support.OsgiServiceFactoryBean:394 - Publishing service under classes [{org.escapek.server.core.IServerStateController}]
2008-07-29 18:01:53,816 [SpringOsgiExtenderThread-18] INFO  o.s.o.c.support.OsgiBundleXmlApplicationContext:315 - Publishing application context as OSGi service with properties {org.springframework.context.service.name=org.escapek.server.core, Bundle-SymbolicName=org.escapek.server.core, Bundle-Version=0.1.0.SNAPSHOT}

This works fine, the org.escapek.server.core.event.IServerEventPublishe r service is published.
No i'd like to use this service and inject it as a reference in a bean of the same bundle. I could inject the bean directly, but by injecting the service reference I will be able to move the bean later if I wish. To do so I add :

	<reference id="ServerEventPublisher" 
		interface="org.escapek.server.core.event.IServerEventPublisher" />

to declare the reference. Now the extender says :

2008-07-29 18:05:28,284 [OSGi Console] INFO  o.s.o.e.s.DefaultOsgiApplicationContextCreator:67 - Discovered configurations {osgibundle:/META-INF/spring/*.xml} in bundle [org.escapek.server.core (org.escapek.server.core;singleton:=true)]

osgi> 2008-07-29 18:05:30,347 [SpringOsgiExtenderThread-21] INFO  o.s.o.c.support.OsgiBundleXmlApplicationContext:412 - Refreshing org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext@9fe666: display name [OsgiBundleXmlApplicationContext(bundle=org.escapek.server.core, config=osgibundle:/META-INF/spring/*.xml)]; startup date [Tue Jul 29 18:05:30 CEST 2008]; root of context hierarchy
2008-07-29 18:05:30,347 [SpringOsgiExtenderThread-21] INFO  o.s.beans.factory.xml.XmlBeanDefinitionReader:323 - Loading XML bean definitions from URL [bundleentry://1403/META-INF/spring/bundle-context-osgi.xml]
2008-07-29 18:05:30,397 [SpringOsgiExtenderThread-21] INFO  o.s.beans.factory.xml.XmlBeanDefinitionReader:323 - Loading XML bean definitions from URL [bundleentry://1403/META-INF/spring/bundle-context.xml]
2008-07-29 18:05:30,447 [SpringOsgiExtenderThread-21] INFO  o.s.o.c.support.OsgiBundleXmlApplicationContext:427 - Bean factory for application context [org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext@9fe666]: org.springframework.beans.factory.support.DefaultListableBeanFactory@2110fc
2008-07-29 18:05:30,537 [SpringOsgiExtenderThread-21] INFO  o.s.o.e.i.d.startup.DependencyServiceManager:249 - Adding OSGi service dependency for importer [&ServerEventPublisher] matching OSGi filter [(objectClass=org.escapek.server.core.event.IServerEventPublisher)]
2008-07-29 18:05:30,828 [SpringOsgiExtenderThread-21] INFO  o.s.o.e.i.d.startup.DependencyServiceManager:267 - OsgiBundleXmlApplicationContext(bundle=org.escapek.server.core, config=osgibundle:/META-INF/spring/*.xml) is waiting for unsatisfied dependencies [[&ServerEventPublisher]]

It seems that some dependency are unsatisfied. What's the reason why ? I've only added a reference to a declared service (which was published before the reference was added). I don't see why there's is this unsatisfied dependency...

[Costin Leau]

Importing services exported by the same bundle is unsupported. The main reason is supporting mandatory dependencies - a mandatory dependency cannot be satisfied if the service is not available however, since the imports are the first one to run, the target service is not going to be exported since the importer is not satisfied.
You have a nasty cycle which isn't easy to break - additionally, from a functional point of view, things could be simplified.
My advice is to simply inject the bean - when you 'split' your bundle you can simply keep the wiring but add the bean definition as a service import rather then a class description.

[Nico]

My advice is to simply inject the bean - when you 'split' your bundle you can simply keep the wiring but add the bean definition as a service import rather then a class description.

That's what I've actually done to workaround. Thanks for the explanations.

[jmcginn]

Note: I also have gotten this to work by making the service dependencies not mandatory (use the cardinality attribute 0..1 or 0..N). I wasn't able to use the beans in my situation becuase I had the scenario of a list of services that could dynamically grow or shrink during runtime.

However "optional" depdendencies may not satisfy your requirements either.