Comments on: So what's the deal with Spring-OSGi? http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/ The voice of SpringSource Sun, 20 Jul 2008 22:37:24 +0000 http://wordpress.org/?v=2.0.11 by: Costin Leau http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-108611 Thu, 05 Jun 2008 11:34:15 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-108611 Berre, if you're looking for help try the Spring-DM forums or mailing list. Cheers, Berre, if you're looking for help try the Spring-DM forums or mailing list.
Cheers,

]]> by: Berre http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-107656 Tue, 27 May 2008 17:13:58 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-107656 Hi, I'm a real rookie when it comes to OSGi. But I've been reading A LOT about it :)- I've installed Equinox and all the spring bundles. I've even got a bundle working. But now I'm still facing some questions concerning the Import / Export / ... statements in the manifest. (currently I am trying to start a bundle that needs the ApplicationEvent of Spring, which is as I see it exported by the spring-context bundle that is started in my Equinox. I'm doing the import in my bundle but when I start it, I get a ClassNotFoundException) Could you help me? (maybe some docs about it, urls, ...) Hi,
I'm a real rookie when it comes to OSGi. But I've been reading A LOT about it :) - I've installed Equinox and all the spring bundles. I've even got a bundle working.

But now I'm still facing some questions concerning the Import / Export / … statements in the manifest. (currently I am trying to start a bundle that needs the ApplicationEvent of Spring, which is as I see it exported by the spring-context bundle that is started in my Equinox. I'm doing the import in my bundle but when I start it, I get a ClassNotFoundException)

Could you help me? (maybe some docs about it, urls, …)

]]> by: SpringSource Team Blog » Spring Dynamic Modules 1.0 is here http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-92576 Fri, 25 Jan 2008 15:58:29 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-92576 [...] A lot of features have been improved or added since my previous post (about 1.0 M1); I'll talk more about them in future entries (there is also the reference documentation that explains the library at length) so I'll just name a few: [...] […] A lot of features have been improved or added since my previous post (about 1.0 M1); I'll talk more about them in future entries (there is also the reference documentation that explains the library at length) so I'll just name a few: […]

]]> by: Eclipse Runtime and Spring « Codecurl - David Black http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-85052 Sat, 05 Jan 2008 14:53:02 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-85052 [...] post info By codecurl Categories: CapeDeveloper, Java and OSGi I’ve been watching with interest the moves towards a proposal for an Eclipse Runtime project, to focus efforts around Eclipse as a runtime platform, with Equinox/OSGi at its core. OSGi is the Java component specification on which the Eclipse platform is built. In fact, Equinox is the reference implementation for the OSGi R4.1 framework and JSR 291. The other work I’ve been following with interest is the Spring framework’s OSGi integration, namely Spring Dynamic Modules for OSGi Service Platforms. The combination of an Eclipse Runtime and Spring as a runtime platform has huge potential, and it is potential that can be realised and exploited today. Apart from the proven dynamic component model and advanced classloading capabilities of OSGi, and the rich development environment that Eclipse provides for it, and the productivity advantages of developing on the platform that is also your runtime, and the Spring framework as a whole, and the wonderful power and simplicity of inversion-of-control and dependency injection, one of the key use cases I keep coming back to when I think about this is hot service re-deployment, being able to update services other components are using without having to bounce the server and without those components missing a beat. In the always-needs-to-be-on, software-as-a-service cloud of the rapidly approaching future, this is a key business operations requirement. I agree with the assertion that the Java market will continue to fragment, but I think a lot of people will head in this direction. [...] […] post info By codecurl Categories: CapeDeveloper, Java and OSGi I've been watching with interest the moves towards a proposal for an Eclipse Runtime project, to focus efforts around Eclipse as a runtime platform, with Equinox/OSGi at its core. OSGi is the Java component specification on which the Eclipse platform is built. In fact, Equinox is the reference implementation for the OSGi R4.1 framework and JSR 291. The other work I've been following with interest is the Spring framework's OSGi integration, namely Spring Dynamic Modules for OSGi Service Platforms. The combination of an Eclipse Runtime and Spring as a runtime platform has huge potential, and it is potential that can be realised and exploited today. Apart from the proven dynamic component model and advanced classloading capabilities of OSGi, and the rich development environment that Eclipse provides for it, and the productivity advantages of developing on the platform that is also your runtime, and the Spring framework as a whole, and the wonderful power and simplicity of inversion-of-control and dependency injection, one of the key use cases I keep coming back to when I think about this is hot service re-deployment, being able to update services other components are using without having to bounce the server and without those components missing a beat. In the always-needs-to-be-on, software-as-a-service cloud of the rapidly approaching future, this is a key business operations requirement. I agree with the assertion that the Java market will continue to fragment, but I think a lot of people will head in this direction. […]

]]> by: Harrys http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-75467 Tue, 04 Dec 2007 08:30:44 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-75467 Nice... Nice…

]]> by: Herakles http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-75448 Tue, 04 Dec 2007 07:45:43 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-75448 Sorry :( Sorry :(

]]> by: Costin Leau http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-55216 Mon, 15 Oct 2007 16:41:26 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-55216 Hi Jerome, I glad you liked the entry - I plan to write a new one in the near future. About the compatibility - we chose to not use Spring 1.2 since there just way too many things that we depend on that we\'d have to backport otherwise. In fact, we\'ve asked for some features in Spring 2.5 which we\'ll in there, in the RC release. That and the OSGi-friendly, out-of-the-box artifacts are quite handy also. It should be possible to backport things back to 1.2 but that would be a quite an effort. I\'m not sure why you would want though since 2.1 is compatible with 1.2 and in many cases, requires just updating the jar. Moreover, if you\'re running inside an OSGi environment, you\'d have nothing to worry about since the platform deals with versioning for you. Cheers, Costin Hi Jerome,

