Spring DM Bundle startup order problem?

[pumbers]

I've created a small blog application to test out Spring DM server. For now, I've created three bundles: resources (datasources, etc), core (domain model classes, DAO's and utility classes) and services (business logic). I'll be adding a fourth bundle, a web app which will use the services bundle to manage the blog.

I ran into the problem mentioned in thread 206103 (sorry, the forum won't let me post the url) around bundle package cross-references and followed the advice to create a par project referencing all three bundles. The referencing issue went away - but now I have another problem.

It seems that the startup order for the bundles is critical in that if I deploy them individually & manually in the correct order (resources, core, services) everything works fine. If I simply deploy the par project the resources bundle starts up OK but the other two bundles fail to deploy after timing out waiting for mandatory references from the first bundle.

The puzzling part is that if I telnet in to the container and check the first bundle, it has started correctly and all the required services appear to be registered. So, even if "resources" is the last bundle to start, why don't the other two bundles see the first and resolve their references?

I've had a similar problem exporting a transaction manager service from a bundle. Other bundles look for an instance of PlatformTransactionManager which never seems to resolve despite the fact that telnetting in to the container shows that the service is available under the specified interface.

I'm not sure whether this is related to the startup order of the bundles or is something class related (as I've only had the problem with certain classes/interfaces).

Any ideas anyone?

[Glyn Normington]

This behaviour is unexpected as dm Server installs all the bundles of a PAR before starting them and then uses Spring DM to "damp" the use of services (that is, wait for them) before they are published. So the start order of bundles in a PAR shouldn't matter.

I tried to look at the thread you mentioned, but I couldn't find it at URL:
http://forum.springframework.org/sho...d.php?t=206103. Please could you check the thread number?

It would be helpful if you could raise a JIRA issue to track this problem.

[pumbers]

That's what I figured - and it doesn't seem to happen for every exported service. In the bundles I mentioned above I export an EntityManager and TransactionManager; the Entitymanager is imported correctly by the second bundle, but the TransactionManager fails with this timeout problem. (at least as far as I can tell). I'll see if I can put together some sample bundles to demonstrate the problem and upload them later today.

The URL for the other thread is: /showthread.php?p=206103.

[Glyn Normington]

I'll see if I can put together some sample bundles to demonstrate the problem and upload them later today.

That would be very helpful. Thanks.

[pumbers]

I've attached a complete zip of the bundles for the sample project. There are four projects: blog (par), blog.resources, blog.core, blog.services. This is a "simpler" version of the project where I've temporarily removed the EntityManager & TransactionManager but the problem shows itself with the data source & DAO beans. Please be gentle if I'm making an obvious mistake - I'll still learning :-)

When I start the server with the par deployed, I get the messages:

Mandatory reference '&dataSource' in bundle 'blog-1-blog.core' version '1.0.0' is waiting for service with filter '(&(objectClass=javax.sql.DataSource)(!(com.spring source.server.app.name=*)))'.
[2008-10-21 07:49:17.671] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&postDao' in bundle 'blog-1-blog.services' version '1.0.0' is waiting for service with filter '(&(org.springframework.osgi.bean.name=postDao)(&( objectClass=blog.core.persistence.GenericDao)(!(co m.springsource.server.app.name=*))))'.

These repeat several times before the timeout and eventual failure to load the bundles. Checking the telnet console, I can see that blog.resources does export a javax.sql.DataSource:

Registered Services
{java.sql.Wrapper, javax.sql.CommonDataSource, javax.sql.DataSource}={org.springframework.osgi.be an.name=dataSource, Bundle-SymbolicName=blog-1-blog.resources, Bundle-Version=1.0.0, com.springsource.server.app.name=blog-1, service.id=107}

I'm assuming that the wait for the postDao service is because the DAO cannot be initialized until the DataSource is available, so that part of the message is a red herring. But, why is the blog.core bundle waiting for a DataSource when there's one available? Is this somehow related to the fact that there is a "com.springsource.server.app.name=*" filter element to the mandatory reference which is only there when I deploy the par?

So, now I remove the blog par from the server and start the server up with nothing deployed. Then I deploy the bundles manually one by one: resources, core, then services. This time, everything starts up OK. However, if I deploy all three bundles at the same time then start the server I get the same error messages as I do with the par deploy.

It looks like when I deploy the bundles manually and give each one time to start up before deploying the next, all work well. But, when I deploy all three simultaneously and let Spring try to resolve the dependencies, I get a problem.

Am I missing something, or mis-configuring something?

[Glyn Normington]

I tried reproducing your problem for half an hour but am still struggling to get the exact set of external dependencies. Please could you tell me which bundles at which versions you added to satisfy your application.

One thing to check: make sure you haven't accidentally deployed some of these bundles standalone before deploying the PAR. It looks on the face of it as if the PAR is looking for services outside the PAR that the application expects to be inside the PAR, although I'll be able to get further when I can reproduce the behaviour you are seeing.

[pumbers]

The attached text files list the contents of my repository/bundles/usr and repository/libraries/usr directories. Hopefully that'll give you the external dependencies (although they should be pretty limited: jpa, hibernate, commons dbcp and hsqldb basically).

In between deploys I "clean" the server from the eclipse server console and I can't see any sign of the blog bundles in between deploys sog I'm assuming the clean worked.

[Glyn Normington]

Thanks for your help in reproducing the problem. The behaviour you are seeing is due to a limitation in the way dm Server handles services published and consumed in a PAR in that it does not support the "auto-export" attribute.

If you are interested in this limitation being removed, please would you raise an issue on http://issuetracker.springsource.com pointing at this thread.

Meanwhile, you can work around the limitation by listing the interfaces explicitly using syntax like this:

<osgi:interfaces>
<value>com.xyz.MessageService</value>
<value>com.xyz.MarkerInterface</value>
</osgi:interfaces>

[pumbers]

Thanks Glyn, I've changed the application to explicitly declare the interfaces exported (v2 zip is attached), and it's certainly changed the problem a little but it hasn't fixed it.

The datasource exported from resources to core is now found correctly, but any services exported from core (transactionManager, entityManagerFactory and postDao) are not - same problem resolving mandatory references. It doesn't matter whether I deploy it as a par or as individual bundles.

I can't see what is different about the resources & core bundles that would cause them to export services differently, or for that matter the imports in core and services. Again, if you check the telnet console the services are being exported correctly under the specified interfaces, but Spring doesn't seem to be able to find them when it tries to wire-up the services bundle.

[Glyn Normington]

There seems to be a bug in the service scoping logic which surfaces with the particular style of <osgi:service> in v2. I converted to the more normal style and the PAR deployed successfully.

For instance, I replaced:

<osgi:service id="dataSourceService" ref="dataSource">
<osgi:interfaces>
<value>javax.sql.DataSource</value>
</osgi:interfaces>
</osgi:service>

with:

<osgi:service id="dataSourceService" ref="dataSource" interface="javax.sql.DataSource" />

We'll fix the bug in due course, but if you would like to track the fix, please raise an issue as discussed earlier in the thread.