Comments on: OSGi at LinkedIn: Integrating Spring DM (Part 1) http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/ The corporate blog of LinkedIn, the world's largest professional networking site. Sat, 12 Dec 2009 02:37:13 +0000 http://wordpress.com/ hourly 1 By: The LinkedIn Blog » Blog Archive OSGi at LinkedIn - Bundle repositories « http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-6555 The LinkedIn Blog » Blog Archive OSGi at LinkedIn - Bundle repositories « Tue, 17 Feb 2009 23:01:31 +0000 http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-6555 [...] check out part 1 and part 2 in Yan’s overview of OSGi at [...] [...] check out part 1 and part 2 in Yan’s overview of OSGi at [...]

]]> By: Agustín Ramos http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-2550 Agustín Ramos Mon, 21 Jul 2008 18:44:58 +0000 http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-2550 Yan Thank you very much for this informative post. I´m pretty sure you've got some time to think about how to scale OSGi through clustering or something like that. Would you share your thoughts with us? Cheers, Agustín Ramos certum Yan

Thank you very much for this informative post. I´m pretty sure you’ve got some time to think about how to scale OSGi through clustering or something like that. Would you share your thoughts with us?
Cheers,
Agustín Ramos
certum

]]> By: Costin Leau http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-2549 Costin Leau Mon, 30 Jun 2008 09:04:27 +0000 http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-2549 Hi Yan, Thanks for the post on Spring-DM. Regarding the race condition you mentioned, I've raised an issue for it in our bug tracker: http://jira.springframework.org/browse/OSGI-551 (I haven't found any previous reports on it). To clarify a bit the case, Spring-DM extender registers the namespace handlers when bundles are resolved. The namespace get used when bundles are started so the race condition should occur only if bundle B2 gets resolved _and_ started before B1 gets resolved. From what I've seen, even though I can't find anything about this in the spec right now, most OSGi implementations will try to resolve bundles eagerly before starting any other bundles. I assume this happens so that cases such as DynamicImport properly work between reruns. Nevertheless, we could try to address this problem in Spring-DM itself. Note that one could enforce a relationship between the bundles through wiring in which case OSGi would handle the resolving order automatically. Let's continue the discussion about the race condition on the forum/jira. Cheers, Costin Leau Spring-DM Lead Hi Yan,

Thanks for the post on Spring-DM. Regarding the race condition you mentioned, I’ve raised an issue for it in our bug tracker: http://jira.springframework.org/browse/OSGI-551 (I haven’t found any previous reports on it).
To clarify a bit the case, Spring-DM extender registers the namespace handlers when bundles are resolved. The namespace get used when bundles are started so the race condition should occur only if bundle B2 gets resolved _and_ started before B1 gets resolved.
From what I’ve seen, even though I can’t find anything about this in the spec right now, most OSGi implementations will try to resolve bundles eagerly before starting any other bundles. I assume this happens so that cases such as DynamicImport properly work between reruns.
Nevertheless, we could try to address this problem in Spring-DM itself. Note that one could enforce a relationship between the bundles through wiring in which case OSGi would handle the resolving order automatically.

Let’s continue the discussion about the race condition on the forum/jira.

Cheers,
Costin Leau
Spring-DM Lead

]]> By: Yan Pujante http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-2548 Yan Pujante Tue, 24 Jun 2008 13:46:02 +0000 http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-2548 Damon, I am glad to hear that this kind of post is useful. The initiative of a more technical blog has been started very recently, but we are very commited to it now. In a very near future, there will be a separate blog from this one entirely dedicated to engineering posts! Damon, I am glad to hear that this kind of post is useful. The initiative of a more technical blog has been started very recently, but we are very commited to it now. In a very near future, there will be a separate blog from this one entirely dedicated to engineering posts!

]]> By: Damon Wilder Carr http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-2547 Damon Wilder Carr Tue, 24 Jun 2008 01:35:39 +0000 http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/#comment-2547 This is great that your sharing this critical information as it is scarce. It is quite obvious you have put a great deal of work, skill and passion into the technical aspect of LinkedIn, certainly something I had taken for granted (which shows how well it works!). I'd love to see a specific and on-going series of discussion just for your technical members, and if not already in existence perhaps a new LinkedIn group for sharing ideas? Kind Regards, Damon Wilder Carr http://damon.agilefactor.com/ This is great that your sharing this critical information as it is scarce. It is quite obvious you have put a great deal of work, skill and passion into the technical aspect of LinkedIn, certainly something I had taken for granted (which shows how well it works!).

I’d love to see a specific and on-going series of discussion just for your technical members, and if not already in existence perhaps a new LinkedIn group for sharing ideas?

Kind Regards,
Damon Wilder Carr
http://damon.agilefactor.com/

]]>