I glad you liked the entry - I plan to write a new one in the near future.
About the compatibility - we chose to not use Spring 1.2 since there just way too many things that we depend on that we\'d have to backport otherwise. In fact, we\'ve asked for some features in Spring 2.5 which we\'ll in there, in the RC release.
That and the OSGi-friendly, out-of-the-box artifacts are quite handy also.
It should be possible to backport things back to 1.2 but that would be a quite an effort. I\'m not sure why you would want though since 2.1 is compatible with 1.2 and in many cases, requires just updating the jar. Moreover, if you\'re running inside an OSGi environment, you\'d have nothing to worry about since the platform deals with versioning for you.

Cheers,
Costin

]]> by: romje http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-55215 Mon, 15 Oct 2007 16:34:45 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-55215 Hi all, thanks costin for this quite interesting entry... I wondered about technical requirements for this project, as stated on the Website: spring 2.0.5 and JDK 1.4 , OSGir4...But I wondered about the opportunity to get a back port for this module into a Spring 1.2 environment ? Is it a great work ? I may understand (naively) that it's just a matter of ApplicationContext isn't it ? I'm obliged to used jdk 1.4 and Spring 1.2 for developing bundles (rcp application and osgi services) Cheers jerome Hi all,
thanks costin for this quite interesting entry…
I wondered about technical requirements for this project, as stated on the Website: spring 2.0.5 and JDK 1.4 , OSGir4…But I wondered about the opportunity to get a back port for this module into a Spring 1.2 environment ?
Is it a great work ? I may understand (naively) that it's just a matter of ApplicationContext isn't it ?

I'm obliged to used jdk 1.4 and Spring 1.2 for developing bundles (rcp application and osgi services)

Cheers
jerome

]]> by: Costin Leau http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-52733 Mon, 01 Oct 2007 18:29:26 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-52733 [quote comment="52689"]Hi Costin, I have two bundles with same running (Installed & Started) on OSGi but they are different versions (1.0 & 2.0), both bundles have register service with common interface on service registry. While getting the service from "Service Registry" how can we differentiate the version 1.0 from 2.0? They known way is use LDAP filter while getting service, but for this purpose we have to change code and update the bundle where I am getting service. Is there any other way we will specify we want the version 1.0 not 2.0, like using manifest file or XML file (Spring OSGi XML)??? Thanks, Shan.[/quote] What you need is sevice versioning. This is something that the OSGi specification doesn't cover (intentionally I think) since properties can support most versioning schema. We haven't added any support for this in Spring OSGi yet but we're likely to do that in the future. Feel free to discuss this on our mailing list and raise an issue on JIRA. Thanks, Costin [quote comment="52689"]Hi Costin,

I have two bundles with same running (Installed & Started) on OSGi but they are different versions (1.0 & 2.0), both bundles have register service with common interface on service registry.

While getting the service from "Service Registry" how can we differentiate the version 1.0 from 2.0?

They known way is use LDAP filter while getting service, but for this purpose we have to change code and update the bundle where I am getting service.

Is there any other way we will specify we want the version 1.0 not 2.0, like using manifest file or XML file (Spring OSGi XML)???

Thanks,
Shan.[/quote]

What you need is sevice versioning. This is something that the OSGi specification doesn't cover (intentionally I think) since properties can support most versioning schema.
We haven't added any support for this in Spring OSGi yet but we're likely to do that in the future. Feel free to discuss this on our mailing list and raise an issue on JIRA.

Thanks,
Costin

]]> by: Shan http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-52689 Mon, 01 Oct 2007 10:49:02 +0000 http://blog.springsource.com/main/2007/04/05/so-whats-the-deal-with-spring-osgi/#comment-52689 Hi Costin, I have two bundles with same running (Installed & Started) on OSGi but they are different versions (1.0 & 2.0), both bundles have register service with common interface on service registry. While getting the service from "Service Registry" how can we differentiate the version 1.0 from 2.0? They known way is use LDAP filter while getting service, but for this purpose we have to change code and update the bundle where I am getting service. Is there any other way we will specify we want the version 1.0 not 2.0, like using manifest file or XML file (Spring OSGi XML)??? Thanks, Shan. Hi Costin,

I have two bundles with same running (Installed & Started) on OSGi but they are different versions (1.0 & 2.0), both bundles have register service with common interface on service registry.

While getting the service from "Service Registry" how can we differentiate the version 1.0 from 2.0?

They known way is use LDAP filter while getting service, but for this purpose we have to change code and update the bundle where I am getting service.

Is there any other way we will specify we want the version 1.0 not 2.0, like using manifest file or XML file (Spring OSGi XML)???

Thanks,
Shan.

]]>