RC1 Weirdness

[tysgodhi]

I've got two apps running in production on dmServer 1.0.2.SR02. To test 2.0.0.RC1, I copied all my bundles from /bundles/usr to /usr, changed the imports to the new Spring library, and ran the apps in STS. One runs and the other doesn't. It had an error:

An Import-Package could not be resolved. Caused by missing constraint in bundle <com.springsource.org.apache.xbean.spring_3.3.0>
constraint: <Import-Package: org.springframework.beans; version="[2.5.4.A,3.0.0)">

that went away when I removed the 3.3.0 version of xbean.spring and replaced it with the 3.6.0 version. The system is apparently treating 3.0.0.RELEASE as subsequent to 3.0.0. The other error is:

Uses violation: <Import-Package: org.springframework.mock.staticmock; version="0.0.0"> in bundle <[my app bundle]>
Uses conflict reported, but no conflicts detected.
. com.springsource.kernel.osgi.framework.UnableToSat isfyBundleDependenciesException: Unable to satisfy dependencies of bundle '[my app bundle]' at version '1.3.0': Cannot resolve: [my app]
Resolver report:
Uses violation: <Import-Package: org.springframework.mock.staticmock; version="0.0.0"> in bundle <[my app bundle]>
Uses conflict reported, but no conflicts detected.

What does this mean, and what the heck is "org.springframework.mock.staticmock?" I don't use anything like that in the app.

Also, RC1 is way, way, way slower starting up than 1.0.2.SR02, so no upgrades for The Kid at this point in time!

In a general sense, I really like the idea of putting the dependencies in the container rather than each of the apps, but it sure is a challenge getting stuff like Hibernate, ActiveMQ, JAXB and JAX-WS to play nicely in the same container with all their dependencies, so that sort of imposes limits.

[Glyn Normington]

I've got two apps running in production on dmServer 1.0.2.SR02. To test 2.0.0.RC1, I copied all my bundles from /bundles/usr to /usr, changed the imports to the new Spring library, and ran the apps in STS. One runs and the other doesn't. It had an error:

An Import-Package could not be resolved. Caused by missing constraint in bundle <com.springsource.org.apache.xbean.spring_3.3.0>
constraint: <Import-Package: org.springframework.beans; version="[2.5.4.A,3.0.0)">

that went away when I removed the 3.3.0 version of xbean.spring and replaced it with the 3.6.0 version. The system is apparently treating 3.0.0.RELEASE as subsequent to 3.0.0.

That's correct OSGi semantics. The version range [2.5.4.A,3.0.0) excludes 3.0.0 (as well as 3.0.0.RELEASE etc.).

The other error is:

Uses violation: <Import-Package: org.springframework.mock.staticmock; version="0.0.0"> in bundle <[my app bundle]>
Uses conflict reported, but no conflicts detected.
. com.springsource.kernel.osgi.framework.UnableToSat isfyBundleDependenciesException: Unable to satisfy dependencies of bundle '[my app bundle]' at version '1.3.0': Cannot resolve: [my app]
Resolver report:
Uses violation: <Import-Package: org.springframework.mock.staticmock; version="0.0.0"> in bundle <[my app bundle]>
Uses conflict reported, but no conflicts detected.

What does this mean, and what the heck is "org.springframework.mock.staticmock?" I don't use anything like that in the app.

This is a known problem. Please see DMS-2260 for a workaround.

Also, RC1 is way, way, way slower starting up than 1.0.2.SR02, so no upgrades for The Kid at this point in time!

You may care to raise an issue detailing your environment and the timings you are seeing as well as what forces you to restart dm Server.

In a general sense, I really like the idea of putting the dependencies in the container rather than each of the apps, but it sure is a challenge getting stuff like Hibernate, ActiveMQ, JAXB and JAX-WS to play nicely in the same container with all their dependencies, so that sort of imposes limits.

If you wanted to, you could include some of those dependencies in a scoped plan along with the application which would reduce the amount of sharing and the associated constraints. But you'd have to pay attention to the meaning of scoping in order to choose plans that would resolve ok. In particular, packages exported inside a scoped plan cannot be imported from outside.

[tysgodhi]

DMS-2260 solved the "staticmock" problem. I now have an ActiveMQ dependency problem because I had to move from v.5.1 to 5.3, and I will try a scoped plan. Thanks for your help!

[tysgodhi]

One question on scoped plans. If I limit the scope to just the plan (scoped="false"? scoped="true"?) and include the dependency bundles in the plan, then those bundles shouldn't create conflicts for other apps outside the plan. But, if I expose services in the scoped plan through the OSGi services registry, are those services available to apps outside the plan?

[Glyn Normington]

No, services are scoped too.

BTW you can improve the startup speed of dm Server 2.0 a little by deleting the hosted repository application from the pickup directory if the server instance does not need to host a repository (for another server to use as a remote repository).

[tysgodhi]

Well, my original idea had been to separate bundles doing JMS, database persistence and web services in order to provide those services to one another but have their own upgrade and maintenance paths. If they can't expose their services across scopes, then I can't scope. So, I'll probably aim for two out of three, and put the dependencies for the JMS bundle in MODULE-INF/WEB-INF/lib. Thanks!

[Glyn Normington]

If they can't expose their services across scopes, then I can't scope.

You can make a service punch through a scope so it is visible in the global scope and other scopes by adding the service property, e.g.:

<service id="publishIntoGlobal" interface="java.lang.CharSequence">
		<service-properties>
			<beans:entry key="com.springsource.service.scope" value="global" />
		</service-properties>
		<beans:bean class="java.lang.String">
			<beans:constructor-arg value="foo"/>
		</beans:bean>
</service>

[tysgodhi]

Wonderful! Thanks!