<osgi:set> problems

[ShadowR]

This is becoming a habit, sorry...

I've been trying to use dm Server and declarative services to provide an SPI, bundles present a service to a host bundle which has a selection mechanism and facade for the rest of the application.

I'm seeing:

Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'memberType' of bean class [org.springframework.osgi.service.importer.support.OsgiServiceCollectionProxyFactoryBean]: Bean property 'memberType' is not writable or has an invalid setter method. Does the parameter type of the setter match the return type of the getter?
	at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1012)
	at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:857)
	at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:76)
	at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:58)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1338)

trying to deploy the host bundle, before any services are added to it.

The OSGi context is thus:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi"
	xsi:schemaLocation="http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-2.0-m1.xsd
		http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">


	<osgi:set id="tldHandlers" interface="com.othellonames.orp.tld.TLDHandler" />

</beans>

I get this problem with no actual Java code in the bundle, just the context file... Any ideas?

[Glyn Normington]

This is very odd. Please could you capture a minimal test bundle that reproduces the problem. It should export the interface com.othellonames.orp.tld, otherwise you'll need a second bundle to export that. Then raise a JIRA issue and attach the bundle so we can take a look.

(Please note for the record that this example is using Spring DM and not Declarative Services.)

[ShadowR]

My mistake.

Please find attached by bundles (exported as is from STS 2.3.0 + dmTools nightly).

They fail either deployed individually or as part of a PAR.

[Glyn Normington]

Just took a quick look and the packages com.othellonames.orp.domain and com.othellonames.orp.exception are imported but not exported so the testcase does not look complete. Have I got that right?

Also if you could post binary JARs it would speed up reproducing the problem.

[ShadowR]

D'oh... yes...

Here you go; those bundles are just models and exceptions but you're right .

The new zip contains the exported binary bundles and an additional sources zip.

[Glyn Normington]

I'm afraid those bundles are far from minimal. I got:

[2010-02-10 09:32:10.625] fs-watcher <HD0003E> Hot re-deploy failed for file 'com.othellonames.orp.domain-1.0.0.jar'. com.springsource.kernel.deployer.core.DeploymentEx ception: Dependency satisfaction failed
at com.springsource.kernel.deployer.core.internal.Pip elinedApplicationDeployer.driveInstallPipeline(Pip elinedApplicationDeployer.java:280)
at com.springsource.kernel.deployer.core.internal.Pip elinedApplicationDeployer.doInstall(PipelinedAppli cationDeployer.java:160)
at com.springsource.kernel.deployer.core.internal.Pip elinedApplicationDeployer.install(PipelinedApplica tionDeployer.java:132)
at com.springsource.kernel.deployer.core.internal.Pip elinedApplicationDeployer.deploy(PipelinedApplicat ionDeployer.java:196)
at com.springsource.kernel.deployer.hot.HotDeployment FileSystemListener.deploy(HotDeploymentFileSystemL istener.java:185)
at com.springsource.kernel.deployer.hot.HotDeployment FileSystemListener.onChange(HotDeploymentFileSyste mListener.java:92)
at com.springsource.util.io.FileSystemChecker.notifyL isteners(FileSystemChecker.java:182)
at com.springsource.util.io.FileSystemChecker.check(F ileSystemChecker.java:145)
at com.springsource.kernel.deployer.hot.WatchTask.run (WatchTask.java:69)
at java.lang.Thread.run(Thread.java:637)
Caused by: com.springsource.kernel.osgi.framework.UnableToSat isfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'com.othellonames.orp.domain' at version '1.0.0': Cannot resolve: com.othellonames.orp.domain
Resolver report:
An Import-Package could not be resolved. Caused by missing constraint in bundle <com.othellonames.orp.domain_1.0.0>
constraint: <Import-Package: org.hibernate.annotations; version="0.0.0">

at com.springsource.kernel.install.pipeline.stage.res olve.internal.QuasiResolveStage.process(QuasiResol veStage.java:54)
at com.springsource.kernel.install.pipeline.internal. StandardPipeline.doProcessTree(StandardPipeline.ja va:71)
at com.springsource.kernel.install.pipeline.internal. CompensatingPipeline.doProcessTree(CompensatingPip eline.java:81)
at com.springsource.kernel.install.pipeline.stage.Abs tractPipelineStage.process(AbstractPipelineStage.j ava:50)
at com.springsource.kernel.install.pipeline.internal. StandardPipeline.doProcessTree(StandardPipeline.ja va:71)
at com.springsource.kernel.install.pipeline.stage.Abs tractPipelineStage.process(AbstractPipelineStage.j ava:50)
at com.springsource.kernel.deployer.core.internal.Pip elinedApplicationDeployer.driveInstallPipeline(Pip elinedApplicationDeployer.java:277)
... 9 common frames omitted

Please would you strip the dependencies right down so the problem is isolated. The reason we ask people to do this is that often they solve their own problems in the process.

However, I did notice another problem and raised DMS-2318 to cover it.

[ShadowR]

Please would you strip the dependencies right down so the problem is isolated. The reason we ask people to do this is that often they solve their own problems in the process.

Erk, not doing very well at this am I...


OK, I've started a new Bundle from scratch and can't get it to fail. The console (correctly) just sits there saying waiting for service...

[Glyn Normington]

No problem. I'm glad you've got something that works. If you incrementally evolve it towards the failing system, the issue should stick out like a sort thumb when you make the incremental change that causes it to come back.

[ShadowR]

Unfortunately the test case bundle has no relation to the desired system...

OK I've thinned this out, and can get it to fail... Absolutely no idea why...

It fails within or without the PAR, but I've included it as it stops STS complaining about being unable to find the package or bundle.

[Glyn Normington]

Have you tried pointing at the schema version we normally use in dm Server? Instead of:

xsi:schemaLocation="http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-2.0-m1.xsd

use:

xsi:schemaLocation="http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi.xsd