[ https://issues.jboss.org/browse/FORGE-770?page=com.atlassian.jira.plugin.... ] George Gastaldi edited comment on FORGE-770 at 6/2/13 6:34 PM: --------------------------------------------------------------- Here are the comments from David Bosschaert about OSGi versioning: {quote} Let's say you have a component that wants to use the org.acme.Foo service. Let's say you have 2 versions of the Foo service in your system: // version 1.0 interface Foo { public void bar(); } // version 2.0 interface Foo { public void bar(); public void bar(int blah); } Each of the above would be in a separate module. If I want to use the bar(int) API I clearly need version 2.0 of the API. So such a client would import org.acme at version range [2.0, 3.0), so it has visibility of the correct API. When looking up services they are normally looked up by API name, so org.acme.Foo. If there is both an 1.0 and 2.0 service in the system, how do you pick the right one? How does the service registry decide which one to return? Since it knows the client that is requesting the service it will check whether the interface requested as visible by the client is the same one as the interface implemented by the service. If it is not the same then it is a different version of the interface and the service should not be returned to the client. If it is assignable then we're good and the client gets the service instance. This is how OSGi frameworks do it, and it's actually quite a simple process, as the Class.isAssignableFrom() API gives you the tool you need to do it :) If you want automated support for installing additional addons when required you really need some sort of a repository that has all the addons and exposes metadata about what they provide. Then you need a resolver that knows how to use this information and installs the addons on request. This is potentially a (very) large piece of work. Especially resolvers are complex and can take a lot of time to write. The OSGi Enterprise R5 spec [1] and [2] defines a Repository spec that can be used to catalogue your addons in a machine-readable way. Then, the OSGi Resolver spec (also in [1] and [2]) implements a general purpose resolver that can work with the Repository to install just the additional modules that you want. If you want to play with this stuff the Reference Implementations are available as opensource, see here for more details: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations I would think twice before implementing all this stuff, as it might seem simple when you start out but it could end up being more work than you think. OSGi implements all these things already. If you're inside AS8 then JBoss OSGi provides all this. If you are in a different environment you could simply use Apache Felix, which is about 500 kb and very embeddable. Cheers, David [1] http://www.osgi.org/Download/Release5 [2] http://www.osgi.org/javadoc/r5/enterprise/ {quote} was (Author: gastaldi): Here are the comments feom David Bosschaert about OSGi versioning: {quote} Let's say you have a component that wants to use the org.acme.Foo service. Let's say you have 2 versions of the Foo service in your system: // version 1.0 interface Foo { public void bar(); } // version 2.0 interface Foo { public void bar(); public void bar(int blah); } Each of the above would be in a separate module. If I want to use the bar(int) API I clearly need version 2.0 of the API. So such a client would import org.acme at version range [2.0, 3.0), so it has visibility of the correct API. When looking up services they are normally looked up by API name, so org.acme.Foo. If there is both an 1.0 and 2.0 service in the system, how do you pick the right one? How does the service registry decide which one to return? Since it knows the client that is requesting the service it will check whether the interface requested as visible by the client is the same one as the interface implemented by the service. If it is not the same then it is a different version of the interface and the service should not be returned to the client. If it is assignable then we're good and the client gets the service instance. This is how OSGi frameworks do it, and it's actually quite a simple process, as the Class.isAssignableFrom() API gives you the tool you need to do it :) If you want automated support for installing additional addons when required you really need some sort of a repository that has all the addons and exposes metadata about what they provide. Then you need a resolver that knows how to use this information and installs the addons on request. This is potentially a (very) large piece of work. Especially resolvers are complex and can take a lot of time to write. The OSGi Enterprise R5 spec [1] and [2] defines a Repository spec that can be used to catalogue your addons in a machine-readable way. Then, the OSGi Resolver spec (also in [1] and [2]) implements a general purpose resolver that can work with the Repository to install just the additional modules that you want. If you want to play with this stuff the Reference Implementations are available as opensource, see here for more details: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations I would think twice before implementing all this stuff, as it might seem simple when you start out but it could end up being more work than you think. OSGi implements all these things already. If you're inside AS8 then JBoss OSGi provides all this. If you are in a different environment you could simply use Apache Felix, which is about 500 kb and very embeddable. Cheers, David [1] http://www.osgi.org/Download/Release5 [2] http://www.osgi.org/javadoc/r5/enterprise/ {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira