Enhancement Request: Pointing Spring dm Server to a hybrid maven repo

[scotthamilton77]

Context: using the Spring dm Server 1.0.2 SR02.

For the convenience of development (and possibly for deployment in production, but this isn't thought thru yet), we're thinking of ways to make the transitive dependencies for our projects easier to get to the Spring dm Server.

Right now we configure the server to also point to a location where we copy the dependencies to during our maven build, but this is an extra step that also complicates the maven-eclipse integration. (It's doable, but non ideal.)

We saw there is the possibility to point the server to a local maven repo using the ** wildcard pattern in the configuration, so we tried that, pointing it to our development environment local repo location. It's a great idea, but...

...our maven repo is used for many projects, and thus there is a mix of bundle and regular jars in the repo. Spring dm Server gets to the first jar that isn't an osgi bundle and fails to initialize with an error that the manifest is corrupt.

So this is kind of an enhancement request if not a "tell me the secret to make this work" .

It would be great if there was a way to point the server to a location that might have some non-osgi JARs and, even if the server threw a WARNING into the log, at least it didn't die and continued to search the remaining path(s) for osgi bundles.

For a maven-based development environment, this would seem to be a sweet deal and (hopefully) would not be too hard to implement and, if perhaps made a configurable behavior of the server, would not threaten an intended production behavior where you might want the stricter "absolutely no plain old jars" in the bundle repository paths.

Can it be done?

[Andy Wilkinson]

Hi Scott. This should work in 1.0, and does work in 2.0 (unless something's regressed very recently). Could you raise a JIRA, please? Then we can verify that it does indeed work in 2.0 and consider fixing it in 1.0.

[scotthamilton77]

Hi Scott. This should work in 1.0, and does work in 2.0 (unless something's regressed very recently). Could you raise a JIRA, please? Then we can verify that it does indeed work in 2.0 and consider fixing it in 1.0.

Thanks, Andy. Before I raise a JIRA, let me see if this sounds right to you.

I purged my repo and was not able to reproduce the problem, so I'm willing to hold off on the original possible bug until I see it again - let's call it a corrupt JAR until further info says that's not the problem.

Now, however, I have another problem - that with the introduction of a commons-codec in my maven repo, I get the following exception on spring dm server (1.0.2.SR02):

[2009-10-13 17:45:15.789] main                     <SPKB0002E> Start failed:
com.springsource.server.osgi.framework.OsgiFrameworkException: Error installing fragment from 'R:\bin\springsource\dm-server-1.0.2.SR02\repository\bundles\subsystems\com.springsource.server.kernel\com.springsource.server.kernel.dm-1.0.2.SR02.jar' for bundle 'org.springframework.osgi.extender'
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.resolveFragments(EquinoxBundleInstaller.java:179)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.doInstallBundleInternal(EquinoxBundleInstaller.java:149)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.doInstallBundle(EquinoxBundleInstaller.java:105)
	at com.springsource.server.osgi.framework.support.AbstractBundleInstaller.installBundleFromLocation(AbstractBundleInstaller.java:170)
	at com.springsource.server.osgi.framework.support.AbstractBundleInstaller.installBundleFromDefinition(AbstractBundleInstaller.java:242)
	at com.springsource.server.osgi.framework.support.AbstractBundleInstaller.installBundle(AbstractBundleInstaller.java:137)
	at com.springsource.server.osgi.framework.support.AbstractBundleInstaller.installBundle(AbstractBundleInstaller.java:109)
	at com.springsource.server.kernel.bootstrap.KernelBootstrap.start(KernelBootstrap.java:73)
	at com.springsource.server.kernel.bootstrap.Bootstrap.main(Bootstrap.java:73)
Caused by: org.eclipse.osgi.framework.internal.core.Framework$DuplicateBundleException: Bundle "org.apache.commons.codec" version "1.3.0.v20080530-1600" has already been installed from: file:///R:\repository\org\eclipse\birt\org.apache.commons.codec_1.3.0.v20080530-1600\2.3\org.apache.commons.codec_1.3.0.v20080530-1600-2.3.jar
	at org.eclipse.osgi.framework.internal.core.Framework.createAndVerifyBundle(Framework.java:700)
	at org.eclipse.osgi.framework.internal.core.Framework.installWorkerPrivileged(Framework.java:939)
	at org.eclipse.osgi.framework.internal.core.Framework$1.run(Framework.java:824)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.Framework.installWorker(Framework.java:905)
	at org.eclipse.osgi.framework.internal.core.Framework.installBundle(Framework.java:819)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.installBundle(BundleContextImpl.java:215)
	at com.springsource.server.osgi.framework.equinox.BundleContextWrapper.installBundle(BundleContextWrapper.java:199)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.doInstallBundleInternal(EquinoxBundleInstaller.java:145)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.satisfyConstraints(EquinoxBundleInstaller.java:237)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.doInstallBundleInternal(EquinoxBundleInstaller.java:157)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.satisfyConstraints(EquinoxBundleInstaller.java:237)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.doInstallBundleInternal(EquinoxBundleInstaller.java:157)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.satisfyConstraints(EquinoxBundleInstaller.java:237)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.doInstallBundleInternal(EquinoxBundleInstaller.java:157)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.satisfyConstraints(EquinoxBundleInstaller.java:265)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.doInstallBundleInternal(EquinoxBundleInstaller.java:157)
	at com.springsource.server.osgi.framework.equinox.EquinoxBundleInstaller.resolveFragments(EquinoxBundleInstaller.java:177)
	... 8 more

My server.config has the following. The R:/repository line is the one I am inserting into the search path, obviously. My question is: shouldn't the search precedence below then indicate that the server should find anything it needs from its own subsystems first before using a similar bundle provided from my repository?

	"provisioning" : {
	    "searchPaths": [
	        "repository/bundles/subsystems/{name}/{bundle}.jar",
	        "repository/bundles/ext/{bundle}",
	        "R:/repository/**/{bundle}.jar",
	        "repository/libraries/ext/{library}",
	        "repository/libraries/usr/{library}"
	    ]
	},

[Andy Wilkinson]

There's definitely a bug here. Once a bundle's been installed, the constraint satisfaction algortithm should not make an attempt to install it again. This should hold true irrespective of any ordering in the provisioning configuration. It would be great if you could open a JIRA for this. If your Maven repo's not too big, and doesn't contain anything confidential, would it be possible to zip it up and attach it to the issue? It would be a big help in reproducing the problem.

Thanks,
Andy

[scotthamilton77]

JIRA created, thanks. Let me know if more information is needed.

https://issuetracker.springsource.com/browse/DMS-1738

[Andy Wilkinson]

Thanks, Scott.